Forum: GNU Radio GNU Radio and USRP baseband demodulation/decoding

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Einar T. (Guest)
on 2009-02-05 13:43
(Received via mailing list)
Hi all,

I am trying to use the USRP with the LFRX daughterboard to receive a
baseband signal coming from an external RF-frontend (the signal is
originally 2-PSK passband). I am a GNU Radio novice, and have some
difficulties understanding how to synchronize to and decode the
NRZI-coded baseband signal. I suppose ones the synchronization is done
the actual decoding will be easy.

I find it difficult to understand the process of synchronizing, what I
would like to see is some kind of guide or feedback on how to pick
exactly the correct number of samples for each symbol, enabling the
decoding of the signal symbol for symbol.

What would be the correct approach to solve this problem?

(I am in fact also having similar problems understanding this using the
OSSIE SDR system, so it may be a more general lack of understanding on
my behalf)

--
Einar T.
Johnathan C. (Guest)
on 2009-02-05 15:37
(Received via mailing list)
On Thu, Feb 5, 2009 at 3:42 AM, Einar T. <removed_email_address@domain.invalid>
wrote:

> signal symbol for symbol.
You will need to synchronize both to the transmitter carrier frequency
and phase, and as you mention, also to the bit timing.  For BPSK, GNU
Radio has a ready made block to do each.

Carrier recovery/synchronization can be done with a Costas loop, which
will track out any residual carrier resulting from not being tuned to
exactly the center frequency of your passband.  For symbol timing,
there is a resampling block implementing the Muller and Muller
algorithm.  This will track the "center of the bit" and fractionally
resample to 1 sample per symbol.  This is a common enough combination
that there is a combined block to do both with less CPU consumption
and better SNR (gr.mpsk_receiver_cc).

From there you can use a hard-decision slicer on the I channel, or
implement your own more sophisticated algorithm based on whether there
is error coding or some other known property of the transmit signal.

An example that implements all of the above (using separate Costas and
M&M blocks) may be found in the gnuradio-examples/python/digital-bert
directory.  This implements a continuous BPSK transmitter using a
known, scrambled bit sequence.  The receiver performs filtering,
synchronization, demodulation, retiming, bit slicing, and
descrambling, then measures the bit error rate and estimates the
receiver signal to noise ratio.  These values, plus the current
frequency offset and timing offset, are displayed once per second.

A more sophisticated example is the digital packet radio that
interfaces with the Linux TCP/IP stack, which may be found in the
python/digital directory.  This combines a configurable PHY later (bit
rate, modulation technique, etc.) with a (very) simple CSMA MAC.  This
is harder to study, and the details of the DQPSK implementation are
buried in another directory, but it is full-fledged 2-way half-duplex
radio link using GNU Radio.

Welcome to GNU Radio!

Johnathan
Einar T. (Guest)
on 2009-02-05 21:09
(Received via mailing list)
Johnathan C. wrote:

> Carrier recovery/synchronization can be done with a Costas loop,
> which will track out any residual carrier resulting from not being
> tuned to exactly the center frequency of your passband.  For symbol
> timing, there is a resampling block implementing the Muller and
> Muller algorithm.  This will track the "center of the bit" and
> fractionally resample to 1 sample per symbol.  This is a common
> enough combination that there is a combined block to do both with
> less CPU consumption and better SNR (gr.mpsk_receiver_cc).

I have been studying digital-bert example files, and will try to do
something similar. However I have a follow up questions.

How will the synchronization and carrier recovery function on my
baseband signal as there really is no carrier left after the down
conversion? My specific signal is down converted from 5.8 GHz to
baseband from an RF front end, which is not controlled by GNU Radio at
all. Would the blocks you mentioned function with the baseband signal if
the center frequency is specified to be 0 Hz?

> Welcome to GNU Radio!

Thank you! :)


--
Einar T.
Johnathan C. (Guest)
on 2009-02-05 23:22
(Received via mailing list)
On Thu, Feb 5, 2009 at 10:59 AM, Einar T. <removed_email_address@domain.invalid>
wrote:

> How will the synchronization and carrier recovery function on my
> baseband signal as there really is no carrier left after the down
> conversion? My specific signal is down converted from 5.8 GHz to
> baseband from an RF front end, which is not controlled by GNU Radio at
> all. Would the blocks you mentioned function with the baseband signal if
> the center frequency is specified to be 0 Hz?

Even after downconversion to 0 Hz IF, there will be a residual carrier
based on the frequency stability of the transmitter and receiver.  The
Costas loop block will track out this carrier until its output is
truly baseband.  Due to the difference in crystal timebases between
the transmitter and receiver (or relative motion causing Doppler),
there will also be a timing error, with the M&M block will handle.

