On 04/01/2012 06:44 AM, Jon Watson wrote:
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 <t...@trondeau.com>
*To:* Jon Watson <jon_wat...@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
_______________________________________________
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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
