On 2022-07-09 12:40, sp wrote:
Marcus D. Leech thanks very much. Your description is very useful for
me. But I am not a communication engineer, I am a software developer,
Can you introduce me to a reference book that discusses scaling in
radio hardware?
But, with your description, I think I should follow your method...
simple Python program to re-scale it. of course in helping a
communication engineer.
My point is that re-scaling a data-set has NOTHING to do with
communications, DSP, SDR, UHD, or even Gnu Radio. It's a
pretty-ordinary numerical thing
that anyone who has dealt with large data-sets that needs to re-scale
them (for example, normalizing them) would need to understand.
If the data-set is small, you can read the entire thing into a Numpy
array in Python, for example, determine the required scaling, and
re-scale and write the
array back out. If it's larger, then you'd need to do it in chunks.
On Sat, Jul 9, 2022 at 8:57 PM Marcus D. Leech
<patchvonbr...@gmail.com> wrote:
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
