[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.

[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]

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.

[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]

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.

[Rob Watkins]

Hi, I am getting the same problem with an SF100-G-GB/IE and 1.50.7 firmware; response is HTTP/1.1 200 OK, but every time I get this in the log:

May 15 14:52:24 boa: recvfaillog: NON-POLLING RECEIVE API: Error reading response from server.

…and all messages are constantly resent (which obviously builds up pretty quickly!)

The link above to SF100 v1.51.14 firmware doesn’t work, but if I browse the FTP files I see I just need to remove the .bin – also there are newer releases though – which one is right for me – bearing in mind this other problem I am having: http://www.multitech.net/developer/forums/topic/receiving-messages-with-line-breaks/

Thanks,
Rob

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

[Author]

Posts