Re: [Discuss-gnuradio] constellation algorithm at benchmark

[yeran]

Hi Dear Nathan,

Thank you for your reply.

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

> Date: Wed, 17 Jul 2013 11:55:19 -0400
> Subject: Re: [Discuss-gnuradio] constellation algorithm at benchmark
> From: address@hidden
> To: address@hidden
> CC: address@hidden
>
> On Wed, Jul 17, 2013 at 11:20 AM, yeran <address@hidden> wrote:
> > Hi Dear All,
> >
> > 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?
>
> >
> > Thanks in advance. Look forward to any suggestions!
> >
> > Ada
> >