implementing pre-triggering in FPGA

[Sholyoake]

Hi,

Some years ago, we had an application to acquire data from 24 sensors in an array at ~500kS/s where any of the 24 could potentially trigger an acquisition, the issue began when despite the NI Sales engineer categorically stating that the PXI kit we purchased did support pre-triggering, that turned out to not be the case..... we tried implementing an alternative approach where we just acquired data continually and would look for events manually, but this generated huge volumes of data, as well as the hardware regularly running out of capacity to run fast enough and filling the buffer

someone suggested we implement the hardware side in an FPGA, and I'm currently exploring options, does it seem reasonable to the folks here that if we purchased a high spec FPGA module (and we're open to recommendations on that) we would be able to implement a system with 24 voltage inputs, each with a user definable trigger level, which would give 2 seconds of pre-trigger samples and potentially log for 48 hours post trigger, at a sample rate of 500kS/s?

I've got some older hardware and was considering a basic feasibility test, but if that seems too high spec for even a top-end FPGA module, we should look at exploring other options

[ZYOng]

What models of DAQ and FPGA modules do you have?

[Sholyoake]

---

@ZYOng wrote:

What models of DAQ and FPGA modules do you have?

---

right now an older cRIO 9114 chassis with a Virtex-5 LX50 FPGA, currently running a ni9403 TTL card

I don't expect that to be able to cope with the full spec, but if I can implement a pre-triggered system on a couple of channels at 50-100KHz that would be enough to procure a more modern PXI FPGA module on the back of to run at full spec

[mcduff]

---

@Sholyoake wrote:

we would be able to implement a system with 24 voltage inputs, each with a user definable trigger level, which would give 2 seconds of pre-trigger samples and potentially log for 48 hours post trigger, at a sample rate of 500kS/s?

---

What are your exact requirements? You want each channel to have a user defined trigger level? If you do that, the channels may not be synchronized. Your requirement user definable trigger level implies analog input, but your NI 9403 is a digital module. Do you want your triggering per channel to trigger on either rising or falling edges since for digital there really is no level. If you don't need individual triggers for each channel, I think it would be easier, faster to implement it in DAQmx. For digital, I don't know what boards support pretriggering, but for analog input there are cards that support it.

[Sholyoake]

---

@mcduff wrote:

---

@Sholyoake wrote:

we would be able to implement a system with 24 voltage inputs, each with a user definable trigger level, which would give 2 seconds of pre-trigger samples and potentially log for 48 hours post trigger, at a sample rate of 500kS/s?

---

What are your exact requirements? You want each channel to have a user defined trigger level? If you do that, the channels may not be synchronized. Your requirement user definable trigger level implies analog input, but your NI 9403 is a digital module. Do you want your triggering per channel to trigger on either rising or falling edges since for digital there really is no level. If you don't need individual triggers for each channel, I think it would be easier, faster to implement it in DAQmx. For digital, I don't know what boards support pretriggering, but for analog input there are cards that support it.

---

you're right, I was using the digital card in a different application, I have 9234 cards for analogue voltages

my issue trigger wise is that we're basically listening on 24 channels for an event, we don't know which channel the event will occur closest to, so ideally every channel needs to be able to trigger an acquisition cycle, unless we just have a longer pre-trigger time and look at the arrival times

another option would be to add the channel baseline voltages together and if the total goes over a threshold, it triggers an aquisition

If you can point me at a PXI card which can take a voltage input at ~500kHz and supports pre-triggering I'd be very grateful

The big trouble as I see it is the long acquisition time post-trigger I've not managed to have any form of acquisition last more than a few minutes before the buffer overflows

to clarify further I've been using a PXIe-1071 chassis with 8840 controller and two PXIe-6368 I/O modules for the actual application with zero success

so my question is really two related questions, is there hardware which will handle my spec of 24 channels at 24bit resolution, at 500kS/s for 48 hours, if so I'd like to make a smaller, slower version as a proof of concept I can show to my colleagues who control the budget

[mcduff]

---

@Sholyoake wrote: you're right, I was using the digital card in a different application, I have 9234 cards for analogue voltages

---

These don't support analog triggering, and also are limited to 51.2kSa/s.

---

@Sholyoake wrote:

