Dbpsk on gnuradio-3.5 and Ubuntu 11.10

GNU Radio
1

All,

I have been playing with two simple flow-graphs in gnuradio-companion,
one for dbpsk transmitter and other for dbpsk receiver. The transmitter
flow-graph is:

vector source – > packet encoder – > dpsk modulator – > uhd: usrp
sink

The receiver flow-graph is:

uhd: usrp source --> low-pass filter --> dpsk demodulator --> packet
decoder --> file sink

The vector source is given a vector {10,20,30} as input, repeat is set
to “yes”; in the packet encoder, samples/symbols is set to 8,
bits/symbols is set to 1 (because dbpsk scheme is to be used), pad for
usrp is set to “yes” and payload is set to “0”; in the dpsk
modulator,samples/symbols is set to 8and all other parameters are left
unchanged.

At the receiver, I use matching/appropriate parameters inside the dpsk
demodulator and low-pass filter blocks. And the sampling rate is set to
be 1M Sps on both transmitter and receiver.

Now, the issue is that I do not receive any decoded symbols in the file
sink. Previously, when I was running the two flow-graphs on two
computers with Ubuntu 11.04 and gnuradio-3.4 on them, everything was
just fine, but as soon as I have upgraded the OS and gnuradio to 11.10
and 3.5 versions, I do not get anything in the file sink.

Could someone provide a suggestion in this regard?

Thanks.
Jon

2

On Thu, Mar 29, 2012 at 10:04 AM, Jon W. [email protected]
wrote:

uhd: usrp source → low-pass filter → dpsk demodulator → packet decoder
1M Sps on both transmitter and receiver.
Jon
Jon,

I’m not sure why this would change between 3.4 and 3.5, but my guess
is that it’s something to do with the frequency offset, which tends to
be the biggest problem with these things. I’ve attached a GRC example
that runs what you want in a loopback simulation (you need gr-qtgui
installed for this). It looks good here, but I haven’t tried going
over the air. This was just to make sure the data and everything were
passing through the algorithm blocks correctly.

Try figuring out what the frequency difference is between your two
USRPs (to about 100 Hz or so) and correct either the transmitter or
receiver to more closely match them up.

Also, when you were using 3.4, were you using UHD or libusrp(2)?

Tom

3

Hi Tom,

Thanks for your suggestions but unfortunately they did not work so far.
As per your suggestion, I have tried tuning the center frequency of the
receiver node according to the estimated frequency offset between the
receiver and the transmitter but it did not help :frowning:

I have again verified that the two aforementioned flow-graphs work fine
on gnuradio-3.4 when i) USRP1 radios are used with libusrp(2), ii) USRP
N200 radios are used with uhd: usrp source/sink. But the same setup does
not work with gnuradio-3.5 where I use uhd: usrp source/sink along with
USRP N200 radios. I am a bit surprised to see this weird behavior
because the frequency offset between two USRP N200 radios is usually on
the order of few hundreds of Hz while the frequency offset between two
USRP1 nodes is on the order of few KHz (and I have been able to
retrieve/decode the transmitted symbols via dbpsk on gnuradio-3.4 with
USRP1 radios successfully). So, I am a bit baffled now about what is
going on. I have also attached to this email my two flow-graphs for your
information. You will see that I have removed the LPF at the receiver,
decreased the sampling rate inside the two flow-graphs to 500K Sps
(because with a sampling rate of 1M Sps, if I run the
receiver flow-graph long enough then I start seeing overruns occurring
at a crazy rate). Moreover, I have now changed the payload of packet
encoder on the transmitter to 4 bytes so as to make sure that the packet
encoder packetizes every input sample and sends it with no delay. With
this setting, 500K/(8824)= ~325.520 symbols should be transmitted
every second. So, I should be receiving 325.520*N samples(or symbols) in
the file sink if I run the receiver flow-graph for N seconds (assuming
transmitter is already on), but I rather find the file sink just empty.
Is there any recent change/upgrade in the functionality of packet
encoder/decoder, uhd: usrp sink/source etc (which might be causing this
phenomena)? Lastly, I did simulated the flow-graph you provided me and
was able to write the decoded symbols in a file and later read them from
octave. What are your thoughts now?

Thanks a lot for the help.
Jon

From: Tom R. [email protected]
To: Jon W. [email protected]
Cc: “[email protected]” [email protected]
Sent: Saturday, March 31, 2012 9:34 AM
Subject: Re: [Discuss-gnuradio] dbpsk on gnuradio-3.5 and Ubuntu 11.10

Jon,

I’m not sure why this would change between 3.4 and 3.5, but my guess
is that it’s something to do with the frequency offset, which tends to
be the biggest problem with these things. I’ve attached a GRC example
that runs what you want in a loopback simulation (you need gr-qtgui
installed for this). It looks good here, but I haven’t tried going
over the air. This was just to make sure the data and everything were
passing through the algorithm blocks correctly.

Try figuring out what the frequency difference is between your two
USRPs (to about 100 Hz or so) and correct either the transmitter or
receiver to more closely match them up.

Also, when you were using 3.4, were you using UHD or libusrp(2)?

Tom

4

On 04/01/2012 06:44 AM, Jon W. wrote:

