Teensy 4.1 NTP server

[manitou]

I am also getting a clock sync of 40.2 - 40.6ppm which seems to be way off what others are getting... The room is about 22C and the board is open-air. My GPS is a (presumably) knockoff M8N.

That ppm is a bit high (spec 30 ppm?). My dozen or so T4's are within 10 ppm, though the Teensy4-micromod is 40 ppm, but that's a different PCB layout and different crystal (Sparkfun). Is your T4.1 socketed? If you remove it from your PCB and put it in breadboard and hook it up to GPS and Ethernet, do you still get 40 ppm drift? Or do you have other T4.1s you can test?

[Talkiet]

That ppm is a bit high (spec 30 ppm?). My dozen or so T4's are within 10 ppm, though the Teensy4-micromod is 40 ppm, but that's a different PCB layout and different crystal (Sparkfun). Is your T4.1 socketed? If you remove it from your PCB and put it in breadboard and hook it up to GPS and Ethernet, do you still get 40 ppm drift? Or do you have other T4.1s you can test?

This T4.1 behaved the same when just hooked up with jumpers (eth port was on it's own little breakout)... I do have quite a few T4.1s and based on your comment I will swap a few in over the next few days and see how they behave. (Yes, the board I am using has a socket for the T4.1)


Cheers - N

[Talkiet]

I did sub in a second T4.1 (purchased at the same time as the first, from Sparkfun) and got results very closely aligned with the first example (40.2 - 40.6 ppm)

It doesn't really worry me as I am moving to a new approach to keep my timer in check using a DS3231 (paying attention to the type of it - and still disciplining to GPS every so often) but thought it was interesting.

Also relevant to this thread is that GPS master frame with the leap second offset. Takes up to 12.5 minutes after a fresh signal acquisition to get the leap second offset and the embedded value in your chip may differ from unit to unit depending on when they were made/flashed. Yes the battery backup does save it, but I do a lot of full resets on my units in testing and I only found out about the GPS master frame behaviour recently...

Cheers - N

[Talkiet]

Interesting... a 3rd T4.1 and this time I get the ticks evening out at about 999990 ticks, while the first two were both around 999960... This one was bought at a different time. I will try them all in the same board with exactly the same build and compare - but I suspect some of the T4.1s I have are significantly out of spec with the crystal.

(Is there a serial number in a Teensy I can extract?)

Cheers - N

[Talkiet]

In fact, checking under a microscope seems to show both the 24Mhz and 32.768kHz crystals are at least visually different on the two types of T4.1 I have that are giving in and (apparently) out of spec crystal performance.



The good (10ppm) Teensy is the one on the left with the "2400T" 24Mhz crystal... The one on the right (and another - not shown) Teensy both have the other crystals and stabilise at about 40ppm off...

Is this a known issue with some T4.1s? They were obtained from Sparkfun - any chance they are counterfeit? I haven't seen a counterfeit since the first 3.2 I bought

Cheers - N

[Talkiet]

That ppm is a bit high (spec 30 ppm?). My dozen or so T4's are within 10 ppm, though the Teensy4-micromod is 40 ppm, but that's a different PCB layout and different crystal (Sparkfun). Is your T4.1 socketed? If you remove it from your PCB and put it in breadboard and hook it up to GPS and Ethernet, do you still get 40 ppm drift? Or do you have other T4.1s you can test?

Just noticed that you also have a 40ppm T4.1 (although a micromod)... My most recent post in this thread shows that yes, I have different crystals on two fullsize T4.1s... It seems that some of the crystals are out of spec :-(

Cheers - N

[manitou]

(Is there a serial number in a Teensy I can extract?)

The Ethernet MAC address and USB id are unique. The MCU stencil has a "batch date", me thinks, (shown in your closeup photo), but your concern is with the crystal.

[defragster]

PRJC builds all the T_4.1's distributed by others like Sparkfun. The shown items are of different builds as one seems to be the early "A" 1062 and the one on the right s seems to indicate it is a newer/current "B" version of the NXP supplied 1062 MCU.

In these times with limited part availability, it is possible alternates are sourced to allow production. This is the first apparent notice of variation in the crystal showing this.

I can say the latest PJRC Supplied Beta T_4.1 with a "B" MCU shows a 2400T crystal in place. Other recent T_4.0 and 4.1 boards (Beta and other on desk) show the "A" MCU with the 2400T crystal.

Each Teensy does present a unique Serial number - there is code in CORES and the forum that can expose that to print, and it is presented over USB during Host connection and TyCommander displays that.

[Talkiet]

Thanks. It's not the end of the world as anything less than perfect needs to be compensated for in my application - I need ms synced separate units, but might be worth noting somewhere on the specs somewhere as it's about double the published tolerance in less accurate unit.

I have no reason to believe it is the MCU though so probably not worth bothering getting the serial unless someone would like a record of the units with the less accurate clock.

Cheers - Neil G

[manitou]

In fact, checking under a microscope

Curious, what kind of microscope are you using?

[JBeale]

I'm running the T4.1 NTP server and it has been working well. I can load the server webpage and see the charts and the text stats at the bottom of the page OK. I'm wondering if there's an easy way to programmatically retrieve one of those stats, every so often. My first thought was to simply fetch the webpage as text and search for the line of interest, but I see it's not just plain text. The parameter I am interested in is the clock frequency estimate, as for example the web browser shows:

 Estimate of NTP clock freq: 0.00000851 s/s

However when I simply fetch the webpage as a text file (eg. wget 192.168.1.211) I see the actual number is hidden behind some sort of javascript:

<p>Estimate of NTP clock freq: <span id='pidD'></span> s/s</p>

Is there an easy way for a remote system using a Python script, for example, to retrieve this value via some URL query?

EDIT: I see using the browser developer tools that the number does appear in the HTML code, and refreshes periodically.

Estimate of NTP clock freq: <span id="pidD">0.000008502</span>  s/s

So there's some javascript magic that pushes out the updates. I wonder how to capture that update from eg. Python.
My knowledge of HTML is still pretty much Web 1.0.

[ddrown]

The parameter I am interested in is the clock frequency estimate

The stats are all exported via json at /state.json: https://github.com/ddrown/teensy-ntp...WebContent.cpp

an example using the commands curl and jq:

$ curl -s http://teensy-1.lan/state.json | jq .pidD
0.000010005

you could also do this with python

[JBeale]

Your solution is great; thank you! I wasn't even aware of 'jq' prior to this.

[ddrown]

Your solution is great; thank you! I wasn't even aware of 'jq' prior to this.

jq is a very useful command line tool

[defragster]

jq is a very useful command line tool

Wondering what this useful JQ tool was, this came up:

stedolan.github.io/jq/

Windows and other OS versions at the ready. Shows here on WIN11 as:

jq - commandline JSON processor [version 1.6]

Usage:  jq [options] <jq filter> [file...]
        jq [options] --args <jq filter> [strings...]
        jq [options] --jsonargs <jq filter> [JSON_TEXTS...]

jq is a tool for processing JSON inputs, applying the given filter to
its JSON text inputs and producing the filter's results as JSON on
standard output.

The simplest filter is ., which copies jq's input to its output
unmodified (except for formatting, but note that IEEE754 is used
for number representation internally, with all that that implies).

For more advanced filters see the jq(1) manpage ("man jq")
and/or https://stedolan.github.io/jq

Example:

        $ echo '{"foo": 0}' | jq .
        {
                "foo": 0
        }

For a listing of options, use jq --help.

[ddrown]

Wondering what this useful JQ tool was, this came up:

stedolan.github.io/jq/

Yup, that's jq.

On windows, you can use powershell like this:

PS C:\Users\abob\Downloads> (Invoke-RestMethod http://teensy-1.lan/state.json).pidD
0.000010007

Or if you want to still use jq:

PS C:\Users\abob\Downloads> (Invoke-WebRequest http://teensy-1.lan/state.json).Content | .\jq-win64.exe .pidD
1.0009e-05

[JBeale]

Here is a plot of my Teensy's onboard crystal drift during 34 hours after a restart. (At least, I think this TeensyNTP-reported value is the onboard clock drift). Total change over that time was less than 0.4 PPM so that looks reasonably stable to me. The data plotted comes from running

curl -s http://teensy-ntp1.lan/state.json | jq ".clockPpb"

once every minute. I have the T4.1 sitting in a 8" hollow concrete block which is inside a sealed styrofoam box, to reduce the rate of temperature change on the board. The PPS input comes from a GPSDO. The +5V power to the Teensy is just from a cheap wall-wart, so voltage stability is another variable.

[ddrown]

Here is a plot of my Teensy's onboard crystal drift during 34 hours after a restart. (At least, I think this TeensyNTP-reported value is the onboard clock drift). Total change over that time was less than 0.4 PPM so that looks reasonably stable to me. I have the T4.1 sitting in a 8" hollow concrete block which is inside a sealed styrofoam box, to reduce the rate of temperature change on the board. The PPS input comes from a GPSDO. The +5V power to the Teensy is just from a cheap wall-wart, so voltage stability is another variable.

That's a nice graph, low amounts of short term change as well.

[mui]

Any thoughts on doing PTP announce?