Cinterion radio bands
Giacinto Cifelli
gciofono at gmail.com
Fri May 15 10:53:24 UTC 2020
Dear all,
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?
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...
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?
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?
Thank you for your comments.
regards,
Giacinto
More information about the ModemManager-devel
mailing list