Multi-threading TCP client with POST

General
1

Hi,

I want to read the accelerometer data from the sparkfun board LSM6DS3 via I2C to the Photon every 20ms. This information needs to be sent every 500ms to our private server using POST.

The problem arises because whilst we are sending data to our server, we are unable to keep reading from the accelerometer.

We have tried to use the FIFO function on the accelerometer to retain the values temporarily whilst we are sending to the server. However there seems to be an issue with this new accelerometer FIFO that others are also experiencing - ie the XYZ data that comes out is garbled after a few minutes.

So can anybody suggest please how we could go about using the new multi-threading on the Photon for this case ? The issue we see here is that we are sending to our server, not the Particle Cloud.

Perhaps there is another solution to this we havent considered ?

Any help would be awesome. cheers.

2

For multithreading you could have a look into this thread
Particle Photon multi blink sample using threads

But without knowing the reason for the need to POST I dare to suggest the alternative use of the TCPClient or UDP libraries.

3

Thanks for the link, Ill check it out.

Sorry I don’t understand your final comment about using TCPClient instead of POST. We are using TCPClient to establish the connection, and we are sending to our server using POST with JSON.

We decided against UDP because it does not confirm the reception of the packet, and for our purpose (a seismic sensor) we must have all the data received by the server.

4

As I understand it POST is one sort of HTTP request, where TCP is a bit more basic and since can be more concise and hence quicker.

5

Is the server on the same LAN as the photon ?
In that case UDP likely wont lose many if any packets.

Http/tcp does not guarantee a request will result in success either, just that the packets get to the server, which may fail for a number of reasons, if the http server is not running the actual post data wont even be submitted.

1 Like
6

UDP is best for infrequent small data like telemetry.
You can send your own home-grown UDP packet to “ACK” receipt. Sender can timeout.

Using TCP, with HTTP for a tiny spit of telemetry has a huge amount of handshaking overhead as every data report is a new TCP connection and all the HTML goop. And, there’s the issue of TCP disconnect protocol.

1 Like