I have created a setup where an Arduino Due transmit sensor readings via bluetooth (HC06) to an Android tablet. The tablet samples are 125ms long and it takes about 100ms for the Due to measure and transmit the sensor readings hence there is some "oversampling". However on rare occasions, some measurements are not received in the expected timesample. Instead multiple readings appear in the following sample suggesting to me, that the buffers of the bluetooth transmitter and/or receiver are holding the data.
I am therefore looking for some kind of strategy and protocol to compensate for these events. I was thinking something like an extra transmission each loop with the time that loop took and that the tablet would interpret this to guess what sample the readings belong to.
I hope the above makes sense and that someone has experience in this?
A review of the Blue Tooth specifications will show the protocol is time sliced so one station can transmit for a limited time and then the other station can transmit for the next time slot. There is no other way for it to work, but you seem to want one station to transmit all it's data and then switch to receive.
djerik:
I have created a setup where an Arduino Due transmit sensor readings via bluetooth (HC06) to an Android tablet. The tablet samples are 125ms long and it takes about 100ms for the Due to measure and transmit the sensor readings hence there is some "oversampling".
I have read that a few times and each time I understood it less.
What do you mean by "tablet sample" - it seems to me the sampling is happening on the Due.
Do you mean that you want to send 10 measurements per second from the Due to the Tablet?
What exactly does the message for a measurement contain (how many bytes of data)?
Paul_KD7HB:
A review of the Blue Tooth specifications will show the protocol is time sliced so one station can transmit for a limited time and then the other station can transmit for the next time slot. There is no other way for it to work, but you seem to want one station to transmit all it's data and then switch to receive.
Paul
The Arduino/HC06 only transmits to the Android tablet. Nothing in the other direction
Robin2:
I have read that a few times and each time I understood it less.
What do you mean by "tablet sample" - it seems to me the sampling is happening on the Due.
Do you mean that you want to send 10 measurements per second from the Due to the Tablet?
What exactly does the message for a measurement contain (how many bytes of data)?
...R
Sorry for the vague description. Maybe sampling is the wrong term, but the tablet is using a timer to create a new "sample" every 125 ms. Every message/value received within those 125 ms is attached to the latest "sample".
When some measurements arrive later, they appear in a later timespan, than when they where actually measured by the Arduino.
Each message is about 12 bytes long and describes the channel and the value measured. 4 different channels are measured and transferred in each loop with a total execution time of 100ms. The serial connection is running at 115200 baud.
If I recall correctly, the Blue tooth time slice is 12.5 ms. So you get a transmission every other time slice. If you do not coordinate your whole system, you will have what you are seeing.
djerik:
Sorry for the vague description. Maybe sampling is the wrong term, but the tablet is using a timer to create a new "sample" every 125 ms. Every message/value received within those 125 ms is attached to the latest "sample".
It will be difficult to align the timing on two different devices. I suggest you do the timing on the Arduino and include with each data item some character that identifies which time-group it belongs to - for example the characters 0 to 9. Then the Tablet can consider all the values accompanied by (say) '5' as one group and all the values associated with '6' as another group.
djerik:
Sorry for the vague description. Maybe sampling is the wrong term, but the tablet is using a timer to create a new "sample" every 125 ms. Every message/value received within those 125 ms is attached to the latest "sample".
A better term might be "polling" as in "the tablet application polls the bluetooth receive buffer every 125 ms and processes data as available."
The fundamental issue is that the approach appears to be that the data is time tagged (the x-axis in your plot) on the tablet side with the polling which is asynchronous from the actual time of collection on the Arduino side.
Time tagging on the Arduino side (as suggested in post #8) would resolve this presuming you can adapt the software on the tablet side to parse and interpret the message. The logic would be something along the line of assigning "tablet time" to the first sample and incrementing that time by 100 ms for each successive sample.
When some measurements arrive later, they appear in a later timespan, than when they where actually measured by the Arduino.
Each message is about 12 bytes long and describes the channel and the value measured. 4 different channels are measured and transferred in each loop with a total execution time of 100ms. The serial connection is running at 115200 baud.
I concur with the plan to only time things on the Arduino. That means you will have to save the data until you know you have the start of the next batch. Then process the first, saved batch. More work, but only way I see to avoid your problem.
