[USRP-users] B200mini X1

Steven Knudsen ee.knud at gmail.com
Tue Mar 29 10:46:41 EDT 2016


Okay. Thanks, Marcus.

I appreciate you digging into the code and providing the referenced filename.

From your description, it appears to be a first-order update, nothing too fancy, but run fast enough that it’s pretty good.

You also anticipate the next step and I agree that there’s no real need to sample continuously. Rather, as you suggest, it would be good enough to every so often sample the set point (correction value) via the UHD and cache the value on the host. Then at boot, if there is no 1 PPS reference, write that value back to the USRP FPGA’s DAC register. I may be making things up a little having not looked at the code, but that’s the general idea, and what I have done in the past with other systems.

It’s a little bit academic and there are other solutions, like driving the reference input with 1 PPS derived from a GPSDO that has high stability (stratum-3), for example.

I think I have plenty to go on now and thank you for the quick response.

Steven


Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen

Der entscheidende Augenblick der menschlichen Entwicklung ist immerwährend. Darum sind die revolutionären geistigen Bewegungen, welche alles Frühere für nichtig erklären, im Recht, denn es ist noch nichts geschehen. - Franz Kafka

> On Mar 29, 2016, at 05:17, Marcus Müller via USRP-users <usrp-users at lists.ettus.com> wrote:
> 
> Hi steven,
>> is whether or not the DAC setting for the VCTCXO is saved periodically
> Hm, what do you mean with "saved"? Saved as in "stored somewhere for later analysis"?
> 
> No; the value is updated continously, whether there is an active PPS signal or there just was one (which isn't active anymore).
> 
> I had to read Verilog myself, since I didn't want to give you false information, but: 
> usrp3/top/b205/b205_ref_pll.v has a state machine.
> Lines 78-100: Assuming you're in the state "ref_detected", "ref_is_pps" = 1, ref_is_10M = 0, but then, the PPS pulses stop, nothing will change the state; the transition only happens when there's a rising PPS edge, but it's too early or too late.
> So, "valid_ref" is 1, at least until the next PPS pulse comes; if that comes in time, yay, we get to gradually adjust the externa
> Lines 193-255: since valid_ref==1, and ref_is_pps==1, you're in a loop between states
> MEASURE->CAPTURE->CALCULATE_ERROR->CALCULATE_ADJUSTMENT->CALCULATE_OUTPUT_VALUE->APPLY_OUTPUT_VALUE->MEASURE
> 
> So what happens here is based on the continously running PLL chip's internal clocks, an adjustment for the VCO is calculated and applied. So yes, the DAC value is continously kept during operation, but no, they're not sent to the host computer for analysis.
> 
> Adding another stream that would be "continously sampled" from these values would be rather intense, but you could go ahead and just add a UHD user settings register, so that you can, by adding a method to UHD somewhere, read it from the host computer periodically. Maybe easier: "tapping" the lines running to the DAC by also feeding them to the GPIO port, and monitoring those with e.g. a logic analyser device or any SPI-to-USB converter that works with the 12.5MHz SPI clock; or, instead, because you're already modifying the FPGA, just outputting the calculated errors/adjustment values/... to the GPIO in whatever format you please (e.g. either as parallel bus values, or by using instantiating another SPI driver module). 
> 
> Best regards,
> Marcus
> 
> 
> On 29.03.2016 05:28, Steven Knudsen via USRP-users wrote:
>> Thanks very much for the confirmation. 
>> 
>> And thanks for opting for the really stable option. 
>> 
>> I am looking at details for holdover when 1 PPS is not available. This is relevant to TDMA systems, among other things.
>> 
>> An obvious question that the list or Ettus may be able to help with, and that saves me looking into the FPGA source, is whether or not the DAC setting for the VCTCXO is saved periodically while there is an external reference? I hope so :-)  I am assuming there is a simple control loop for the DAC value, guessing a PID or something.
>> 
>> I recently had to develop a comparable clock discipline subsystem for a radio that was being refitted with digital technologies and that would be expected to operate with or without GPS and support ranges in excess of 30 km. Loads of fun.
>> 
>> Thanks again for the quick response!
>> 
>> steven
>> 
>> 
>> Steven Knudsen, Ph.D., P.Eng.
>> www. techconficio.ca <http://techconficio.ca/>
>> www.linkedin.com/in/knudstevenknudsen <http://www.linkedin.com/in/knudstevenknudsen>
>> 
>> Der entscheidende Augenblick der menschlichen Entwicklung ist immerwährend. Darum sind die revolutionären geistigen Bewegungen, welche alles Frühere für nichtig erklären, im Recht, denn es ist noch nichts geschehen. - Franz Kafka
>> 
>>> On Mar 28, 2016, at 17:14, Derek Kozel < <mailto:derek.kozel at ettus.com>derek.kozel at ettus.com <mailto:derek.kozel at ettus.com>> wrote:
>>> 
>>> Hello Steven,
>>> 
>>> The onboard reference is a VCTCXO indeed made by CTS, you've found the right datasheet. It is the 0.5ppm version.
>>> 
>>> Regards,
>>> Derek
>>> 
>>> On Mon, Mar 28, 2016 at 3:57 PM, Steven Knudsen via USRP-users <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>> wrote:
>>> I may be blind, but I have not found a document reference for the clock on the B200mini. However, from the markings on the clock I think it’s a CTS VTCXO matching the link to the data sheet below. Can anyone confirm this and if so, the stability grade?
>>> 
>>> http://www.ctscorp.com/wp-content/uploads/2015/11/008-0371-0.pdf <http://www.ctscorp.com/wp-content/uploads/2015/11/008-0371-0.pdf>
>>> 
>>> thanks!
>>> 
>>> steven
>>> 
>>> 
>>> Steven Knudsen, Ph.D., P.Eng.
>>> www. techconficio.ca <http://techconficio.ca/>
>>>  <http://www.linkedin.com/in/knudstevenknudsen>www.linkedin.com/in/knudstevenknudsen <http://www.linkedin.com/in/knudstevenknudsen>
>>> 
>>> All the wires are cut, my friends
>>> Live beyond the severed ends.  Louis MacNeice
>>> 
>>> 
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
> 
> _______________________________________________
> 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/20160329/36a6fa4e/attachment-0002.html>


More information about the USRP-users mailing list