Digital out

[Nikolas Karalis]

Now that USB3 is supported, it seems that the digital out could be a viable solution for TTLs.

I couldn't get it to work and looking at the "How it works" section of the user guide it mentions this has not been implemented.

Is it somehow possible to send TTLs (corresponding to the 8 trigger events) through the digital out HDMI?

Best,

Nikolas

--

Nikolas Karalis - http://www.nikolaskaralis.gr

Neuroscience Graduate Student

Ludwig-Maximilians Universität München 

Centre for Integrative Neuroscience -  Universität Tübingen

Neuroscience Graduate
Université Bordeaux 2 - Charité Universitätsmedizin Berlin
Applied Mathematics and Physics Graduate 
National Technical University of Athens, Greece

[Aarón Cuevas]

TTL output has never been an USB issue, but a software one. We still need to figure a way for processors down the pipeline to send messages to the source nodes while respecting the modular approach. I have a couple of ideas, though.

What's your intended use scenario?

[Nikolas Karalis]

Hi Aaron,

the issue I refer to in the previous thread is this one.

The intended scenario is triggering external events (eg. laser) based on events generated by the GUI (eg. phase detection).

So far, the implementation I am using is with the arduino sink. However, I am getting variable latency.
I think that the fact that I have to go through the usb2 of the arduino is adding extra latency.

So I think that if the output would be through the digital out on the board, this would save a few milliseconds.

On the same topic, I wanted to try reducing the software buffer in order to decrease the latency. Do you think this is easy/good idea (for small channel number)?

If so, could you please point me to the relevant section of the source code for changing this?

One last thing: I couldn't figure out how to choose which channels are sent to the analog out. Is this possible at the moment?

If I understand correctly, this is done at the level of the fpga, so it should have minimal lag.

Cheers,

Nikolas

--
You received this message because you are subscribed to the Google Groups "Open Ephys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-ephys+...@googlegroups.com.
To post to this group, send email to open-...@googlegroups.com.
Visit this group at http://groups.google.com/group/open-ephys.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-ephys/a2aa5b0b-5578-4075-ad2d-ae0194f24739%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jakob Voigts]

The intended scenario is triggering external events (eg. laser) based on events generated by the GUI (eg. phase detection).

So far, the implementation I am using is with the arduino sink. However, I am getting variable latency.
I think that the fact that I have to go through the usb2 of the arduino is adding extra latency.

So I think that if the output would be through the digital out on the board, this would save a few milliseconds.

Yea the latency and jitter come from the usb. Its not entirely clear to me if  going through the aq. board would help though - its also a usb protocol, with the associated latencies and jitter, and possibly makes matters worse because the same usb connection is already busy transmitting data to the pc. It's possible that going to usb3 and reducing the package size is a viable solution but i dont know if anyone has systematically tested this. We should ask around at SfN and try to get this test run and documented.

There is a project planned to make an acquisition board that interfaces with the host PC via pcie, which would drop the round-trip latencies to ~1ms or even below, but we dont know exactly how fast this will be making progress.

On the same topic, I wanted to try reducing the software buffer in order to decrease the latency. Do you think this is easy/good idea (for small channel number)?

If so, could you please point me to the relevant section of the source code for changing this?

You can certainly get at least some improvements - in theory you can try reducing the buffer sizes until something breaks and then go with the smallest possible one. 

If you click on the 'x ms' text in the header bar, right next to the CPU meter etc. you'll open the 'audio settings' dialog - somewhat counterintuitively, the 'audio buffer size' determines the buffer sizes that are passed around the processing pipeline. The smaller these are, the higher the CPU load, but the lower the jitter due to software buffers. We should make this clearar by labeling the windows etc better - ill open an issue on that.

 

One last thing: I couldn't figure out how to choose which channels are sent to the analog out. Is this possible at the moment?

If I understand correctly, this is done at the level of the fpga, so it should have minimal lag.

Yea, the setting for that is in the rhythm interface, there are two 'audio out' boxes, click on these and then select a channel from the 'options' box on the right.

These have, if i remember correctly, 1 sample delay.

[Nikolas Karalis]

Hi Jakob,

thanks for the answers and the suggestions.

I actually ran some tests comparing the different options.

As a test signal I feed a 10Hz sine wave, bandpass [8 12] and detect the peak. The event is sent to an arduino.

Using USB2 and default buffer (1024 samples), the latency is ~25 ms with very high variance.

Using buffers of 64 and 128 samples, you can get it down to 12 ms. For 32 channels and with a powerful laptop, you see some increase in the CPU usage (the before was minimal), but nothing dramatic.

USB3 improves things and can go down to 8 ms.

The smallest buffers can lead to crash and actually are not really improving the latency, so I think 64 or 128 samples provide a good balance.

I also tried with the -lowlatency and the -rt kernel at Ubuntu, in the hope things would be further improved, but they did not help. If anything they increase the variability.

However, I am not sure if perhaps I need to recompile the GUI using new headers to see any effect (that I did not try).

Hope the above info is useful for people attempting closed-loop experiments.

Cheers,

Nikolas

--
You received this message because you are subscribed to the Google Groups "Open Ephys" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-ephys+...@googlegroups.com.
To post to this group, send email to open-...@googlegroups.com.
Visit this group at http://groups.google.com/group/open-ephys.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-ephys/03a52753-5299-49e7-b0f4-08192be3a921%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jakob Voigts]

Awesome, thx for running the tests!

I pasted your reply here for future reference: https://open-ephys.atlassian.net/wiki/display/OEW/Acquisition+board+data+latency

but please feel free to add more details, plots etc if you have more information.

To unsubscribe from this group and stop receiving emails from it, send an email to open-ephys+unsubscribe@googlegroups.com.

To post to this group, send email to open-...@googlegroups.com.
Visit this group at http://groups.google.com/group/open-ephys.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-ephys/03a52753-5299-49e7-b0f4-08192be3a921%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Aarón Cuevas]

Just a bit of math to back the measures up.

The GUI data thread actually works with "ticks", processing at once all all the data gathered between the last tick and the current one. The ticks are generated by the audio hardware with a time between them equal to audio_buffer_size/audio_sample_rate. In the default case 1024/44800, which is 22,9ms. The maximum latency is thus the time between ticks plus the added latency of the processing and output system. This is in the worst case, when the event happens just after a tick has been issued and has to wait a whole tick time to be processed. In the best case, when the event happens just before a tick, the latency can be just the processing and output. That's why reducing the buffer size not only reduces the maximum latency but also the variance, as there is less room for variation between ticks. Note that the audio buffer size is the max size, but not the actual number of samples (which will be always lower than that).

In theory there is also a lower limit you can get, due not just the USB transfer size but the dara burst size from the FPGA, but I wouldn't change those numbers. It should be around 10ms@30KS/s in the best transfer conditions but worst case scenario (event just after the tick). Your 8ms are lower but near, and it's normal that most of the events happen at around the middle of the buffer than just at the beggining, so the measurements make sense.

We'll probably change the dialog box so instead of specifying a buffer size users can enter a max latency target and we calculate the needed buffer size (but probably leaving the audio sample rate unchanged, as setting it lower than the source sample rate would make everything stop working).

I have to run some checks, though, because I'm not sure that a 64 or 128 buffer size is fully stable. I'll do that when I'm back from SfN to come up with a minimum buffer size that is sure to work.