You can test and see what works for you. No damage done :)
Respectfully i think that Marcus misunderstood.
If you divide by largest number, you will end up in {-1, +1}. It will
be bad if you try to floor or ceil that:(
You should divide by smallest number, which is itself divided by 100.
This way you can be assured that your error for your ceil or floor
will be < 1%:)
You want your numbers in [inf, 100], [-100, -inf]Nikos On Wed, Jul 6, 2022 at 12:03 PM sp <[email protected]> wrote: > > Thanks! I will examine your useful description... > > On Sun, Jul 3, 2022 at 8:45 PM Marcus D. Leech <[email protected]> > 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 <[email protected]> wrote: >>> >>> On Sat, Jul 2, 2022 at 6:54 PM Marcus D Leech <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> 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 -- [email protected] >>> > >> To unsubscribe send an email to [email protected] >>> > > _______________________________________________ >>> > > USRP-users mailing list -- [email protected] >>> > > To unsubscribe send an email to [email protected] >> >> _______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
