The idea of the u8 data type is that it does a raw dump of the data. So if you receive it, then cast the buffer as uint32_t *, you'll get your data.
On a side note, sc16 is actually a bit different. Not only do we have signed 16-bit ints, we also have to take special care with endianness and, more annoyingly, I+Q ordering. Cheers, Martin On 08.12.2015 07:23, Jason Matusiak wrote: > (I originally responded to the wrong mailing list....) > >> No, there's not. If there's demand, we can add that of course. Do you >> actually need to *stream* u32 types? Will u8 work for you? You can >> re-cast it to whatever in your application. > > Martin, I doubt that there is a high demand, I just sort of assumed > since the standard transport was for complex values (a pair of 16b ints) > that a 32b int was probably a baked in option. > > I am sure I can make 8b work, I'll just have to work through how best to > shift it. Are there any gotchyas I need to be aware of (like handling > the smaller size within the CHDR frames differently), etc? > > Thanks! > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