Johnathan
Tachwali, Yahia (Guest)
on 2009-02-06 16:41
(Received via mailing list)
Hello Einar,

Knowing your modulation type can simplify your symbol and carrier
synchronization design. However, if your are not restricted with certain
modulation type and you just want to use an arbitrary modulation to get
you going then I suggest to use differential coding such as D-BPSK which
does not require coherent detection (no carrier synchronization is
required) and that can simplify your design.

I hope that help a little. If you are really after symbol
synchronization, I have read several publications by Dr.F.Harris and
Dr.C.Dick but they tend to do their implementations in FPGA.

Kind regards,
Yahia Tachwali
________________________________________
From: discuss-gnuradio-bounces+ytachwali=removed_email_address@domain.invalid
[discuss-gnuradio-bounces+ytachwali=removed_email_address@domain.invalid] On 
Behalf Of Einar
Thorsrud [removed_email_address@domain.invalid]
Sent: Thursday, February 05, 2009 5:42 AM
To: removed_email_address@domain.invalid
Subject: [Discuss-gnuradio] GNU Radio and USRP baseband
demodulation/decoding

Hi all,

I am trying to use the USRP with the LFRX daughterboard to receive a
baseband signal coming from an external RF-frontend (the signal is
originally 2-PSK passband). I am a GNU Radio novice, and have some
difficulties understanding how to synchronize to and decode the
NRZI-coded baseband signal. I suppose ones the synchronization is done
the actual decoding will be easy.

I find it difficult to understand the process of synchronizing, what I
would like to see is some kind of guide or feedback on how to pick
exactly the correct number of samples for each symbol, enabling the
decoding of the signal symbol for symbol.

What would be the correct approach to solve this problem?

(I am in fact also having similar problems understanding this using the
OSSIE SDR system, so it may be a more general lack of understanding on
my behalf)

--
Einar T.


_______________________________________________
Discuss-gnuradio mailing list
removed_email_address@domain.invalid
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Ed Criscuolo (Guest)
on 2009-02-06 18:07
(Received via mailing list)
Einar T. wrote:
 > Hi all,
 >
 > I am trying to use the USRP with the LFRX daughterboard to receive a
 > baseband signal coming from an external RF-frontend (the signal is
 > originally 2-PSK passband). I am a GNU Radio novice, and have some
 > difficulties understanding how to synchronize to and decode the
 > NRZI-coded baseband signal. I suppose ones the synchronization is
done
 > the actual decoding will be easy.
 >
 > I find it difficult to understand the process of synchronizing, what
I
 > would like to see is some kind of guide or feedback on how to pick
 > exactly the correct number of samples for each symbol, enabling the
 > decoding of the signal symbol for symbol.
 >
 > What would be the correct approach to solve this problem?


There are two different kinds synchronizing: bit level and packet
level.

For bit synchronizing, you'll want to use the clock recovery block
based on the M&M algorithm.  It will find the bits and resample
the data stream at the bit rate.  It requires a minimum of
2 samples per bit to work.  I've found that anywhere from 2-4
samples per bit works fine.

The output of the clock recovery block is still a stream of
"soft bits" that can take on any value between +1 and -1.  You
need to then put it thru a bitslicer to convert it to a stream
of 1's and 0's.

Once you have the actual binary bitstream, decoding NRZI is easy.
There's a custom block to do this provided in the "GMSK Spacecraft
Groundstation" project in CGRAN:

https://www.cgran.org/wiki/Projects

This project would be good for you to study, as it represents
a real-world application that does something very similar to
what you want, performing both bit and packet synchronization.

@(^.^)@  Ed
Einar T. (Guest)
on 2009-02-11 18:04
(Received via mailing list)
Ed Criscuolo wrote:
> Once you have the actual binary bitstream, decoding NRZI is easy.
> There's a custom block to do this provided in the "GMSK Spacecraft
> Groundstation" project in CGRAN:
>
> https://www.cgran.org/wiki/Projects
>
> This project would be good for you to study, as it represents
> a real-world application that does something very similar to
> what you want, performing both bit and packet synchronization.

Thank you. This was a very interesting project indeed. I will try to
reuse as much as possible.

I am also having problems testing the system as I go along. What I would
like to do is use a vector sink, and print the received samples to the
screen. Hover when I tried initially with only a vector source connected
directly to a vector sink, and using the read()-method, only "()" is
printed. This seems to be the case no matter where in the code the print
statement is issued. (Using "print tb.gr_vector_sink_x_0.data()")

What is wrong? And what would be the easiest way to verify the received
samples?

- Einar
This topic is locked and can not be replied to.