"Laureline" embedded GPS NTP server

[ve7xen]

Great news! I already spent the time to build a dedicated NTP server around an old ATNGW100 board and GPS had laying around, but I wonder if this might perform better (probably) in a smaller form factor. Do you support any of the ntpd extensions for e.g. querying clock state, or is there some other interface?

Those Hammond cases are expensive. Wouldn't take much to redesign for one of the Sick of Beige cases I don't think, and perhaps you can get your PCB area down as well. http://dangerousprototypes.com/docs/Sick_of_Beige_compatible_cases

[gxti]

I really like the metal box. It helps keep outside noise from interfering with the GPS module, and keeps inside noise from the pre-regulator and CPU from leaking out. Plus it just looks really nice, much better than a boring black plastic box. It is a sizeable fraction of the parts cost but the PCB costs twice as much right now so I stand to save more by getting PCBs made in bulk than I do losing the box. It also seems like it would be easier to get custom end plates for extruded enclosures than a typical plastic tub. Someone told me Hammond even does it themselves at prices barely above what their stock cases retail for at 25 qty but I don't see any mention on their website.

I have an inkling that I should probably split the project in two. One fancy ready-to-use box with everything included and one experimenter board based on revision 3, with or without the GPS module populated, and with 5V input only. For that I would be happy to tweak it for sick-of-beige. The existing boards already have mounting holes as well, so if you're not afraid of a drill bit it'd be easy to make your own.

[dfmischler]

The rev 3 boards have 10MHz out ... not ... high quality ... there will definitely be frequency wiggles...

I guess I'll just keep looking for a cheap enough HP Z3801A or Trimble Thunderbolt then.  Thanks for your reply.

[dans34]

how  much are you looking to sel one of theese for ?

[AndyEverett]

I have built a very similar project using an Navman Jupiter GPS module - this module has a 10KHz output locked to GPS, which was ideal for disciplining a 10MHz TCXO / OCXO. However, GPS modules do not seem to have a very long shelf life - within a couple of years they have been replaced by a different device with a completely different footprint or software interface. I have also had some experience of commercial GPS time servers. The company I work for purchased a small network time server off these guys: http://www.timetoolsglobal.com/information/gps-ntp-network-sync-products/ which is relatively low cost unit and is quite impressive. We have used it sync a small network of computers and CCTV cameras.

[gxti]

Cool. I find that 1PPS is plenty for this application. I believe the receiver I'm using (NEO-6M) supports 10PPS output as well but I haven't bothered turning it on as it would just mean more time spent running PLL math. Worth a try though, even saturating the Ethernet with NTP queries I'm under 10% CPU load, if I recall correctly. The higher frequency GPS timing outputs (10kHz or even 10MHz) are handy for building GPSDOs without a microcontroller but they're definitely not needed here.

NEO-6 is a staple of u-blox's lineup, and their new NEO-7 is footprint compatible, so I'm not worried about sourcing components for quite a while. If I got my hands on some NEO-6T modules I would consider producing some carrier boards with the same layout as some of the popular timing modules like the Jupiter and/or Trimble's offerings. I'm sure people would be interested but a reel of NEO-6T is not cheap and that's the only reliable way to get them.

I'd also like at some point to build a rack-mount version of Laureline with redundant power supplies and possibly an OCXO but first I have to get this one out the door. Hopefully should have 12 units shippable this week, and I'll see how many more I'll need to make from there.

Pics of the final boards since I haven't posted in a while:


Documentation, work-in-progress but mostly done:
http://partiallystapled.com/pub/laureline-docs/

[Kohanbash]

Hi
Nice project. I just sent a board in to OSH Park two weeks ago for a very similar project. I wanted to log data and have it time synced to the computers in my robot.

I am doing something very similar with a GPS and a micro running an NTP server.
The other things I did was:
- Added several serial ports that will publish time and data
- Analog, digital, counter, and encoder inputs that get timestamped and published via serial.

I wanted to add CAN but am saving that for the next revision.

I will be putting everything on my blog once I have it tested and ready.

Edit: Just linked this project from my blog: http://robotsforroboticists.com/the-workbench/

[kony]

gxti: Any particular reason for having routed surround of oscillator ? Reducing drift due to mechanical tension of temperature dependent expansion of PCB ?

[gxti]

