Re: [Discuss-gnuradio] Streaming Funcube Dongle Pro+ over UDP

[Marcus Müller]

Hi again,

I was a little surprised that your connection couldn't handle the 12.3 Mbit/s for the complex 192ksam/s,
so I had a look at the source code of the fcd_source; that basically wraps an audio source.
Surprise was mine when I found out that there's no complex 192ksam/s at all... The audio device is set to
deliver 96ksam/s of stereo, that gets converted to 96ksam/s of complex samples.
Therefore, the data rate is only 6.144Mbit/s for your wifi link... Not very much.
Anyway, what (due to that being the default data type in GR), the audio source inside the fcd_source converts
the 16bit adc resolution of your dongle to 32bit floats; so, instead of streaming those using GR over your network,
you can also just stream raw audio data from your beaglebone to your receiver computer, something like
arecord --format={try something like S16_LE, U16_LE, see man arecord} -D beagleboardaudiodev --file-type=raw --channels=2 --disable-resample --disable-channels --disable-format |ncat host port
and
ncat -l port > rxfifo
on the receiver.
And then reading that file using a file source, converting the 16bit signed/unsigned ints to floats, packing them into complexes and using that for your receiver; note, however, that a lost packet is not tolerable in this case, you will end up with corrupt samples if lost bytes are not multiples of 4...

To the TCP/UDP sources in GR: they do what they were designed for, dropping samples from an outside source makes sense if your flowgraph can't handle the load, since there is no such thing as the infinite buffer or the infinite acceptance of latency; not so much for your fifos. They start blocking when you ram+swap is used up...

Greetings
Marcus

On 08/10/2013 03:15 AM, Vanush Vaswani wrote:

Iain, thanks for that. Will be helpful in my gnuradio pursuits.

I think the TCP blocks should be definitely be decoupled from GRC...

With regards to my problem, I tried the ncat/fifo approach, and it works acceptably. Using TCP, I get a few overflows on the sender (beaglebone) as expected due to the nature of TCP. With UDP, I can stream with very few skips (and this is all over WiFi too). Thus, for my app, I may use a fifo + Twisted to get data out of gnuradio. I think the TCP/UDP blocks are a bit spartan in gnuradio.

For the record, here are my commands
sender: ncat -u 192.168.0.8 31337 < txfifo           (txfifo is a File sink directly connected to a FCDPP source)
receiver: ncat -k -u -l 192.168.0.8 > rxfifo             (rxfifo is a File source connected to a WBFM Receiver and then Audio sink)

On Sat, Aug 10, 2013 at 8:15 AM, Marcus D. Leech <address@hidden> wrote:

On 08/09/2013 05:29 PM, Marcus Müller wrote:

You're right, although grc_blks2 is in grc/grc_gnuradio, which, as far as I would guess from here,
won't be built if you don't build GRC, which you usually don't when in a headless environment.

There's also no necessity to do the development side on the target platform, if you're just targetting a headless environment.  Take the generated
  Python, and run it on the target.

-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio