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