A small measure of thermal isolation, and in theory you could wrap some insulation around the tab. Also it looks kinda cool and makes people ask questions :-)

[jkline]

I was lucky enough to score a Laureline and have had it running for a week or so.

First off, thank you!

I do have a couple of questions:

In looking at the doc, I don't see a way in the configuration to get laureline to respond to ntp commands (e.g., ntpq -p).  Is that true?  If so, is there any chance to get that in the next software rev?  I'd like to know how well the server thinks it's doing.  I routinely use ntpq -p, ntpq -c rv, ntpq -c clocvarr, ntpdc -c kerninfo and ntptime.

Also, I have some devices that will only take one ntp server (for that matter, that includes OS X out of the box -- even though one can change that).  As such, I'll need to remember to switch them to another server if and when another leap second is scheduled.  The doc says something along the lines of "laureline doesn't support leap seconds at present".  Do you anticipate there will be an update to support leap seconds this year or next?

Again, thank you for this product.  It's exactly what I have been looking for.

Cheers,
John

[gxti]

In looking at the doc, I don't see a way in the configuration to get laureline to respond to ntp commands (e.g., ntpq -p).  Is that true?  If so, is there any chance to get that in the next software rev?  I'd like to know how well the server thinks it's doing.  I routinely use ntpq -p, ntpq -c rv, ntpq -c clocvarr, ntpdc -c kerninfo and ntptime.

Monitor commands aren't implemented yet but I'd like to implement them. Part of the problem is that it's not a "normal" ntpd so I have to figure out how to produce the statistics that people want to see from the PLL math that I have. I also have to be careful about security -- right now the 'monlist' command is a major problem for the internet because it can be abused to amplify DDoS attacks. Obviously I'm not going to implement monlist but all query types are potential problems, whereas just answering time requests is fairly safe because the reply is the same size as the query. I also need to improve the logging because really nobody wants to see the second-by-second raw captures by default, they want to see the same kinds of statistics that you're looking for from ntpq.

Also, I have some devices that will only take one ntp server (for that matter, that includes OS X out of the box -- even though one can change that).  As such, I'll need to remember to switch them to another server if and when another leap second is scheduled.  The doc says something along the lines of "laureline doesn't support leap seconds at present".  Do you anticipate there will be an update to support leap seconds this year or next?

First off yes, I definitely need to add support for leap seconds because it is necessary as a precursor to adding more sanity checking e.g. going into a failsafe mode if the GPS suddenly returns bogus data.

Secondly, the answer with respect to leap seconds and NTP clients is it depends on the client. Hardware devices that take a single NTP server tend to be using a "SNTP" sort of mode where it basically just polls the server periodically and sets the clock to whatever it gets back, every time. These kinds of client will be perfectly fine in case of a leap second, because Laureline will instantly start returning the correct time-of-day after the leap second. The lack of support in Laureline is not that it continues on the old timescale, but rather that it fails to notify clients that it's going to step. When the leap second comes, the GPS instantly starts reporting the new timescale and Laureline follows suit. It's the smart clients with a full ntpd stack that get confused, because they will refuse to jump a second into the past just because the NTP server suddenly says so. As long as they have enough sources telling them that a leap second is coming then they will step and everyone is happy.

Again, thank you for this product.  It's exactly what I have been looking for.

Cheers,
John

You're very welcome, please let me know what else you would like to see.

[jkline]

Thanks for the quick response.  I will indeed let you know if I think of anything else.

[hn]

I just received my Laureline and it is also working fantastically!

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.1.186   .GPS.            1 u   17   32  377    0.395    0.009   0.033

Also, I have some devices that will only take one ntp server (for that matter, that includes OS X out of the box -- even though one can change that).

In addition to specifying one's own ntp.conf for OS X, one can also just put a space-delimited list of ntp servers in the "Date & Time Preferences" in order to have it use multiple servers which should handle the leap-second issue (if I'm understanding it correctly that as long there are servers in the list that handle leap seconds properly the issue is mitigated).

[LabSpokane]

If you "industrialize" this with a locking power connector and some type of mounting kit to fasten it to a rack rail, din rail or backpanel, the world will beat a path to your door.  The next least expensive NTP server I've seen with this feature set is around $1500, and it is terrible. 

Excellent work!

[gxti]

