Hi there,
I’m trying to stream the FCDPP over UDP to a another computer
The setup is as follows
FCDPP Source -> UDP Sink
For the receiver,
UDP Source -> LPF -> Quadrature demod -> FM Deemph -> LPF -> Audio sink
Unfortunately, when I run the flowgraph on the receiver end, I only hear
a
bunch of clicks.
The console is full of messages “WARN: Too much data; dropping packet.”.
WX GUI FFT Sink and Waterfall seem to work, though with the same
messages.
Any hints to rectify this issue?
Hi Vanush,
I think you are connecting a audio sink . So the
problem
for dropping could be a sampling issue. your audio sink or audio card in
your computer is sampled at a lesser rate than your computer can
process.
so you might need to downsample before audio sink or do a resampling. I
saw
a similar message just yesterday or day before. check the mailing list
for
it.
Do you set sampling rate 192000 on both ends? Post your grc files.
On Thu, 8 Aug 2013 14:09:42 +1000
Vanush V. [email protected] wrote:
sink
Unfortunately, when I run the flowgraph on the receiver end, I only
hear a bunch of clicks.
The console is full of messages “WARN: Too much data; dropping
packet.”. WX GUI FFT Sink and Waterfall seem to work, though with the
same messages.Any hints to rectify this issue?
–
Alexey B. [email protected]
Different parts of the flow graph can have different sample rates.
You need to use the rational resampler so it’s output matches what
your soundcard expects.
You may also need a complex to real somewhere. There are plenty of
examples for a FM receiver on the web.
Best Regards
Iain
So the receiver begins with a sample rate of 48 KHz? So how is it
possible
to FM demodulation this case?
How can I set the sampling rate on both ends to be the same? FCDPP
sampling
rate is 192 KHz.
If I include an audio sink, is the rate of the flowgraph controlled by
the
sound card sampling rate?
Attached are my .grc files.
Hi,
your warning points to the UDP source: Since your receiver can’t process
all the samples that it gets
via UDP, and the UDP source runs out of buffering capacity, it starts to
drop UDP packets.
There are two things that you must do:
Best Regards
Marcus
Am 08.08.2013 18:09, schrieb Iain Young, G7III:
Hi Vanush,
as Iain pointed out, the sound card enforces a low sample rate by
being an actual piece of hardware;
therefore, 44.1ksamples/s “leave” your flowgraph at the audio sink,
while you feed it 192ksamples/s from the
funcube.
A faster computer might help, but first adjust the sampling rates
(although if your computer is really fast travelling away from you, the
192ks/s might hit him with 44.1ks/s, but I guess if you get a computer
that fast, it might be the end of everything.)
08.08.2013 20:18 Vanush V.:
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.
How does the flowgraph work having a sample rate ‘mismatch’ when the
FCDPP block is in the same graph?!
Could you give me a hint in working around this issue?
Sent from my iPhone
Ok,
would a faster computer help? I am running the receiver on a 2008
Macbook
air, might be a bit slow for modern standards.
On 09/08/13 00:22, Vanush V. 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:
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
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?
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.
As 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.
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
Hi Marcus,
No… that didn’t do it. In fact, connected UDP source to null sink and
still get console full of warnings.
I think something is wrong somewhere, maybe in network setup or network
stack of BBB.
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…
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 V.:
On 08/09/2013 02:08 PM, Marcus M. wrote:
Well, the beaglebone surely is slow, but since the receiver says that
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.
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.
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 08/08/13 17:52, Vanush V. wrote:
So the receiver begins with a sample rate of 48 KHz? So how is it
possible to FM demodulation this case?
No, that’s my transmit chain (assuming you are referring to my
GUI_TRX_JACK flowgraph)
The (Simplified) FM RX chain in the same flowgraph goes through
the following blocks:
UHD_Source : This is the HW receiver. In my case, a USRP running at
250k. In your case the FCDPP, running at 192k
A FIR Filter for tuning. If you just want the centre frequency that
you’ve configured on the FCDPP then you can safely remove this block
A BPF, which does two things:
a) Implements a Band Pass Filter of ~10k [can be changed at runtime
in my case, set the width appropriately for your signal
b) Decimates [IE down samples] at a 5:1 ratio, so 250k becomes 50k.
You would need to modify this, probably easiest to make the decimation
1, and then modify the rational resampler as appropriate. I did it this
way to reduce the workload of the resampler.
A rational resampler, which resamples from 50k to 48k. In your case,
I’d modify that to resample from 192k to whatever your soundcard
supports
An NBFM receive block. Note the Audio and Quadrature rates shown, and
their relationship to the audio device’s rate, and the output from the
resampler
The audio sink device, that happens to run at 48k, since my
“soundcards” (actually the jack audio system) run at 48k. Yours may
want 44k1
In my case, it is narrow band FM, so I had no need to receive bandwidths
of >50k (Heck, >10k on the BPF would mean someone was over deviating!),
so I used the fact that the BPF could decimate as well as filter.
I urge you again to google for “gnuradio grc FM Receiver example”. There
are plenty out there. Yes, you will need to replace whatever source
block they use with the dongle source block. You will also need to
adjust any resampling appropriately.
(And as Marcusj ust mentioned, if you dont have any GUI elements [they
can usually be safely removed from the flow graph], just select the non
GUI option in the “Options”, build the flow graph, and run it from the
command line)
Look at http://hal.g7iii.net/GRC/Examples/Simple_Multimode_RX.png again.
It does the FM receive at 192k (I was being lazy, it was only an
example, and a “learning test”), but then resamples at the “real” level
before sending on to the audio device.
Implement just the FM bits (switch to WBFM if you want]. It will show
you the effects of the BPF. You can even add another waterfall AFTER
the resampling, so you can see the effect of that.
Iain
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs