Ok, thanks for the clarification.
On Sat, Jul 9, 2022 at 9:15 PM Marcus D. Leech <patchvonbr...@gmail.com>
wrote:
> 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
