Thanks! I will examine your useful description...

On Sun, Jul 3, 2022 at 8:45 PM Marcus D. Leech <patchvonbr...@gmail.com>
wrote:

> 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

Reply via email to