Gemalto is now part of the Thales Group, find out more.

You are here

BGS2T-RS232 HTTP POST Data Corruption? | Thales IoT Developer Community

August 4, 2018 - 9:12am, 1865 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.