Cinterion radio bands

[Aleksander Morgado]

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...

> 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 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?

> 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.

>
> Thank you for your comments.
>

Thank you for your help!

-- 
Aleksander
https://aleksander.es