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 <mle...@ripnet.com
<mailto:mle...@ripnet.com>> 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
Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
