Timing accuracy of USB trigger out

Post Reply
Enrico Segre
Posts: 7
Joined: Wed May 19, 2004 8:51 am
Location: Weizmann Institute
Contact:

Timing accuracy of USB trigger out

Post by Enrico Segre »

I'm programming some custom modification to ActiView 5.19. The goal, as said in my other posts, is to add some online analysis, whose results generate trigger output. The aim is to reach very precise timings, with latency times, possibly, within 1ms (1ms is the limit achievable by using Labview timer functions running at "time critical priority" in separate threads).
I'm currently generating the trigger output by sending the proper arrays of 64 bytes to the function USB_WRITE (I took it from an example). My question is: how much time can pass between the call to USB_WRITE (which can in principle be timed down to the ms) and the actual change of the trigger line? I experience latencies of the order of a few ms, which are understandable considering that there are fixed bursts of data incoming every 1/128 sec on the USB. As a matter of fact, I even run USB_WRITE in a subVI at "subroutine priority", but its caller has to be only "time critical" due to the Labview timer VIs.
Would there be any way to achieve better accuracy?

Thanks in advance, Enrico

Guest

Post by Guest »

Since Windows is not a real-time operating system, you can not control the output timing of the triggers precisely within this OS. With choosing the time critical priority for your output trigger thread, you have already implemented the available options.

Actually, the problem is not in the trigger output thread, but rather in the (variable) time needed to do the online data analysis which should generate the trigger. The incoming EEG data is stored into a large ringbuffer. ActiView constantly processes blocks of data from this buffer. However, when the processor is busy with other tasks, ActiView lags behind temporary with the processing tasks (for example: try dragging a Window). The buffer clock in the lower right corner shows the process (red needle is the pointer of the incoming data, green needle indicates the backlog by ActiView).

The solution is to use only the trigger inputs as real world timing events. So, you should feedback your output trigger signal to one of the trigger inputs. With this method, you will always have to exact trigger moments relative to the EEG data available in the resultant file. In other words, you cannot controll in advance when exactly you will sent a trigger out, but you can know afterwards exactly when the output trigger has occurred.

Note that you have to make this trigger connection in hardware at the receiver trigger port. Any trigger "connection" in ActiView itself (just a wire in LabVIEW) will result in trigger timing without synchronization with the EEG data (EEG data is buffered, direct triggers in software are not)

Best regards, Coen (BioSemi)

Enrico Segre
Posts: 7
Joined: Wed May 19, 2004 8:51 am
Location: Weizmann Institute
Contact:

Post by Enrico Segre »

Thanks for the answer, Coen!

Just a few comments:

>Actually, the problem is not in the trigger output thread, but rather in
>the (variable) time needed to do the online data analysis which should
>generate the trigger. The incoming EEG data is stored into a large >ringbuffer. ActiView constantly processes blocks of data from this buffer.

I'm aware of it, and what I'm actually striving to do is to estimate as precisely as possible this variable time. My application is such, that the decision wether to send or not the trigger can be taken by analyzing some amount of data in the near past, not necessarily up to the same real world time. What I can then do, is to instruct the program to predict when in the future (future w.r.o. both the real world horizon and the available data horizon) to send out the trigger.

>The solution is to use only the trigger inputs as real world timing events.
>So, you should feedback your output trigger signal to one of the trigger
>inputs. With this method, you will always have to exact trigger moments
>relative to the EEG data available in the resultant file.

I'm exactly doing this.

> In other words, you cannot controll in advance when exactly you will
>sent a trigger out,

This is what I'm striving for. My hope is that sending the trigger out from a time critical subVI using a Labview Wait, I'll get a good approximation of it. My experience showed that with minimal background activity, the additional jitter can be as low as 1-2msec. I asked about the last link of the chain, the time passing from the call to USB_WRITE to the actual trigger out, because I thought that it can be of the same order.


Thanks once more,
Enrico

Coen
Site Admin
Posts: 1124
Joined: Fri Mar 26, 2004 7:00 pm
Location: Amsterdam, Netherlands
Contact:

Post by Coen »

Latencies in the order of a few msec is what we would expect as an optimum. Because of the Windows OS, and the USB driver layers, it is impossible to have more accurate control over the trigger timing. The only way to improve on this would be to change to a real-time operating system.

Best regards, Coen (BioSemi)

Enrico Segre
Posts: 7
Joined: Wed May 19, 2004 8:51 am
Location: Weizmann Institute
Contact:

Post by Enrico Segre »

Thanks once more for your reply. Such times are indeed acceptable for my present application. I do agree that as a monitoring/recording interface, Actiview is perfect as it is, and there is no need to enforce such strict timing, provided (as it is) that there is no data loss. The problem arises only for special applications like mine, which pretend to live on top of ActiView.
This leads me to a further (very general and very gross) question: would it then possible to port ActiView to a RT OS? I thought of Linux RT, but I do not know at all how Labview will perform and how to interface it with the RT layer. Or, to use Labview's RT module, which runs dedicated hardware (an USB card on PXI??). And I imagine that it should be possible to implement everything from scratch, coding an USB layer for a RT OS, and coding a RT application on top of it using e.g. C, which is for sure a tremendous task.
Do you have some view or practical reccomendation on that?

Best regards, Enrico

Coen
Site Admin
Posts: 1124
Joined: Fri Mar 26, 2004 7:00 pm
Location: Amsterdam, Netherlands
Contact:

Post by Coen »

It would be best to base everything on National Instruments real-time hardware. Interface to the PXI hardware can be done with a National Instruments PCI 6533 digital I/O card, our old style receiver (http://www.biosemi.com/products_activeone.htm), and ActiView 4.09 (http://www.biosemi.com/download_actiview.htm)

Best regards, Coen (BioSemi)

lucaciti
Posts: 5
Joined: Mon Nov 14, 2005 5:12 pm

Post by lucaciti »

Dear all,
I would be interested in the format of the usbdata argument of USB_WRITE in order to drive the trigger outputs.
Thanks,
Luca

Coen
Site Admin
Posts: 1124
Joined: Fri Mar 26, 2004 7:00 pm
Location: Amsterdam, Netherlands
Contact:

Post by Coen »

The "data" input of USB_WRITE is an array of 64 Bytes. The first Byte is used to start/stop the acquisition (00=stop, FF= start). The second and third byte are used to control the outgoing triggers (example: 01 + 00 makes pin 17 High, and 18-31 Low ). The remaining 61 bytes are not used.

Best regards, Coen (BioSemi)

lucaciti
Posts: 5
Joined: Mon Nov 14, 2005 5:12 pm

Post by lucaciti »

Thank you!
Luca Citi
PhD student in "Biorobotic science and engineering"
IMT - Institutions, Markets, Technologies
Lucca Institute for Advanced Studies - Italy

Post Reply