so my question is really two related questions, is there hardware which will handle my spec of 24 channels at 24bit resolution, at 500kS/s for 48 hours, if so I'd like to make a smaller, slower version as a proof of concept I can show to my colleagues who control the budget

---

Most, if not all,  DAQmx modules that are 24 bit are Sound and Vibration modules. The high end ones, I believe can sample up to 204.8kSa/s, but that is the max. I don't know of any hardware that is 24 bit and can sample higher from NI.

---

@Sholyoake wrote:

The big trouble as I see it is the long acquisition time post-trigger I've not managed to have any form of acquisition last more than a few minutes before the buffer overflows

---

This is the result of a programming error. I have had systems run for weeks at higher sample rates. This depends on how you are reading, writing data.

---

@Sholyoake wrote:

my issue trigger wise is that we're basically listening on 24 channels for an event, we don't know which channel the event will occur closest to, so ideally every channel needs to be able to trigger an acquisition cycle, unless we just have a longer pre-trigger time and look at the arrival times

another option would be to add the channel baseline voltages together and if the total goes over a threshold, it triggers an aquisition

---

This type of logic would need either a FPGA or some custom hardware that could read in the inputs and output a trigger. Keep in mind, FPGA programming is much more difficult than DAQmx programming.

[Terry_ALE]

3 bytes per sample x 24 channels x 500ksamples/sec = 36 MB/sec

Two (2) seconds of pre-trigger is 3 MB of data per channel.

###

From https://www.xilinx.com/publications/matrix/Virtex5_Family_FPGAs.pdf the Virtex LX-50 has 2-4 Mbits of Block memory, so you would need to use DRAM which I do not know if the https://www.ni.com/en-us/support/model.crio-9114.html has any.  NI does not sell the 9114 any more so that is a problem if you need replacement parts etc.

The Virtex-5 LX-50 works only with ISE (and not Vivado) which does not run on Windows 10 or newer.  This will add complexity and risk to your work.

###

The PXIe-6368 on the other hand seems to meet the specs with two cards.  I am not sure about pre-trigger, maybe it can only do it for one channel?  That is an NI-DAQmx question to be reviewed.  See https://www.ni.com/en/support/documentation/supplemental/21/ni-daqmx-data-acquisition-triggering-tec...

###

I recommend looking at the Multi-Function RIO cards (previously R Series): https://www.ni.com/en-us/shop/category/multifunction-io.html?productId=118757

See:

https://www.ni.com/en-us/shop/model/pxie-7862.html

https://www.ni.com/en-us/shop/model/pxie-7861.html

Their open FPGA allows you to put triggers on each channel.  The DRAM allows you to hold pre-trigger samples on the board.  36 MB/sec is a relatively light load for a newer chassis such as 1095/2.

[Sholyoake]

---

@mcduff wrote:

---

---

---

This is the result of a programming error. I have had systems run for weeks at higher sample rates. This depends on how you are reading, writing data.

---

I will dig out the code for this (the PXi system is currently locked in storage with the code locally on it) I have had multiple certified architects and a couple of NI applications engineers review it and look to optimise it for speed, if you have any suggestions I am more than willing to listen to them

[Sholyoake]

code attached, any advice or mods appreciated!

This runs up to about 200KHz before it starts to fill the buffer

[mcduff]

Quick rewrite.Test and use with caution.

1. You modified an example. Not a bad starting point but won't work for every application.
2. For Continuous Sampling do NOT wire in the number of samples in the timing function. It sets the buffer size. Set the number in the Read Function.
3. You are saving to TDMS. Use the built in logging of DAQmx, much better than anything me or you can write.
4. For best efficiency, write in a multiple of the disk sector size.
5. I set the buffer to ~8s of data, should be plenty.
6. I set the file size to ~10s of data; every 10s a new file will be created. The data acquisition is gapless, so no worry about losing points. See 3. YOu can make this longer or shorter.
7. I also set the read to ~100ms of data; depends on sampling rate and disk sector size.
8. I used events so you can make changes easily to file name, pause/start, etc. You can add your own.
9. Depending on the sampling rate and number of channels, you may want to visualize your data in another loop. Option is there.

I only tested without trigger and simulated device. Try saving at 500kHz and see what happens. VI is not pretty, done fast, you should add error checking, etc. For example, this VI will not work if you do not supply a valid path for saving data.