Receiving messages with line breaks

[Rob Watkins]

I have an odd problem with line breaks. I am developing a process using the SF100-G-GB/IE to receive measurement messages from an environmental monitor.

These messages are split onto three lines. When I first set up the SF100 it had firmware 1.31, and I only received the first line of the message.

I upgraded to 1.50.7, and I got the first 2 lines. I still do not get the third line!

A few things to note:

1. The messages are truncated on the SF100 itself – both in the Inbox and the SMS Received trace log.

2. If I get the monitor to send to my phone then the message arrives fine.

3. If I forward that received message from my phone it receives on the SF100 fine.

4. REALLY weirdly, if I switch it to Unicode, then the messages are truncated at the end of the second line whether they are sent directly from the monitor, or forwarded from my phone.

I’m trying to get hold of the monitor manufacturer but they are not being very helpful. Is there anything obvious I can do? Ideally another nice easy firmware update!

I am also having this problem here:

Non Polling Receive – Multiple calls to page for same message

Thanks!
Rob

• This topic was modified 10 years ago by Rob Watkins.

[Bryon Davis]

Hi Rob,
To fix you non-polling receive API, please update to firmware version 1.51.25. See the links below.

SF100 v1.51.25
https://webfiles.multitech.com/engineering/unofficial-releases/iSMS%20(Formerly%20SMSFinder)/Firmware/SF100/1.51.25/SF100-u-v1.51.25-13Jan2014.zip

SF400 and SF800 v1.51.25
https://webfiles.multitech.com/engineering/unofficial-releases/iSMS%20(Formerly%20SMSFinder)/Firmware/SF400_SF800/1.51.25/SF400-800-u-v1.51.25-13Jan2014.zip

When using carriage returns and linefeeds with 7 bit ASCII, we recommend using ASCII 7-bit Character set “3GPP 23.038”, which can be set in the “SMS Settings” menu. When sending through the API using 7-bit ASCII, you should URL encode the carriage returns to %0D and linefeeds to %0A.

Here is an example of a 7-bit ASCII HTTP sendmsg request with carriage returns:
http://192.168.2.1:81/sendmsg?user=admin&passwd=admin&cat=1&enc=0&to=”17637773333″&text=line1line2line3

With Unicode you don’t need to URL encode the carriage returns and linefeeds, they should be just included as their Unicode values 0D and 0A.

Here is an example of a Unicode HTTP sendmsg request with carriage returns:
http://192.168.2.1:81/sendmsg?user=admin&passwd=admin&cat=1&enc=2&to=”17637773333″&text=6c;69;6e;65;31;0d;6c;69;6e;65;32;0d;6c;69;6e;65;033

I tested the above sendmsg requests and both successfully sent messages with 3 lines with no gaps between them.

Regards,
Bryon

[Rob Watkins]

Hi Byron, thanks for quick reply! That firmware upgrade has fixed the non-polling receive API errors, but unfortunately I’m still getting truncation of the incoming SMSes.

I get: Line 1<CRLF>Line 2<CRLF>
When I should be getting I getting: Line 1<CRLF>Line 2<CRLF>Line 3

In SMS Settings I have:

ASCII 7-bit Configuration\Character Set: 3GPP 23.038

All other checkboxes are off. (I have also tried with the Extended ASCII 8-bit (ISO-8859-1) checked).

This is the recent entries in the live log:

May 15 16:40:04 modem: livelog: [RECV] : 
+CMT: "+447590354018",,"14/05/15,16:39:59+04",145,4,0,0,"+447785016005",145,34
7934,R10,
MAX:74.9dB LAeq 15MAY

May 15 16:40:04 modem: livelog: [RECV] : +CMT: "+447590354018",,"14/05/15,16:39:59+04",145,4,0,0,"+447785016005",145,34
7934,R10,
MAX:74.9dB LAeq 15MAY

May 15 16:40:04 modem: livelog: [SEND] : AT+CNMA
May 15 16:40:05 modem: livelog: [RECV] : 
OK

As you can see there is a spurious blank line after “15MAY” which should contain data – mobile phones receiving messages from the same source do show this line.

Very obscure! Hope you can help.

EDIT: Actually, on this blog platform you CAN’T see the second blank line after 15MAY but I assure you it’s there on the live log!

EDIT 2: I retrieved the log with curl, and the extra blank line is just a normal 0D0A sequence, at least in the web page.