same setup does not work with gnuradio-3.5 where I use uhd: usrp
Sps, if I run the receiver flow-graph long enough then I start seeing
I did simulated the flow-graph you provided me and was able to write
Sent: Saturday, March 31, 2012 9:34 AM
passing through the algorithm blocks correctly.

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
I have almost the same problem when I use bfsk. My platform is USRP E100
with the daughter board RFX2400 or RFX 900. I am still using GNU Radio
3.4. When I transmit data through the loopback which does not use RF
frontend, my RX can receive data successfully but once the RF frontend
is used there would be nothing at the RX. I used gr.channel_model to
simulate the channel, it seems bfsk is only sensitive to frequency
offset. When I set the parameter ‘frequency_offset’ to less than 0.3, RX
can receive data with some packet lost. If the frequency offset is
larger than 0.3, RX has no output. I don’t know what is the unit of this
frequency offset. Is that KHz or just Hz?
In real RF channel, even when I connect the two daughter boards with
wire, RX still can not receive anything.
I know someone has succeeded in using bfsk with his GNU Radio version
3.1.3( That is too old) and platform USRP. His code is almost the same
with me since we are refer to the same code(cc1k.py, cc1k_sos_pkt.py,
cc1k_txtext.py and cc1k_rxtest.py). I don’t know whether the version
discrepancy of GNU Radio affect the result? If so, why?

Br,

Zhonghua

5

Hi Tom and Jon,

I have been trying the same thing but in vain. I am working in 10.10
Ubuntu with 3.5.1 gnuradio, and I am getting the same problem that is
nothing is being stored at the file sink end when run over the air (So I
am pretty sure that the problem is not with the OS upgrade).

I even set the actual frequencies of the two usrp2s to be 2300M at which
no warning was displayed. So I presume the frequency offset problem that
Tom was talking about is taken care off.

I even tried using file source at tx end, but it resulted similarly.

Also, all my simulations are running perfectly when using channel model.

Please reply with your thoughts/any updates, ASAP.

Also, could you please let me know how to use multiple uspr2s using MIMO
cable for transmission.

Thanks in advance.
Sahil Singla
Senior Undergrad, IIT Delhi

Jon W. wrote in post #1054461:

Hi Tom,

Thanks for your suggestions but unfortunately they did not work so far.
As per your suggestion, I have tried tuning the center frequency of the
receiver node according to the estimated frequency offset between the
receiver and the transmitter but it did not help :frowning:

I have again verified that the two aforementioned flow-graphs work fine
on gnuradio-3.4 when i) USRP1 radios are used with libusrp(2), ii) USRP
N200 radios are used with uhd: usrp source/sink. But the same setup does
not work with gnuradio-3.5 where I use uhd: usrp source/sink along with
USRP N200 radios. I am a bit surprised to see this weird behavior
because the frequency offset between two USRP N200 radios is usually on
the order of few hundreds of Hz while the frequency offset between two
USRP1 nodes is on the order of few KHz (and I have been able to
retrieve/decode the transmitted symbols via dbpsk on gnuradio-3.4 with
USRP1 radios successfully). So, I am a bit baffled now about what is
going on. I have also attached to this email my two flow-graphs for your
information. You will see that I have removed the LPF at the receiver,
decreased the sampling rate inside the two flow-graphs to 500K Sps
(because with a sampling rate of 1M Sps, if I run the
receiver flow-graph long enough then I start seeing overruns occurring
at a crazy rate). Moreover, I have now changed the payload of packet
encoder on the transmitter to 4 bytes so as to make sure that the packet
encoder packetizes every input sample and sends it with no delay. With
this setting, 500K/(8824)= ~325.520 symbols should be transmitted
every second. So, I should be receiving 325.520*N samples(or symbols) in
the file sink if I run the receiver flow-graph for N seconds (assuming
transmitter is already on), but I rather find the file sink just empty.
Is there any recent change/upgrade in the functionality of packet
encoder/decoder, uhd: usrp sink/source etc (which might be causing this
phenomena)? Lastly, I did simulated the flow-graph you provided me and
was able to write the decoded symbols in a file and later read them from
octave. What are your thoughts now?

Thanks a lot for the help.
Jon

From: Tom R. [email protected]
To: Jon W. [email protected]
Cc: “[email protected]” [email protected]
Sent: Saturday, March 31, 2012 9:34 AM
Subject: Re: [Discuss-gnuradio] dbpsk on gnuradio-3.5 and Ubuntu 11.10

Jon,

I’m not sure why this would change between 3.4 and 3.5, but my guess
is that it’s something to do with the frequency offset, which tends to
be the biggest problem with these things. I’ve attached a GRC example
that runs what you want in a loopback simulation (you need gr-qtgui
installed for this). It looks good here, but I haven’t tried going
over the air. This was just to make sure the data and everything were
passing through the algorithm blocks correctly.

Try figuring out what the frequency difference is between your two
USRPs (to about 100 Hz or so) and correct either the transmitter or
receiver to more closely match them up.

Also, when you were using 3.4, were you using UHD or libusrp(2)?

Tom

6

Does anyone solved this problem. I am having the same problem…Thanks
in advance

Regards
Praveen

7

I don’t think the DBPSK module works in 3.5. I have been having problems
too in both Debian and Ubuntu. For an experiment, I doubled the filter
bandwidths and this helped quite a bit for the first few packets before
reverting to not working again - with the same data in loopback. It is
probably a buffers error but there is nothing in the debug.

Praveen Kumar MG wrote in post #1087584:

Does anyone solved this problem. I am having the same problem…Thanks
in advance

Regards
Praveen