Hi Joel - IIRC UHD takes and provides std::complex<float> values that are
in (-1.0,+1.0), meaning that the minimum (most negative) value is
-1.0+epsilon and the maximum (most positive) value is 1.0-epsilon, where
"epsilon" is the smallest positive 32-bit float value (approximately
1.17549e-38).
If you're looking just for conversion from sc16 (aka
"std::complex<int16_t>") to std::complex<float> in C++ (note that "float"
is 32-bits in C++), you could do something like the following (which should
work with pretty much any C++ standard):
{{{
#include <complex>
#include <limits>
#include <sys/types.h>
static float scale_factor = float(1) /
float(std::min(int16_t(-std::numeric_limits<int16_t>::min()),
std::numeric_limits<int16_t>::max()));
std::complex<float> sc16_to_float (const std::complex<int16_t>& input) {
return std::complex<float>
(std::real(input) * scale_factor,
std::imag (input) * scale_factor);
}
}}}
There are, obviously, more efficient ways to do this. I believe that VOLK
provides CPU optimized functions something along the lines of the above
code. Hope this is useful! - MLD
On Fri, Sep 6, 2019 at 8:47 AM J Subash via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Imad,
>
>
> Thanks very much for your reply. Unfortunately that solution does not
> work.
>
> Because if it reads 4 bytes (two int16_t in C/C++ parlance; <i2 in numpy
> world) which for argument sake holds 15, 16 (which are integers). These are
> then cast as floats which makes them 15.0 and 16.0 and then when viewed as
> np.complex64 becomes 15.0 + 16.0j.
>
>
> I have had a look at the converters section in the uhd API (
> https://github.com/EttusResearch/uhd/tree/master/host/lib/convert) but
> can't get my head around the code.
>
>
> Thanks.
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
