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.
On Sat, Aug 10, 2013 at 8:13 PM, Marcus Müller <mar...@hostalia.de> wrote:
> 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>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 Consortiumhttp://www.sbrac.org
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> 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
