Suggested hardware for sharing 3+ National Instruments DAQ boards?

13 posts / 0 new
Last post
DrNeon
Suggested hardware for sharing 3+ National Instruments DAQ boards?

I'm looking to put together a USB server capable of sharing 3 or more National Instrument USB DAQ boards, preferably via my employer's VPN. I was wondering to what extent the VirtualHere USB server performance depends on the hardware running it...will a Raspberry Pi 4 do a better job allowing high speed interfacing with the DAQ boards compared to a Pi 0 W? Is there a minimum memory requirement for the USB server, and would more memory be helpful? I'm trying to make this somewhat cost effective so, if I won't need 4 or 8 GB of RAM, I probably won't get the pricier systems. I saw another thread mention the NanoPi NEO2; would that be a better option for this purpose than a Raspberry Pi? Again, I'm not sure what hardware aspects will be the ones that define performance of the USB server (CPU speed, RAM, etc.). Hoping to share via WiFi instead of Ethernet.

Michael
.

A 2GB pi4 would be best. However just try with 1 NI DAQ board connected first because network latency might be an issue. If that works fine then 3 should be ok too.

DrNeon
I have the setup put together

I have the setup put together and can see the DAQ board from the client computer, but I think it feels a bit...slow. I need to do some comparisons to make sure it isn't in my head. Just for a frame of reference, what is a good latency value? On the client, it seems to spike to 150ms or 170ms periodically, but otherwise stay relatively low. The response from the DAQ board in the test panel software seems a bit flakey when running at sampling rates over 1kHz (which honestly doesn't seem very fast). Is there anything you'd suggest to test the connection? I haven't even tried the VPN aspect yet, this is just on my own local network (DAQ->Raspberry pi 4->5GHz WiFi on a good router -> WiFi back to desktop running client software).

DrNeon
The issue might be that there

The issue might be that there is something iffy with the Raspberry Pi 4 5Ghz WiFi (so say the forums)...trying on the 2.4Ghz and will see if things improve. Will report either way...

Michael
.

Yes the 5Ghz wifi on the pi4 is not very good because it is 1T1R whereas ideally a 2 or 3T3R would be much better. You can get 2T2R 802.11ac dongles for the pi

DrNeon
The new dongle seems to help

The new dongle seems to help a bit with keeping the latency (as reported by vhui64.exe) relatively low. I'm still running into a problem where the DAQ board periodically generates errors about not being able to send samples out fast enough or something like that. The error is:
------------------
Error -200284 occurred at DAQ Assistant
Possible Reason(s):
Some or all of the samples requested have not yet been acquired.
To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate. If your task uses a start trigger, make sure that your start trigger is configured correctly. It is also possible that you configured the task for external timing, and no clock was supplied. If this is the case, supply an external clock.
Property: RelativeTo
Corresponding Value: Current Read Position
Property: Offset
Corresponding Value: 0
-------------------
Note that this error seems a bit random...if I wait a few seconds and try the DAQ command again (i.e. read channel AI0 continuously at 1kHz), it sometimes works, sometimes doesn't and gives an error. I guess this would make more sense to me if it were consistent (i.e. some kinds of acquisitions are beyond the performance of the networked USB interface), but the error seems fairly inconsistent with respect to the acquisition settings. Is there anything I can do with VirtualHere to troubleshoot this, or settings I should play with? The data rates I'm requesting don't seem particularly high.

Michael
.

OK unfortunately think the latency is still too much. I don't think this is going to be possible. As another test if its not too much trouble just plug the pi into an ethernet link stop the wifi link and see if that resolves all the issues. If so its definitely latency in a WiFi link

DrNeon
I tried plugging the Pi into

I tried plugging the Pi into my router via Ethernet (Cat7), and get the same kinds of errors, randomly. Granted, my desktop (i.e. the client) is also on the WiFi network, so not sure if that is causing an issue as well (though speedtest gives very nice numbers with my desktop). But moving the USB server to Ethernet doesn't seem to make things any better. Again, this is for relatively low sampling rates (a few kHz). Is there anything I can adjust in the VirtualHere software to fix or modulate this issue? A buffer size or compression rate or something? Would this be improved with more powerful server hardware? It seems folks have used DAQ devices in the past with VirtualHere, so I'm not sure what is going wrong with my setup, as I don't think I'm asking much of it.

Michael
.

It's not going to work because of latency

DrNeon
Would a CPU-optimized version

Would a CPU-optimized version of the server provide any improved performance that might help with this issue (compared to the generic ARM trial version I'm using now)?

Michael
.

No, the timings on that device are too tight so latency is the problem

DrNeon
I've been playing around with

I've been playing around with faster acquisitions (200kHz sampling of 10k data points) and so far it seems to be working well. I'm guessing that there's some combinations of DAQ sampling rates and number of points acquired at a time that works well for this setup, and some combinations that do not work well. Strange that a 3kHz sampling continuously repeating acquisition of 500 data points causes problems (it works for a few iterations and then issues the error above), but a 200kHz sampling continuously repeating acquisition of 10k data points seems to be working fine so far (fingers crossed).

Michael
.

Great! So that must mean it does buffer the data in certain modes. Thats good to know.

I notice some video cameras do that too. Sometimes they will be quite jerky via virtualhere in some low data/ low resolution modes, but in higher resolutions they work fine because they compress the signal themselves before putting on the usb bus

Log in or register to post comments