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