Streaming Funcube Dongle Pro+ over UDP

GNU Radio
21

On 08/09/2013 05:29 PM, Marcus M. 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.

22

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)

23

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

24

Hi Vanush,

I was not aware of the gr-fcdproplus project; however, in practice, the
only difference is really the 192k sampling rate of that audio device (I
can’t really see why the dl1ksv did not patch that functionality into
gr-fcd, but that’s completely his choice. It’s easier, anyway, to
isolate all that control device handling into a hardware-specific
source).

Let’s assume you have your file source that reads the 16 (signed)
integers coming from the sound card; that file source should have
“short” set as its output type (that’s 16 bit :slight_smile: ), as it simply reads
raw bytes.
You convert those using “short to float”;
I and Q samples are interleaved. So you take “Deinterleave”, get two
parallel float-streams.
These, you combine using float to complex.
Quite straightforward :slight_smile:

Greetings,

Marcus

25

Hi,

yeah, makes sense to use OS functionality thats available.
One question - how does one pack the samples back into complex within
gnuradio (or grc)?
FYI, I am referring to OOT block gr-fcdproplus, not gr-fcd. The funcube
dongle pro+ has an improved quadrature sampling rate of 192 KHz.