Device works well, very handy when connecting to MCUs and crossing voltage domains.
Very handy for car related stuff and non-isolated mains powered stuff.
Worth the money, very handy device !

Very handy for debugging any of a variety of devices that happen to have UARTs. Totally plug and play on OS X. We never even looked at the doc. Just plug it in, hook up VCC, GND, TX and RX and off it goes. Remember TX is from your computer, not your device, so plug your device's RX into the pin labeled TX and vice versa. We guessed right the first time on this.

We just ordered three more of these. We need extras in the lab so we aren't always fighting over the one we have.

Unlike some reviewers, I don't have the sophisticated equipment and knowledge to validate or refute claims like "locked to UTC ±200ns". Nor do I actually need to have the accurate time to within 200ns. But I do love the idea of precision timekeeping, so I bought a Laureline.

I started by plugging it into my laptop via USB and attaching a terminal program. As promised, within 3 minutes it was synchronized to GPS time and busy tuning its on-board TXCO. I gave the device a static IP address via my DHCP server (the laureline's hardware address is shown by the "info" command over USB), and plunked it on the network. I also gave it the hostname "ntp" in my DNS (you could use a hosts file too).

In my ntp.conf, I used the configuration line:
server ntp iburst minpoll 2 maxpoll 2

these settings allow ntpd to query the laureline more frequently. With just a handfull of machines querying the laureline over the local network, it can't do any harm, and it seems to give better performance in terms of ntpdc kerninfo's "estimated error" figure.

(I also retained the lines for pool.ntp.org, so in case of an "outage" of the laureline I'll still get network time)

Over the last few weeks I've been informally monitoring my main home computer's NTP performance. It reports an "estimated error" of under 25µs typically (2.5e-5s), and often under 10µs (1e-5s). During that time, the frequency offset for computer's own uncompensated oscillator has varied by about ±1ppm. (which actually seems pretty good)

A final note: I ordered the suggested sparkfun.com antenna. sparkfun.com's page on the antenna specifies it as 3.3V, but the linked datasheet specifies it as 3-5V. I did *not* move the laureline's solder jumper, and so far the antenna seems to work properly with the 5V supply. I've asked sparkfun to clarify their specifications for the antenna, but they hadn't updated the description the last time I looked.

It installed easily, took a few minutes to stabilze. It's been running for several weeks, consistently giving substantially better performance than internet sources. (Right now, I'm showing that I'm within about 11 microseconds; my internet sources are still configures, and are running around 2 to 5 milliseconds off. That is fairly typical.)

My comments and positive experience with the Laureline pretty match what the previous reviewer (that's jrichert) said, delivery took a long time, but eventually it arrived. The use of FTDI rather than the widely-used Prolific USB/serial was great, it just worked out of the box rather than having to go to some Russian site to find patched Windows binaries that may or may not work on your system. Configuration via USB serial was a breeze, plugged it in, a few minutes later I had a lock, and then NTP output, from something that's a tenth the price of a Symmetricom or equivalent.

One for the wishlist, it'd be nice to have the indicator LEDs on the "front" (antenna) side rather than the "back" (power/network cable side). Most SOHO gear (non-rack mount) has the cabling coming out the back and indicator LEDs on the front, with the Laureline you've got to either loop all of the cabling round the back or stick your head around the side to see the status LEDs.

Update: For those using it under Windows, some notes: There's no easy way via the GUI to point to the Laureline, you need to go into the registry and change HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer to "<Laureline-IP>,0x1", then open a command shell as Administrator and restart the Windows time service with "net stop w32time" and "net start w32time", then finally force a resync with "w32tm /resync". To check that this worked, go into Control Panel | Date and Time | Internet Time which will still display the time server as one of the small number of choices that Microsoft provide (none of which are pool.ntp.org or anything similar, sigh), however if all worked out OK you'll see the message "The clock was successfully synchronized with <Laureline-IP> on ... at ...".

Just got my Laureline yesterday, connected it to my local network, and from that moment I enjoy a highly accurate time base on all my little computers!

I unpacked it, plugged it in, connected an unamplified GPS antenna stuck to the glass of my office window and it synced up quickly and has provided time without a hitch since then.

It makes claims about its accuracy which seem to be beyond the NTP spec, and no explanation of how its accuracy was measured. Nevertheless, it seems to work quite well, and I'm sure the designer has made it as accurate as possible.

Everything should be so simple to set up!

Note that it comes jumpered for 5v amplified antennas, but the Tindie site recommends a 3v amplified antenna. Not sure that combination would work.

The new version is on a par with my best NTP servers.
It would be nice if the build/ship status updates had happened a bit more often.
Highly recommended.

By the way, the time specs for a Laureline (200 nanoseconds) are derived from the GPS+local oscillator. They are unrelated to NTP time transfer resolution, which is limited by a number of factors that start at the source network interface and end in the kernel of the receiving device, and NTP timestamp resolution which is ~200 picoseconds.

I was a bit disappointed for the delay of delivery but can understand, you don't have hundreds of them on stock.
But now, since the device is here, I am very happy with it. All is working fine. Configuration via PC and USB worked also perfect. What I most like is the possibility to feed my GPS antenna with 3.3 or 5 Volts. This makes it possible to drive my GPS splitter and use only one antenna.
What I like to have in a future release is the possibility to acces the NTP Server over the network, because my NTP Pi and the Laureline NTP are fed by a USB Power Supply. So there is no way to check the status or alter the configuration without connecting it to a PC or have a look a the LED's.
With that step it would probably also be possible, to add a another timesource from the LAN, like I am doing it with my Raspberry Pi.
My Raspberry is now grabbing time from my "www.blitzortung.org" lightning detection system, the Laureline NTP and from the Swiss Time Source.

So congrats to you, for the nice hard- and software developement and thanks for sharing it with us..

Best wishes from Switzerland, Joe, HB9DRT

The cable works great, but when powered on it will pull the reset pin low by default. I have to send some obscure command using either an FTDI-specific library or low-level USB functions. A bit more info about this would have been helpful. In case anyone else is trying to figure this out, this is the command you need (from libftdi):

Pull reset low: ftdi_set_bitmode(ftdi, 0xf1, BITMODE_CBUS)
Release reset: ftdi_set_bitmode(ftdi, 0xf0, BITMODE_CBUS)

After doing this, the device works as expected. However, if you use libftdi to transmit/receive data, you should set the baud rate to four times the actual baud rate because there's something wrong with the internal baud rate calculation.

I'm actually running the device at 2Mbaud, which is twice as high as the maximum specified speed, but it works fine for me.

One small suggestion: If you used clear heat shrink instead of black, you would be able to cover the entire board with it without blocking any labels or LEDs.

UPDATE: Your board has some EMI issues. Whenever I turn the mains switch on my power supply on or off, it seems to create an EMI spike powerful enough to reset the FTDI chip on your board. The power LED turns off for a moment and the USB device disconnects and then reconnects to the computer. I suspect the cause of the problem is that you don't have enough capacitors on the 5V line. You only have 100nF after the ferrite bead, the FTDI datasheet recommends 10nF before the ferrite bead and 100nF+4.7uF after it. This is disappointing because I was planning to use this device in a noisy environment (that's why I needed isolation in the first place).

I bought this little receiver with a view to comparing it with my other NTP servers. The Laureline server is a dedicated NTP server which differs from the rest in my park which are based on general purpose operating systems such as linux and FreeBSD. One of the features that attracted me was the inclusion of an keyed IDC connector, hosting the Ublox 1PPS output.

My Laureline is cased, as I paid for that option. It is a nice little silver affair with transparent end plates pierced for the interface connectors.
Unscrewing either plate allows the server PCB to slide out. The small size of the case, tailored for the micr-controller PCB means that there are cables connected to both ends. This is not ideal, and makes finding a place to put it a bit more difficult. I prefer all cable entries on one face.
There is no doc supplied, but that available on links from the tindie site is excellent.

Installation:
Nothing heart-stopping to report. I had one problem which I will mention later related to the ethernet jack but once I had mastered that everything worked fine. After testing, when I had the server USB connected to a Win7 PC, I moved the power cable a powered USB hub. No issues there, but as that is not connected to a computer I can't access the serial console. My choice.

Configuration:
The server configures itself if you have a DHCP server, such as your ISP's router, on the same net. If you don't, then you need to configure an IP address via the serial console. I have a router with DHCP server capability, but I needed to connect to the serial console to enable the 1PPS output (off by default) and to enable syslog messages, output on port 514.
There is one other thing I would mention about the use of DHCP. When I first connected it, and powered up a few times, I noticed that the assigned host name I was getting, as well as the IP addresses were changing. This is problematic for configuring the NTP configuration files. So in order to fix that I configured a static DHCP address for the server's MAC address. I could have also configured the IP address using the serial console. That address was added to the ntp.conf files and the necessary configuration changes my syslog server config and firewall, to allow the UDP packets through, and I was set.
ntp.conf
server 192.168.1.23 minpoll 4 maxpoll 4
syslog.conf
+laurelineA.stratum1.d2g.com
*.* /var/log/laurelineA.log
firewall ipfw (your wall may differ):
# Allow inbound syslog UDP from our local net only
add 503 set 5 allow log logamount 128 udp from 192.168.0.0/16 to 192.168.1.3 dst-port 514 keep-state

# ipfw show 503
00530 411840 54940405 set 0 allow log logamount 128 udp from 192.168.0.0/16 to 192.168.1.3 dst-port 514 keep-state
it generates a lot of data

Operation:
Once the NTP configuration files were set up and ntpd restarted all went well. The server is serving good time on a par with my other servers. For example ntpq -pn is showing
remote refid st when poll reach delay offset jitter
=======================================================
+192.168.1.4 .PPS1. 1 u 9 16 377 0.896 -0.005 0.013
+192.168.1.15 192.168.1.23 2 u 8 16 377 0.971 -0.003 0.029
*192.168.1.23 .GPS. 1 u 6 16 377 0.581 0.012 0.008 <===Laureline
-145.238.203.14 .TS-3. 1 u 3 16 377 3.239 -0.212 0.035
-217.147.208.1 194.242.34.149 2 u 5 16 377 23.592 0.132 0.020
-91.235.212.22 212.82.32.15 2 u 5 16 377 17.275 -0.684 0.031
$
You can see here that it is the selected server, the jitter is at the NTP floor most of the day with the offset in the low tens of microseconds. The fact that there is no OS in the server minimises the latency which keeps the jitter down, making it one of the most stable servers that i have.

If have collected and graphed the following information over a day, images attached, to give you and idea of the perf.
a) NTP peerstat data from the above client
b) Hardware 1PPS jitter data from the Ublox Neo-6M . The jitter is measured with a Agilent 53230A
c) The servers TCXO stability data from the syslog messages
d) The servers PPS offset from UTC as reported by the syslog messages.
If you can't see the image .I can't :-( here is a link.
<http://stratum1.d2g.com/images/LaurelineNTP/Laureline-GPS-NTP-Server-stats.png>

Note that for those wanting to collect the syslog messages, useful for monitoring, they are output every second and at power on, ethernet reconfig, loss of PPS etc. This amounts to a 20 plus megabyte daily transfer.

Update 08/07/2014:

For those interested in trying it, out I have put the code for a syslog message filter on my site.
It can be found in a tarball at <http://stratum1.d2g.com/public/LaurelineNTP > .
There are two README's, one for the filter and another for a test data generator I put together as waiting a number of years to test leaps and stuff seemed a bit long.
The filter reads of the syslog stream and creates loopstat data in the same format as NTP. The files are archived using that same shema as NTP as the days roll over. It's quite useful, as the statistics can be manipulated with the same tools I use to graph my other servers.
It's simple but lets me see what's going on day to day. Check out the LaurelineA link in the NTP Server statistics page.

Issues:
As indicated above, I have an issue with my ethernet jack. I cannot easily get a stable connection. I have contacted the seller/designer and he is sending me a replacement which I should receive shortly.
As mentioned above, I am collecting the syslog monitoring data. This has shown that I occasionally get loss of PPS and power-cycle/ethernet reconfig not sure which. The frequency is about once a day. The PPS loss may be due to my antenna placement which is not ideal at the moment (facing north in an urban canyon) but I have yet to see the same issue at the same time with other receivers I have. The power cycle/ethernet reconf causes the server to serve less than optimum time for a couple of minutes before the PLL locks and syncs up to UTC. This is probably related to my duff jack.

Limitations:
Or nice to have in future firmware releases ;-).
Leap second support. We will need it in '15 or '16.
Syslog configuration option to limit volume of data
A case option with all interfaces on one side.

