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