Re: [Discuss-gnuradio] Pack k bits?

[Tom Rondeau]

On Wed, Mar 28, 2012 at 8:48 AM, Nowlan, Sean
<address@hidden> wrote:
> I want to take an input stream of bytes in which only one LSB is relevant
> (e.g., the output of the GR GLFSR block) and pack these bits into bytes with
> k relevant bits. For example, I’d like to take a stream of raw bits
> generated by the GLFSR and feed them to an M-PSK modulator, which requires
> chunks with k=log2(M) bits. Unfortunately I haven’t found this to be
> straightforward. There is no “pack_k_bits” module that I could find, so I
> tried using  unpacked_to_packed_bb and packed_to_unpacked_bb. They are not
> working like I would expect. For instance, here’s an example in Python:
>
> …
>
> data = [1,0,1,0, 0,0,1,0, 1,1,1,0, 0,1,1,0]

Ok, finally got some time to work through this.

What's happening here is that first you are packing these into bytes,
but in reverse order since you're taking the LSB first. So the output
of self.pack is:
[01000101, 01100111] --> 0x45, 0x67

Then you are telling the upacked_to_packed to read the LSB first and
unpack from there where the output stream has 2-bits per byte:

[01, 00, 01, 01 | 01, 10, 01, 11]  --> unpack 2, LSB, read left to right

That means that you are reading each byte out from left to right and
putting them into bytes two at a time. In other words:

Byte 1: [01, 00, 01, 01]
    01 --> 10 (2)
    01 --> 10 (2)
    00 --> 00 (0)
    01 --> 10 (2)

Byte 2: [01, 10, 01, 11]
    11 --> 11 (3)
    01 --> 10 (2)
    10 --> 01 (1)
    01 --> 10 (2)

If you want it your way, use gr.GR_MSB_FIRST for the gr.unpacked_to_packed_bb.

Working through it this way, I'm pretty sure what's happening is
correct. There might be a confusion about byte order and how the
unpacked_to_packed with LSB first swaps things around on you. For
instance, you said that "data = [1,0,1,0, 0,0,1,0, 1,1,1,0, 0,1,1,0]
# 45 67", but they are just bits in a string of bytes at that point,
so you're trying to read it backwards. That vector is actually [0xA2,
0xE6].

Of course, now I'm confused... but I'm pretty sure the way that it's
working is correct.

Tom


> self.source = gr.vector_source_b(data, False, 1)
>
> self.pack = gr.unpacked_to_packed_bb(1, gr.GR_LSB_FIRST)
>
> self.unpack = gr.packed_to_unpacked_bb(2, gr.GR_LSB_FIRST)      # stuff 2
> bits into LSB of each output byte
>
> self.head = gr.head(gr.sizeof_char, 8)                              # should
> have 16/2 = 8 output bytes
>
> self.sink = gr.file_sink(gr.sizeof_char, “out.bin”)
>
> self.connect(self.source, self.pack, self.unpack, self.head, self.sink)
>
> …
>
>
>
> This gives the following:
>
> $ hexdump -C out.bin
>
> 0000000  02 02 00 02 03 02 01 02                           |……..|
>
> 0000008
>
>
>
> But I would expect the following:
>
> 0000000  01 01 00 01 03 01 02 01                           |……..|
>
> 0000008
>
>
>
> Notice that the two least significant bits are in reverse order. Any clue
> what’s going on here?
>
>
>
> Thanks,
>
> Sean
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>