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

[Tom Rondeau]

On Thu, Mar 4, 2010 at 11:38 AM, Mattias Kjellsson <address@hidden> wrote:
> 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


Matt and I wrote a resampler based on polyphase filterbanks a few
months ago. It's called gr_pfb_clock_sync_xxf (in the filter
directory). It works really well for any PAM signal (we've tested it
with PSK and QAMs successfully). You can see how its used in the new
dbpsk2.py and dqpsk2.py files.

Tom