Gemalto is now part of the Thales Group, find out more.

You are here

PLS8-E: wrong index range in <indDescr> field in +CIEV URCs | Thales IoT Developer Community

June 11, 2019 - 6:36pm, 6356 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):
    +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.