Rob

• This reply was modified 10 years ago by Rob Watkins.
• This reply was modified 10 years ago by Rob Watkins.
• This reply was modified 10 years ago by Rob Watkins.
• This reply was modified 10 years ago by Rob Watkins.

[Bryon Davis]

Hi Rob,
I was able successfully to receive a sms message with 3 lines on my SF800. The sms message was the same simple 3 line message as before, but was received.

The +CMT message shows all 3 lines:

May 15 13:39:23 txrx1-modem: livelog: [RECV] : +CMT: “+17637727561″,,”14/05/15,13:39:19-20″,145,4,0,0,”+16363848863”,145,17
line1
line2
line3

You +CMT message shows the sms as already changed coming out of the modem. So either it wasn’t successfully sent with 3 lines, the modem didn’t like something about the message and changed, or the cellular network changed it.

I’m wondering if the message was originally sent correctly, or if there is a special character that is causing problems. Can you try sending a simple 3 line message similar to mine and see if that goes through successfully. You can also try sending your original message to a cel phone and see if it displays correctly.

Regards,
Bryon

[Rob Watkins]

Hi Byron, as I said, it’s very weird!

I can receive general three line (and more) messages fine on the SF100.

My mobile can receive the three line messages from the monitor device in question fine. I have also tested this with other mobile phones – all fine.

Then, I can receive three line messages generated by the device fine, *IF AND ONLY IF* I forward them from my mobile.

It’s only messages sent directly to the SF100 from the monitor that are missing the last line.

Bit worried about it lost being in the modem – I notice in the trace logs the last number in the +CMT line is the character count, which matches the truncated message.

I’ve increased the logging level just in case that helps and opened a support ticket, but if you have any more ideas please let me know!

[Rob Watkins]

Interestingly, if I put the new firmware in Unicode mode, the forwarded messages now work, and show an anomaly – the non-working messages from the monitor show 0D0A CRLF pairs, whereas the working ones from my phone show OA LFs only.

[Bryon Davis]

Hi Rob,
I’m thinking that the device that is sending the sms messages is using a special character, or possibly a PDU header variable that the iSMS modem doesn’t handle properly. The +CMT in the logs shows what is coming out of the modem. In text mode, the modem will translate the received PDU message to text.

You can try sending you original message with only alpha numeric characters (no colon brackets ect..) and then add them back in one at a time and see if a certain character breaks it.

You can also try setting the iSMS into PDU mode, in the SMS Settings. This may handle the message better than the modem’s built in PDU to Text mode convertor.

In my testing with cel phones, I also noticed that a single carriage return or single linefeed is handled better than having both.

I’ll work with the tech working on your support case to help resolve this.

Regards,
Bryon

[Rob Watkins]

Thanks Byron. I have just tried switching it to PDU mode with no success; trying PDU + Unicode currently.

Unfortunately, although I’d love to try it character by character, I have no control over what is in the message from the monitor – it sends what it sends!

Rob

[Rob Watkins]

Just before I head off for the week, here’s the latest live log in PDU + Unicode mode for the last message receipt in case it is helpful.

I don’t know what those numbers are, I couldn’t decode them as Unicode code points – however, if that 48 / 49 after the CMT is the character count for just the message text, that’s actually about right.

May 16 17:35:06 modem: livelog: [RECV] : 
+CMT: ,48
0791447758100650040C9144570953040200004150617153404021B7DC8CC692E6580D453388D5D962AE1859086206CB7150CCD60C661B0A

May 16 17:35:06 modem: livelog: [SEND] : AT+CNMA
May 16 17:35:07 modem: livelog: [RECV] : 
OK

May 16 17:35:17 modem: livelog: [RECV] : 
+CSQ: 23,5

OK

May 16 17:37:19 modem: livelog: [RECV] : 
+CSQ: 23,0

OK

May 16 17:37:57 modem: livelog: [RECV] : 
+CMT: ,49
0791447758100650040C9144570953048100004150617173254022B7DC8CC692C660AC86A219C4EA6A39178E2C043183E53828666B06B30D05

May 16 17:37:57 modem: livelog: [SEND] : AT+CNMA
May 16 17:37:58 modem: livelog: [RECV] : 
OK

• This reply was modified 10 years ago by Rob Watkins.

[Author]

Posts