Streaming with USB 5132

[Dave_Thomson]

I'm considering a project that needs to stream significant quantities of 10 MHz data into RAM.  I'll be looking for events and saving peak heights, not saving the data to disk.  Since the customer wants to use a laptop, I'm looking at the USB 5132 scope.  I see that it has the ability to clock at 1/n x 50MS/s, so a 12.5 MS/s rate would be fine.  What I need to figure out is how fast it could stream events or data into the PC with this clocking rate.  One option would be to use analog triggering.  If I had 100 pretrigger points and 100 post trigger points, how many events could this device stream to the PC.  Both channels.  E.g., how many events per second could the PC receive?  Or, another way, how close together could two captured events be?

Another approach (which I use with the 6133 S PCI cards) would be to acquire and stream continuous data, and look for events in software.  This allows for more complex triggering algorithms.  This would imply a 25 MB/s transfer rate from the 5132.  Doesn't sound too bad for the USB bus, but can the scope support this mode?

Has anyone already run these types of benchmarks?

Thanks,

    DaveT

[Jake_G]

Hey Dave,

What you are attempting to do should be possible.

There is a great tutorial on High-Speed event detection located here.  There is also a link to an example VI in related links.

It uses the 5112 as and example, but it should work with the USB device as well.

[Aaron_W.]

Hey Dave,

After looking into it a bit more, I have a little more information for you.

Put simply, how quickly you can send a trigger is dependent on how efficient the code is, the speed of the CPU, USB Bus speed, etc.

Since the USB-5132 doesn't support multi-record acquisition (and by record I mean 1 record = 1 waveform), you must use single-record acquisition and resubmit the session with the niScope Initiate Acquisition VI each time.  This means the records will be software timed which depends on processor speed, which is why there will be no determinism.

There are basically three parts to determine how quickly you can send each trigger:  The acquisition of the data, fetching the data using niScope Fetch (data) with the CPU, and re-sending the niScope Initiate Acquisition VI command from the CPU.  While the first one is easy to measure (Samples / Samples per second = seconds), the other two are dependent on the scheduler of the CPU.  For instance, you would get the data from the USB device using the niScope Fetch (data) function and re-committing using the niScope Initiate Acquisition VI command in software, which would each have a non-deterministic amount of time to complete.  The page I linked above has some benchmarking that you may be able to use as a guide.  To give you a rough idea though, the niScope Fetch (data) function should be somewhere on the order of tens of milliseconds depending on the size of the waveform, while the niScope Initiate Acquisition VI command should be about 1 to 2 milliseconds.

There is a way to benchmark this process on your machine by using a VI similar to the one seen in Benchmark Loop Iteration Time with Tick Count Timer.