Service:
Michael is very responsive.

Conclusion:
A very nice little box. Very stable accurate time, on a par with other OS based servers. Probably a little more expensive than rolling your own with a Raspberry PI, Beablebone Black or other full linux solution. For European clients this is an issue as we have to pay around $45 duty on the import.

*The only issue is spacers between the boards. I trimmed some nylon stand-offs.

It is a very-well desined PCB board which mate to the Trimble Resolution-T GPS receiver timing board.
The price of the PPS Piggy back panel is OK and one should not waste his time to built similar PCB especially if he is a Time-nuts and building a GPSDO.... because the GPSDO is more colplicate citcuit then this one.....
I recommend to everybody who is gong to use the Trimble Rersolution-T board.. or the SMT board..

This is a great little board with which I am using both the T and SMT versions of the Resolution-T. As with any design there are extras we would like. Board standoffs would be a plus as finding suitable length ones is not that easy. Without them, a robust installation is problematic. The other thing would be an output level converter and jumper to allow 3v so that the tx/rx and pps outputs could be directly connected to ucontroller gpio lines.

This design could also easily be adapted to other receivers, such as the M12M or M12+T from Motorola/i-Lotus. There are a large number of those in hobbyist hands. Having one would certainly tidy up some of my boxes.

With PPS Piggy and Trimble Resolution T you can build very accurate GPS timing device for your NTP server. This board helps to connect Trimble receiver to PC via USB or RS-232 (COM). You can purchase Trimble and antenna for it on Ebay - they are cheap. For further information google "ntpd gps pps".
You can debug the board with Trimble Studio software under Windows. It shows satellite tracking, antenna status, PPS status, etc.

I agree with mycroft: you can damage Trimble connector unless you use brass standoff. So be careful.

This is a nice adapter to a Trimble Resolution T timming GPS module. It simplifies the interface to a PC and solves the problem of having to supply 3.3 V to the module.

The only negative point so far is that this adapter is mechanically fragile. It connects to and is supported only by the 2x5 header. A standoff or separator would be nice.