PLS8-E: wrong index range in <indDescr> field in +CIEV URCs | Telit Cinterion IoT Developer Community
June 11, 2019 - 6:36pm, 7861 views
Working with a PLS8-E, firmware version REVISION 03.017.
The indicator settings reported in AT+CIND=? are as follows:
+CIND: ("battchg",(0-5)),("signal",(0-5)),("service",(0-1)),("call",(0-1)),("roam",(0-1)),("smsfull",(0-1)),("GPRS coverage",(0-1)),("callsetup",(0-3))
There are 8 values reported, so the expected <ind> values in +CIEV URCs are from 1 (battchg) to 8 (callsetup).
The +CIEV URCs in the PLS8 have the expected format as per 3GPP TS 27.007:
+CIEV: <indDescr>, <indValue>
But, the problem is that it looks like the PLS8 uses indices 0 to 7 instead of 1 to 8 for the +CIEV URCs, so e.g. when a voice call is accepted +CIEV: 7,0 is received to report that call setup is finished (should have been 8,0) and +CIEV: 3,1 to report that call is ongoing (should have been 4,1). Some real logs from interacting with the PLS8-E:
(ttyACM1): --> 'ATA<CR>'
(ttyACM1): <-- '<CR><LF>OK<CR>
(ttyACM1): <-- '<CR><LF>+CIEV: 7,0<CR><LF><CR><LF>+CIEV: 3,1<CR><LF>'
Is this a known issue with the PLS8?
Is this a known issue with Gemalto/Cinterion modules in general?
While I haven't found an explicit reference to what the range should be for <indDescr> in 3GPP TS 27.007, I did find an example in that document where the start at 1 is implicit (3GPP TS 27.007 V16.0.0 (2019-03) page 221):
AT+CIND=?
+CIND: ("memory",(0-2)),("call",(0,1)),("data",(0,1)),("roam",(0,1)),("alpha",(0,1)),("message",(0,1)),("index1",(0-11)),("index2",(0-11)),("index3",(0-11)),("signal",(0-5)),("service",(0,1)),("sel1",(0,1)),("sel2",(0,1)),("sel3",(0,1)),("battchg",(0-5))
+CIND: 10,5 <--- this is "signal" indicator, the 10th in the list so <indDescr> starts at 1 in the spec.
Thanks!
Hello,
I can't see AT+CIND command in the AT commands specification document for PLS8-E module. Can you specify the document version? There's AT^SIND command which is not 3GPP standard command. It can be used to configure (+CIEV:) URC's. With this command I can get URC's like in the example below:
+CIEV: call,1
NO CARRIER
+CIEV: call,0
I have used rev4 module for this test.
Could you give the complete example how you configure and get the mentioned URC's?
You are right that for AT+CIND command it is not directly specified in 3GPP document how the values retirned by URC should be indexed. At the same time in the example they seem to be indexed from 1. But still the document describes +CIND URC.
Best regards,
Bartłomiej
Hey Bartłomiej
The configuration is pretty basic. Using ModemManager here, which tries to match the expected <indDescr> numeric values. MM expects the indices starting at 1, as that is the case for all previous ****ms used to implement this logic.
First the logic checks which indicators are supported with +CIND=?:
(ttyACM1): --> 'AT+CIND=?<CR>'
(ttyACM1): <-- '<CR><LF>+CIND: ("battchg",(0-5)),("signal",(0-5)),("service",(0-1)),("call",(0-1)),("roam",(0-1)),("smsfull",(0-1)),("GPRS coverage",(0-1)),("callsetup",(0-3))<CR><LF><CR><LF>OK<CR><LF>'
Modem supports signal quality indications via CIND at index '2'(min: 0, ***: 5)
Modem supports roaming indications via CIND at index '5'
Modem supports service indications via CIND at index '3'
Then the logic checks which are the supported settings in CMER=?:
(ttyACM1): --> 'AT+CMER=?<CR>'
(ttyACM1): <-- '<CR><LF>+CMER: (0-3),(0),(0),(0-1),(0-1)<CR><LF><CR><LF>OK<CR><LF>'
Supported +CMER *****: discard-urcs, discard-urcs-if-link-reserved, buffer-urcs-if-link-reserved, forward-urcs
Supported +CMER indication settings: disable, enable-not-caused-by-cind
+CMER enable ****: forward-urcs
+CMER disable ****: discard-urcs
+CMER indication setting: enable-not-caused-by-cind
And then it configures +CMER settings on the ttyACM port:
(ttyACM1): --> 'AT+CMER=3,0,0,1<CR>'
(ttyACM1): <-- '<CR><LF>OK<CR><LF>'
After that, the logic just processes the +CIEV URCs as they're received, with the format specific by 3GPP TS 27.007; i.e.:
+CIEV: <indDescr>,<indValue>
(being <indDescr> the index of the indicator in +CIND=?)
ModemManager also uses AT^SIND for a couple of settings as well (e.g. to enable "psinfo" +CIEV reporting).
(ttyACM1): --> 'AT^SIND="psinfo",1<CR>'
(ttyACM1): <-- '<CR><LF>^SIND: psinfo,1,0<CR><LF><CR><LF>OK<CR><LF>'
The AT command spec of the PLS8-E that I have with me (v01.000 date June 2103) does not make any reference to AT+CIND. It does make reference to the Cinterion-specific AT^SIND, but the reference doesn't report either "call" or "callsetup" indicators as supported by AT^SIND (while they are supported by +CIND).
I'm really not sure how should I get "call" or "callsetup" indicator updates if not using the standard +CIND, is there any Cinterion-specific command for that?
Small update here. Even if the PLS8-E reference I have doesn't include "call" and "callsetup" indicators in AT^SIND, I do see at least "call" supported by AT^SIND, but no "callsetup":
$ sudo mmcli -m 0 --command="AT^SIND=?"
response: '^SIND: ((signal,(99)),(service,(0-1)),(sounder,(0-1)),(message,(0-1)),(call,(0-1)),(roam,(0-1)),(smsfull,(0-1)),(audio,(0-1)),(simstatus,(0,1,3-5)),(simdata,(0-1)),(eons,(0-5)),(nitz,(0-1)),(sendsms,(0-1)),(psinfo,(0-10,16,17)),(simlocal,(0-1)),(lsta,(0-1)),(pacsp,(0-1,99)),(steerroam,(0-1)),(pagingcoor,(0-16)),(ceer,(0-8,99)),(iccid,(0-1)),(euiccid,(0-1)),(imsi,(0-1)),(is_cert,(0-1)),(newsms,(0-1)),(voiceprompt,(0-1)),(ltebot,(0-1)),(simread,(0-7,255))),(0-2)'
I do have both "call" and "callsetup" in +CIND=? though:
$ sudo mmcli -m 0 --command="AT+CIND=?"
response: '+CIND: ("battchg",(0-5)),("signal",(0-5)),("service",(0-1)),("call",(0-1)),("roam",(0-1)),("smsfull",(0-1)),("GPRS coverage",(0-1)),("callsetup",(0-3))'
Hello,
Thank you for the details. Now it is all clear.
Both commands (+CMER and +CIND) are optional in 3GPP documentation. And I can't find these commands in any official AT commands specification document for PLS8-E module.
So it means that we don't support these commands. There is a proprietary ^SIND command instead where you can configure URC's that contain parameter names instead of indices.
Additionally it looks like ModemManager is not fully compatible with this module. Maybe there is a way configure it for not using these commands, but I'm not ModemManager expert here. There are other ways to use this module under Linux depending on what you need. An interesting way could be to use MBIM, but for this you'd need revision 4 module. Here's an example for ELS81: https://iot-developer.thalesgroup.com/tutorial/make-els81-eus-mbim-funct...
But there are other ways without MBIM.
Best regards,
Bartłomiej
Hey Bartłomiej,
The "cinterion" plugin in ModemManager relies on 3GPP-standard functions (implemented in the generic modem object) and then subclasses cinterion-specific behavior in the cinterion modem object. Trying to give some background here about why MM uses +CIEV/+CMER with the PLS8, not because the cinterion plugin does it explicitly, but because the generic implementation does it. Maybe it's too much to ask given that you've said that you don't support those commands, but as those AT commands do give AT responses in the PLS8 (i.e. instead of ERROR), I wonder if the behavior with the +CIEV index starting at 0 is specific to the PLS8 or applicable to all Cinterion modules. If the index always starts at 0 in all Cinterion modules, I'll update the "cinterion" plugin in ModemManager to reflect that. So far, only the "signal" indicator would be used, so it's not really a big deal anyway.
BTW, ModemManager is mostly compatible with the PLS8 module, not sure why you say otherwise? Of course there are things that may not be completely implemented, but overall it works ok, not better or worse than any other module managed by ModemManager.
Regarding the MBIM support, I totally didn't know that Cinterion had MBIM capable modules! Is there any way I can get PLS8-capable firmware with MBIM support? Very glad to see that you're suggesting to use libmbim/mbimcli to set up the module under Linux, but please remember that ModemManager itself also supports these modules using the same libmbim ;D
Is there any documentation about which non-standard MBIM services are implemented by the PLS8?
Hello,
Please let me explain a little bit more - Gemalto modules contain chips from third party companies (like Qualcomm for example). They are integrated into Gemalto products, some Gemalto proprietary commands are also added. The AT commands specification released for the module ******* all the commands officially supported by the Gemalto product. So I suppose that in this case these 2 commands must have been implemented by the chip provider but for some reason they were not added to the official product's interface. So this index issue might be the case for a certain chip provider. Honestly I can't see these commands also in other current products documentation.
If you write about updating the Cinterion plugin I think that these commands might be replaced with AT^SIND command which is also supported by other Cinterion modules.
As for MBIM PLS8-E revision 4 supports it.
As for the document I'll check what's available and let you know.
Best regards,
Bartłomiej
Hello,
As for your question about non-standard MBIM services the answer is that we don't customize MBIM and therefore we also don't currently have any dedicated document for this.
In case of PLS8 module it just ***** to be activated through the right SSRVSET setting (#4). It is described in the AT commands specification document for this module. Usage of CDC-ECM and CDC MBIM are mutually exclusive.
All other operations, for example management of the GNSS, are done through AT commands.
Best regards,
Bartłomiej
Hello Aleksander,
the following Cinterions modules support MBIM by setting SSRVSET=4:
ELS61
ELS81
PLS8 R4
Best regards,
Markus
How about using AT^SLCC=1 to switch on ^SLCC URCs? This should give you additional details about the call status.
Regards,
Reinhard
Hey Reinhard,
The AT Command reference I have for the PLS-8 is missing AT^SLCC. Is there any place I can get a new one?
Pages