Measuring Velocity with Digital Input

[deskpilot]

I am not very familiar with digital inputs and so am having trouble picturing this system. I will be starting from scratch but will have PXI chassis' available. I will have about 381 events. Event 1 will trigger acquisition, and over the next 10 - 20 ms, I need to capture the next 380 events. I don't need to know how long each event stays high, only the time in relation to the first event. I would like to catch any event that stays high for at least 1 microsecond.

Since it will require multiple chassis, I think I will just wire Event 1 to each chassis and so shouldn't have to worry about any syncing problems? A colleague has been looking at PXIe-6544 and 6545, but I'm not sure this is the right tool, and hoping there is a less costly alternative.

Hopefully someone can give me a kickstart in the right direction.

[Ryan_M]

To what accuracy and resolution do you need to take the measurement?

Is the event repeated or a single burst?

[deskpilot]

The event is a single burst.  It is going to be about 1 ms between Event 1 and when the rest of the events start going high. As for the accuracy of this time, a +/- of 1 microsecond would be ideal, 10 would be acceptable, and 50 would be pushing it. The final event could occur up to 20 ms after Event 1, but I'm much more interested in the first 10 ms if buffering is a problem.

[John_P1]

Hi deskpilot,

Are the "events" TTL pulses that are occuring on a single line (but at different times from each other)?  If so, I would use one of our Multifunction DAQ Devices (either the PCIe 6320 or the PCI 6220 depending on the required form factor).  You would want to configure the device for a buffered edge count task (see X Series User Manual) and simply count the board's internal timebase (100 MHz on X Series, 80 MHz on M Series).  You would use the first Event as an Arm Start trigger.

Best Regards,

[deskpilot]

The events should look like a TTL. They will start out at 5V and drop to zero. The rise/fall time should be fast enough for TTL. They are not on the same line. There will be approximately 381 lines. Each line will pulse more than once. Thats why I mentioned multiple chassis may be a requirement. Forgive my ignorance here, but the manual makes it look like I will get an array of numbers that correspond to the tick count that lines up with a change? So I will get an array of numbers back, one for each change?

Also, with that PCI card, would I have 24 channels because there are 24 digital lines, or 4 channels because there are 4 counters? I would like to use PXI, but I assume that PXI 6220 will work. If I can use 24 channels per card, 16 cards wouldnt be bad, but if I can only use 4 channels per card, that doesn't look like a good option.

Message Edited by deskpilot on 03-15-2010 01:03 PM

[deskpilot]

So I came across the 7811R. It looks like this may be a viable option. I have a little bit of knowledge and experience with the FPGA.

I'm trying to figure out if the 80 KB of onboard memory would be enough, but I'm not exactly sure how to calculate that. If each channel gives me a an array of numbers, that means 4000 bits per array. So if each number is 32 bit, then I could have 125 pulses per channel? This would be more than sufficient, I'm guessing around 20 pulses per channel on the high side.

[John_P1]

Hi Deskpilot,

If you're looking at separate lines, then my previous idea would not scale so well (each X Series card only has 4 counters).  I like the idea of using an R Series board to do this and would suggest posting over at the Real Time Measurement and Control forum to double-check the feasibility. 

If you had to do this with M/X Series boards, then the more efficient solution would be to use the Digital Inputs instead of counters.  The R Series should be more elegant but I thought I would type up the suggestion for M/X Series anyway:

We have a few M/X Series Boards that have 32 clocked digital lines (48 digital lines total, but only 32 support HW timing).  Depending on the board selection, you could sample the digital lines at 1 MHz (PXI 6224,  PCIe 6323) or 10 MHz (PXI 6254, PCIe 6353).  Then, in software you could determine which sample the rising edge occurs on and use this to timestamp when the event occurs.  The two options would respectively give you 1us or 100 ns resolution.

The X Series (623x) cards have built-in timing and triggering for the digital lines.  The M Series cards (622x) need to take in the clock from another source (you can use a Counter Output to create a 1 MHz or 10 MHz clock which can be triggered by your first event).

At 381 lines you'd require 12 boards.  Each board requires 2 terminal blocks for access to all of the lines.

Again, I recommend looking into the R Series board for your task, I just wanted to post another solution in case somebody comes along with a similar issue but with a few less lines.

Best Regards,

[deskpilot]

John, thank you for your support so far. I am investigating the FPGA card further, but want to make sure I understand this option just in case I run into a snag on that one.

Looking at the PXI-6254, the onboard memory is only 4000 samples. I think what you are talking about is acquiring a digital waveform, or an on/off for each channel at each sample? This would give me about 1.6 million samples for 32 digital lines at 1 MHz for 20 ms. I don't see how I could pull the information off of the card fast enough to prevent buffer overflow, alhtough I'm not familiar with LVRT and maybe this would make the difference? I was hoping to stay in windows, but would be willing to go RT.

[John_P1]

Hi deskpilot,

The data would be continuously DMA-transferred to a memory buffer in your PC.  However, thinking about this in a little more detail, at 10 MHz and with this number of lines the amount of data would be quite large (381 lines * 10 MHz *1byte/8bits = ~480 MB/sec).  This is going to be more than the PCI bus can sustain (typically about 80 or 90 MB/sec).

With the large number of lines you are using, the 10 MHz sample rate doesn't seem very reasonable anymore on the PXI/PCI platform (although you should still be able to acquire at 1 MHz continuously).  On the other hand, The PXIe (6353) cards use the PCIe bus which should be able to sustain the 480 MB/sec transfer rate.  The issue would then become whether or not the controller can process the data quickly enough so you don't overflow the memory buffer.

Again, I still think the FPGA solution would be much more elegant for this number of lines, but a PXIe chassis full of 6353s should also be able to keep up at 10 MHz.  A PXI chassis with 6224s should also be able to keep up at 1 MHz.  If the FPGA option doesn't work for whatever reason, we can look into either of these solutions in a bit more detail if necessary.

One other thing to double-check... is the pulse width of your events wide enough such that sampling at 1/10 MHz would be fast enough to guarantee that we catch the event?

Best Regards,