Changed PDU format since R7.43


#1

After updating my Q2686 to newest R7.4.3.0 I found that Status Reports are not now interpreted with our software.
Look at the example:

  1. old PDU format
    +CMGR: 1,25…00C62B0B919720685883F3014003712352020140037153800200
  2. new PDU format
    +CMGR: 1,“A”,25…C6340B919720685883F3015070017363020150700173540200

As you see, now there is no zeroes at the beggining of PDU, which should show us that there is no SMSC information. This is critical - how should we know that we should skip this C634 stuff?

PS: also tested with R7.42 and R7.40. R7.40 does not contain this bug. R7.42 does.


#2

Hello,

So the R7.43 and the 7.42 behaves this way?

You can know whether there is SMS center information from the length. In your sample the length is 25 octets. The lenght does not contain the SMS center information field.

But i don’t really understand why it has been changed. Did you report this problem to your FAE?

BR
Sandor


#3

Yes I did.
They adviced me exactly the same thing - to measure length in octets and compare it with provided length. It should solve the problem but I expect increased possibility of parsing error with this method since it is enough to skip one byte in status report to make it unreadable.
Also they told me that it is closer to standart to parse PDU this way, but I still do not understand why Sms Center Address as zero octet is not so standart.
Now I think about downgrading all newer modules until it won’t be impossible to not to use R7.xx.


#4

This seems to be fixed in R7.45 beta version.


#5

Wow! Are you sure? The problem occurs only when receiving SR messages without SMS center information. We already modified firmware for this “feature” but had not put it into production yet.


#6

Sorry, my bad. The correction done in R7.45 is for SMS in hex mode (UDH was missing since R7.43). Don’t know if it is smae for SMS PDU.