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.
Senior Undergrad, IIT Delhi
Jon W. wrote in post #1054461:
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/(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.
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
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)?