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

_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

Reply via email to