Howto "AT^SXRAT" (Cinterion specific)

Norbert van Bolhuis norbert.vanbolhuis at ev-box.com
Wed Feb 24 22:37:31 UTC 2021


Hi Giancinto,

Thanks for your answer!


On 2/24/21 4:47 PM, Giacinto Cifelli wrote:
> Hi Norbert, Aleksander,
> 
>>
>> Giacinto, added you in CC, in case you have some suggestion.
> 
> don't worry, I am following MM, libMbim, libQmi.
> 
>>
>>>
>>> We're using a Cinterion ELS61-E R2 and seem to suffer from a lot of
>>> "packet data disconnects" and cell/rat/MO switching.
> 
> Are you using the bare modem or on some datacard?
> Is the power supply good?
> And the antenna?
> Please ask your contact in Thales (or a reseller) if there is a more
> recent FW for your modem.  (I am part of Thales, too, but I am not
> deep into ELS61 and all its variants and options, so it would take
> more time to me to find out than for a more direct contact).
> 



Yeah, Thales supports us with the "packet data disconnects" and 
cell/rat/MO switching issues.
Let me be clear: about 95% of our systems have a proper working and 
stable LTE connection using the bare Cinterion ELS61-E R2 modem.
We're trying to draw a conclusion on the remaining 5%. It doesn't look 
like it simply is a "too weak signal case" although it might have 
something to do with it.

Thanks for your suggestions, we did plan to checkout the antenna (once 
more).
About the power supply, I guess you mean it has to be a single voltage 
source (for BATT+BB and BATT+RF) and must be able to provide the peak 
current. Or is there anything else you had in mind?



> These would be the main things to look at, to understand and fix the
> root cause, the rest below (in  which I am going to comment anyway),
> could be workarounds for special situations, but not the solution.
> 


That is quite an interesting and clear statement.
So what you're saying is that the many cell/rat/MO switching we see
cannot really be resolved by limiting the RAT?
Not even when the signal really is too weak or when we're near the 
2G<->3G or 3G<->4G RAT-switch-over threshold?


>>> We're advised to force the modem to use 3G/2G (or 4G/2G) Radio Access
>>> Technology with the AT^SXRAT command.
> 
> MM doesn't use (as of today) this command, so you are guaranteed that
> the modem will remember the settings.
> AT^SXRAT allows to set up to 3 preferences, which can also be
> combined.  I haven't tested on ELS61, but PLS62 should be the same.
> 
>>> We've been told the "AT+COPS=0" may reset SXRAT settings.
> 
> I have checked on the ATC, and indeed AT+COPS=,,,x (or AT+COPS=0) will
> change the preferences, as well as AT^SXRAT, and the last-sent will
> define the behavior.
> 
>>>
>>> I've tried to do this via:
>>> mmcli -m 0 --set-allowed-modes='2g|4g' --set-preferred-mode='4g'
>>>
>>> but it doesn't work and even if it would, I'm not sure this means the
>>> "AT^SXRAT" command alwaysf ollows "AT+COPS=0" nicely.
>>>
>>> I see no "AT^SXRAT" in the source code, so I guess "AT^SXRAT" is a
>>> Cinterion specific command that isn't supported yet.
>>>
>>> I do like to use the "AT^SXRAT" command.
>>>
>>> So I'd like to do a "AT^SXRAT" after each "AT+COPS=0". This involves
>>> changing modem_3gpp_register_in_network, is this the right thing to do?
>>>
>>> If not, how to best use the "AT^SXRAT" command?
>>>
>>
>> The Cinterion plugin currently uses AT+COPS also to configure access
>> technology; e.g. if 4G-only is requested, we would run AT+COPS=,,,7
>>
>> Does this COPS based logic to configure access tech not work in the
>> ELS61? Is ^SXRAT the only way to do that in the ELS61? If ^SXRAT is
>> the only way to do it, we could upgrade the Cinterion plugin to use
>> it. But I'm not sure that sending the SXRAT after each COPS would make
>> much sense; is there no other way to do that?
>>
>> Also, if COPS=0 resets the desired access tech, I wonder if the same
>> is currently happening with our already available COPS based access
>> tech selection logic.
> 
> AT^SXRAT could be used for Intel chipsets (ELS61, PLS62, ...), instead
> of the AT^SCFG="Radio/Band..." commands and/or AT+COPS=,,,x (and so in
> the --set-allowed-modes command)
> However AT+COPS=0 might be sent at startup if the modem reports +COPS:
> 2, and in this case it will start the registration/attach, but also
> reset the preferred technologies.
> 
> I don't really agree to append AT^SXRAT to AT+COPS, that would make
> the modem search twice in most of the cases, and I know that it is
> particularly slow on this chipset under some conditions.
> And so it would maybe solve a specific problem, but introduce others.
> 
> If you want a single tech, a better solution would be to track that in
> the code where AT+COPS=0 is sent and use AT+COPS=0,,,x instead.


It's only 
mm_iface_modem_3gpp_register_in_network->modem_3gpp_register_in_network
that sends "AT+COPS=0" (and factory_reset).
I'm not sure when modem_3gpp_register_in_network is called. In a quick
test where I let NetworkManager disconnect(DOWN) and connect(UP) the 
mobile connection it doesn't seem to be called (and so the one RAT that
was set with --set-allowed-modes was honored)

So SXRAT shouldn't follow COPS=0, OK. Then how to implement SXRAT
for combined RAT (preferences)?
I guess it is not "enough" to simply use SXRAT instead of COPS=,,,x in
the function: set_current_modes?


Regards,
Norbert



More information about the ModemManager-devel mailing list