Re: [Discuss-gnuradio] Pack k bits?

[Nowlan, Sean]

Any comment on this? I think the current implementation of gr_packed_to_unpacked_bb(int k, gr_endianness_t endianness) puts bits in an incorrect order when k > 1 and endianness = gr.GR_LSB_FIRST.

 

From: discuss-gnuradio-bounces+address@hidden [mailto:discuss-gnuradio-bounces+address@hidden On Behalf Of Nowlan, Sean
Sent: Wednesday, March 28, 2012 9:26 AM
To: address@hidden
Subject: Re: [Discuss-gnuradio] Pack k bits?

 

I think it would work if I modified gnuradio/gnuradio-core/src/lib/gengen/gr_packed_to_unpacked_XX.cc.t (line 119) to the following:

 

x = (x>>1) | (get_bit_le(in, index_tmp) << (d_bits_per_chunk - 1) );

 

-OR-

 

x |= get_bit_le(in, index_tmp) << j;

 

I haven’t tested, but I think these are functionally equivalent. Does this change sound reasonable?

 

-- Sean

 

From: discuss-gnuradio-bounces+address@hidden [mailto:discuss-gnuradio-bounces+address@hidden On Behalf Of Nowlan, Sean
Sent: Wednesday, March 28, 2012 8:49 AM
To: address@hidden
Subject: [Discuss-gnuradio] Pack k bits?

 

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 = "" 0,0,1,0, 1,1,1,0, 0,1,1,0]                                # 45 67

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