TCP/IP - Identifying Network Issues
Published by Kiel on June 1st, 2011 in Developer
When streaming data over Enobio's TCP/IP connection I've noticed that when ever there is packet inteference (listed as error codes 1+2 in the file recording function) junk data gets transmitted.
This is in contrast to the Enobio graph / file recording functions which seem to use the last good value until the network restores itself.
Is there anyway to identify this junk data given the Enobio TCP/IP connection does not transmit each samples error code as with the file recorder.
As an example of this effect, I've attached the TCP/IP data for CH1 and its associated LOG FILE. Notice how after suffering from packet loss the TCP/IP connection starts picking up weird channel data after 35 samples.
Thanks,
- Kiel
TCP/IP LOG FILE
CH1 CH1 CH2 CH3 CH4 STATUS
14321 14321 16302 16970 16006 0
14320 14320 16301 16969 16005 0
14319 14319 16300 16967 16005 0
14317 14317 16299 16966 16003 0
14317 14317 16299 16966 16003 1
14317 14317 16299 16966 16003 1
14317 14317 16299 16966 16003 1
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
14317 14317 16299 16966 16003 2
16299 14317 16299 16966 16003 2
16299 14317 16299 16966 16003 2
16299 14317 16299 16966 16003 2
16299 14317 16299 16966 16003 2
16299 14317 16299 16966 16003 2
16299 14317 16299 16966 16003 2
16299 14317 16299 16966 16003 2
16299 14317 16299 16966 16003 2
16299 14317 16299 16966 16003 1
16299 14317 16299 16966 16003 1
16299 14317 16299 16966 16003 1
16298 14315 16298 16965 16001 0
16298 14315 16298 16965 16000 0
16298 14314 16298 16965 16000 0
14314 14314 16297 16965 16001 0
14313 14314 16297 16965 16002 0
14311 14313 16295 16963 16002 0
14310 14311 16294 16962 16001 0
14308 14310 16294 16960 15999 0
14307 14308 16294 16960 15997 0
TCP/IP - Identifying Network Issues
Dear Kiel,
the fact that after 35 samples the value of channel 1 becomes the one of channel 3 is indeed weird and I will investigate more.
Now the rest of the values are "normal" and the TCP stream is exactly the same as the one of the visualisation (the only difference is that in the visualisation stream, there might be a high pass filter applied). This can also be seen in the sample you provided where the last healthy sample
14317 14317 16299 16966 16003
is repeated throughout the stream of lost packets.
At the moment no, there is no way to track "bad data" in the TCP but this in principle should not so much the result of a realtime algorithm as the "bad" values are in a logical range (repeating the last value).
Thanks for the
Thanks for the update.
Ideally it would be prefable for the software to transmit the error flag the FILE LOGGER is using over the TCP/IP connection as well as the EEG data in order to identify any signal problems.
As I work on doing real-time diagnostics using EEG it would be useful to know if the data I'm about to make a decision on (e.g. output of an FFT window) contains logical but erroneous data. Is there any possiblity of getting this fix in a future update (preferably in version 1.5, given the issue with pre September 2010 hardware).