[time-nuts] Designing an embedded precision GPS time server

[Philip Gladstone]

I built a couple of NTP time servers around this board: 
https://www.olimex.com/Products/ARM/ST/STM32-E407/open-source-hardware 
which supports IEEE1588. It also acts as a PTP source on the LAN. It is 
part of the IPv6 ntp pool and is currently serving about 1000 requests 
per minute. It uses a custom PCB to connect to a small display an the 
GPS board (it has support for a number of different GPS boards).

It just needs putting into a case to complete the project. Of course, 
the last 10% takes 90% of the time!

Philip


On 28/10/2017 15:58, Nick Sayer via time-nuts wrote:
> That looks and sounds very, very much like what I want to do.
>
> Thank you very much for your testing suggestions. When it comes time, I had indeed planned on adding it to the NTP pool if for no other reason than to contribute to the cause (but also for testing).
>
> I believe I’m going to start with one of my GPS module breakouts and an E70 XPlained development board. From a hardware perspective, I expect that to be reasonably close to what the final hardware will be (the one thing I would guess would change would be perhaps swapping out the PHY chip for one that’s capable of doing PHY level timestamping, if that’s necessary and possible).
>
> But my plan at the moment is to first try to get something that even answers the phone, see how terrible it is, and then see what has to be done to make it truly worthy.
>
> Those interested can follow the hackaday project. This whole thing is going to be open hardware and GPLed firmware (again, assuming I succeed).
>
> https://hackaday.io/project/27873-embedded-gps-ntp-server
>
>> On Oct 27, 2017, at 12:27 PM, Leo Bodnar <leo at leobodnar.com> wrote:
>>
>> Hi Nick,
>>
>> Last year I have designed an NTP server with sub-microsecond turnaround accuracy/jitter at fully saturated 100K+ packets/sec traffic (full 100Mb wire speed) that costs just £250 from stock.
>> Its holdover performance on signal loss is in the order of 4-5ms/day.
>> https://store.uputronics.com/index.php?route=product/product&path=60_70&product_id=92
>>
>> If you can come up with a cheaper and higher performance alternative I am very interested in licensing your design.
>>
>> When you come to testing I can highly recommend placing your prototypes in public NTP pool and asking the admins to add it to .ch zone - you are guaranteed to get full 110kpps traffic spikes that will help to flush out bugs.
>> Just a few devices collectively served 1.1 trillion packets in less than a year http://leobodnar.com/LeoNTP/ (and have been through the infamous snapchat incident.)
>>
>> Jitter and holdover need to be tested on a controlled LAN segment - I can highly recommend contacting Denny Page on this list and sending him a unit to test.
>> He built sophisticated and highly tuned testing system that tracks timing jitter and offset down to dozens of nanoseconds accuracy.
>> Denny is vendor-neutral and provided honest and fair feedback while I was developing my unit.
>>
>> Hope this helps!
>>
>> Thanks
>> Leo
>>
>> On 26 Oct 2017, at 17:00, time-nuts-request at febo.com wrote:
>>
>>> Date: Wed, 25 Oct 2017 17:53:46 -0700
>>> From: Nick Sayer <nsayer at kfu.com>
>>>
>>> I’ve just completed a project (off topic) with the ATSAMS70 chip and learned a lot in a relatively short time, and I really like the result.
>>>
>>> I am considering a new project based on its cousin, the ATSAME70. The E70 has an Ethernet 10/100 MAC built in as well as the rest of the stuff the S70 has (USARTs, SD/MMC, AES-256, TRNG, high-speed USB… it’s quite nice), and Atmel Start (the software development framework I’ve been using) purports to have a ready-to-use IP stack (alas, no IPv6, but it’s a starting point at least).
>>>
>>> Where I am going with this is I am considering designing a precision embedded NTP/PTP server. I’d connect one of the SkyTraq modules I’ve got piles of up to a GPIO and USART and the Ethernet port would provide NTP/PTP. The idea behind making it an embedded system would be to try and make it as accurate as it reasonably can be with the hope that (at least on the local segment) it would wind up being more accurate than a Pi Zero doing the same thing. At the very least, you’d expect such a thing to be a whole lot less hassle to set up, given decent firmware.
>>>
>>> This may be a fool’s errand, certainly, but looking at it from here, I would think that such a design might offer accuracy in the microsecond range, but that’s just a tremendously uninformed guess at this point (and what does that accuracy mean to a peer that might itself be incapable of better than 2 orders of magnitude coarser?).
>>>
>>> Anybody have any ideas or suggestions along these lines?
>>>