BGS2T-RS232 HTTP POST Data Corruption? | Thales IoT Developer Community
August 4, 2018 - 9:12am, 2093 views
Hi,
We are using Cinterion BGS2T Modems for M2M connectivity in our equipment at around 10 separate sites, mostly in the UK.
All modems use SIM cards provided by ESEYE and we use the modem's HTTP / Polling Service to POST data to our server.
We configure each of the 10 modems in the same way and can reliably POST data to our server from the units. The units are configured in Germany and soak tested there for around 1 week and we see no issues with connectivity etc.- they function with 100% reliability.
However, with our latest two installations, when we move the equipment to the UK and operate it there we experience problems. When we POST data (a JSON string) using the HTTP POST method, the modem returns a ^SISW: 1, 2 command indicating the POST / Data transfer is successful, however, our server rejects the POST because the JSON is corrupted.
We have obtained TCP session traces of both 'good' and 'bad' posts from our SIM card provider.
A good post looks like this:
POST /DataReceiver/AddMeasurement HTTP/1.1
Host: www.********.com:80
Connection: Keep-Alive
User-Agent: MC75/4.1
Content-Length: 128
Content-Type: application/json
{"MeasurementID":********************************************************************}
HTTP/1.1 200 OK
A bad post looks like this:
POST /DataReceiver/AddMeasurement HTTP/1.1
Host: www.**********.com:80
Connection: Keep-Alive
User-Agent: MC75/4.1
Content-Length: 128
Content-Type: application/json
....................................................................................................................{"Measuremen
HTTP/1.1 500 Internal Server Error
The problem is that spurious characters / data appear at the start of the JSON string (often 0 byte values - shown here as '.' characters).
The problem is highly intermittent, but can affect upto 90% of POSTs during some periods.
We have checked the string that is sent to the modem via its RS232 interface and it is correct, so the problem does not *** there.
It seems that the JSON is being corrupted somewhere between entering the modem and arriving at the server.
Has anyone any ideas what this problem might be?
Jim.
Hi,
What release is of your module (what is ATI1 response)?
Can you trace your module and check with program like WireShark what it sends or track your server?
Do i understand it correctly, that your server receive from your module corrupted JSON?
I've tried to test your case and in my side it looks like everything looks okay (on my server).
Can you send me your server (even in the private message)?
Best regards,
Krzysztof
Hi James,
I have sent you an email to start looking into your problem.
Best regards Simon
Hi,
After additional testing and advice from Gemalto, we believe that we have traced the source of the problem above to the use of 1200bps communication between the BGS2T module and our hardware.
Gemalto suggested that we use a higher bit-rate, so we moved to 9600bps and the problem with the corrupted data POST disappeared.
We have no explanation for this despite us configuring the BGS2T for 1200bps as recommended in the module documentation.
As such, it seems that one ***** to be careful with which bit-rates are used when communicating with the module in order to avoid problems.
Jim.