On 2022-07-09 12:01, sp wrote:
I assume this already does ceil or floor, so your data needs to be
already in the right scale:)
But all of my problems are related to scaling...
want to use the converted class in USRP that can solve my
scaling problem and I am sure that my data is converted correctly..
So I want to use only the converter class not the c function on volk
functions...
If the file was recorded from a HackRF using GNu Radio, then it is
already scaled appropriately.
If not, then figure out what the largest sample amplitude is and
re-scale your file as appropriate.
If you have a real-time, floating-point, sample-stream where the range
of the data-set is unknown in advance, then you have a serious problem
that cannot be solved with converters.
The reality is that the various SDR device drivers out there,
particularly in the context of Gnu Radio, will convert sample-sterams
into complex-floats
in the appropriate {-1.0,+1.0} range appropriately.
Any converter you write for UHD will *necessarily* need to take a
scaling parameter, and you have no way of knowing that in advance for a
real-time
sample stream from "weird" hardware. For a pre-recorded file, you
have to evaluate the *entire* file anyway to determine what the scaling
factor should
be, and you might as well, having evaluated the entire file, also do
the conversion on the file at the same time. Again, this isn't SDR or
DSP or GnuRadio,
or UHD specifically, it's just a data-scaling exercise that you might
find yourself in whenever dealing with *ANY* numerically-based discipline.
Since it's a file, the conversion doesn't have to go in real-time, and
you could even use a simple Python program to re-scale it.
On Sat, Jul 9, 2022 at 8:01 PM Marcus D. Leech
<patchvonbr...@gmail.com> wrote:
On 2022-07-09 11:02, Nikos Balkanas wrote:
> Correction> These functions work on integers.
>
> So they go as:
> int16 data = htobe16(le32toh(int32 data))
> Or the associate functions,
> htonl, htons
>
> So you need to already have converted your floats to ints...
> If in doubt, test them first on a single data...
> Sorry about the confusion.
>
> Nikos
>
>
My question would be--why?
UHD and Gnu Radio already do these conversions for you.
The *single* case where being able to send sample data as big-endian
SC16 without any intervening conversions is from a file. Anything
that
involves computation-with-samples
on the host requires, necessarily, that those samples be in a
format
understood by the CPU on the host.
Further, if there are bottlenecks, I would want to absolutely confirm
that the major bottleneck in the UHD driver is in doing conversion to
big-endian wire format before
venturing down the road of making that available "directly". I
have lost track of this thread, but my recollection is that this file
originates in a capture from a HackRF
whose absolute-maximum sample-rate is 20e6SPS. That's a rate
that
is *easily* handled by the existing UHD "stack" without resorting to
this type of optimization, IMHO.
_______________________________________________
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
