S
sp
Sat, Jul 9, 2022 1:55 PM
I know that data in USRP on FPGA is in format big-endian sint16, but in
Gnuradio data is in format complex float 32...
I found these links
The conversion encompasses several elements. The most obvious is that of
the data type: Most FPGAs use integer data types, the most common being
complex 16-bit integers (16 bit for I and Q, respectively). If the user
wants his data in float, the converter casts the data type and also scales
the data, typically such that the full dynamic range of the 16-Bit integers
is mapped onto the float range of -1 to 1. The converter also handles the
endianness: On the network, data is usually stored as big-endian, whereas
most platforms store data internally as little-endian.
https://files.ettus.com/manual/classuhd_1_1convert_1_1converter.html#a371906249b8bd546b98bd0a867e70c88
https://files.ettus.com/manual/page_converters.html
According to them, I want to use the Convert class to convert complex float
32 to sint16....
But my program is can not run successfully, Anyone can guide me on How
should I use the Converter class...!!!
Thanks in advance
#include <uhd/convert.hpp>
int main()
{
int16_t *in_p;
float *out_p;
*in_p=1234;
uhd::convert::converter::input_type in(in_p);
uhd::convert::converter::output_type out(out_p);
uhd::convert::converter::sptr convert;
convert->conv(in,out,1);
std::cout<<*out_p;
}
I know that data in USRP on FPGA is in format big-endian sint16, but in
Gnuradio data is in format complex float 32...
I found these links
The conversion encompasses several elements. The most obvious is that of
the data type: Most FPGAs use integer data types, the most common being
complex 16-bit integers (16 bit for I and Q, respectively). If the user
wants his data in float, the converter casts the data type and also scales
the data, typically such that the full dynamic range of the 16-Bit integers
is mapped onto the float range of -1 to 1. The converter also handles the
endianness: On the network, data is usually stored as big-endian, whereas
most platforms store data internally as little-endian.
https://files.ettus.com/manual/classuhd_1_1convert_1_1converter.html#a371906249b8bd546b98bd0a867e70c88
https://files.ettus.com/manual/page_converters.html
According to them, I want to use the Convert class to convert complex float
32 to sint16....
But my program is can not run successfully, Anyone can guide me on How
should I use the Converter class...!!!
Thanks in advance
#include <uhd/convert.hpp>
>
>
> int main()
>
> {
>
> int16_t *in_p;
>
> float *out_p;
>
> *in_p=1234;
>
> uhd::convert::converter::input_type in(in_p);
>
> uhd::convert::converter::output_type out(out_p);
>
> uhd::convert::converter::sptr convert;
>
> convert->conv(in,out,1);
>
> std::cout<<*out_p;
>
> }
>
>
NB
Nikos Balkanas
Sat, Jul 9, 2022 2:36 PM
Hi,
I don't know about gnuradio classes:( Maybe you should ask them...
But in C, I would use le32toh, I assume gnuradio is in little endian.
and then htobe16 to get for uhd:
uint16 data = htobe16(le32toh(float 32 data))
I assume this already does ceil or floor, so your data needs to be
already in the right scale:)
HTH
Nikos
On Sat, Jul 9, 2022 at 4:57 PM sp stackprogramer@gmail.com wrote:
I know that data in USRP on FPGA is in format big-endian sint16, but in Gnuradio data is in format complex float 32...
I found these links
The conversion encompasses several elements. The most obvious is that of the data type: Most FPGAs use integer data types, the most common being complex 16-bit integers (16 bit for I and Q, respectively). If the user wants his data in float, the converter casts the data type and also scales the data, typically such that the full dynamic range of the 16-Bit integers is mapped onto the float range of -1 to 1. The converter also handles the endianness: On the network, data is usually stored as big-endian, whereas most platforms store data internally as little-endian.
https://files.ettus.com/manual/classuhd_1_1convert_1_1converter.html#a371906249b8bd546b98bd0a867e70c88
https://files.ettus.com/manual/page_converters.html
According to them, I want to use the Convert class to convert complex float 32 to sint16....
But my program is can not run successfully, Anyone can guide me on How should I use the Converter class...!!!
Thanks in advance
#include <uhd/convert.hpp>
int main()
{
int16_t *in_p;
float *out_p;
*in_p=1234;
uhd::convert::converter::input_type in(in_p);
uhd::convert::converter::output_type out(out_p);
uhd::convert::converter::sptr convert;
convert->conv(in,out,1);
std::cout<<*out_p;
}
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Hi,
I don't know about gnuradio classes:( Maybe you should ask them...
But in C, I would use le32toh, I assume gnuradio is in little endian.
and then htobe16 to get for uhd:
uint16 data = htobe16(le32toh(float 32 data))
I assume this already does ceil or floor, so your data needs to be
already in the right scale:)
HTH
Nikos
On Sat, Jul 9, 2022 at 4:57 PM sp <stackprogramer@gmail.com> wrote:
>
> I know that data in USRP on FPGA is in format big-endian sint16, but in Gnuradio data is in format complex float 32...
> I found these links
> The conversion encompasses several elements. The most obvious is that of the data type: Most FPGAs use integer data types, the most common being complex 16-bit integers (16 bit for I and Q, respectively). If the user wants his data in float, the converter casts the data type and also scales the data, typically such that the full dynamic range of the 16-Bit integers is mapped onto the float range of -1 to 1. The converter also handles the endianness: On the network, data is usually stored as big-endian, whereas most platforms store data internally as little-endian.
>
> https://files.ettus.com/manual/classuhd_1_1convert_1_1converter.html#a371906249b8bd546b98bd0a867e70c88
> https://files.ettus.com/manual/page_converters.html
>
> According to them, I want to use the Convert class to convert complex float 32 to sint16....
> But my program is can not run successfully, Anyone can guide me on How should I use the Converter class...!!!
> Thanks in advance
>
>> #include <uhd/convert.hpp>
>
>
>
>>
>> int main()
>>
>> {
>>
>> int16_t *in_p;
>>
>> float *out_p;
>>
>> *in_p=1234;
>>
>> uhd::convert::converter::input_type in(in_p);
>>
>> uhd::convert::converter::output_type out(out_p);
>>
>> uhd::convert::converter::sptr convert;
>>
>> convert->conv(in,out,1);
>>
>> std::cout<<*out_p;
>>
>> }
>
>
> _______________________________________________
> USRP-users mailing list -- usrp-users@lists.ettus.com
> To unsubscribe send an email to usrp-users-leave@lists.ettus.com
NB
Nikos Balkanas
Sat, Jul 9, 2022 3:02 PM
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
On Sat, Jul 9, 2022 at 5:36 PM Nikos Balkanas nbalkanas@gmail.com wrote:
Hi,
I don't know about gnuradio classes:( Maybe you should ask them...
But in C, I would use le32toh, I assume gnuradio is in little endian.
and then htobe16 to get for uhd:
uint16 data = htobe16(le32toh(float 32 data))
I assume this already does ceil or floor, so your data needs to be
already in the right scale:)
HTH
Nikos
On Sat, Jul 9, 2022 at 4:57 PM sp stackprogramer@gmail.com wrote:
I know that data in USRP on FPGA is in format big-endian sint16, but in Gnuradio data is in format complex float 32...
I found these links
The conversion encompasses several elements. The most obvious is that of the data type: Most FPGAs use integer data types, the most common being complex 16-bit integers (16 bit for I and Q, respectively). If the user wants his data in float, the converter casts the data type and also scales the data, typically such that the full dynamic range of the 16-Bit integers is mapped onto the float range of -1 to 1. The converter also handles the endianness: On the network, data is usually stored as big-endian, whereas most platforms store data internally as little-endian.
https://files.ettus.com/manual/classuhd_1_1convert_1_1converter.html#a371906249b8bd546b98bd0a867e70c88
https://files.ettus.com/manual/page_converters.html
According to them, I want to use the Convert class to convert complex float 32 to sint16....
But my program is can not run successfully, Anyone can guide me on How should I use the Converter class...!!!
Thanks in advance
#include <uhd/convert.hpp>
int main()
{
int16_t *in_p;
float *out_p;
*in_p=1234;
uhd::convert::converter::input_type in(in_p);
uhd::convert::converter::output_type out(out_p);
uhd::convert::converter::sptr convert;
convert->conv(in,out,1);
std::cout<<*out_p;
}
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
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
On Sat, Jul 9, 2022 at 5:36 PM Nikos Balkanas <nbalkanas@gmail.com> wrote:
>
> Hi,
>
> I don't know about gnuradio classes:( Maybe you should ask them...
> But in C, I would use le32toh, I assume gnuradio is in little endian.
> and then htobe16 to get for uhd:
> uint16 data = htobe16(le32toh(float 32 data))
> I assume this already does ceil or floor, so your data needs to be
> already in the right scale:)
>
> HTH
> Nikos
>
> On Sat, Jul 9, 2022 at 4:57 PM sp <stackprogramer@gmail.com> wrote:
> >
> > I know that data in USRP on FPGA is in format big-endian sint16, but in Gnuradio data is in format complex float 32...
> > I found these links
> > The conversion encompasses several elements. The most obvious is that of the data type: Most FPGAs use integer data types, the most common being complex 16-bit integers (16 bit for I and Q, respectively). If the user wants his data in float, the converter casts the data type and also scales the data, typically such that the full dynamic range of the 16-Bit integers is mapped onto the float range of -1 to 1. The converter also handles the endianness: On the network, data is usually stored as big-endian, whereas most platforms store data internally as little-endian.
> >
> > https://files.ettus.com/manual/classuhd_1_1convert_1_1converter.html#a371906249b8bd546b98bd0a867e70c88
> > https://files.ettus.com/manual/page_converters.html
> >
> > According to them, I want to use the Convert class to convert complex float 32 to sint16....
> > But my program is can not run successfully, Anyone can guide me on How should I use the Converter class...!!!
> > Thanks in advance
> >
> >> #include <uhd/convert.hpp>
> >
> >
> >
> >>
> >> int main()
> >>
> >> {
> >>
> >> int16_t *in_p;
> >>
> >> float *out_p;
> >>
> >> *in_p=1234;
> >>
> >> uhd::convert::converter::input_type in(in_p);
> >>
> >> uhd::convert::converter::output_type out(out_p);
> >>
> >> uhd::convert::converter::sptr convert;
> >>
> >> convert->conv(in,out,1);
> >>
> >> std::cout<<*out_p;
> >>
> >> }
> >
> >
> > _______________________________________________
> > USRP-users mailing list -- usrp-users@lists.ettus.com
> > To unsubscribe send an email to usrp-users-leave@lists.ettus.com
MD
Marcus D. Leech
Sat, Jul 9, 2022 3:31 PM
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.
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.
NB
Nikos Balkanas
Sat, Jul 9, 2022 3:56 PM
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
Nice:)
On Sat, Jul 9, 2022 at 6:33 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
S
sp
Sat, Jul 9, 2022 4:01 PM
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...
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
>
> 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...
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
>
MD
Marcus D. Leech
Sat, Jul 9, 2022 4:26 PM
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 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
>
S
sp
Sat, Jul 9, 2022 4:40 PM
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 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
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 <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
>>
>
>
MD
Marcus D. Leech
Sat, Jul 9, 2022 4:45 PM
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.
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 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
> <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
>>
>
S
sp
Sat, Jul 9, 2022 5:08 PM
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 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
Ok, thanks for the clarification.
On Sat, Jul 9, 2022 at 9:15 PM Marcus D. Leech <patchvonbraun@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 <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
>>>
>>
>>
>
