PLS8-E: wrong index range in <indDescr> field in +CIEV URCs | Thales IoT Developer Community
June 11, 2019 - 6:36pm, 7585 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!
Nevermind, found one online now :D Let me try SLCC
^SLCC URCs are indeed very convenient to process call state updates, much better than the call/callsetup indicators.
Hi Aleksander,
a colleague implemented SLCC usage for OFONO. You might reuse this...?
According to him: 'this driver uses slcc for everything except initiating a call, also used instead of RING'
Best regards,
Markus
Hey Markus, yes, ended up using ^SLCC as well, it works quite well. The only thing to consider is that ^SLCC based call reports don't seem to be available before SIM-PIN unlock (e.g. for emergency calls).