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