discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] Sample Type Conversions


From: Peter Witkowski
Subject: [Discuss-gnuradio] Sample Type Conversions
Date: Sat, 18 Aug 2018 11:58:37 -0600

Hello,

I have a rather dumb question, and I'm surprised I haven't run into this previously.

I want to convert back and forth between samples of floats and shorts. I noticed the following conventions for samples are used by various devices/blocks:

The various conversion blocks (like short_to_float) take a “scale” parameter to do a multiplication or division by the scale to get the data within a specific range. I guess my question is, which scale is generally used?

For example, if I have a stream of shorts that I want to convert to floats, it stands to reason that I should probably use 32,768 as the scale. This ensures that I get values between -1.0 and +1.0. The resulting stream of samples won't ever totally reach +1.0, but that's probably OK. Using 32,767 would mean that if my samples ever reach -32,768 (e.g., in the case of a 16-bit ADC) I would be outside the desired range for floats. If I want to convert back to my original set of samples, I should use 32,768 again.

However, let's say that my converted stream had lots of math done on it (or alternatively, I'm just starting with a stream of floats) and now it can span the full range of -1.0 to +1.0. If I use my old scale of 32,768, I will overflow, since 1.0 * 32,768 = 32,768, which is outside the range of shorts. Does this mean that I now have to use 32,767 for the conversion back to shorts (which also means that I can't represent -32,768 as the minimum value)? A more general question is how does the block compensate for overflow (i.e., I'm assuming saturation is desired here instead of wrapping around)? My best theory is that the block uses VOLK, which in turn uses various SIMD instructions that perform saturating arithmetic (am I on the right track here?).

Thanks in advance for the assistance.

--
Peter Witkowski
address@hidden

reply via email to

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