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.
On Sat, Aug 10, 2013 at 3:41 AM, Marcus
Müller <address@hidden>
wrote:
Hi Vanush,
remove the gui sink. It also limits the sample processing
speed and thus is equally bad as throttle.
Am 09.08.2013 19:33, schrieb Vanush Vaswani:
Hi,
It doesn't help, I still consistently drop samples.
I tried increasing the buffer size in
udp_source_impl.cc. I can record to .wav perfectly for
about two minutes before the flow graph suddenly exits
with (I'm assuming) a segfault.
For reference, I have attached images of the sender
and receiver. Surely, this sort of streaming has been
done before? I am using a BeagleBone Black running
Ubuntu 12.04 (which runs fine - no overflows). The
correctness of the FM receiver is less of a concern
than the dropped samples.
Regards,
Vanush
On Sat, Aug 10, 2013 at 3:11
AM, Marcus Müller <address@hidden>
wrote:
Hi Vanush,
ok. Throttle does not _do anything_ with the
samples. It just slows down the computational
speed that they are processed with. Remove it,
it breaks your flowgraph.
GRCAs said before, the WARN:... warnings stem
from your UDP source. Data does not get
processed fast enough; that's throttle's fault
(before, the audio sink was limiting
your sample processing speed, which is in its
nature).
Your flowgraphs are _not_ running at the same
rate; they _may_ process samples at the same
average rate (that's what throttle does, stop
the sample flow when it's faster
than specified), but throttle does not convert
sample rates.
Refer to existing Receiver flowgraphs from the
internet on how to do things right, and please
remember: 192kHz input MUST be downsampled for
audio usage.
Have a nice day,
Marcus Müller
Ok, I still don't understand why I'm
getting so many dropped packets.
sender
FCDPP -> UDP Sink
receiver
UDP Src -> _Throttle_ (at 192KHz) ->
WBFM Receive -> Wav File Sink
Note: no audio sinks.
I constantly get "WARN: Too much data;
dropping packet."
Wave file is full of skips, yet both
flowgraphs are running at the same rate?
On Fri, Aug 9, 2013 at 10:37 AM, Iain
Young, G7III <address@hidden>
wrote:
On 09/08/13 00:22, Vanush Vaswani
wrote:
Hi,
If i add a rational resampler to
match the audio rate before the
UDP
sink, I can get a continuous
output, but it's of terrible
quality due to
the loss of information.
You are always going to have to throw
information away. You have 192k
that you are trying to fit into human
hearing, so you *must* filter
and then down sample.
How wide is your BPF/LPF ? Is it more
than your soundcard can handle ?
How does
the flowgraph work having a sample
rate 'mismatch' when the
FCDPP block is in the same graph?!
Your soundcard (probably) expects
44k1. The resampler takes care of
this, but of course, 192k is not going
to go into 44k1. You need to
filter first.
Could you
give me a hint in working around
this issue?
As I said before, google has plenty of
examples of FM receivers with grc
(Google for gnuradio FM receiver grc,
I'm sure you'll find loads)
Here are two working flowgraphs that
start at 192k and 250k
respectively:
http://hal.g7iii.net/GRC/Examples/Simple_Multimode_RX.png
http://hal.g7iii.net/GRC/Examples/GUI_TRX_JACK.
They are actually a multimode
receiver I wrote as an example for a
friend, and a multimode transceiver for
ham radio use, but they show
the FM receive chain.
With both, you'll note I have a variable
BPF so I can listen to
broadcast stations on MW/LW, and FM,
SSB, or CW stations on the amateur
radio bands.
For pure FM you can drop the selector
blocks, and just concentrate on
the NBFM receiver chain
Note if you need to be tuning with the
FIR filter, you'll need to define
filter taps. I used a simple LPF.
Hope that helps
Iain
|