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.
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
