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 <sean.now...@gtri.gatech.edu> 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: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org > [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org] On > Behalf Of Nowlan, Sean > Sent: Wednesday, March 28, 2012 9:26 AM > To: discuss-gnuradio@gnu.org > 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+sean.nowlan=gtri.gatech....@gnu.org > [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech....@gnu.org] On > Behalf Of Nowlan, Sean > Sent: Wednesday, March 28, 2012 8:49 AM > To: discuss-gnuradio@gnu.org > 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 > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
