0

Hopefully this is the best Stack Exchange site for this - I think it's primarily a netcat question.

I'm developing a custom data acquisition device. It can probably be best thought of as a fancy sound card. It's currently running on Ubuntu 14.04. I'm trying to validate the performance of it in MATLAB on another system, and the simplest solution seems to be streaming the raw data from the driver to MATLAB over UDP.

I can generate signals in MATLAB and send them over UDP to the device with a netcat listener:

nc -ul 10000 > /dev/evio

But I'm having trouble getting data to go in the other direction:

nc -u devhost 10000 < /dev/evio

This and other variations I've tried all just fail silently. According to pv no data moves through the pipe at all. The device only implements the read, write, open, and release fops, along with a handful of custom ioctl. If the input buffer is empty, the read call blocks until a frame of data comes in from the hardware and it returns either as much as was requested or the entire frame if too much was requested.

If I just do a simple test like hexdump /dev/evio | less I see the data I expect.

Sending a regular file over nc seems to work fine, according to pv.

I don't actually have a listener set up on the other side, but that shouldn't matter because this is UDP, right? I plan on having this just spamming my dev PC with raw data on that port so MATLAB can fire up a listener and tap into whenever it needs to. (I know this is a bad solution in the long run, but I'm just looking for a simple device to MATLAB bridge for hardware validation.)

Update:

Using dd seems to get a little through the pipe, but I don't know why it works differently. I set the reads to the frame size of the device:

dd if=/dev/evio bs=6144 | pv | nc -u devhost 10000
  16kB 0:00:00 [1.57MB/s] [<=>

And then I had to ctrl+C to close it. Taking nc out of the loop seems to let it run properly forever:

dd if=/dev/evio bs=6144 | pv > /dev/null

Gives a constantly updating pv result, with exactly the data rate I know the device is generating. pv < /dev/evio > /dev/null also gives the same results, which makes sense. I shouldn't have to read one frame at a time.

Katie
  • 101
  • 3
  • I have a limited understanding of NC so bare with me. but i think you need something on the /dev/evio side actually piping the data stream out into netcat. just directing /dev/evio to the port, is the same as just typing /dev/evio into the command line. – Gravy Feb 12 '15 at 14:00
  • @Gravy It's redirecting the stdin file handle to the /dev/evio device, so netcat's reads from stdin actually read from /dev/evio. /dev/evio is constantly generating new data, and if there isn't any available the read blocks until the next frame comes in (about 1.5ms). I can confirm that the redirection works with other programs because `hexdump < /dev/evio | less` works like I would expect. – Katie Feb 12 '15 at 14:10
  • 3
    Could you try socat with udp-sendto:devhost:10000? – Mark R. Feb 12 '15 at 15:44
  • Thanks! That seems to be working perfectly. My first try to listen to it in MATLAB didn't work, but I've confirmed with another tool that the data is coming across and looks like I expect it to. It would be nice to know why netcat didn't like it, but it's not a big deal - this is just for testing anyways. – Katie Feb 12 '15 at 16:58

0 Answers0