On 08/09/2013 02:08 PM, Marcus Müller wrote:
Hi Vanush,
No... that didn't do it. In fact, connected UDP source to null sink
and still get console full of warnings.
Ok, that _is_ strange. Try reducing the payload size - that's my only
guess. Are you using a large vector length on the UDP source?
I can't possibly imagine your computer being too slow to shovel
192ksamples/s from an UDP source to a null sink.
I think something is wrong somewhere, maybe in network setup or
network stack of BBB.
Well, the beaglebone surely is slow, but since the receiver says that
it gets too many packets, I don't think it's the beaglebone's fault,
nor your
networks'.
If anyone has achieved something similar, (sample forwarding), do
feel free to post your grc files. :)
I would try TCP.. but it seems to be coupled with grc, but Beaglebone
is headless! Ack...
hm, tcp_sink is in grc_blks2, and I don't know if that will work on a
headless environment.
However, what happens is really just raw samples over TCP, so you
might have success by reproducing a tcp sink
by creating a unix fifo (mkfifo filename), using ncat to stream across
the network (ncat receiver_ip port < filename),
and using a filesink with that fifo as file; you can do basically the
same (ncat in server mode > fifo, file_source with fifo) on the receiver.
Flow-graphs produced in GRC that don't have any graphical bits don't
have to have any display setup when they're run.
Just don't configure graphical bits, and don't use either of the two
graphical "generate" options when generating the flow-graph.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
