Cinterion radio bands

Fri May 15 16:20:26 UTC 2020

Hey Aleksander,

thank you for your hints.

On Fri, May 15, 2020 at 1:49 PM Aleksander Morgado
<aleksander at aleksander.es> wrote:
>
> Hey!
>
> > I am trying to update the code for the Radio/Bands of Cinterion
> > modules, and it seems a nasty job, because of the way the indicators
> > evolved.
> > Today in the code there is a parser for this format (only for the test part):
> > AT^SCFG=?
> >         ...
> >         ^SCFG: "Radio/Band",("1-479","0-1")
> >         ...
> >
> > where all the bands for 2G+3G fit in an unsigned integer on 32 bits,
> > ie, the value 511 above.
> > The format is decimal, but the interpretation is a bitmap.
> > This is done well in the current code and works well.
> > One possible flaw is that the detection of the charset is not perfect,
> > but the above output is invariant also when UCS2 is used.
> >
> > When we go to LTE, however, the 32 bits are not enough to host all
> > bands, and so it was decided to split the command by technologies.
> > In these implementations there are some divergences.
> > For instance, the PLS62 reports:
> > under GSM charset:
> > AT^SCFG=?
> >      ...
> >      ^SCFG: "Radio/Band/2G",("0x00000004"-"0x00000074")
> >      ^SCFG: "Radio/Band/3G",("0x00000001"-"0x0004019B")
> >      ^SCFG: "Radio/Band/4G",("0x00000001"-"0x080E08DF")
> >      ...
> > and under UCS2 charset:
> >    AT^SCFG=?
> >      ...
> >      ^SCFG: "Radio/Band/2G",("0030007800300030003000300030003000300034"-"0030007800300030003000300030003000370034")
> >      ^SCFG: "Radio/Band/3G",("0030007800300030003000300030003000300031"-"0030007800300030003000340030003100390042")
> >      ^SCFG: "Radio/Band/4G",("0030007800300030003000300030003000300031"-"0030007800300038003000450030003800440046")
> >      ...
> >
> > While the PLPS9 reports (invariant under charset change):
> >      ...
> >      ^SCFG: "Radio/Band/2G",("00000001-0000000f"),,("0","1")
> >      ^SCFG: "Radio/Band/3G",("00000001-000400b5"),,("0","1")
> >      ^SCFG: "Radio/Band/4G",("00000001-8a0e00d5"),("00000002-000001e2"),("0","1")
> >
> >                note also the second range for the LTE bands >32
> >      ...
> >
> > My idea is to parse first the old format, then the newer one. I have a
> > regular expression that works well for all 3 formats for the
> > Radio/Band/xG syntax.
> > Q1: Do you think this strategy is ok?
> >
>
> It probably is, yes. The fact that the modem manufacturers don't
> usually keep the same AT command reference for all their devices is
> extremely annoying as you just found out...

Oh well, for this one the fault is the lack of crystal ball :)
I don't think they imagined once they launched 3G that they needed
more than 32 bands, and the prediction even hold for quite some time
for LTE.
About the inconsistency of point 3 below, this is disappointing
indeed, but it happens sometime when there are more groups working on
different projects in parallel.
And once a product or a feature is on the field, it is quite
impossible to come back. This would put off the current users of that
feature that have perhaps adapted their applications.

>
> > To determine the charset, I use some heuristics on string length and
> > prefix (0x aka 00300078). Note also that a model returns lowercase
> > hexa while another uppercase...
>
> Isn't mm_broadband_modem_get_current_charset () not returning the
> correct thing? I would definitely avoid doing heuristics to detect
> charset if possible.

the plugins/cinterion/mm-broadband-modem-cinterion.c call is:
        !mm_cinterion_parse_scfg_test (response,
                                       g_task_get_source_object (task),
                                       mm_base_modem_get_product_id (_self),

mm_broadband_modem_get_current_charset (MM_BROADBAND_MODEM (self)),
                                       &bands,
                                       &error))

and so mm_broadband_modem_get_current_charset returns MM_MODEM_CHARSET_UNKNOWN.
I am not really surprised because I see no call to AT+CSCS? on the code.
The only time it is called is after setting it, and it looks like it
requires a dbus input, and therefore can only happen after the modem
is detected.
Unfortunately the call above happens during the modem detection phase.

one fix could be sending the line
    AT+CSCS="GSM"
in the initialization, along with other test commands like AT*CNTI=2?

In any case, I do need to check whether I have "0x" at the beginning
of the string (because not all formats have it), and so checking also
for 00300078 (the corresponding UCS2 coding) is not a big issue.

>
> > The charset transformation with mm_charset_take_and_convert_to_utf8()
> > seems to work well only with MM_MODEM_CHARSET_UCS2, which is ok
> > because it is the only conversion needed.
> > Q2: Is there a better way?
> >
>
> If the modem is configured for UCS2,
> mm_broadband_modem_get_current_charset() should return
> MM_MODEM_CHARSET_UCS2. Would not that be enough? Is that not the case?

that would indeed be enough, and no, it is not the case.

>
> > And finally, the main question: please notice above that the PLS62
> > range (and modules in this family) for GSM is different than from any
> > other module:
> >     0x00000004, MM_MODEM_BAND_EGSM
> >     0x00000010, MM_MODEM_BAND_DCS
> >     0x00000020, MM_MODEM_BAND_PCS
> >     0x00000040, MM_MODEM_BAND_G850
> >
> > I am thinking about passing the USB pid to the fuction, since I can't
> > find an internal way to discriminate here (for the
> > mm_cinterion_parse_scfg_test() could be possible, but not for the
> > mm_cinterion_parse_scfg_response(): in case the current GSM band is
> > '4', would be 900MHz for the PLS62, and 850 for all others).
> > Is there another way?
>
> You could use the already available
> mm_kernel_device_get_physdev_pid(), but for this specific case I would
> probably use a different way to handle it. Instead of hardcoding the
> PID check in the code, you could use a udev tag to tag the PLS62 and
> then use that in the code. See the usage of ID_MM_TELIT_BND_ALTERNATE
> in the code for a very similar case in telit modems.

looks perfect, I will do this way.
I have anyway a newer udev rule for the PLS62 enumeration (005b), that
cuts short the check for AT ports.

>
> >
> > Thank you for your comments.
> >
>
> Thank you for your help!
>
> --
> Aleksander
> https://aleksander.es

Thanks again,
Giacinto