TTL signal vs TCP-IP, parctical and timing considerations

[Donat-Pierre]

We have just purchased a BioPac MP1 50 physiological recording system (www.biopac.com). We would like to start/stop an acquisition from another computer system and/or to add annotations and markers.
To this end it seems there are two routes to consider. We could either use the built-in Trigger in/out capability with TTL signal of (0 and +5V square pulse) or use TCP-IP client-server to control it remotely (i.e. using VIs such as TCP-IP Listen). In the later case, I�d use the Beta LabView API libraries that BioPac is about to release for the MP150, instead of the dedicated AcqKnowledge 3.8.1 software, which is really good.

Because we need to correlate event during the physiological recording of our experim
ent, it would be ideal if the resolution were of ms accuracy (i.e. latency less than 1ms) and we need to manage up to 16 trigger channels.

I have very little technical background knowledge on this. Thus, in order to help me evaluate a solution, I would appreciate any comments and suggestions.

1) I would like to know first if anyone could recommend an easy solution to generate TTL signal (0 � 5V logical pulse) on both Windows and LINUX PC?
For instance I read about using the 25-pin parallel port, but I am curious to learn about other possible alternative such as USB, USB2 with or without adapter but also a very cheap card (a couple $100 max). I am already ruling out serial connection, because I am told it is very slow and has horrendous latency.

2) What are the latencies in read and writing/issuing TTL signals com? How does it compare with a dedicated byte stream through TCP-IP, on a dedicated cable and on a network cable?

3) Are they any VI application that you c
ould share to show how LabView 7.0 can talk through the respective ports to generate a pulse forming the trigger information being written or read in?

I look forward to hearing your feedback and suggestions. Many thanks in advance.

Donat-Pierre LUIGI

[Chuck Schumann]

Use TTL. It is likely that the TCP/IP messages will get there fast enough
and that the software will respond in a timely manner but there is no way to
be sure. It is the fastest way to get from your LV application to your
other device. You may need to check the response time that the BioPac will
give to the TTL input verses a TCP/IP message.

You should also consider the level of programming needed to accomplish your
tasks. I would strongly suggest that you get a seasoned LV programmer on
the job or you will be wasting a lot of time and enduring needless
frustration.

The parallel port will respond is sub-millisecond. You should be able to
toggle it several hundred times in a millisecond. I've had LV applications
use the printer port for this type of communications before. I don't
remember the bandwidth but it's more than adequate for this application.

TCP/IP will sometimes get delayed by the OS (either Windows or Linux) due to
other things that are happening at the time which you don't have control of.
The message should go out in very short order (again sub-millisecond) but
there is no control over this.

Good luck,

Chuck

"Donat-Pierre" wrote in message
news:506500000008000000F2FF0000-1079395200000@exchange.ni.com...
We have just purchased a BioPac MP1 50 physiological recording system
(www.biopac.com). We would like to start/stop an acquisition from
another computer system and/or to add annotations and markers.
To this end it seems there are two routes to consider. We could
either use the built-in Trigger in/out capability with TTL signal of
(0 and +5V square pulse) or use TCP-IP client-server to control it
remotely (i.e. using VIs such as TCP-IP Listen). In the later case,
I'd use the Beta LabView API libraries that BioPac is about to release
for the MP150, instead of the dedicated AcqKnowledge 3.8.1 software,
which is really good.

Because we need to correlate event during the physiological recording
of our experiment, it would be ideal if the resolution were of ms
accuracy (i.e. latency less than 1ms) and we need to manage up to 16
trigger channels.

I have very little technical background knowledge on this. Thus, in
order to help me evaluate a solution, I would appreciate any comments
and suggestions.

1) I would like to know first if anyone could recommend an easy
solution to generate TTL signal (0 - 5V logical pulse) on both Windows
and LINUX PC?
For instance I read about using the 25-pin parallel port, but I am
curious to learn about other possible alternative such as USB, USB2
with or without adapter but also a very cheap card (a couple $100
max). I am already ruling out serial connection, because I am told it
is very slow and has horrendous latency.

2) What are the latencies in read and writing/issuing TTL signals
com? How does it compare with a dedicated byte stream through TCP-IP,
on a dedicated cable and on a network cable?

3) Are they any VI application that you could share to show how
LabView 7.0 can talk through the respective ports to generate a pulse
forming the trigger information being written or read in?

I look forward to hearing your feedback and suggestions. Many thanks
in advance.

Donat-Pierre LUIGI

[Donat-Pierre]

Chuck,


Thanks for the input. I started to look into controlling a parallel port with LabView and it is pretty simple. The computer I'd use for the development has 25pin.
I programmed several applications since I started using LabView over a year ago. One of them is controlling fans and servos of a device through serial port, using a TCP-IP client/server. This was pretty easy to do and with the Client server helped to test for the second stage. The purpose was to have the device connected to serial port through a Blue Tooth connection (i.e. wireless) and controlled by a UNIX system during an experiment, through TCP-IP. My PC running the LabView was then only interpreting and relaying the info.
Now, is this really trickier to send byte throu
gh to a given pin so that it generates a signal (i.e. 5v positive edge)?
Do you really think that a couple of examples of LabView app formulating instruction sent through the parallel port would not be enough to get me on track?
Just wondering, because at work I am supposed to be the season LabView programmer that is to say I am the only one. It is true I only have a little over one year experience, which is not much. But on the other hand we can�t afford the fee of a consultant.

That is another issue, for now your input is really helpful and encouraged me to look further into the TTL approach, using most likely the parallel port. I already saw a couple of LabView application using the serial port and I think I there were a couple of discussions on TTL too. With a bit of luck there might one example close to what I want to.

Many thanks in again for your input.

Donat

[chilly_charly]

The archives have some interesting links that you probably read already. Just for "security".
From what you wrote already, I don't think that you will meet major problems if you go that direction.

Using the Parallel Port in LabVIEW 

Setting Individual Bits for the Parallel Data Port Using LabVIEW 

Using the Parallel Port as an Input/Output Channel 

[Donat-Pierre]

Thanks for the links Charly. I "skimmed" through yesterday and plus the web links I collected around I have now a nice knowledge base to get me started - and lots of reading. At the moment I am tided up with processing 6 months of physiodata, but as soon as I get a chance I'll have a go at it.

So far, what I gathered is that there are up to 8 output signals and, depending on the type of port and mode used, there are 4 more biderectional outputs, which means I could program up to 12 TTL output signal/pulse.
Is this correct]?

Although it could be useful to read in a couple of bite/pin, I would be mostly interested in writing out of the port up to 16 TTL pulses to control up to 16 triggers on my physiodata recording device. Does this mean I'll n
eed to use two parallel port (i.e. adding a new one) in order to control all 16triggers independetly?

Thank you all in advance for your contribution,
Donat