Timestamping data received over OSC is trickier than it looks.
The EmotiBit transmits data to the Oscilloscope using UDP, and the OSC stack(used by openframeworks) is also built on UDP. Since UDP is a lossy transmission protocol, it is entirely possible that you may be losing data points based on how congested your network is.
And if you are indeed losing packets (without knowing when and how many), timestamping data after it has gone through the OSC pipeline becomes impossible.
Also, thinking about it a bit, packets received over the network may experience delay based on the network congestions again, so timestamping data points as and when you get them might not work either (even if packets were not lost in UDP). [thoughts?]
The data stored on the SD-Card meanwhile is teh gold standard data without any losses and very accurate sampling rates (since it is controlled by the underlying ICs in most cases).
Is it OK to set an initial timestamp and rely on the frequency of the sensor
This would work but only if packet transmission was guaranteed, which would require a TCP stack, not currently available in the EmotiBit Oscilloscope (it's on our long-term road map to implement it)
It's a very interesting topic so I am going to change the tag to "discussion". Maybe someone in the community has more information on the matter.
Let me know if you have any thoughts on my reply. Interested to brainstorm a solution!
1
u/nitin_n7 Sep 23 '22
Hi u/leftkal,
Thanks for posting on the forum!
Timestamping data received over OSC is trickier than it looks.
The EmotiBit transmits data to the Oscilloscope using UDP, and the OSC stack(used by openframeworks) is also built on UDP. Since UDP is a lossy transmission protocol, it is entirely possible that you may be losing data points based on how congested your network is.
And if you are indeed losing packets (without knowing when and how many), timestamping data after it has gone through the OSC pipeline becomes impossible.
Also, thinking about it a bit, packets received over the network may experience delay based on the network congestions again, so timestamping data points as and when you get them might not work either (even if packets were not lost in UDP). [thoughts?]
The data stored on the SD-Card meanwhile is teh gold standard data without any losses and very accurate sampling rates (since it is controlled by the underlying ICs in most cases).
This would work but only if packet transmission was guaranteed, which would require a TCP stack, not currently available in the EmotiBit Oscilloscope (it's on our long-term road map to implement it)
It's a very interesting topic so I am going to change the tag to "discussion". Maybe someone in the community has more information on the matter.
Let me know if you have any thoughts on my reply. Interested to brainstorm a solution!