Recently, I’ve been working with benchmark_rx.py in narrowband. I’m
using bpsk.
I don’t really understand what happens in the demodulator.
In the generic_mod_demod.py, the receiver block act as the constellation
or mapping function. Previously, I thought for bpsk, it is just if the
sample as complex number’s real part is bigger than 1, then it is mapped
as 1, otherwise, it is mapped as 0. But apparently, it is not what all
happens there, since the output of the receiver (rx_unpack.8b) is not
the same result.
I noticed there are some phase error, and frequency error check. Anyone
has any idea how these parameters work, how it will effect the mapping
result?
Thanks in advance. Look forward to any suggestions!
Recently, I’ve been working with benchmark_rx.py in narrowband. I’m using
bpsk.
I don’t really understand what happens in the demodulator.
In the generic_mod_demod.py, the receiver block act as the constellation or
mapping function. Previously, I thought for bpsk, it is just if the sample
as complex number’s real part is bigger than 1, then it is mapped as 1,
I think you want to make the decision on if the real part is bigger
than 0. Deciding if real(symbol) > 1 would be more like ASK.
otherwise, it is mapped as 0. But apparently, it is not what all happens
there, since the output of the receiver (rx_unpack.8b) is not the same
result.
As you probably noticed since you looked at generic_mod_demod the
demodulator is actually a hierarchical block with the following
connections:
input → agc → FLL → RRC filter → clock sync → constellation
receiver [-> differential decoder[ [-> symbol mapper] → bit unpacker
The RRC filter is a decimating filter that takes number of samples per
symbol and outputs a symbol (a single complex number). This is (or
should be) a matched filter to the one on the RRC on the transmitter
which outputs samples per symbol for every symbol input.
The constellation receiver is converting that symbol to a bit (in the
case of BPSK, or bits for higher PSKs). If you look in
digital_constellation_receiver you’ll see the general_work function
calls d_constellation->decision_maker_pe. For BPSK we gave this block
a BPSK constellation. It’s decision_maker is defined in
digital_constellation; just search for bpsk in there and you’ll see
the decision is made based on the sign of the real part.
The final part of the generic demod is a bit unpacker which will
output regular chars the way you would expect (so your whole bit
stream is the same as what you put in to the modulator).
I noticed there are some phase error, and frequency error check. Anyone has
any idea how these parameters work, how it will effect the mapping result?
I haven’t ever touched these, but I think the setup_logging stuff just
dumps lots of data like phase error to files. I’m not sure if that
answers your question or not though. What checks are you talking
about?
First, you are absolutely right about the decision making, it is based
on if the real part is bigger than 0. It is a typo in my last email.
Second, I totally agree with the flow graph you talked about in
generic_mod_demod. And I looked into the general_work function in the
file digital_constellation_receiver. For BPSK, (I’m not using DBPSK),
the decision is made based on the sign of the real part.
When I use logging, I can put into file the result of each block. The
rx_time_recov.32fc is the data after time_recov block, and before the
receiver block. The rx_unpack.8b is after the unpack block.
But here is my problem. As I didn’t use differential or gray_code, and
the unpack block is only the format changing, not influence the value of
the decision result. So I think the data in rx_unpack.8b should be
one-to-one match to the samples in rx_time_recov.32fc. However, it is
not always the case.
For instance, I take one packet as an example. Even though I can find
the exact packet in rx_unpack.8b, when tracing back to the relevant
address in rx_time_recov.32fc (the relevant address is 8 times the
address in rx_unpack.8b), the samples not always obey the rule what we
assume – the decision is not always made based on the sign of the real
part. And it seems to be irregular.
I read through the c++ file but i think the phase error has no
contributions to decision_maker_pe. The advance_loop() function in
phase_error_tracking() only records the error instead of updating this
information to decision part.
I dont understand how does the gnuradio get the correct decoding result
with the samples. do u have any clues about that?
Thanks!
Ada
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.