I am a bit lost searching for answers everywhere and I need some help to know if the project I want to make is possible using one of the particle devices.
The purpose
I want to track in real time force applied in feet using multiple force sensors.
Questions
Are the small force sensors a good choice/enough and precise (data accuracy) for that?
Can particles devices send really fast data?
Do I need to use meshes or wifi modules for fast sending data? (data will be then used in a separated web app)
If I want to use more than 6 sensors, what solutions are suitable?
Yes, you can measure sensors and send data very quickly using Particle devices. First off, which particle device are you using or do you need a recommendation? Secondly, how fast is fast? And how do you envision transferring this data to a mobile app? (Bluetooth, WiFi, Cellular, IR)
And lastly, force is not measured in feet... in the case of those Adafruit sensors the measurements equate to G-force (other sensors may be Newtons or some other scale). With the Adafruit sensors, you will be taking voltage measurements using the ADC features of whatever Particle device you choose for this and then converting to G-force based on the graph on the datapage that you linked to.
I do not know how to make that Orthotics tracker but you will need many more data points that just 6 force sensors. If you are not making Orthotic inserts and rather just focusing on the data transfer and application design, you probably want a high speed serial connection back to the PC or mobile. You can use multiple force sensors on one Particle device, read them sequentially and then transmit the readings to your PC/Mobile. Bluetooth might be suitable for that application but I've never worked with it. You could use WiFi for the data transfer as the WiFi network is suitably fast. You'll have to looking into sending UDP or TCP packets from the Particle device. While you might use mesh it might not have the speed depending on many factors... it maxes out at 250kbps but has some overhead for encryption.
By the way, the website for the tracking system in the video is here:
It has 25 sensors per square inch. That is more akin to a restive touch overlay for a touch-screen monitor than individual force sensors. The refresh rates differ by recording method: logging locally = 750Hz, wireless = 100Hz. Are you trying to meet those specs?
So to define fast, I would say about 20[ms] to 50[ms] maximum (20 is the best even 10 but I have some doubts ). I know that UDP would be perfect for that because it dosen't care about lost packets but I need to be accurate during the tracking.
My goal is not to reproduce exactly the same thing as the video but kind of. I would like to use a maximum of 8 or maybe 10 force sensors. I tought that I could use a second cheap using UART to get more ADC channels for data transfer but if I can get the whole thing running on just one particle device it would be perfect! And for now I just want to make it work so even if it's 6 sensors it's fine.
High speed serial connection
It is possible throw wifi or only via usb cable?
I think that the best for what I want to acheive is to send the data in parallel.
As I see it in my mind:
Senders: 2 devices (1 per foot)
Receivers: home wifi router? or particle mesh gateway?
Then using the REST api to get the data (maybe to low or not suitable because of the limit of calls)? or using UDP or TCP (but how fast) and create a socket with nodejs (where the app reside) to intercept data?
In fact, I think using the wifi connection because of it’s range in a room. Also, I searched a bit more and finally I don’t need something so accurate that what I could think just before. I just want to know when the pressure is more on the toe, on the middle of the foot or more on the heel and I want to visualize that phenomenon throw the web app. Maybe with just some points representing the force sensors and the force applied to them.
So I think that because the data I want will not be so accurate but just like a range of pressure, normally I could send those data throw wifi quickly (we will say that the network has the least possible noise).
In that case, there is 2 latencies:
The latency of sending the data over wifi
The latency of reading the ADC data with the argon
With that in mind, could the argon be a good choice?
You need one WiFi device per foot. I would use Photons because they are faster. Argon might work when used as stand-alone devices (no mesh network) since you have now reduced the number of sensors. Number of sensors will influence hardware decision… generally, with more sensors use Photon. Use UDP or TCP to send the real-time data via WiFi to your PC or mobile app.
The mesh network will not work for this. You want to send the data too fast for the low-bandwidth mesh and mesh uses UDP which will be subject to packet loss unless you use some type of packet acknowledgement scheme (which will double or triple the number of packets transmitted on the mesh which can overwhelm it.)
Another thought, why not store the data readings in memory in a FIFO buffer - very fast to write to and then send at the rate that the comms can manage. That way you could use mesh or wifi or BLE when that arrives. The advantage of buffering the data is that you then do not need to be so worried about latencies. You can also bundle the data messages more efficiently (using 255 bytes or 622 bytes with 0.8.0). I am assuming here that your monitoring isn’t continuous - i.e. that the data buffer will not fill up. Ideally you have these as battery powered, you could use 2 Photons and that way you would have 8 analog channels without having to worry about external ADCs. If you turn off the WiFi module whilst running the tests and run in MANUAL mode - power usage should not be an issue. Nice project idea.
Many answers
Thank you for the precision in the explanation @ninjatill!
@armor I understand the idea but I don't know how to pick the data and put them in buffers
What do you mean when you say:
622 bytes with 0.8.0
Imagine we want to use ['A0', 'A1', 'A2', 'A3', 'A4', 'A5', 'A6', 'A7']
We read the data using the analogRead()
Now, how do we have to make our buffer?
I have a little trouble representing the 12 bits ADC in the bytes of a buffer sorry for that.
Quick code/pseudo code for photon.ino
TCPClient client;
byte server[] = { xxx, yyy, zz, ww }; // nodejs server IP
int ADC_pin_1 = A0; etc...
int ADC_val_1 = 0; etc...
void setup() {}
void loop() {
if (client.available()) {
ADC_val_1 = analogRead(ADC_pin_1)
client.write(buffer, length);
// What datatype buffer variable needs to be?
// How I can calculate the buffer length?
}
if (!client.connected()) {
client.stop();
for(;;);
}
}
And finally, how do I have to do to construct the FIFO buffer and decode it? Do you have some links where I can read something or do you have some examples in minds?
Suggest that you search on the forum for "reading multiple analog" and FIFO buffer or circular buffer look at the community libraries. A google search will also pull up. Essentially you want something that you can push data into (and tell you if the buffer is full or not) and then have another process read and tell you whether the buffer is empty or not.
There is no problem putting your values into a JSON format just use snprintf() to format the message into a char array (c string) and then push that into your circular buffer. It helps to simplify if you keep the char array stored the same length (fixed format). Clearly the number of entries in your buffer will need to be enough to cope with the difference between reading and sending speeds. Also, you will need to store the buffer in RAM and available space will constrain its size. So you may just store the raw values and time and source. Search up using Struct. Quick example:
Struct myData{
char foot; //R or L
unsigned long millistime; //system millis() time of readings
uint16_t a[8]; //2 bytes per 8 analogRead values of range 0-4095
}; //total 22 bytes
Quickly made up and not validated JSON...
{"FOOT":"RIGHT","TIME":"00:00:00:000","READINGS": {"A0":"4095","A1":"0000",....}}
I have a little trouble representing the 12 bits ADC in the bytes of a buffer sorry for that.
Just use format %04i to create a known length number in ascii - no need to store bits.
). I know that UDP would be perfect for that because it dosen't care about lost packets but I need to be accurate during the tracking.
