Hi all,
I am learning to do some channel estimation using GNU Radio and USRP.
Currently I have done some simulation with file_sink/source and
gr_channel_model in GNU Radio, but I do not quite understand the
results. I’ll explain my settings and simulation results below and hope
someone can give me some hints.
My set up is based on digital_bert_tx/rx.py under
gr-digital/examples/narrowband. I removed the scrambler/descrambler
block and also use bpsk modulation so that the ideal constellation
points should be just 1+0j. Then I add a channel for simulation (in the
rx part):
self._chn = gr.channel_model(options.noise, 0, 1.0, [p2c(0.8, 30)])
where options.noise specify the additive noise voltage, and p2c(…)
give a channel h = 0.8 * exp(j*pi/6).
To simulate I use tx part to write to a data file ‘air.dat’, then use rx
part to receive and demod the signal.
The results are attached as three figures, each with the name indicating
the noise voltage specified on the command line. The black 'o’s show the
symbols right after the simulation channel, and the margenta points show
the symbols after time_recov, and red ones show the constellation points
just before decision maker. The blue ones are meant to be estimated
channel info, which now is not correct.
Here are my questions:
-
The figures show that when noise is 1e-5 (which means SNR is about
100dB since the signal strength at tx is 1), the constellation point
after time_recov matches the received signal quite well and the
constellation point before decision maker is around 1+0j. So it means
that the Costas loop between the two recovers the signal from the phase
rotation caused by the channel?
-
When the noise is set to 1e-3, the constellation points after
time_recov form a unit circle. I wonder why the phases become so random.
-
When the noise is set to 1e-1, and the corresponding SNR is about
20dB(which I think is not quite low for practical application), both the
constellation points after time_recov and before decision maker appear
along side the unit circle. Also the BER is as high as about 0.5. Why
the performance of the demodulator becomes so bad? Maybe some parameters
of the Costas loop can (or should) be adjusted?
-
I notice that the script use digital_constellation_receiver_cb block.
I doubt this block is a combination of digital_mpsk_receiver_cc and
constellation decoder. Particularly, I found the macros VERBOSE_MM and
M_TWOPI in digital_constellation_receiver_cb.cc unused. Is it intended?
Oh I need to mention that the simulation is based the source code GNU
Radio v3.5.3. I am still new to SDR so I really appreciate your help.
2012/4/12 Alick Z. [email protected]:
block and also use bpsk modulation so that the ideal constellation
100dB since the signal strength at tx is 1), the constellation point
constellation points after time_recov and before decision maker appear
Radio v3.5.3. I am still new to SDR so I really appreciate your help.
–
alick
Alick,
Why are you using 1’s and 0’s? Is this just for some academic exercise
or are you trying to do something with this kind of a constellation?
I’m only asking out of curiosity.
It also looks like you’re heavily biasing the output to be all 1’s and
very few 0’s. That’s going to be problematic for the recovery loops.
In particular, the FLL uses bandedge filters that rely on the excess
bandwidth. If you are never, or rarely, transitioning between symbols,
the excess bandwidth of the signal is going to be pretty much absent.
So I’d add the randomizer back in and see how that works.
For simulation purposes, you can probably go in and remove the FLL
from the receiver chain in generic_mod_demod.py.
Tom
On Thu, 12 Apr 2012 13:33:01 -0400, Tom R. wrote:
bandwidth. If you are never, or rarely, transitioning between symbols,
the excess bandwidth of the signal is going to be pretty much absent.
So I’d add the randomizer back in and see how that works.
For simulation purposes, you can probably go in and remove the FLL
from the receiver chain in generic_mod_demod.py.
Tom
Hi Tom, thank you for pointing out the issue of my set up. I want to
embed channel estimation function into the receiver with training
sequences (here all 1’s). In a practical configuration, I think frame
structure with preamble containing training sequences and (randomized)
payload should work. (Is it so?) But now I haven’t looked deep into the
packet/frame related code, and I am not sure how to find frame header
right on constellation. (Could you give some advice?) So I just begin
with the set up above, which is problematic for the recovery loops.
Besides, yes I will add the scrambler back in and do some tests.
alick
On Thu, Apr 12, 2012 at 10:28 PM, Alick Z. [email protected]
wrote:
In particular, the FLL uses bandedge filters that rely on the excess
embed channel estimation function into the receiver with training
sequences (here all 1’s). In a practical configuration, I think frame
structure with preamble containing training sequences and (randomized)
payload should work. (Is it so?) But now I haven’t looked deep into the
Yes, you should be able to use that. As long as you know the data, you
can get the channel estimation.
packet/frame related code, and I am not sure how to find frame header
right on constellation. (Could you give some advice?) So I just begin
with the set up above, which is problematic for the recovery loops.
Besides, yes I will add the scrambler back in and do some tests.
alick
Look at the gr_framer_sink_1 (in gnuradio-core/src/lib/general). It’s
a state machine that pulls apart the header info.
Tom