discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] 4-to-32 bit symbol mapper block


From: Christopher Friedt
Subject: Re: [Discuss-gnuradio] 4-to-32 bit symbol mapper block
Date: Sat, 3 Jan 2015 15:56:52 -0500

On Sat, Jan 3, 2015 at 1:38 PM, Marcus Müller <address@hidden> wrote:
> Then: If I understand you correctly, what you have is an input stream of
> unsigned (32 bit)ints, each int containing exactly one bit of information:
> 0x00000000, 0x00000001, 0x00000001, 0x00000000, and so forth.
> This format is especially wasteful on memory, and wherever GNU Radio
> uses unpacked bits, they are usually transported as unsigned char items
> (giving you a memory overhead of only 8x instead of 32x), so there's
> blocks for that particular job (packed_to_unpacked and the reverse).

For sure it's wasteful on memory. I usually just try getting something
working before optimizing it. Unit tests pass now, thankfully :-)

So, assuming that I may do this basing my class on the
sync_interpolator class, I'd like to pack my input and output -
ideally as 32 or 64-bit ints (whatever the wordsize is - 64 bits in my
case). From what I've read, I can only expect to pack up to 32-bits
into each integer-type output item [1], and therefore will
unfortunately only be able to pack up to 4-bits into each integer-type
input. Is that correct, or is there also a 64-bit output type?

I guess if I'm packing 4 bits into one byte on the output and 32-bits
into an int on the output, I would probably just use a sync block with
a ratio of 1-1, and e.g. add an example to remind the user to use the
Pack 4 Bits block on the input.

It was an interesting exercise to learn a bit about some of gr's
various blocks :-)

> Since I really *want* to understand what is happening here, I'll go

I wrote most of my code snippet when I was 1/2 asleep at 2 am last
night! Sorry for subjecting you to it!

[1] 
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#What-are-items-in-a-flowgraph



reply via email to

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