A USRP suitable for TCP operation?

[cochenob]

I had an application where I wanted to stream data from some N210's/NI 2920's at a remote location, though a wireless mesh network, and back to the host PC.  The application is time and phase sensitive (I'm using a MIMO cable...and it's essential that I receive the stream of samples in the order that they occurred).  On the benchtop, this is never an issue.  However, once we got out to the field and tried to send data through an actual wireless network, the driver started throwing all sorts of error messages suggesting that data packets were not being received in order, or dropped entirely.   

Eventually, I realized this was a reminder that the radios operate with UDP, not TCP.  There is no method for ACK/NAK or retransmitting packets for retransmission if the network ends up rearranging or dropping data, so the driver on the local machine just gives up.

We figured a way around it temporarily, but eventually we'd like to be able to treat the radios like any other networked device.  It would seem to me though that I've seen applications where people are streaming SDR data back over a WiFi link.  Am I imagining this?  Should I be looking to move to a different radio?

---

Brandon

[James_Battleaxe]

Hi Brandon,

I want to clarify the issue a little. When you're taking this device out in the field, I'm assuming you're connected to a laptop or some host PC, acquiring data on the USRP, sending the data to the Host, and then sending the data from the Host to your network. Is that understanding correct? 

My main point of confusion is I'm not sure if you're trying to generate signals that can be picked up by an existing network, or if you're acquiring data and trying to send the acquired data over a network and that's what you're struggling with. 

[cochenob]

James-

Sorry for the confusion.  Let me clarify.

At the "remote" end, I have some USRPs embedded on an unmanned boat acquiring data. The USRPs are plugged right into a network switch/router that was connected to an antenna, which send packets out over a wireless mesh network.

At the "local" end on land is me and my laptop running the processing application, which is also connected to a network switch and antenna that pulls packets off the wireless link.  Depending on the range of the boat, there may even be a repeater or two between the boat and shore.

I believe the issue is that the USRP driver, using UDP, doesn't have any way to handling dropped packets or latency in the network, which, depending on the distance of the boat and number of "hops" back to shore, turned out to be more significant than anticipated!

As a 'fix', we managed to shove a laptop running the receiver processing application in the boat along with the radios so there could be a direct connection.  In order to keep tabs on the application program, we used the WiFi network to do a Remote Desktop connection into the embedded machine. This way, there were no interruptions between the USRPs and the laptop processing and displaying the data, and the less reliable WiFi link was just used to "check in on" the sensor through the Remote Desktop connection.

This worked, though ultimately there won't be space to put a laptop along with the radios.  As I see it my options are...

1. Move to a different radio that can handle TCP (though I'm not sure if something like this exists?  E-series maybe?)

2. Embed a computer in with the radios (unlikely, though I'd have to crunch the numbers to see if there's an embedded solution that can run LabView and meet my memory and speed requirements for processing the IQ data...oh...and SWAP limitations).

3. All of the processing is running in "real time" on the laptop. Maybe it's time to move some of that into an FPGA?  (Though requires a move to a different radio AND FPGA development.)

Hopefully this paints the picture a bit better.

---

Brandon

[psisterhen]

All of the configuration packets (gain, frequency, etc.) and data streaming packets to/from the FPGA of those devices uses UDP.  There isn't a variant (without an embedded processor) that uses TCP.  So if the network between your Host PC and the device has packet loss or latency issues, you may lose packets.

As you have realized, connecting a PC directly to the device can help mitigate the effects of a lossy network, and going to an E-series device with an embedded processor would have a similar effect.  

However, none of the E-series devices are currently supported for LabVIEW programming.  You'd use the C/C++/Python UHD or GnuRadio APIs for that.

There are some optimizations you can try. (tuning to ideal packet sizes, or setting the bits-over-the-wire to 8 rather than 16).  Here are some tips:

http://zone.ni.com/reference/en-XX/help/373380J-01/usrphelp/data_streaming_performance_tips/

[cochenob]

Hi Paul...thanks for the thoughts.

Does NI have any products on the horizon that would be similar to an E-series device?  (i.e. - something that's really in the spirit of 'embedded' and not a giant PXI chassis that holds both a USRP and a controller).

It's looking more and more like the best solution is to find some kind of compact PC with enough RAM for my application that can run Windows/LabView.

I'm curious though...I could swear I've seen applications in the SDR community where people have done SDR over TCP networks. Have they had to go through similar tricks?  Have I imagined all of this?

[DylanDylanDylan]

We have a stand-alone USRP, not sure if it meets your size requirements:

http://www.ni.com/en-us/support/model.usrp-2974.html

[cochenob]

Dylan x3-

Hey!  This is looking like something interesting.  $13k is a bit of sticker shock relative to a N210 and laptop, but we'll look into it.

Thanks!