Re: [Discuss-gnuradio] Pack k bits?

[Ben Reynwar]

So I'll add a bit more detail, and bump the thread because I don't
understand this either.

If we apply the following unpackings to a byte of value 69 we get:

gr.packed_to_unpacked_bb(1, gr.GR_LSB_FIRST)  -> (1, 0, 1, 0, 0, 0, 1, 0)
gr.packed_to_unpacked_bb(1, gr.GR_MSB_FIRST) -> (0, 1, 0, 0, 0, 1, 0, 1)
gr.packed_to_unpacked_bb(2, gr.GR_LSB_FIRST) -> (2, 2, 0, 2)
gr.packed_to_unpacked_bb(2, gr.GR_MSB_FIRST) -> (1, 0, 1, 1)

packed_to_unpacked and unpacked_to_packed are consistent with one another.

On Fri, Mar 30, 2012 at 1:33 PM, Nowlan, Sean
<address@hidden> wrote:
> 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: address@hidden
> [mailto: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: address@hidden
> [mailto: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 = [1,0,1,0, 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
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>