On 2022-07-03 11:29, sp wrote:
Thanks! So I set scaler to an appropriate value that ceil is not
effected my data. But in Gnuradio I can not find an easy convert solution.
So I do test and error to find a solution.
This isn't even a Gnu Radio or UHD problem, just a generic
programming/algorithms thing. Not even DSP.
Let's say your complex-float file from a HackRF is NOT scaled into
{-1.0,+1.0}. Then you simply look at the largest absolute value across
the whole file and divide all your values by that value. Then you've
preserved dynamic range without clipping, and it is then in the
"expected" domain of complex-floats in Gnu Radio (or UHD for that
matter).
We're talking about files here, so it's not like you have to
"understand" this is in real-time. You can do a one-time conversion
of the not-scaled-to-{-1.0,+1.0} file into that range, and then it's
in the right range.
But my *guess* is that hackrf recording tools if they're using
complex-float will have the floating-point already scaled into
{-1.0,+1.0}, and in
host-native IEEE-754 floating-point format. I'd be mildly astonished
if it were otherwise.
On Sun, Jul 3, 2022 at 1:44 AM Nikos Balkanas <nbalka...@gmail.com> wrote:
On Sat, Jul 2, 2022 at 6:54 PM Marcus D Leech
<patchvonbr...@gmail.com> wrote:
>
> The convention in the UHD and GnuRadio universe is that floats
are scaled into {-1.0,+1.0}.
>
> If you setup your streamer to use complex float CPU format and
sc16 wire format you just need to scale your complex floats
appropriately.
Just to elaborate on this a bit. If your data is large enough (>>1)
then +- 1 won't make any difference...
If it is (< 1) then it will be a big problem. Scale accordingly:)
You can use either ceil or floor. Same error:)
Nikos
>
> Sent from my iPhone
>
> > On Jul 2, 2022, at 10:22 AM, Nikos Balkanas
<nbalka...@gmail.com> wrote:
> >
> > Hi,
> >
> > I don't know volk_32fc_convert_16 ic. Dunno if it converts
between big
> > and little indians:(
> > When converting a float to int, you always have to ceil or
floor the float.
> > Ceil sounds as good as any. You can easily change that to
floor if you
> > run into problems.
> > Since clibs le32to* take ints as arguments, I would first convert
> > float32 to int32 from gnuradio save to file, and then worry about
> > the indians when importing to uhd...
> >
> > HTH
> > Nikos
> >
> >> On Fri, Jul 1, 2022 at 8:42 AM sp h
<stackprogra...@gmail.com> wrote:
> >>
> >> I recorded a complex signal file, I did it with HackRFONE,
For sending on USRP I want to use the int16 option as input, My
question is how can convert a complex float 32 signal to complex
int 16 for USRP?
> >> what's the relation between complex float 32 and complex int
32 in USRP?
> >> I know that in USRP numbers are in format complex int 16 and
big-endian and in Gnuradio numbers in format complex float 32 and
little-endian...
> >> https://files.ettus.com/manual/page_converters.html
> >> I used volk lib but the float that I entered as input, is
ceiled to bigger integers. Is this a method valid for converting
signals...?Or my data will be corrupt!!!
> >> Thanks in advance.
> >>
> >>
> >>> lv_16sc_t* outputVector;
> >>>
> >>> lv_32fc_t* inputVector;
> >>>
> >>> inputVector->real(25.55);
> >>>
> >>> inputVector->imag(45);
> >>>
> >>> volk_32fc_convert_16ic(outputVector,inputVector,32);
> >>>
> >>> qDebug()<<outputVector->real()<<"-----";
> >>
> >>
> >> The output:
> >>>
> >>> 26 -----
> >>
> >> _______________________________________________
> >> USRP-users mailing list -- usrp-users@lists.ettus.com
> >> To unsubscribe send an email to usrp-users-le...@lists.ettus.com
> > _______________________________________________
> > USRP-users mailing list -- usrp-users@lists.ettus.com
> > To unsubscribe send an email to usrp-users-le...@lists.ettus.com
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
