Re: [Discuss-gnuradio] gr_unpack_k_bits_bb, its inverse, and higher order constellations

[Mattias Kjellsson]

Tom Rondeau wrote:
> On Thu, Mar 4, 2010 at 10:28 AM, Mattias Kjellsson <address@hidden> wrote:
>   
>> Eric Blossom wrote:
>>     
>>> I assume that you mean 1 byte per symbol.
>>> I suggest that you create *_ci and *_ii versions that handle 32-bits.
>>>
>>> Eric
>>>       
>> You are correct, one byte per symbol. Or one symbol per byte, whichever
>> way one wants to look at it.
>> To clarify what the custom block does is that it takes K bytes with 1
>> significant bit (in lsb, from a glfsr or similar) and turns it into 1
>> byte with K significant bits. Then it's just to feed these new, "packed"
>> (is this the word for it?), bytes into the chunks_to_symbols_bc- block,
>> producing one symbol for every byte.
>>
>> Is this really stupid, or has it just not been done yet? I assume that
>> there are more people working with more signal- points than two in their
>> constellations. But at the same time it seems like I'm wasting a lot of
>> resources on copying bytes with only two or three (qpsk, qam16)
>> significant bits in them...
>>
>>
>> //Mattias
>>     
>
> Have you looked at
> gnuradio-core/src/python/gnuradio/blks2impl/dqpsk.py (and qam8, qam16,
> qam64, and qam256.py)? They handle the modulation and demodulation
> parts of the TX and RX. We don't have a good synchronization scheme,
> but I think these do what you want.
>
> Tom
>   
I know of them, and have looked at them, but nothing more. Since I don't
speak python very well, I try to do everything in c++.

I have tried to use pilots mixed in every few data- symbols and
compensate the data- symbols using these known symbols. I'm getting kind
of good results, although I think the custom early/late gate sampler I
wrote has a settling time way to long  (between 900 and 3000 symbols
depending on which constants I put in). I'll try to rewrite the M&M-
sync- block to utilize the slicer_45deg(), and see what results I get
with that. From what I can tell from the paper pointed to by the header-
file, the optimized M&M- loop should be able to handle at least QPSK,
and have a way shorter settling time than 900 symbols.

I think the pilot- compensation code should still work and compensate
any screw to the constellation.

I'm getting all exited just writing about it ;) I'll let you know how it
goes.
//Mattias