N210 DAC and ADC usage

[Fabien PELLET]

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

[Marcus Müller]

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

[Marcus Müller]

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

[Fabien PELLET]

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

[Marcus D Leech]

See here for the schematics which will help you find the full specs for the AUX 
ADC and DAC. 

https://files.ettus.com/schematics/n200/

Yes you can certainly modify the FPGA and UHD to support these. But you’ll 
mostly be on your own. 

Sent from my iPhone

> On Mar 4, 2022, at 9:35 AM, 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

[Marcus Müller]

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

Re: N210 DAC and ADC usage

[Marcus Müller]

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

[Fabien PELLET]

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: N210 DAC and ADC usage

[Marcus D. Leech]

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

[Fabien PELLET]

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

[Marcus Müller]

Hi Fabien!

Sadly, as said, the AUX ADC and DAC are asynchronous, by design. You can't make them 
synchronous without developing a different streaming architecture for the N210; that would 
be a major change to the FPGA design, I'd presume, not just a little change :(


The thing I could imagine you could do is embed aux ADC bits in the least significant bits 
of your sample stream – but then you'd actively need to reduce the quality of that to get 
AUX data.


If you need your audio sampling to be synchronous to your RF sampling, I'd recommend using 
a clock that is synchronous to the 10 MHz clock of the USRP (e.g. by using the same 10 MHz 
reference for both the USRP and your audio equipment, or by taking a clock from the USRP) 
to achieve rate matching, and if you need not only rate, but also time-alignment, using 
timed commands and GPIOs to trigger sampling of the audio devices (if these support that), 
or to embed an impulse (couple a GPIO output with a small capacitor into the audio line) 
in the audio stream to align it in software.


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 21:32, Fabien PELLET wrote:
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 expos