DIN rail is a great idea. Polycase makes a nice box with a DIN mount that comes with a wall-mount bracket, although I doubt I'd be able to fit all the connections I want on what would be the bottom face when mounted. Ethernet, power and antenna I can do, but adding timecode outputs or a fault/alarm output could get tricky. Having everything along one edge is good for keeping cables tidy, and it also means I can use the same PCB in a 1U rack case without changing anything.

[alex.forencich]

This looks like a really cool project.  I need IEEE 1588 (PTP) support, though.  And a stable 10 MHz output would be very nice as well.  I have been looking around for a reasonably-priced solution that provides those features for a while now, but no luck.  Any possibility of those features in a later revision?

[baldusi]

I know this is very advanced. But may I inquire if adding a POE option is too expensive? With it I could leave it in the ducts between the switch and the antenna, almost like a truly embedded solution.

[mrflibble]

I know this is very advanced. But may I inquire if adding a POE option is too expensive? With it I could leave it in the ducts between the switch and the antenna, almost like a truly embedded solution.

See this post: https://www.eevblog.com/forum/oshw/%27laureline%27-embedded-gps-ntp-server/msg217830/#msg217830

[reneen]

Hi,

I am trying to get a hold of GTXI (I think his name is Michael), as I ordered and started building a couple of boards, I would like to find out which metal case he had used.  I cant find one with the internal measurement of 49mm X 80mm. Also if he has an suggestions in regards to updating the firmware or hardware.

If anyone else can chime in with any information, I certainly would appreciate it.

Renee

PS:  I know that this is a 2014 project, but it seems to be well done!

[AndrewBCN]

Hi,
I am trying to get a hold of GTXI (I think his name is Michael), ...

Hi Renee,
It seems gtxi has not logged in since 2014, and the repository on GitHub has also not been updated for the last 7 years, ditto apparently for his website.
His name is Michael Tharp, his email address is gxti@partiallystapled.com

Note that seven years ago we didn't have cheap and high performance SBC computers to work with. I would guess that in 2021, anybody building a GPS synchronized NTP server would use a readily available RPi or another SBC (instead of going to the trouble of designing a PCB for a low-end STM32F1 MCU), couple that with an inexpensive GPS module with a 1PPS output, and program the "glue" to make it all work under Linux (the Linux kernel has a driver for a 1PPS input for timing purposes). Or at least that's the route I would have suggested to you, if your objective was to build a standards compliant NTP server in the shortest time with a limited budget.

[MadScientist]

Has anyone tried the ATGM336H for PPS solutions it’s suppose to be a neo clone

[JBeale]

I've been using a Teensy 4.1 with the Ethernet kit https://www.pjrc.com/store/ethernet_kit.html as a NTP server, as described in this thread: https://forum.pjrc.com/threads/61581-Teensy-4-1-NTP-server and it has been working well for the past year or so. The Teensy's MAC does have hardware timestamping. I provide a 1PPS signal from a separate GPDSO. The board itself is very compact. My implementation is less so because I put it inside an 8" concrete block and then that in an insulated box, to slow down its temperature drift. Having done that, the Teensy reports an internal clock drift of 0.005 ppm per hour (which is measured and also corrected by the external GPSDO 1-PPS) so that seems to work pretty well.

[reneen]

Hi Andrew,

I have been following your NTP Project for a while, and i will probably build one, but the thing that attracts me to the Laureline is that all of the configuration has to be done via the USB, and the Ethernet only give you the opportunity to query the time. It is a bit safer from any intruding hands trying to reset or change time etc.
It will be use on a non-mission critical business environment where I want to have a backup source to the internet NTP's. 

JBeale: Same with the Teensy 4.1 I think, but I just ordered one to try it.

Thank you for your opinions and feedback. I have been tinkering with GPSDO for a couple of years now, and this will give me an opportunity to benefit from their accuracy.

I will let you both know of my testing and opinion.

Renee

[JBeale]

Yes, AFAIK the Teensy implements only what is actually needed on the network side, and it has no OS at all. Not to say it's necessarily secure from any network malfeasance, but if there is an attack, it would have to be designed for that rather unusual device.  Mine is only on my LAN, not exposed to the wider net but it has worked fine for a year or so, and it has the attractive feature of being fairly cheap as such things go.

[montecri]

My take on GPS NTP servers:

https://github.com/Montecri/GPSTimeServer