Dear all,
I am working with 3 people on a project involving GNU Radio and USRP1.
We
have tried to implement a simple point to point digital communication
system in GRC involving DQPSK modulation. Using a vector source we are
sending a finite stream of zeros and ones (the vector source has Repeat
set
to yes). On the receiver side, what we receive is really very strange:
The
same stream of zeros and ones, but with extra zeros in between our
actual
data. For example, we send three ones and three zeros, but what we
receive
is a one followed by seven zeros, another one followed by seven zeros,
another one followed by seven zeros, and then a zero followed by seven
zeros e.t.c. We tried to experiment more by using the ‘KEEP 1 in N’
block
and the ‘DECIMATING FIR FILTER’, but things are not working out the way
they should.
I am also attaching a snapshot of the .grc file for your reference.
Please
tell us the reason why these extra zeros are present between our data
bits,
and the way to combat this effect (remember that the decimating fir
filter
and keep 1 in N block are not showing the desired output). Any kind of
help
is appreciated in advance.
You do not need to use throttles when using a UHD sink/source, because
the device provides timing for the flowgraph.
Remove the throttles and try again. If you still see the failure I’d
say you are not achieving symbol sync.
-John
Dear John,
Thank you for such a prompt reply. Okay, we will remove the throttle
blocks
just now. But can you guide us how to achieve symbol synchronization
then?
Best Regards,
Huzaifa
John M. wrote:
ones and three zeros, but what we receive is a one followed by seven
desired output). Any kind of help is appreciated in advance.
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
View this message in context:
http://old.nabble.com/Problem-with-USRP!-tp33653047p33653144.html
Sent from the GnuRadio mailing list archive at Nabble.com.
We just removed the throttle blocks and the same problem remains. Please
let
us know how to achieve symbol synchronization.
huzaifazafar108 wrote:
is really very strange: The same stream of zeros and ones, but with
our data bits, and the way to combat this effect (remember that the
Discuss-gnuradio Info Page
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
View this message in context:
http://old.nabble.com/Problem-with-USRP!-tp33653047p33653150.html
Sent from the GnuRadio mailing list archive at Nabble.com.
We just removed the throttle blocks and the same problem remains. Please let
us know how to achieve symbol synchronization.
Well, you’re using DPSK, but not using a differential encoder on the TX
side, nor a differential decoder on the RX side.
extra zeros in between our actual data. For example, we send three
decimating fir filter and keep 1 in N block are not showing the
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
Dear Marcus,
I truly appreciate your prompt reply. However, I am not sure what should
I
put in the ‘modulus’ field of the block. By hit and trial, wrong outputs
are
emerging. Please guide.
Best Regards,
Huzaifa
Marcus D. Leech wrote:
Dear John,
John M. wrote:
On 04/08/2012 01:58 PM, Huzaifa Zafar wrote:
zeros, another one followed by seven zeros, another one followed by
Discuss-gnuradio mailing list
http://www.sbrac.org
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
View this message in context:
http://old.nabble.com/Problem-with-USRP!-tp33653047p33653178.html
Sent from the GnuRadio mailing list archive at Nabble.com.
A few more things:
-
You have both the receive and transmit portions assigned to TX/RX.
This only works if you run in half-duplex mode and stop streaming to the
USRP. This is not the case.
-
Note the difference between sample rate, symbol rate, and bit rate.
symbol_rate = sample_rate / samples_per_symbol
bit_rate = sample_rate/bits_per_symbol
I think there are issues with packing/unpacking of bits. The
requirements for packing and unpacking aren’t completely consistent
across the mod/demods within GNU Radio. Let me experiment real quick
and get back to you.
-John
Dear John,
Waiting for your response…
And the reason for using TX/RX is that we connected the antennas on
TX/RX
ports on the daughtercard (in both transmitter and receiver).
Thanks,
Huzaifa
John M. wrote:
huzaifazafar108 wrote:
source has Repeat set to yes). On the receiver side, what we receive
Please tell us the reason why these extra zeros are present between
[email protected]
Principal Investigator
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
View this message in context:
http://old.nabble.com/Problem-with-USRP!-tp33653047p33653209.html
Sent from the GnuRadio mailing list archive at Nabble.com.
For the vector source it looks like you’re using [1,1,1,0,0,0].
Perhaps the rest is getting cut-off, but if not then I would change
this to use a long random vector for the testing. If you are using
[1,1,1,0,0,0] repeated then the four symbols won’t be used with
similar frequency, which might make things more difficult.
Also the differential encoding and decoding should be taken care of
within the DPSK mod and demod blocks, so that should be OK.
On Sun, Apr 8, 2012 at 2:25 PM, huzaifazafar108
It doesn’t matter where you put your antenna… Ask yourself a
fundamental question: When you assign both a receive chain and a
transmit chain to the same antenna port in a flow-graph, which one gets
access? How can you transmit and receive with the same frequency with
the same antenna without jamming the receiver? Take the time to
understand these issues before you do something that will damage the
receiver LNA’s.
Insert a unpacked-to-packed block between your vector source and the
modulator. bits per chunk = 1. See if this produces what you would
expect.
I also strongly suggest that you simulate these by looping the output of
the mod to the input of the demod. This removes the USRP as a variable
until you get a better understanding of how these blocks are working.
-John
expect.
I also strongly suggest that you simulate these by looping the output
of the mod to the input of the demod. This removes the USRP as a
variable until you get a better understanding of how these blocks are
working.
-John
John:
Based on the flow-graph they showed, they’re using two different USRP –
one for RX one for TX.
Thanks,
- Note the difference between sample rate, symbol rate, and bit rate.
emerging. Please guide.
us know how to achieve symbol synchronization.
throttle
because
On 04/08/2012 01:58 PM, Huzaifa Zafar wrote:
receive
to experiment more by using the ‘KEEP 1 in N’ block and the
decimating fir filter and keep 1 in N block are not showing the
Discuss-gnuradio mailing list
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
My mistake. Apologies for overlooking the details, Huzaifa.
Try the unpacked-to-packed block.
-John
Yeah we did try this sending the output of the mod to the input of the
demod
thing and it works fine. The problem is only introduced when we are
introducing an USRP sink for transmitter and USRP source for the
receiver.
We are trying the packed to unpacked thing and will get back to you very
soon.
Well may be it is a problem in the parameters of the USRP block. I would
be
glad if you can guide us the appropriate block (UHD, USRP or whatever)
and
their appropriate settings for the purpose.
Best,
Huzaifa
John M. wrote:
fundamental question: When you assign both a receive chain and a
I also strongly suggest that you simulate these by looping the output
Thanks,
- Note the difference between sample rate, symbol rate, and bit
-John
are
let
Thank you for such a prompt reply. Okay, we will remove the
You do not need to use throttles when using a UHD sink/source,
source has Repeat set to yes). On the receiver side, what we
We tried
that the
Discuss-gnuradio Info Page
http://www.sbrac.org
Discuss-gnuradio Info Page
–
View this message in context:
http://old.nabble.com/Problem-with-USRP!-tp33653047p33653315.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Sir,
Repeat is set to yes. I guess this is not the problem. Also, without the
USRP block (by sending the modulation output to the demoudalation
input),
everything is working the way it should.
Best,
Huzaifa
Ben R. wrote:
On Sun, Apr 8, 2012 at 2:25 PM, huzaifazafar108
Dear John,
John M. wrote:
ones and three zeros, but what we receive is a one followed by seven
desired output). Any kind of help is appreciated in advance.
http://old.nabble.com/Problem-with-USRP!-tp33653047p33653150.html
[email protected]
Discuss-gnuradio Info Page
–
View this message in context:
http://old.nabble.com/Problem-with-USRP!-tp33653047p33653317.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Yeah we did try this sending the output of the mod to the input of the
demod
thing and it works fine. The problem is only introduced when we are
introducing an USRP sink for transmitter and USRP source for the
receiver.
We are trying the packed to unpacked thing and will get back to you very
soon.
Well may be it is a problem in the parameters of the USRP block. I would
be
glad if you can guide us the appropriate block (UHD, USRP or whatever)
and
their appropriate settings for the purpose.
Best,
Huzaifa
John M. wrote:
fundamental question: When you assign both a receive chain and a
I also strongly suggest that you simulate these by looping the output
Thanks,
- Note the difference between sample rate, symbol rate, and bit
-John
are
let
Thank you for such a prompt reply. Okay, we will remove the
You do not need to use throttles when using a UHD sink/source,
source has Repeat set to yes). On the receiver side, what we
We tried
that the
Discuss-gnuradio Info Page
http://www.sbrac.org
Discuss-gnuradio Info Page
–
View this message in context:
http://old.nabble.com/Problem-with-USRP!-tp33653047p33653316.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Dear Team GNURadio,
Please get back to us. We are facing the same problem rite now as well.
Best Regards,
Huzaifa
huzaifazafar108 wrote:
within the DPSK mod and demod blocks, so that should be OK.
huzaifazafar108 wrote:
source we are sending a finite stream of zeros and ones (the vector
I am also attaching a snapshot of the .grc file for your reference.
Discuss-gnuradio mailing list
Discuss-gnuradio Info Page
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page
–
View this message in context:
http://old.nabble.com/Problem-with-USRP!-tp33653047p33660591.html
Sent from the GnuRadio mailing list archive at Nabble.com.
Huzaifa,
You may be experiencing a frequency offset between your two USRPs. Use
the
FFT sink on the receiving USRP to determine where the transmitted signal
lies, and offset the transmit or receive frequency appropriately so the
received signal is centered in the FFT. I don’t believe the DPSK blocks
include any sort of frequency estimation or offset correction.
–n
On Tue, Apr 10, 2012 at 3:55 AM, huzaifazafar108