[USRP-users] XO error correction on B210

Dario Fertonani dario.fertonani at gmail.com
Wed Mar 30 11:02:23 EDT 2016


Going back to this old thread...

I can report that scaling all frequencies more or less works. However, I'm
looking for a cleaner solution.

Does any of the Ettus Research boards provide access to the VCXO for fine
tuning?

About the HW solution mentioned by Ian for the B210 board, does it require
soldering? Is there any documentation available?

Thanks,
Dario





On Tue, Jul 28, 2015 at 1:48 PM, Ian Buckley <ianb at ionconcepts.com> wrote:

> Off the top of my head the only initial thing that occurs to me as a
> potential problem for your idea is the granularity of adjustment available
> in the RF synthesizers and the Baseband synthesizer might be different so
> there might be a different residual error from the ideal correction you
> supply vs what you actually get.
>
> There is actually a *potential* H/W mechanism to do this properly
> engineered into the B2x0 boards, however it is disabled by default in
> manufacture in preference to the 10MHz reference clock circuit (They are
> mutually exclusive). If the PCB is stuffed differently then a AuxDAC in the
> AD9361 can be used to tune the 40MHz VCTCXO under S/W control rather like
> typical cellphone handsets do.
>
> -Ian
>
>
>
> On Jul 28, 2015, at 1:18 PM, Dario Fertonani via USRP-users <
> usrp-users at lists.ettus.com> wrote:
>
> I'm looking for a software solution for XO error correction. In an ideal
> world there would be an API that finely drives the XO, so that every
> frequency derived from it through division/multiplication is properly
> scaled too. In my understanding this capability doesn't exist on B210/UHD.
> Please confirm/correct this understanding.
>
> The focus here is on correcting a long-term bias, not the noise around it
> (which is actually satisfactorily low on B210). Let's assume for now that
> the correction can be applied at the init stage and doesn't need any update
> after that. My plan is to replace the following code
>
> rfBoard->set_master_clock_rate( MasterClockRate_Hz );
> rfBoard->set_rx_rate( SamplingFreq_Hz );
> rfBoard->set_tx_rate( SamplingFreq_Hz );
>
> with this one
>
> rfBoard->set_master_clock_rate( MasterClockRate_Hz * ScaleXO );
> rfBoard->set_rx_rate( SamplingFreq_Hz * ScaleXO );
> rfBoard->set_tx_rate( SamplingFreq_Hz * ScaleXO );
>
> and similarly with all other calls with values in Hz, like for
> uhd::tune_request_t. In the code above the variable *_Hz are double
> variables in Hz and ScaleXO is a double variable very close to 1 (for
> example 1.0000005 is an error of 500 ppb). Am I overlooking anything? The
> only problem I can think of is preserving the constraint that the master
> clock rate is an integer multiple of the sampling rate, which isn't a
> function of ScaleXO in exact math but may become so in finite math. For
> example, if an exact ratio of N becomes (N+1e-30) because of finite math,
> will UHD work? If not, will it dump a warning/error?
>
> Thanks,
> Dario
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160330/ce8cdb59/attachment-0002.html>


More information about the USRP-users mailing list