1

I want to receive binary data over a 7-Bit encoded SMS to my PC/GPRS-Stick (XS Stick P14 from 4G Systems). That works in principle fine, but if I send a binary <linefeed>-character (0x0A), the GPRS-stick will change this to:

<carriage retrun>+<linefeed>(0x0D0A)

Examle:

If I send this binary hex values: 000102030405060708090A0

I get one Byte more: 000102030405060708090D0A0

I don't understand this automatic replacement... Is it possibly not allowed to send <linefeed> -characters over 7-Bit SMS, or do I have to configure the modem via special at-commands?

Best Regards

Andreas

Andreas
  • 342
  • 1
  • 10
  • 1
    If you want to send binary over a 7 bit ASCII channel then it's a good idea to encode it as printable ASCII characters, e.g. [uuencode](https://en.wikipedia.org/wiki/Uuencoding). That way you won't run into problems with control characters, and of course it takes care of the fact that you're missing bit 7. – Paul R Apr 11 '13 at 09:25
  • Thank you for your interesting alternative approach, but I want to use the full SMS capacity, without any overhead if possible – Andreas Apr 11 '13 at 09:48

1 Answers1

2

So you are reading the received SMS with AT command AT+CMGL (or AT+CMGR), right? And I assume you are reading it in text mode (AT+CMGF=1). And within the returned <data> parameter your modem inserts an extra \r in front of \n if any.

The information text response for AT+CMGL is specified to have "\r\n" around the message content, e.g.

...<CR><LF><data>[<CR><LF>...

, and maybe the implementers felt uncomfortable having a single \n at the end and decided to drop that (or maybe it is a bug?). Does the insertion of \r happen for any placement of \n?

Interestingly 27.005 does not discuss what should happen if <data> contains <CR><LF>... In V.250 the following is said:

5.7.3 Information text formats for test commands

In general, the format of information text returned by extended syntax commands shall be specified in the definition of the command. ... Note that the DCE may insert intermediate characters in very long information text responses, in order to avoid overrunning DTE receive buffers. If intermediate characters are included, the DCE shall not include the character sequences "0 " (3/0, 0/13) or "OK" (4/15, 4/11, 0/13), so that DTE can avoid false detection of the end of these information text responses.

Your scenario seems not to be too long response text, but interestingly the DCE (aka modem) seems to be relatively free to insert <CR> when it feels like.

Anyhow, if my assumption that you are reading in text mode is correct I would suggest to try to change the character set to hex (AT+CSCS="HEX"). That could make the modem behave differently with regards to \r insertion (or maybe not). If not you could try UCS-2 which also forces a hex response (see this answer).

If none of this helps, you could change to read messages in PDU mode (e.g. AT+CMGF=0). That is just a raw dump of SMS message of every single bit that is transferred over the air, and I would be astonishingly shocked if the modem manages to insert any extra \r characters in there. You then end up having to decode that after having received it (not trivial, look for some already written library), but at least it should work.

Community
  • 1
  • 1
hlovdal
  • 26,565
  • 10
  • 94
  • 165