Forum: GNU Radio Streaming Funcube Dongle Pro+ over UDP

F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2013-08-08 06:11
(Received via mailing list)
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?
080e3a7c076624fe71d3e868d496552e?d=identicon&s=25 Karan T. (karan_t)
on 2013-08-08 07:44
(Received via mailing list)
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.
F0c896e8108913ff73aecda8dd5958ac?d=identicon&s=25 Alexey Bazhin (Guest)
on 2013-08-08 15:36
(Received via mailing list)
Do you set sampling rate 192000 on both ends? Post your grc files.

On Thu, 8 Aug 2013 14:09:42 +1000
Vanush Vaswani <vanush@gmail.com> 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 Bazhin <baz@irc.msk.ru>
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2013-08-08 17:58
(Received via mailing list)
Attachment: udp_rcv.grc (7 KB)
Attachment: udp_send.grc (4 KB)
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.
4a41bed29f715721ff51ab969558cf9d?d=identicon&s=25 Iain Young, G7III (Guest)
on 2013-08-08 18:10
(Received via mailing list)
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
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2013-08-08 18:54
(Received via mailing list)
So the receiver begins with a sample rate of 48 KHz? So how is it
possible
to FM demodulation this case?
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-08-08 20:14
(Received via mailing list)
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:
1) The Samples for the audio sink _must_ be resampled to the right sound
card sampling rate,
e.g. 44.1kHz, otherwise that card will see a highly frequency-shifted
version of the real signal
2) take care that the samples from the network get processed fast enough
so that there will be no dropping.

Best Regards
Marcus

Am 08.08.2013 18:09, schrieb Iain Young, G7III:
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2013-08-08 20:20
(Received via mailing list)
Ok,

would a faster computer help? I am running the receiver on a 2008
Macbook
air, might be a bit slow for modern standards.
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-08-08 21:03
(Received via mailing list)
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 Vaswani:
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2013-08-09 01:23
(Received via mailing list)
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
4a41bed29f715721ff51ab969558cf9d?d=identicon&s=25 Iain Young, G7III (Guest)
on 2013-08-09 02:38
(Received via mailing list)
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.png

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
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2013-08-09 17:56
(Received via mailing list)
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?
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-08-09 19:13
(Received via mailing list)
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 Mller
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2013-08-09 19:34
(Received via mailing list)
Attachment: udp_rcv.grc.png (50 KB)
Attachment: udp_send2.grc.png (30 KB)
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
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-08-09 19:42
(Received via mailing list)
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:
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2013-08-09 20:34
(Received via mailing list)
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...
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-08-09 20:38
(Received via mailing list)
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.
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2013-08-09 23:12
(Received via mailing list)
On 08/09/2013 02:08 PM, Marcus Mller 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.
4a41bed29f715721ff51ab969558cf9d?d=identicon&s=25 Iain Young, G7III (Guest)
on 2013-08-09 23:22
(Received via mailing list)
On 08/08/13 17:52, Vanush Vaswani 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:

1) UHD_Source : This is the HW receiver. In my case, a USRP running at
250k. In your case the FCDPP, running at 192k

2) 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

3) 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.

4) 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

5) 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

6) 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
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus Leech (Guest)
on 2013-08-10 13:01
(Received via mailing list)
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2013-08-10 17:18
(Received via mailing list)
On 08/09/2013 05:29 PM, Marcus Mller 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.
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2013-08-10 20:18
(Received via mailing list)
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)
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-08-10 20:51
(Received via mailing list)
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
F18b7b61dfbfe46c7af3cbcbda568c4f?d=identicon&s=25 Vanush Vaswani (Guest)
on 2013-08-11 17:16
(Received via mailing list)
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.
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-08-11 17:50
(Received via mailing list)
Hi Vanush,

I was not aware of the gr-fcdproplus project; however, in practice, the
only difference is really the 192k sampling rate of that audio device (I
can't really see why the dl1ksv did not patch that functionality into
gr-fcd, but that's completely his choice. It's easier, anyway, to
isolate all that control device handling into a hardware-specific
source).

Let's assume you have your file source that reads the 16 (signed)
integers coming from the sound card; that file source should have
"short" set as its output type (that's 16 bit :) ), as it simply reads
raw bytes.
You convert those using "short to float";
I and Q samples are interleaved. So you take "Deinterleave", get two
parallel float-streams.
These, you combine using float to complex.
Quite straightforward :)

Greetings,

Marcus
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.