Forum Rule: Always post complete source code & details to reproduce any issue!
Page 2 of 2 FirstFirst 1 2
Results 26 to 32 of 32

Thread: Teensy 4.1 NTP server

  1. #26
    Senior Member
    Join Date
    Oct 2012
    Location
    Portland OR
    Posts
    706
    With more data, I see my wild surmise about my GPSDO was wrong, and your more obvious suggestion was correct. Almost all the variation I saw was explained by air movement over the T4.1 PCB, as well as the ambient temperature. When I left the office with the door closed overnight, the error was a mostly a regular low-pass-filtered square wave tracking the 23-minute HVAC on/off cycle. This morning, after I sealed the T4.1 into an 8 inch cinderblock to remove drafts and stabilize its temperature, the chi-squared value is often less than 1 and rarely exceeds 5, and the offset rarely exceeds 30 ns, so the performance is quite different from before.
    Code:
    count       offset      frequency   chisq      ppb  ntpseconds
    1723630418 0.000000013 0.000007707 0.333104610 7708 3805121064
    1798629840 0.000000009 0.000007707 0.333148301 7707 3805121067
    1823629647 0.000000023 0.000007707 0.638458192 7709 3805121068
    1898629069 0.000000020 0.000007707 0.305683136 7709 3805121071
    1998628298 0.000000026 0.000007707 0.437653899 7710 3805121075
    2073627720 0.000000018 0.000007708 0.405045867 7709 3805121078
    2148627142 0.000000010 0.000007708 0.337020397 7709 3805121081
    2248626371 0.000000016 0.000007708 0.325883627 7709 3805121085
    2323625793 0.000000010 0.000007708 0.257352889 7709 3805121088
    2348625600 0.000000022 0.000007708 0.275229812 7710 3805121089
    2423625022 0.000000014 0.000007708 0.226483017 7709 3805121092
    2523624251 0.000000017 0.000007708 0.229082704 7710 3805121096
    2598623673 0.000000010 0.000007709 0.233526707 7709 3805121099
    2698622902 0.000000014 0.000007709 0.233599454 7710 3805121103
    2723622709 0.000000024 0.000007709 0.321402192 7711 3805121104
    2823621938 0.000000023 0.000007709 0.375832856 7711 3805121108
    2898621360 0.000000010 0.000007709 0.377925456 7710 3805121111
    2998620589 0.000000010 0.000007709 0.421401381 7710 3805121115
    3023620396 0.000000020 0.000007709 0.451219887 7711 3805121116
    3123619625 0.000000020 0.000007710 0.515136003 7711 3805121120
    3198619047 0.000000007 0.000007710 0.347284496 7710 3805121123
    3298618276 0.000000007 0.000007710 0.274755895 7710 3805121127
    3323618083 0.000000017 0.000007710 0.437681466 7712 3805121128
    3423617312 0.000000014 0.000007710 0.339892298 7711 3805121132
    3523616541 0.000000010 0.000007710 0.339898229 7711 3805121136
    Last edited by JBeale; 07-30-2020 at 06:18 PM.

  2. #27
    Quote Originally Posted by JBeale View Post
    With more data, I see my wild surmise about my GPSDO was wrong, and your more obvious suggestion was correct. Almost all the variation I saw was explained by air movement over the T4.1 PCB, as well as the ambient temperature. When I left the office with the door closed overnight, the error was a mostly a regular low-pass-filtered square wave tracking the 23-minute HVAC on/off cycle. This morning, after I sealed the T4.1 into an 8 inch cinderblock to remove drafts and stabilize its temperature, the chi-squared value is often less than 1 and rarely exceeds 5, and the offset rarely exceeds 30 ns, so the performance is quite different from before.
    Nice! Good idea with the cinderblock, that should add a lot of thermal mass

  3. #28
    Senior Member
    Join Date
    Oct 2012
    Location
    Portland OR
    Posts
    706
    After a few days of sitting in a concrete block, which is in turn inside a large styrofoam box, the T4.1 temperature and frequency drift has mostly stabilized. Its reported CPU temperature is around 61.2 C and the frequency drift is near +8.612 ppm, with stability near 0.005 ppm in one hour. Based on the crude reported CPU temperature, this particular T4.1 frequency tempco is +0.195 ppm/C so it appears that the oscillator temperature is not drifting more than 25 milli-degrees in that time period. Not too bad!

    Click image for larger version. 

Name:	T41-NTP-ppb-2a.jpg 
Views:	16 
Size:	106.4 KB 
ID:	21230
    Click image for larger version. 

Name:	T41-NTP-ppb-2b.jpg 
Views:	14 
Size:	61.4 KB 
ID:	21231

  4. #29
    Quote Originally Posted by JBeale View Post
    After a few days of sitting in a concrete block, which is in turn inside a large styrofoam box, the T4.1 temperature and frequency drift has mostly stabilized. Its reported CPU temperature is around 61.2 C and the frequency drift is near +8.612 ppm, with stability near 0.005 ppm in one hour. Based on the crude reported CPU temperature, this particular T4.1 frequency tempco is +0.195 ppm/C so it appears that the oscillator temperature is not drifting more than 25 milli-degrees in that time period. Not too bad!
    My two have a tempco of 0.154ppm/C and 0.206ppm/C, so that fits with your 0.195ppm/C.

    Wander being 0.005 ppm in an hour is pretty impressive.

  5. #30
    Senior Member
    Join Date
    Oct 2012
    Location
    Portland OR
    Posts
    706
    Well, I am cherry-picking the best few hours I've seen so far, but the concrete block is pretty effective in slowing down temperature changes. It appears to me if I had a high-resolution temperature sensor, and the temperature gradients and rate of change with time are low enough, that it may be possible to compensate the drift for that sort of stability over the medium term (at least for many hours). I don't know about temperature hysteresis and no doubt there is also an aging component longer-term, but so far in this experiment, I don't see much variation that isn't explained by temperature. I don't actually have a need for that level of performance, but it's interesting how stable it seems to be. If you maintained a constant error of 5 ppb for one year, it would add up to 0.16 seconds.

  6. #31
    Senior Member+ manitou's Avatar
    Join Date
    Jan 2013
    Posts
    2,583
    @ddrown, your isr in examples/lwip_1588_input/ needs asm volatile ("dsb");, otherwise the ISR fires twice for each PPS.

    https://github.com/ddrown/teensy41_ethernet
    Last edited by manitou; 08-29-2020 at 12:34 PM.

  7. #32
    Quote Originally Posted by manitou View Post
    @ddrown, your isr in examples/lwip_1588_input/ needs asm volatile ("dsb");, otherwise the ISR fires twice for each PPS.

    https://github.com/ddrown/teensy41_ethernet
    You're correct, I've updated that example.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •