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 <patchvonbraun@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 <patchvonbraun@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-leave@lists.ettus.com > >

On 2022-07-09 13:22, Nikos Balkanas wrote: > 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 > > Gnu Radio for the most part uses whatever is the CPU-native format on the machine it's executing on.  It cannot be otherwise, except at the edge,   or when data are serialized for use in things like messages and network stacks. But *samples* are always represented in the native-CPU format in Gnu Radio.   If this were not the case, then native CPU operations could not work on that data.   MOST machines these days are little-endian (x86, etc).   Some versions of   ARM have been configurable for big-endian, but most extant implementations use little-endian format. Things like "file sink" simply write out the CPU-native format for whatever the data type is.

> on that data.   MOST machines these days are little-endian (x86, etc).   except for the JVM and all the Android applications which are big-endian hence ! I am not sure x86-based PCs account for "most machines" today, although they are arguably the most supported GNU Radio running environment. Best, JM

On 2022-07-09 15:39, friedtj@free.fr wrote: >> on that data.   MOST machines these days are little-endian (x86, etc). > except for the JVM and all the Android applications which are big-endian hence ! > I am not sure x86-based PCs account for "most machines" today, although they are > arguably the most supported GNU Radio running environment. > > Best, JM Well, sure. Except that JVM runs on actual CPU hardware, which is overwhelmingly little-endian. I've been involved with computers and computing and computer architecture since 1979. In that time there   have been many flirtations with both styles of representation, including machines that could be configured at   boot time.   Which is why I said "these days"....