Re: N210 DAC and ADC usage
The problem is that the latency using a sound card is terrible, even using jackd. Using N210's sink ans source for audio purposes give very good latencies but it limites me to half-duplex. This is for what I'm interested by using that ADC and DAC. Marcus D. Leech a écrit >On 2022-03-05 14:16, Fabien PELLET wrote: >> Hi Marcus, >> >> Thanks for the detailed answer. I already know get_rx_dboard_iface >> method as it is it that I use to access the IO of LFRX and LFTX. >> >> The problem is that this is asynchrous. For my need, I would like to >> feed it synchronously at a defined sample rate for audio purpose for >> example. >> >> Do you think if I write an OOT sink or source that use that method I >> can get create something near synchronous ? >> >> Best regards, >> Fabien, F4CTZ >You'd have to look at the specs for the ADC/DAC. Doing a synchronous >sampling *thing* would require that you create a stream using FPGA >logic. Those > AUX_ADC and AUX_DAC are intended for low-speed, query-driven usage, >like reading the RSSI value from a RF chain, or driving an attenuator for > gain setting, rather than streaming. > >For audio rates, you're probably better off just using a sound >card--they are available with sample rates up to 192ksps these days. > > >> >> Marcus Müller a écrit >> >> Just realized that there *is* a C++ API: >> >> usrp_block->get_device()->get_rx_dboard_iface()->read_aux_adc(); >> >> replace _rx_ with _tx_ for the LFTX, and read_aux_adc with >> write_aux_dac for the DAC. >> >> Best regards, >> Marcus >> >> DISCLAIMER: Any attached Code is provided As Is. It has not been >> tested or validated as a product, for use in a deployed application or >> system, or for use in hazardous environments. You assume all risks for >> use of the Code. Use of the Code is subject to terms of the licenses >> to the UHD or RFNoC code with which the Code is used. Standard >> licenses to UHD and RFNoC can be found at >> https://www.ettus.com/sdr-software/licenses/. >> >> NI will only perform services based on its understanding and condition >> that the goods or services (i) are not for the use in the production >> or development of any item produced, purchased, or ordered by any >> entity with a footnote 1 designation in the license requirement column >> of Supplement No. 4 to Part 744, U.S. Export Administration >> Regulations and (ii) such a company is not a party to the >> transaction. If our understanding is incorrect, please notify us >> immediately because a specific authorization may be required from the >> U.S. Commerce Department before the transaction may proceed further. >> >> On 05.03.22 13:31, Marcus Müller wrote: >> > Hi Fabien, >> > >> > no need to modify the FPGA. The functionality is there – it's just >> not exposed to the >> > user. Also, note that interacting with the auxiliary ADC and DAC is >> going to be >> > asynchronous to the sample flow – there might be millions of samples >> from the main ADC >> > that have flown by before an AUX_DAC setting takes effect! >> > >> > You also don't really need to modify UHD – you *can* use the UHD >> property tree (through >> > uspr_block->get_device()->get_tree()->access() ), it's just not a >> proper, stable, >> > well-tested, failure-checking API. >> > >> > Best regards, >> > Marcus >> > >> > On 04.03.22 15:01, Fabien PELLET wrote: >> >> Yes, sorry indeed I was talking about AUX_DAC and AUX_ADC that are >> replicated from the >> >> motherboard. >> >> >> >> I already use IO which works very well. So there is no way to send >> samples (or receive) >> >> at a specific sample rate using that AUX_DAC or ADC. It is just >> some "analog IOs" for >> >> reading some external sensors for example if I understand well what >> you wrote. >> >> >> >> What are the specifications of that AUX ? >> >> >> >> Using a specifique FPGA firmware and custom UHD library, would it >> be possible to >> >> transform them as GR source or sink ? >> >> >> >> Thanks, >> >> >> >> Best regards, >> >> >> >> Fabien, F4CTZ. >> >> >> >> Le 04/03/2022 à 14:35, Marcus Müller a écrit : >> >>> Sorry, hit "send" accidentally: >> >>> >> >>> Dear Fabien, >> >>> >> >>> there's no ADC on these daughterboards. Just an EEPROM for >> identification, opamps for >> >>> amplification and signal conditioning, and on the LFTX a >> switch-mode power supply. >> >>> You're right, they do exppose the AUX DACs and ADC lines from the >> motherboad. >> >>> >> >>> However, these are without further ado not accessible from UHD, >> and thus also not from >> >>> GNU Radio. Some daughterboard drivers use them. >> >>> >> >>> I'm not sure UHD exposes them in all version, but `uhd_usrp_probe >> --tree` might show >> >>> properties called "AUX_DAC_A" (or _B, or AUX_ADC_.., you get the >> idea). You can use >> >>> get_device() on your USRP blocks and access theses properties from >> your GNU Radio >> >>> program (from C++), but it's not really an API – more
Re: N210 DAC and ADC usage
On 2022-03-05 14:16, Fabien PELLET wrote: Hi Marcus, Thanks for the detailed answer. I already know get_rx_dboard_iface method as it is it that I use to access the IO of LFRX and LFTX. The problem is that this is asynchrous. For my need, I would like to feed it synchronously at a defined sample rate for audio purpose for example. Do you think if I write an OOT sink or source that use that method I can get create something near synchronous ? Best regards, Fabien, F4CTZ You'd have to look at the specs for the ADC/DAC. Doing a synchronous sampling *thing* would require that you create a stream using FPGA logic. Those AUX_ADC and AUX_DAC are intended for low-speed, query-driven usage, like reading the RSSI value from a RF chain, or driving an attenuator for gain setting, rather than streaming. For audio rates, you're probably better off just using a sound card--they are available with sample rates up to 192ksps these days. Marcus Müller a écrit Just realized that there *is* a C++ API: usrp_block->get_device()->get_rx_dboard_iface()->read_aux_adc(); replace _rx_ with _tx_ for the LFTX, and read_aux_adc with write_aux_dac for the DAC. Best regards, Marcus DISCLAIMER: Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments. You assume all risks for use of the Code. Use of the Code is subject to terms of the licenses to the UHD or RFNoC code with which the Code is used. Standard licenses to UHD and RFNoC can be found at https://www.ettus.com/sdr-software/licenses/. NI will only perform services based on its understanding and condition that the goods or services (i) are not for the use in the production or development of any item produced, purchased, or ordered by any entity with a footnote 1 designation in the license requirement column of Supplement No. 4 to Part 744, U.S. Export Administration Regulations and (ii) such a company is not a party to the transaction. If our understanding is incorrect, please notify us immediately because a specific authorization may be required from the U.S. Commerce Department before the transaction may proceed further. On 05.03.22 13:31, Marcus Müller wrote: > Hi Fabien, > > no need to modify the FPGA. The functionality is there – it's just not exposed to the > user. Also, note that interacting with the auxiliary ADC and DAC is going to be > asynchronous to the sample flow – there might be millions of samples from the main ADC > that have flown by before an AUX_DAC setting takes effect! > > You also don't really need to modify UHD – you *can* use the UHD property tree (through > uspr_block->get_device()->get_tree()->access() ), it's just not a proper, stable, > well-tested, failure-checking API. > > Best regards, > Marcus > > On 04.03.22 15:01, Fabien PELLET wrote: >> Yes, sorry indeed I was talking about AUX_DAC and AUX_ADC that are replicated from the >> motherboard. >> >> I already use IO which works very well. So there is no way to send samples (or receive) >> at a specific sample rate using that AUX_DAC or ADC. It is just some "analog IOs" for >> reading some external sensors for example if I understand well what you wrote. >> >> What are the specifications of that AUX ? >> >> Using a specifique FPGA firmware and custom UHD library, would it be possible to >> transform them as GR source or sink ? >> >> Thanks, >> >> Best regards, >> >> Fabien, F4CTZ. >> >> Le 04/03/2022 à 14:35, Marcus Müller a écrit : >>> Sorry, hit "send" accidentally: >>> >>> Dear Fabien, >>> >>> there's no ADC on these daughterboards. Just an EEPROM for identification, opamps for >>> amplification and signal conditioning, and on the LFTX a switch-mode power supply. >>> You're right, they do exppose the AUX DACs and ADC lines from the motherboad. >>> >>> However, these are without further ado not accessible from UHD, and thus also not from >>> GNU Radio. Some daughterboard drivers use them. >>> >>> I'm not sure UHD exposes them in all version, but `uhd_usrp_probe --tree` might show >>> properties called "AUX_DAC_A" (or _B, or AUX_ADC_.., you get the idea). You can use >>> get_device() on your USRP blocks and access theses properties from your GNU Radio >>> program (from C++), but it's not really an API – more an exposing of intestines... >>> >>> Best regards, >>> Marcus >>> >>> On 04.03.22 14:30, Marcus Müller wrote: Dear Fabien, there's no ADC on these daughterboards. Just an EEPROM for identification, opamps for amplification and signal conditioning, and on the LFTX a switch-mode power supply. Best regards, Marcus On 04.03.22 10:30, Fabien PELLET wrote: > Hello, > > As there are IOs available on LFTX and LFRX, there are also ADC and DAC available. > > Is there a way to use them as SOURCE and SINK in gnuradio for low speed conversio
Re: N210 DAC and ADC usage
Hi Marcus, Thanks for the detailed answer. I already know get_rx_dboard_iface method as it is it that I use to access the IO of LFRX and LFTX. The problem is that this is asynchrous. For my need, I would like to feed it synchronously at a defined sample rate for audio purpose for example. Do you think if I write an OOT sink or source that use that method I can get create something near synchronous ? Best regards, Fabien, F4CTZ Marcus Müller a écrit >Just realized that there *is* a C++ API: > >usrp_block->get_device()->get_rx_dboard_iface()->read_aux_adc(); > >replace _rx_ with _tx_ for the LFTX, and read_aux_adc with write_aux_dac for >the DAC. > >Best regards, >Marcus > >DISCLAIMER: Any attached Code is provided As Is. It has not been tested or >validated as a product, for use in a deployed application or system, or for >use in hazardous environments. You assume all risks for use of the Code. Use >of the Code is subject to terms of the licenses to the UHD or RFNoC code with >which the Code is used. Standard licenses to UHD and RFNoC can be found at >https://www.ettus.com/sdr-software/licenses/. > >NI will only perform services based on its understanding and condition that >the goods or services (i) are not for the use in the production or development >of any item produced, purchased, or ordered by any entity with a footnote 1 >designation in the license requirement column of Supplement No. 4 to Part 744, >U.S. Export Administration Regulations and (ii) such a company is not a party >to the transaction. If our understanding is incorrect, please notify us >immediately because a specific authorization may be required from the U.S. >Commerce Department before the transaction may proceed further. > >On 05.03.22 13:31, Marcus Müller wrote: >> Hi Fabien, >> >> no need to modify the FPGA. The functionality is there – it's just not >> exposed to the >> user. Also, note that interacting with the auxiliary ADC and DAC is going to >> be >> asynchronous to the sample flow – there might be millions of samples from >> the main ADC >> that have flown by before an AUX_DAC setting takes effect! >> >> You also don't really need to modify UHD – you *can* use the UHD property >> tree (through >> uspr_block->get_device()->get_tree()->access() ), it's just not a proper, >> stable, >> well-tested, failure-checking API. >> >> Best regards, >> Marcus >> >> On 04.03.22 15:01, Fabien PELLET wrote: >>> Yes, sorry indeed I was talking about AUX_DAC and AUX_ADC that are >>> replicated from the >>> motherboard. >>> >>> I already use IO which works very well. So there is no way to send samples >>> (or receive) >>> at a specific sample rate using that AUX_DAC or ADC. It is just some >>> "analog IOs" for >>> reading some external sensors for example if I understand well what you >>> wrote. >>> >>> What are the specifications of that AUX ? >>> >>> Using a specifique FPGA firmware and custom UHD library, would it be >>> possible to >>> transform them as GR source or sink ? >>> >>> Thanks, >>> >>> Best regards, >>> >>> Fabien, F4CTZ. >>> >>> Le 04/03/2022 à 14:35, Marcus Müller a écrit : Sorry, hit "send" accidentally: Dear Fabien, there's no ADC on these daughterboards. Just an EEPROM for identification, opamps for amplification and signal conditioning, and on the LFTX a switch-mode power supply. You're right, they do exppose the AUX DACs and ADC lines from the motherboad. However, these are without further ado not accessible from UHD, and thus also not from GNU Radio. Some daughterboard drivers use them. I'm not sure UHD exposes them in all version, but `uhd_usrp_probe --tree` might show properties called "AUX_DAC_A" (or _B, or AUX_ADC_.., you get the idea). You can use get_device() on your USRP blocks and access theses properties from your GNU Radio program (from C++), but it's not really an API – more an exposing of intestines... Best regards, Marcus On 04.03.22 14:30, Marcus Müller wrote: > Dear Fabien, > > there's no ADC on these daughterboards. Just an EEPROM for > identification, opamps for > amplification and signal conditioning, and on the LFTX a switch-mode > power supply. > > Best regards, > Marcus > > On 04.03.22 10:30, Fabien PELLET wrote: >> Hello, >> >> As there are IOs available on LFTX and LFRX, there are also ADC and DAC >> available. >> >> Is there a way to use them as SOURCE and SINK in gnuradio for low speed >> conversion ? >> >> Thanks, >> >> Best regards, >> >> Fabien, F4CTZ. >> >> >>> >
Re: GRC 3.9.4.0 - module porting problem
Hi Ryan,
Thanks for the prompt reply.
The C++ compiler version used to first build GRC 3.9.4.0 and then compile
the OOT GRC block code is (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
I will check the same on the computer being used for GRC 3.8.2.0 use shortly
and critically look at the cmake output for clues in discrepancy.
I have found in the past that an incremental inclusion of the C++ source
code through the build process helps to identify the cause of the import
failure. - He says, stating the obvious!!
All the best,
David
-Original Message-
From: Ryan Volz
Sent: Friday, March 4, 2022 10:22 PM
To: discuss-gnuradio@gnu.org
Subject: Re: GRC 3.9.4.0 - module porting problem
Hi David,
If it works somewhere with GR 3.9, then it's not a porting problem and
you've done everything right there.
I've recently discovered for myself that an OOT's Python bindings will throw
this error when even the compiler version is different between building GNU
Radio and the OOT, in addition to needing the same pybind11 version. Is
there a chance this is what you're seeing? Run "gnuradio-config-info --cxx"
to see what compiler GNU Radio was built with, and compare with what you're
using to build the OOT module.
(For me, this has happened in building OOT modules for conda-forge when the
conda-forge project recently started using GCC 10 instead of GCC 9. Modules
built with GCC 10 were not compatible with a GNU Radio built with GCC 9. It
turns out that they actually would be compatible, and pybind11 is being too
careful, but I would have had to know that ahead of time to avoid the
problem. So for now I have to stick to the same compiler version for
everything.)
Cheers,
Ryan
On 3/4/22 3:35 PM, David Taylor (manx.net) wrote:
Hi All,
I am sorry to be covering what is old ground, but I am having a final
loading issue with an otherwise working OOT block.
The block works under GRC 3.8.2.0 and GRC 3.9.4.0 was built on another
computer without issue.
ImportError:generic_type "channel_signal_generator_cc" referenced unknown
base type "gr::sync_block"
Ubuntu 20.04
python 3.8
pybind11 2.5.0 – replacing 2.4.3 in accordance with the latest 3.9 Module
Porting Guide (28 Feb 2022)
pygccxml 2.2.1
Additional libraries are found at cmake and during the build. The block
imports correctly with no changes necessary to the .yml file.
The new block was created using 3.9 gr_modtool and code dropped in, noting
the changes to shared_ptr use.
The block was sync_block type at definition, with the virtual block
classes noted in the porting guide automatically inserted during bind in
/python/bindings/
void bind_channel_signal_generator_cc(py::module& m)
{
using channel_signal_generator_cc=
::gr::oot::channel_signal_generator_cc;
py::class_gr::basic_block,
std::shared_ptr>(m,
"channel_signal_generator_cc", D(channel_signal_generator_cc))
.def(py::init(&channel_signal_generator_cc::make),
py::arg("samp_rate"),
py::arg("length_chips"),
py::arg("duration_sec"),
py::arg("filename"),
py::arg("CN0_dB"),
D(channel_signal_generator_cc,make)
)
Any comments would be welcome.
Many thanks,
David GD4FMB
Re: N210 DAC and ADC usage
Just realized that there *is* a C++ API: usrp_block->get_device()->get_rx_dboard_iface()->read_aux_adc(); replace _rx_ with _tx_ for the LFTX, and read_aux_adc with write_aux_dac for the DAC. Best regards, Marcus DISCLAIMER: Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments. You assume all risks for use of the Code. Use of the Code is subject to terms of the licenses to the UHD or RFNoC code with which the Code is used. Standard licenses to UHD and RFNoC can be found at https://www.ettus.com/sdr-software/licenses/. NI will only perform services based on its understanding and condition that the goods or services (i) are not for the use in the production or development of any item produced, purchased, or ordered by any entity with a footnote 1 designation in the license requirement column of Supplement No. 4 to Part 744, U.S. Export Administration Regulations and (ii) such a company is not a party to the transaction. If our understanding is incorrect, please notify us immediately because a specific authorization may be required from the U.S. Commerce Department before the transaction may proceed further. On 05.03.22 13:31, Marcus Müller wrote: Hi Fabien, no need to modify the FPGA. The functionality is there – it's just not exposed to the user. Also, note that interacting with the auxiliary ADC and DAC is going to be asynchronous to the sample flow – there might be millions of samples from the main ADC that have flown by before an AUX_DAC setting takes effect! You also don't really need to modify UHD – you *can* use the UHD property tree (through uspr_block->get_device()->get_tree()->access() ), it's just not a proper, stable, well-tested, failure-checking API. Best regards, Marcus On 04.03.22 15:01, Fabien PELLET wrote: Yes, sorry indeed I was talking about AUX_DAC and AUX_ADC that are replicated from the motherboard. I already use IO which works very well. So there is no way to send samples (or receive) at a specific sample rate using that AUX_DAC or ADC. It is just some "analog IOs" for reading some external sensors for example if I understand well what you wrote. What are the specifications of that AUX ? Using a specifique FPGA firmware and custom UHD library, would it be possible to transform them as GR source or sink ? Thanks, Best regards, Fabien, F4CTZ. Le 04/03/2022 à 14:35, Marcus Müller a écrit : Sorry, hit "send" accidentally: Dear Fabien, there's no ADC on these daughterboards. Just an EEPROM for identification, opamps for amplification and signal conditioning, and on the LFTX a switch-mode power supply. You're right, they do exppose the AUX DACs and ADC lines from the motherboad. However, these are without further ado not accessible from UHD, and thus also not from GNU Radio. Some daughterboard drivers use them. I'm not sure UHD exposes them in all version, but `uhd_usrp_probe --tree` might show properties called "AUX_DAC_A" (or _B, or AUX_ADC_.., you get the idea). You can use get_device() on your USRP blocks and access theses properties from your GNU Radio program (from C++), but it's not really an API – more an exposing of intestines... Best regards, Marcus On 04.03.22 14:30, Marcus Müller wrote: Dear Fabien, there's no ADC on these daughterboards. Just an EEPROM for identification, opamps for amplification and signal conditioning, and on the LFTX a switch-mode power supply. Best regards, Marcus On 04.03.22 10:30, Fabien PELLET wrote: Hello, As there are IOs available on LFTX and LFRX, there are also ADC and DAC available. Is there a way to use them as SOURCE and SINK in gnuradio for low speed conversion ? Thanks, Best regards, Fabien, F4CTZ.
Re: N210 DAC and ADC usage
Hi Fabien, no need to modify the FPGA. The functionality is there – it's just not exposed to the user. Also, note that interacting with the auxiliary ADC and DAC is going to be asynchronous to the sample flow – there might be millions of samples from the main ADC that have flown by before an AUX_DAC setting takes effect! You also don't really need to modify UHD – you *can* use the UHD property tree (through uspr_block->get_device()->get_tree()->access() ), it's just not a proper, stable, well-tested, failure-checking API. Best regards, Marcus On 04.03.22 15:01, Fabien PELLET wrote: Yes, sorry indeed I was talking about AUX_DAC and AUX_ADC that are replicated from the motherboard. I already use IO which works very well. So there is no way to send samples (or receive) at a specific sample rate using that AUX_DAC or ADC. It is just some "analog IOs" for reading some external sensors for example if I understand well what you wrote. What are the specifications of that AUX ? Using a specifique FPGA firmware and custom UHD library, would it be possible to transform them as GR source or sink ? Thanks, Best regards, Fabien, F4CTZ. Le 04/03/2022 à 14:35, Marcus Müller a écrit : Sorry, hit "send" accidentally: Dear Fabien, there's no ADC on these daughterboards. Just an EEPROM for identification, opamps for amplification and signal conditioning, and on the LFTX a switch-mode power supply. You're right, they do exppose the AUX DACs and ADC lines from the motherboad. However, these are without further ado not accessible from UHD, and thus also not from GNU Radio. Some daughterboard drivers use them. I'm not sure UHD exposes them in all version, but `uhd_usrp_probe --tree` might show properties called "AUX_DAC_A" (or _B, or AUX_ADC_.., you get the idea). You can use get_device() on your USRP blocks and access theses properties from your GNU Radio program (from C++), but it's not really an API – more an exposing of intestines... Best regards, Marcus On 04.03.22 14:30, Marcus Müller wrote: Dear Fabien, there's no ADC on these daughterboards. Just an EEPROM for identification, opamps for amplification and signal conditioning, and on the LFTX a switch-mode power supply. Best regards, Marcus On 04.03.22 10:30, Fabien PELLET wrote: Hello, As there are IOs available on LFTX and LFRX, there are also ADC and DAC available. Is there a way to use them as SOURCE and SINK in gnuradio for low speed conversion ? Thanks, Best regards, Fabien, F4CTZ. smime.p7s Description: S/MIME Cryptographic Signature
