jumbled timestamps

[behinger]

I had this now in two XDF recordings in the last day, recorded with lsl_recorder, that the timestamps are completely off after some time.

We send the data via wifi, 128 channels x 1000Hz chunked. Today I did not touch the setup for 3 recordings á 5 min except for start/stop. The second one is attached below and shows broken timestamp after ~2s. The other two are fine.

I plotted this in matlab after load_xdf. These are the timestamps.

In the recording the last channel is the sample_number, given that not all samples are there (even after sorting), imho this shows they are lost somewhere. But in the past ANTs sample_number was also unreliable in the first place & one might run into floating/int overflow issues, but that's another story.

Data: (10 day valid): https://fex.uni-stuttgart.de/fop/UnibE61D/resting_state_broken_timestamps_bug.xdf
I mentioned this wrongly here: cbrnr/mnelab#436 - it has nothing to do with pyxdf/mnelab

[agricolab]

Did you use the ANT SDK for the Outlet?

[behinger]

yes - I grab the data via the ANT SDK and send it via lsl outlet

[agricolab]

I can replicate the plot when loading the dataset with pyxdf 1.17.0, when loading with pyxdf.load_xdf('resting_state_broken_timestamps_bug.xdf', dejitter_timestamps=False, handle_clock_resets=False))

Only that it seems to me as if the jitter starts after 83.86 seconds, and not after ~2s?

first_diff_gt_1_index = np.argmax(np.diff(samples) != 1)
print(f"First sample with diff > 1 is at index: {first_diff_gt_1_index}")
a,b = ts[0], ts[first_diff_gt_1_index-1]
print(f"Time difference between first and last sample with diff > 1: {b-a} seconds")`

prints

First sample with diff > 1 is at index: 83867
Time difference between first and last sample with diff > 1: 83.86379163735546 seconds

[agricolab]

It seems they are primarily out of order.

I assume that your setup consists of

graph LR
    amp --> tablet_pc[PC/creates outlet] --> wifi --> recvr[PC/records inlet]

Loading

so i wonder where this issue occurs. It could the that the wifi connections sends them out of order, or that the buffer between amp and outlet pulling them from the SDK overflows.... Doesn't seem to be an issue with loading the dataset (whether via python or matlab)

I assume you could check whether the issue also occurs when you record the outlet on the outlet PC, i.e before passing the samples via wifi?

[behinger]

Thanks!

They are not only out of order, but many are missing. I can also report that during recording/streaming the reported sampling rate is reduced

1. I will check locally on the laptop, that's a simple and good idea
2. I will try to investigate if this is a result of limiting bandwidth of WiFi. I had problems earlier of that sort but they seemed fixed (and IMHO showed up differently)

[behinger]

I can replicate the plot when loading the dataset with pyxdf 1.17.0, when loading with pyxdf.load_xdf('resting_state_broken_timestamps_bug.xdf', dejitter_timestamps=False, handle_clock_resets=False))

Only that it seems to me as if the jitter starts after 83.86 seconds, and not after ~2s?

first_diff_gt_1_index = np.argmax(np.diff(samples) != 1)
print(f"First sample with diff > 1 is at index: {first_diff_gt_1_index}")
a,b = ts[0], ts[first_diff_gt_1_index-1]
print(f"Time difference between first and last sample with diff > 1: {b-a} seconds")`

prints

First sample with diff > 1 is at index: 83867
Time difference between first and last sample with diff > 1: 83.86379163735546 seconds

I think that is compatible, there is a small 10^5 in the corner, it is around half of the recording

[behinger]

just a different recording with this problem (this time the np.diff of the time stamps) :

@agricolab why did you ask for ANT SDK? 🙈

[agricolab]

Afaik their GUI software now integrates LSL. I just wanted to get the elements involved clarified.

[agricolab]

Afaik their GUI software now integrates LSL. I just wanted to clarify what elements are involved.

Is this just a different recording via WiFi or already a local recording?

[behinger]

Nope still wifi, some months ago I checked for bandwidth for other reasons and that was completely fine...

I never bought the GUI (6k€...)

[behinger]

ok - some further tests, or wifi was limited at 20mbit because mode 820.11 instead of 820.11n was selected. Now we'll do more recording and hope it doesnt appear again. My underlying question to LSL is:

I always thought LSL cannot "miss packages" - or at least get them jumbled in time. Now I'm confused, package loss is a problem for LSL after all?