Forum: GNU Radio dbpsk on gnuradio-3.5 and Ubuntu 11.10

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

On Thu, Mar 29, 2012 at 10:04 AM, Jon Watson <jon_watson@rocketmail.com> 
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

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 :(

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/(8*8*24)= ~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 Rondeau <tom@trondeau.com>
To: Jon Watson <jon_watson@rocketmail.com>
Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
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

On 04/01/2012 06:44 AM, Jon Watson 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
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
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

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 Watson 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 :(
>
> 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/(8*8*24)= ~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 Rondeau <tom@trondeau.com>
> To: Jon Watson <jon_watson@rocketmail.com>
> Cc: "discuss-gnuradio@gnu.org" <discuss-gnuradio@gnu.org>
> 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

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



Regards
Praveen

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