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
