Hi sp,
Where did you figure out that gnuradio is little endian?
I searched their source code. In a few places like pmt_serialize.h
they use big endian.
In wavfile.cc they use different code for big or little endian.
decided on gr configuration...GR_IS_BIG_ENDIAN
In other places they note that they may be wrong...crc32_bb_impl.cc
They always pass endianness when repacking bits
To check if you have a problem, run the cfile output from gnuradio
through a spectrum analyzer.
If you get an "inverted" spectrum you have a problem. Else you are fine:)
I am not using gnuradio, only uhd with an X-300. I am working big
endian all the way and gr-fosphor looks fine:)
If gnuradio gets input data from a usrp, is it still little endian?
They have code for swapping endianess, endian_swap_impl.cc,
but haven't seen it used anywhere in their sources:(
HTH
Nikos
On Sat, Jul 9, 2022 at 7:27 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
