improved cheap ntp stratum 1 server

The cheap stratum ntp server based on ESP8266 turned out as unstable. I’m not sure, if it is a hardware or a software problem.  The module suddenly hangs and then sometimes the watchdog is triggering and sometimes only a poweroff and poweronn will get the wifi connection up again. I had similar problems with my secure esp8266 sensor node. It seems, that the problems are more often with many data transmitted via serial interface.

I have adapted my arduino code to be used with an ESP32 and made a prototype with this platform. Time will show, if this solves all the stability problems.

 

 

4 thoughts on “improved cheap ntp stratum 1 server”

  1. Markus,

    What GPS module did you use for this project?

    Wast it the same GPS module as you used for the ESP8266 project ?

    I ask as a reference in case I use a different GPS I know which one you used to enable any changes that need to be made in code should I try this. I have been giving some thought to a GPS time source, but have not made any decision as yet if I will do so.

  2. John,

    sorry for the late reply. Your comment was in the spam folder….

    I used a NEO 6M module. However I was not really satisfied with jitter. I may try with some ethernet esp32 modules from olimex.

  3. Hi Markus,
    had a lot of fun with your code on the esp32, and some successes. Biggest issue was the inconsistent int service time, which sometimes blows out to over 100us due to conflicts with background processes. I overcame this by looping until 995ms after last pps, locking out the interrupts, and polling for the state change. This gave me consistently < 2us jitter and max 10us error. Next problem is the Neo6M module which has the habit of slewing 1us early for 5 or 6 seconds each time it does a satellite re-selection, then throwing in a big correction of up to the 10us mentioned earlier. I overcame this by maintaining a drift characteristic, detecting the slew activity, then replacing the pps times with something more ordered until it recovers. It now seems to follow the processor clock drift really well, maintaining a short term accuracy of around +/-1us, which is way better than any application I need, but it was a challenge.
    I had tried doing a least squares linear fit to the proceeding time data to resolve it sub microsecond, but until I could get the data <1us jitter this just didn't work, now I think I can pre-qualify the data before admitting to the curve fit algorithm, but as I say I can't use the higher accuracy anyway.
    Anyway, just a bit of nerdy fun, thanks for the inspiration.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.