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: [email protected] > To: [email protected] > CC: [email protected] > > On Wed, Jul 17, 2013 at 11:20 AM, yeran <[email protected]> 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 > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
