sccn / lsl_archived

Multi-modal time-synched data transmission over local network

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

sometimes no clock offsets get recorded

dmedine opened this issue · comments

This issue has been coming up more and more lately. I have had it happen to me at random (about 15% chance) when recording data on a local host. Also see (https://github.com/sccn/labstreaminglayer/issues/337). Other users have reported this to me as well.

I think this is either a problem with liblsl or LabRecorder, but I believe it has been a very long time since the part of liblsl that does this operation has ever changed.

I made a few changes to LabRecorder a few years ago so that I could test the online synchronization methods, so it could be related to that.

I suspect (without thorough investigation) that this happens if and only if there is a stream that connected but has no data, either because none was sent or the connection reset. Without being able to reproduce it, it would be difficult for me be sure or to fix. If someone would like to loan me hardware (with an open source LSL wrapper) that exhibits the issue, I should be able to fix it.

Related to #331?

I suspect (without thorough investigation) that this happens if and only if there is a stream that connected but has no data, either because none was sent or the connection reset.

I tried that (https://github.com/labstreaminglayer/App-Examples/commit/e8102806634b495558144a8f132765c40f040202), but I can't reproduce it (even before any data is sent).

Yes, this is related to https://github.com/sccn/labstreaminglayer/issues/331

I will try to reproduce this and report back.

Here are hex dumps of time synchronization packages, one at the beginning of a recording session and one at the end, sent by mbt smarting streamer version 2.2.3 (time synchronization works) and with version 3.0 (time synchronization returns immediately with a timeout error). Maybe it can help identifying the problem:

with mbt smarting 2.2.3

0000 f4 8e 38 76 e4 ec f4 8e 38 76 e5 82 08 00 45 00 ..8v....8v....E.
0010 00 45 64 4d 40 00 40 11 54 74 c0 a8 00 32 c0 a8 .EdM@.@.Tt...2..
0020 00 64 86 07 40 bd 00 31 82 29 4c 53 4c 3a 74 69 .d..@..1.)LSL:ti
0030 6d 65 64 61 74 61 0d 0a 2d 37 39 35 37 35 35 36 medata..-7957556
0040 38 34 20 34 30 33 36 2e 32 32 30 34 30 39 31 35 84 4036.22040915
0050 38 0d 0a 8..

0000 f4 8e 38 76 e4 ec f4 8e 38 76 e5 82 08 00 45 00 ..8v....8v....E.
0010 00 44 75 1c 40 00 40 11 43 a6 c0 a8 00 32 c0 a8 .Du.@.@.C....2..
0020 00 64 86 07 40 bd 00 30 82 28 4c 53 4c 3a 74 69 .d..@..0.(LSL:ti
0030 6d 65 64 61 74 61 0d 0a 36 37 36 39 34 33 30 30 medata..67694300
0040 39 20 34 30 37 36 2e 34 38 30 33 39 38 33 34 31 9 4076.480398341
0050 0d 0a ..

with mbt smarting 3.0

0000 f4 8e 38 76 e4 ec f4 8e 38 76 e5 82 08 00 45 00 ..8v....8v....E.
0010 00 45 3c 12 40 00 40 11 7c af c0 a8 00 32 c0 a8 .E<.@.@.|....2..
0020 00 64 b4 39 40 bc 00 31 82 29 4c 53 4c 3a 74 69 .d.9@..1.)LSL:ti
0030 6d 65 64 61 74 61 0d 0a 2d 37 39 35 37 35 35 36 medata..-7957556
0040 38 34 20 34 38 36 36 2e 38 37 34 34 31 30 30 30 84 4866.87441000
0050 38 0d 0a 8..

0000 f4 8e 38 76 e4 ec f4 8e 38 76 e5 82 08 00 45 00 ..8v....8v....E.
0010 00 44 42 36 40 00 40 11 76 8c c0 a8 00 32 c0 a8 .DB6@.@.v....2..
0020 00 64 b4 39 40 bc 00 30 82 28 4c 53 4c 3a 74 69 .d.9@..0.(LSL:ti
0030 6d 65 64 61 74 61 0d 0a 39 34 39 33 33 33 39 38 medata..94933398
0040 35 20 34 38 38 31 2e 31 39 37 32 31 36 33 31 34 5 4881.197216314
0050 0d 0a

In both cases the stream is available without problems.

labstreaminglayer/App-LabRecorder@1920214 displays an error message when a timeout occurs, in the long run we should replace it with a better logging mechanism (e.g. an additional comment field in the XDF file?).

The packets look fine to me, but since the time exchange mechanism uses UDP it can't detect dropped packets.

I suspect (without thorough investigation) that this happens if and only if there is a stream that connected but has no data, either because none was sent or the connection reset.

I tried that (labstreaminglayer/App-Examples@e810280), but I can't reproduce it (even before any data is sent).

Another update: even with the outlet open without any sent data on a different computer the time correction gets queried successfully.

Okay. I think I'd need the hardware (with an open source LSL wrapper) that exhibits the issue to be able to fix it. I may have time to look at it in Germany, but I don't want to make promises. Otherwise, someone would have to mail me the device.

I had missed the mailing list thread about this that precipitated this issue. It turns out they are using gUSBamps. I have a couple of those.

I've been using the g.NEEDaccess LSL app to record from them. However, g.NEEDaccess isn't for everyone.
I'm in the middle of updating the gUSBamp LSL app. I'll let you know how that goes.

@gisogrimm I've compiled a very slightly newer version of gUSBampLSL app. You can find it here. I've only made a couple small changes, the most relevant to you is that it is built with Qt5, a recent version of boost, and the latest liblsl. Please let me know if this fixes your problem.