[Q2686RD/Fw752] Data corrupted while sending

Legacy Legacy AirPrime modules
1

I’m evaluating Fw7.52 on Q2686RD and facing a very strange behavior: Data are corrupted by the modem while sending !
I reproduce this error so easily that I can’t believe I’m the only one facing it …

Here’s my sequence :

AT+CFUN=1
AT <- Spamming this command every second until modem is “up”
ATE0
ATV1
AT+CPIN?
AT+CCID
AT+WIPCFG=1
AT+WIPBR=1,6
AT+WIPBR=2,6,11,"apn"
AT+WIPBR=2,6,0,"login"
AT+WIPBR=2,6,1,"pwd"
AT+WIPBR=2,6,12,1
AT+WIPBR=4,6,0 <- I may repeat this command if an error occurs
AT+WIPCREATE=2,1,"IP etc.
AT+WIPDATA=2,1
<HTTP POST header ...>
<sending 25Ko data…>
AT+WIPBR=5,6
AT+WIPBR=0,6
AT+WIPCFG=0
AT

It doesn’t seems revelant, but data are sent by packet of 250 bytes with 400ms of silence between each.
I mean :
250 byte
<wait 400ms>
250 bytes
<wait 400ms>
Etc.

Flow control is set, but CTS stay low on modem’s side.

The error is : On server side, the received file contains a few repeated bytes. Usually 2 bytes in a row, sometimes 3, sometimes only 1.
The place where the error occurs is random. Sometimes, the error occurs twice in the same file of 25Ko.

If I’m sending
<…>
0123456789 ABCDEFG
0123456789 ABCDEFG
0123456789 ABCDEFG
0123456789 ABCDEFG
0123456789 ABCDEFG
0123456789 ABCDEFG
0123456789 ABCDEFG
0123456789 ABCDEFG
<…>

Server may receive
<…>
0123456789 ABCDEFG
0123456789 ABCDEFG
0123456789 ABCDEFG
0123456789 ABCDCDEFG
0123456789 ABCDEFG
0123456789 ABCDEFG
0123456789 ABCDEFG
0123456789 ABCDEFG
<…>

I know that the server, operator or test device (or what ever) can’t be the issue because I’m doing the very same test with a Q2686RD and firmware 7.44.

I’m wondering if I did the upgrade from Fw7.44 to Fw 7.52 properly because ATI9’s response is strange, without plugins versions:

Firmware 7.44:

ATI9
"DWL","V10c05","","Sierra Wireless",62640,"051513 10:45","a0836b50","00010000"
"FW","FW_SRC_744_12_F6_2.Q2687RDG","R7.44.6.201109260825.Q2686RD","Sierra Wireless",2146176,"092611 08:25","d3e08d21","00020000"
"OAT","","","",456544,"101612 09:56","60abb1af","00260000"
 -"Developer Studio","1.2.0.201012171243-R6026"
 -"Open AT Embedded Software Suite package","2.34.0.201009161320"
 -"Open AT OS Package","6.34.0.201007281407"
 -"Firmware Package","7.44.0.201008311212"
 -"Security Plug-in Package","1.4.0.201007300928"
 -"WIP Plug-in Package","5.40.0.201007290812"

Firmware 7.52:

ATI9
"DWL","V10c05","","Sierra Wireless",62640,"051513 10:45","a0836b50","00010000"
"FW","FW_752_34_3.Q2687RDG","R7.52.0.201306260837.Q2686RD","Sierra Wireless",673436,"062613 08:37","89796368","001d0000"
"MODEM","1.3.36","201306260837.Q2686RD","Sierra Wireless",1713240,"062613 08:37","85a2fb97","00020000"
"OAT","","","",654608,"012814 10:26","09b71d07","002a0000"
"ROM","800000"
"RAM","200000"
"DWLNAME","Q2686RD"

But Wipsoft seems correctly updated :

AT+WIPCFG=3
WIP Soft v556 on Open AT OS v652
Mar 25 2013 07:44:00

Wipsoft 5.56 is the one related to Fw 7.52 (As far as I know …)

I certainly did a big mistake somewhere …
Any idea ?

2

Hi,

If flow control (CTS/RTS) is enable why don’t you let the Q26 manage how to send data? I mean why wait 400ms?

When I work with AT COMMAND like you, sending 28kb or more data with FTP and HTTP, it send all data as it can, reading from memory and stop sending when modem required (to send a data over GPRS) and continue when modem is free to receive more data.

I use GPRS modem, so 28kb takes like a half a minute to send, so it work fine for me.

3

Hiya,

One thing to remember is that just because you are sending 250 byte packets with 400mS gaps doesn’t mean that this is how the modem is packaging it up into the TCP packets and sending it - especially as you are doing a HTTP transfer. The modem may well be buffering the data internally until the TCP packet is full (around 1492 bytes or so, depending on TCP settings) and then sending the data to your server. If you attempt to send more data while the TX is in process, the modem may ignore, reject, or overwrite the internal buffer with your next blob of data. I don’t think that WIPSOFT enables you to control this (although you can manage it if you do the transfer using wip from inside an OpenAT program)

If WIPSoft supports flow control on the uart, then (as JLdev says), just dump your whole transfer to the modem uart, starting and stopping the flow as indicated by the flow control lines.

Or … you could simply setup the HTTP connection, dump approx 1k data, then then tear down the connection. Ugly and inefficient though. And not necessarily reliable, either.

Remember that the modem uses an event driven programming model - it’s your responsibility to wait for events and service them appropriately. Simply using time (wait) states is going to lead to grief - especially doing network comms as the GPRS network is not always time reliable…

ciao, Dave

4

Thank you for reply. It points that the issue should be related to these “400ms”.

I’m waiting between each packet because I have to in order to reproduce the behavior of some device already on field.

We’ve got different hardware on which this modem is integrated, each with its own specificity.

Some do not even handle flow control. This is a hardware bug I have to deal with.

Secondly, a few years ago, we had to deal with the bad handling of CTS on modem side :
https://forum.sierrawireless.com/t/uart-bug-in-openat-7-x/4764/1

Because of these two reasons, we’re trying to regulate data flow that way … That was running properly with firmware 7.44