On Thu, Apr 12, 2012 at 10:28 PM, Alick Zhao <[email protected]> wrote: > On Thu, 12 Apr 2012 13:33:01 -0400, Tom Rondeau wrote: >> >> 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 > > 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
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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
