Hobbyist Toolkit

cancel
Showing results for 
Search instead for 
Did you mean: 

LINX supported device for fast signals

Its great that we can run LINZX on an RT target like an RPi with direct access to GPIO's etc..  As this device is natively digital, interfacing ADC's and DAC's would be required to deal with the analog world. The interfaces to these (SPI and I2C) have their speed limitations w.r.t sampling within the RT implementation. Is there any other LINX RT hardware that can handle analog signals art a high rate for either PID control or DSP purposes?  If talking <20kHz is the sound interface on a rPi viable?  What about signals <100kHz?

0 Kudos
Message 1 of 5
(1,742 Views)

Have you checked out the Hats available for the Raspberry Pi?  Some of those may have the IO you are looking for.  Take a look at Sam Sharp's GitHub repository RPi-LINX-Addons for some VIs that interface to these Hats.

David Wilt
The New Standard LLC
0 Kudos
Message 2 of 5
(1,733 Views)

First, LabVIEW with Linx on RPi and Beaglebone Black is not a realtime system like your "RT target" made seem to sound like. It's an embedded target with a normal Linux kernel without realtime capabilities. It shares the attribute with the realtime targets that the LabVIEW executable is running headless (has no UI) and must be precompiled on LabVIEW for Windows and the fullly compiled code gets downloaded to the target.

 

And its hardware isn't easily usable for high speed data acquisition and definitely not by accessing the SPI and I2C interfaces through Linx. If you want to see what is technically possible you need to take a look at the Raspberry Pi hats from Measurement Computing.

Their MCC-118 has 8 channels with your mentioned 100kS/s combined (and not per channel please) sampling rate. However this is only possible since that hat actually contains its own microprocessor which does all the ADC control and then streams the data over the SPI link. And you have to use their compiled shared library to hope to get to that sampling rate. Trying to control the SPI bus directly through Linx is both currently not possible (Linx only supports certain SPI and I2C channels but not fully enough for the MCC boards) and almost certainly not fast enough since it would have to go repeatedly through the LabVIEW Linx layer for each data transfer.

 

As to using the sound on the Raspberry Pi, you are limited to 3 sound outputs (1 on HDMI 1 and HDMI 2 each if present, and not analog, and one on the headphone jack). No microphone input however!

Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 5
(1,718 Views)

Hi,

The Raspberry PI supports USB audio devices. Could the output of arecord be sent to a pipe that the LabVIEW vi reads?

 

There is a great article here about  USB RTL-SDR  adapters:

https://forums.ni.com/t5/Community-Documents/Using-RTL-SDR-with-Linx-running-on-a-Raspberry-Pi/ta-p/...


 

0 Kudos
Message 4 of 5
(1,690 Views)

@AndyLB wrote:

Hi,

The Raspberry PI supports USB audio devices. Could the output of arecord be sent to a pipe that the LabVIEW vi reads?

 

There is a great article here about  USB RTL-SDR  adapters:

https://forums.ni.com/t5/Community-Documents/Using-RTL-SDR-with-Linx-running-on-a-Raspberry-Pi/ta-p/...


Why are you talking about pipes here? The presented project simply provides VIs that call the compiled shared library to access those adapters. Using those VIs you get directly access to the adapter and can do whatever you want to do (as far as the provided VIs access the according shared library functions).

 

Yes you have to compile the shared library from sources since the LabVIEW chroot environment is a little special and seperate from the underlaying host OS on the Raspberry Pi and Beaglebone Black, but that is not an unsurmountable hurdle (although a little above basic point an click ability 😁).

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 5
(1,567 Views)