discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Rondeau
Subject: Re: [Discuss-gnuradio] gr_unpack_k_bits_bb, its inverse, and higher order constellations
Date: Thu, 4 Mar 2010 10:49:39 -0500

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]