Embedded GPS NTP server

A lean embedded GPS based NTP server

Similar projects worth following
While you can throw together a Raspberry Pi and a GPS module to make a stratum 1 NTP server, it takes a non-trivial amount of setup and the resulting accuracy is limited by the heavyweight Linux kernel and OS.

This project aims to use an embedded ARM Cortex M7 chip (specifically the ATSAME70Nxx) with dedicated firmware to do this job, with an accuracy goal of a microsecond or better.

Having recently (more or less) completed the Orthrus v3 design with an ATSAMS70, it occurred to me to see what else could be done with that chip family.

In a sense, this project represents an answer in search of a question because of that, but I do believe there's something of benefit to be had here.

The SAME70 is very much like the S70, but it adds a 10/100 MII/RMII Ethernet MAC. This project will make use of that chip plus a GPS timing module. The GPS module will supply NMEA sentences containing the time, plus PPS pulses that the controller will use to keep accurate track of the time.

The chip will run an IP stack over which it will provide NTP (and perhaps PTP) service.

The chip also has several more peripherals available, but the only other one of interest to this project will be the high speed USB port. This port is useful because if you erase the chip, by default it will start a SAM-BA bootloader listening on USB. This is the easiest means to provide for field firmware upgrades (though it remains to be seen if this function could instead be performed over Ethernet one way or another).

The USB port could also conceivably be used as an alternative to configuration over IP (though it's likely to be far less user-friendly). Better, though, would be an HTTP server, but - again - it remains to be seen exactly how possible or easy that will be to achieve.

Another stretch goal will be IPv6 and mDNS (over IPv4 and v6) support. Again, it remains largely to be seen how much of this is possible.

NTP server v0.pdf

Preliminary schematic

Adobe Portable Document Format - 133.13 kB - 08/10/2020 at 18:01


  • Preliminary design

    Nick Sayer08/10/2020 at 18:01 0 comments

    I've added a schematic of a preliminary design. It's a start, anyway.

  • Starting up again

    Nick Sayer08/07/2020 at 21:23 0 comments

    This project has just sat around for a while, but I've taken a renewed interest in it.

    I've decided to use the KSZ8081MLXCA-TR MII PHY chip. That, a 25 MHz crystal and an RJ45 jack with magnetics is all that needs to be added for the Ethernet part of this project. Along with that, the SPI0 bus will be connected to the aforementioned MAC address EEPROM chip, one of the UARTs will be connected to the serial port on the GPS module, and the PPS pin will be connected to one of the (many) remaining GPIO pins.

  • Getting a MAC address

    Nick Sayer03/18/2020 at 20:53 0 comments

    Glen Akins alerted me to this little chip: The Microchip 25AA02E48T-I/OT. It's a pre-programmed 256x8 SPI flash chip. The chip is available as a SOT23-6 and is a standard SPI peripheral. The top 6 bytes (0xFA-0xFF) come pre-programmed with a globally unique EUI48 address. 38¢ Q:1 pricing at DigiKey. Mischief Managed.

    To use it, you do an 8 byte SPI exchange: 0x03 0xFA followed by 6 "don't care" bytes. You get the MAC address by reading the values during the "don't care" bytes.

  • Getting started

    Nick Sayer10/26/2017 at 21:20 0 comments

    I was talking with someone over e-mail today about this project, and they brought up the topic of a development board.

    It's something I hadn't considered for this project before now, but it makes some sense, now that I think about it.

    For Orthrus, I originally bought an XPLained E70 board, but I didn't actually make any use of it. Its SD card slot lacked the multiplexing hardware required for that firmware. I wound up making my own board, and it worked well enough that no further hardware iteration was strictly necessary.

    But for this project, the E70 XPlained might be just the thing. It has the Ethernet interface on it, which is exactly the same as what I propose to use anyway. All I really need to do is use some jumpers to connect one of my GPS breakout boards up and write the firmware. This has the added advantage of allowing me to try different ways to wire the GPS module to get one that's optimal.

  • Physical design

    Nick Sayer10/26/2017 at 16:01 0 comments

    This is sort of skipping to the end, but I am going to see if I can use a 50x80 mm board for this project and the same case that I use for my GPSDO project. The big question mark is whether an RJ45 jack will fit vertically in the available space or not. Or, if not, whether a taller 50x80 extruded chassis is available.

    Rather than use a 2.1mm power jack as I always have, I am leaning more towards using a USB microB jack for this project. The reason for that would be so that the same jack could be used as a firmware update port as well as to supply power. As with Orthrus, there will be an internal ERASE header that will force the chip to boot into SAM-BA to accept new firmware over USB. It may be possible to update the firmware over Ethernet as well (TBD), but this would be a fail-safe method to reclaim control of a bricked device.

    The back panel will have the power and antenna jacks. I am envisioning putting the Ethernet jack on the front panel so that the integrated LEDs would be visible (and because I'm not sure there would be sufficient space on the back). I'm not yet sure about UI options on the front. I could go with just some light pipes to display rudimentary status, but for extra credit it sure would be nice to be able to actually display the time.

    The hardware should wind up - again - being fairly straightforward. I intend to steal the Ethernet design directly from the E70 Xplained board. Most of the rest of the design comes over from Orthrus. The SkyTraq GPS stuff is quite mature at this point having been put to use in a number of my other projects. The only remaining design questions are the optimal wiring of the PPS signal. The intent will be to use it as a timer capture input. The datasheet is a little unclear how best to achieve that, unfortunately.

View all 5 project logs

Enjoy this project?



Renee N wrote 10/28/2021 at 17:18 point

Hi Nick,  

Have you made any progress on this or is the project dead?  

I really have looked into the Laureline and this appears to follow the same design, but newer and improved.  Could you please comment as I would like to know if to give up and look into one of the many implementations of an RPI with a HAT or a refurbished commecial unit.

  Are you sure? yes | no

Dave wrote 07/16/2020 at 13:20 point

Just found this while looking for a replacement for the Laureline,, a rather nice STM32-based device which is unfortunately no longer available.  Was there any further development on this?

  Are you sure? yes | no

liebman wrote 10/26/2017 at 20:28 point

Interesting.  I 've been planning something similar but wifi based using either an ESP8266 module or an ESP32 module.  Are you planning on building a software PLL to track the PPS signal as most NTP server implementations (as well as the RFC) use?

  Are you sure? yes | no

Nick Sayer wrote 10/29/2017 at 00:24 point

Probably not a PLL, but likely what amounts to an FLL. The plan at the moment is to use capture on a timer running as fast as possible to track the number of timer counts per second and just use that to fractionalize the current timer delta (from the last PPS event).

Because of this - like my standalone GPS clock - I'm not planning to support holdover. You either have GPS reception, or the device won't respond. The good news, though, is that timing modules do a better job of dealing with reduced constellations (that is, poorer reception).

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates