Parallel port trigger pulses in Windows XP and Windows 7

Post Reply
michaelrepucci
Posts: 13
Joined: Thu Aug 11, 2011 9:44 pm
Location: NYC

Parallel port trigger pulses in Windows XP and Windows 7

Post by michaelrepucci »

I've been creating a C++ based application (not LabView) using the LabView_DLL.dll, as described here (www. biosemi. com/faq/make_own_acquisition_software.htm). Now I need my program to send trigger pulses on the parallel port to synchronize with the BioSemi EEG collection (ActiveTwo Mk2), and I'm struggling to come up with the best solution. I can't seem to find a previous topic on this, but if it already exists, please direct me thanks!

But here's some additional info and concerns that I have as well. I had initially hoped that I could use Windows API calls (e.g., CreateFile and WriteFile), as described in the comments here (msdn. microsoft. com/en-us/library/Aa363858), but discovered that there needs to be a handshake with the device that isn't performed by the BioSemi. Alternatively, certain pins can be hard-wired together to fake the handshake, as described in Method 1 of this LabView tutorial (digital. ni. com/public.nsf/allkb/B937AC4D8664E37886257206000551CB), but this is less desirable (for hopefully obvious reasons). I found a possible solution for Windows XP here (logix4u. net/Legacy_Ports/Parallel_Port/Inpout32.dll_for_Windows_98/2000/NT/XP.html), but it doesn't look like it will work on Windows 7, which we plan to upgrade to soon. Moreover, this document (digital. ni. com/public.nsf/allkb/E6415E8A8376F63D86256C46007592E8) seems to suggest that even LabView won't be able to write to the parallel port in Windows 7. But I've gotten the impression that people have working BioSemi systems here (with triggers) on Windows 7, and so I'm confused how they were obtained.

Ideally what I'd like is a solution that works for both Windows XP and Windows 7 (and beyond), hence why I started by looking in the Windows API. What do people recommend?

Thanks in advance for your help!

:) Michael

P.S. - Sorry for the unlinked and cryptic URLs, but with this, my first post, I was prevented from using a nicer format.

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

Post by Coen »

As an alternative for using the parallel (printer) port, you can sent output pulses to the trigger port on the USB-receiver, see http://www.biosemi.com/faq/trigger_signals.htm. Use the USB_WRITE call from the Labview_DLL.dll. An example in LabVIEW is found in ActiView-Light (http://www.biosemi.com/download/ActiView604-Light.zip).

Best regards, Coen (BioSemi)

michaelrepucci
Posts: 13
Joined: Thu Aug 11, 2011 9:44 pm
Location: NYC

Post by michaelrepucci »

Thanks Coen! That seems like it'd be a great solution. Just one question. That page says about the latency "timing of the trigger inputs is accurate to the time period of a sample", but I understood USB communication to have inherent delays of up to 30 ms. Is this not the case with the USB_WRITE function in the BioSemi driver?

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

Post by Coen »

The output delay of the USB_WRITE function was measured to be as low as 2-3 ms. However, we recently found that there (sometimes ?) is a problem when sending more than approx 10 triggers per second. In this case, the extra (more than 10) triggers are ignored. We are looking into this, and try to find a solution soon. Until we have found a solution, wait approx 150 ms after sending a trigger before sending the next one, to ensure the 2-3 ms accuracy.

By the way, the input delay is adjustable in the latest version of the LabVIEW_DLL.dll (download form our website). Use the STRIDE functions to control the delay. Default is approx 50 ms, but with the STRIDE commands it can be adjusted down to the ms range. However, a shorter delay (smaller packages in the USB transfer) will increase processor load. Use the STRIDE commands to make the best trade-off between delay (optimize real-time behavior) and processor load for your application.

Best regards, Coen (BioSemi)

michaelrepucci
Posts: 13
Joined: Thu Aug 11, 2011 9:44 pm
Location: NYC

Post by michaelrepucci »

Thanks for the info Coen. Could you add my contact information to a list to be notified when you find a solution to the 10-packet limit, or simply reply to this thread (I'm subscribed). Thanks!

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

Post by Coen »

The cause of the delay was nothing more than a simple (stupid) bug in my LabVIEW code. The delay in sending triggers is actually in the ms range. It is no problem to reliably sent out 200-300 triggers per second. Sorry for the confusion.

Best regards, Coen (BioSemi)

michaelrepucci
Posts: 13
Joined: Thu Aug 11, 2011 9:44 pm
Location: NYC

Post by michaelrepucci »

I don't understand what data to send to USB_WRITE. [url=http://www.biosemi.com/faq/make_own_acq ... ftware.htm]This link[/url] suggests a 64 byte array. But even with [url=http://www.biosemi.com/faq/trigger_signals.htm]this link[/url] I don't understand which byte of the 64 is recorded as the trigger byte.

Is there an example somewhere or another forum post on this (I couldn't find one). Thanks![/url]

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

Post by Coen »

The 1st Byte (of 64) is used to start/stop the acquisition, the 2nd and 3rd Byte are the 16 output triggers, the further Bytes are not used.

Output trigger 16 is overwritten by the sample rate clock, so actually only 15 output trigger lines are available (can be changed in firmware).

Best regards, Coen (BioSemi)

michaelrepucci
Posts: 13
Joined: Thu Aug 11, 2011 9:44 pm
Location: NYC

Post by michaelrepucci »

So when sending data in the 2nd and 3rd byte, after USB_WRITE has been called to enable the handshake, should the first byte always be '\xFF'? This won't try to re-handshake, right?

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

Post by Coen »

Correct, best regards, Coen (BioSemi)

michaelrepucci
Posts: 13
Joined: Thu Aug 11, 2011 9:44 pm
Location: NYC

Post by michaelrepucci »

Sorry, but I guess I wasn't clear. These output trigger pulses don't seem to get saved to the data stream in the ringbuffer. Is there a way to write to the input trigger pulses which are recorded on the sync line? Or are these output trigger pulses recorded somewhere? I basically need to "time stamp" events in my software in the EEG data, so that the two can be synchronized.

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

Post by Coen »

Just connect the trigger outputs with the trigger inputs at the USB trigger port (pin 1 to pin 17, pin 2 to pin 18,......., pin 15 to pin 31). Your output triggers will then appear in the trigger/status channel. With respect to timing accuracy, this method is actually much better than overwriting the trigger/status channel in the acquisition software.

Best regards, Coen (BioSemi)

michaelrepucci
Posts: 13
Joined: Thu Aug 11, 2011 9:44 pm
Location: NYC

Post by michaelrepucci »

Forgive me for being completely naive, but you are talking about actually connecting the pins on the rear panel of the optical receiver/usb interface with wires, correct? If I'm understanding correctly, there isn't a software solution without this hardware tweak.

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

Post by Coen »

Yes, hard wire the inputs to the outputs.
No, you should not do it in software if accurate timing is important.

Best regards, Coen (BioSemi)

drollen
Posts: 1
Joined: Tue Nov 15, 2011 9:43 pm
Location: USA

Post by drollen »

Coen:

I am having the same issues as the original poster. Do you know of a way to get the parallel port method working in Windows XP or Windows 7? I need all 16 trigger inputs, where 8 inputs will be coming from 1 PC, and the other 8 will be coming from a separate PC. This prohibits me from using the USB_WRITE method you've described here. Thanks for your help.

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

Post by Coen »

Use additional USB-receivers on the PCs that are used to send the triggers.

Best regards, Coen (BioSemi)

Post Reply