Sure GPS board
Home Page Up Setup on Windows Using NTP Windows LAN tips Performance Events Cable modem notes Monitoring with MRTG GPS 18 + FreeBSD GPS 18 + Windows GPS 18x firmware NTP 4.2.4 vs. 4.2.5 NTP 4.2.7p241 Rapco 1804M notes Raspberry Pi RPi - cross-compile Sure GPS board Timestamp issues TSC Interpolation Vista & Windows-7/8 Wi-Fi warning Windows after reboot Win-7/8 & Internet Development versions

 

Timekeeping with the Sure GPS evaluation board

Some experiments using the Sure Electronics GPS evaluation board for NTP

Note the very bright blue Pulse Per Second LED!
It would be nice to replace the current limit resistor.
(Click for an annotated image)

Here's my boxed version.
The box isn't rusty - that's the lighting.
The box was a Maplin N90BQ

I was alerted to this board by the TimeNuts list, and inspired by Tom Van Baak's Web page.  The unit is not just the board, but comes with a GPS magnetic mount antenna puck, and a USB cable, so it's a ready-to-go GPS unit.


 

Meeting the PPS over RS-232 requirement

The purpose of the patches is to provide a true RS-232 level PPS signal on pin 1 (DCD line) of the connector.  Whilst the PPS signal on test point TP9 could be used, it is at CMOS level and not RS-232 level, and may not be recognised correctly by the RS-232 receiver chip in your PC.  You can try it if you like, of course.  I have provided a Serial Port LEDs program to show the status of the RS-232 control lines.  Fortunately, there is an unused CMOS-to-RS-232 level converter gate available in U6, with its input on pin 11 and its output on pin 14.  However, as this is an inverting gate, and we want a positive going PPS signal, it should be driven with a negative going PPS signal.  That available at TP9 is positive going, however it is also used to drive the ridiculously bright blue LED through a CMOS inverter gate in U5, so by taking the output from that inverter on pin 8 of U5 we have the required negative-going PPS signal to drive U6.

.. or as a picture

CMOS
=> positive =>
PPS
pin 9 U5
CMOS
inverter
pin 8 CMOS
=> negative =>
PPS
pin 11 U6
RS-232 level
converter
pin 14 RS-232
=> positive =>
PPS
pin 1 RS-232
connector

The two red patch wires shown below were added by me to provide an RS-232 level, positive-going PPS output.  Note that with the Windows NTP port, the DCD line must be asserted (positive going) as provided by this patch, as that port cannot use an inverted DCD signal.

Board patches

Only two wires need to be soldered to make the required patches - one is just on the top of the board, and the other goes through the hole near the RS-232 connector to connect to points on both the top and bottom of the board.  I used solid enamelled copper wire with the enamel removed at the ends for soldering.  Of course, patching the board like this invalidates the guarantee.

Bottom side     Top side

Here is the through the board lead to pin 1 of the RS-232 connector. Note: This lead is not soldered to the empty hole on the J2 outline.

There are two patch wires shown here.  The first, which is purely on the top side of the board, is from U5, pin 8, carrying the negative-going PPS signal to U6 pin 11.  The second goes from pin 14 of U6, through an existing hole in the the board (no connection), to pin 1 of the RS-232 connector (shown left).

You can check that the patch is working with my Serial Port LEDs program, which shows the status of the RS-232 control lines.  Watch for a brief white flash of the DCD indicator once a second which should approximately coincide with the timing of the brief bright blue flash of the Sure board LED.

Easier alternative

One person has reported that he has obtained satisfactory results connecting the TTL-level positive-going signal on TP9 directly to pin 1 (DCD) of the RS-232 connector.  This may be easier if your soldering abilities are not as good as you wish, as the connection points are larger and easier to solder to.  This does work with the serial ports on many PCs, but may result in a lower protection against electrical noise if you have a long lead from the Sure board to your PC.  A couple of metres lead length should be fine for this method, but possibly not an 80 metre run near interference sources such as electrical machinery - i.e. anything with power switches or motors.  Try it and see, but use at your own risk.
 

The Sure evaluation board in use - it works well!

Initial tests were with a Windows 2000 system (PC Bacchus) running ntpd 4.2.7p97-o, from Dave Hart's site (you may need a 64-bit version, for example) and the board worked perfectly once the NTP serial rate was changed from the NTP default of 4800 baud to the board default of 9600 baud.  If you are running a different version of NTP, you may find that it doesn't pick up the GPS properly, and the reach will stay at zero.  To ensure that NTP does not select the wrong second (by interpreting one of the trailing NMEA sentences as near the second marker), you should also set bit 1 (decimal 2) of the mode parameter.  Here is what I used:

# ref-clock drivers
server 127.127.22.1 minpoll 4			# PPS - serialpps.sys - on COM1:
server 127.127.20.1 minpoll 4 mode 18 prefer	# NMEA serial port, 16 = 9600 baud, 2 = $GPGGA

I only realised the importance of selecting the $GPGGA sentence after earlier testing with the same NTP version, where on a Dell PC running Windows XP (PC Feenix) where it seemed as if the NMEA was sometimes picking up on the wrong second, or at least showing a substantial offset.  Similar issues have been seen with later firmware on the Garmin GPS 18x LVC.  It appears that some NTP versions may make use of use the last sentence received, rather than the first sentence - and the logic for doing that currently escapes me!  I reported a bug and that has now been fixed.  As the Sure unit sends several sentences, there is a chance that the final sentence will be nearer to the following PPS than to the leading PPS edge.

In an early test, using a higher baud rate and $GPGGA selection, the NTP jitter seen on the Windows-7 PC was the same whether the Garmin GPS 18 puck or the Sure-GPS board was used.  The same was true on the Windows 2000 PC, even with the default 9600 baud rate and default NTP configuration.  No tests have been made to compare the PPS signal on a more precise level, but on the basis of present tests I believe it is within 10-20 microseconds, and likely within a microsecond or better.  I'd love to hear of any more exact measurements.

I'm currently testing two of these Sure Electronics boards with the magnetic antenna puck indoors (on the top floor of a two storey building) with a Windows-XP and a Windows-7 64-bit system.  The Windows-7 64-bit system shows an averaged jitter of about 40 microseconds, and the Windows-XP system 2.5 to 3.5 microseconds.  Both are using Dave Hart's kernel-mode serial driver replacement, and have the NTP interpolation enabled (it has to be forced on with the Windows-7 system).  I've written up the Windows-7 system - it is of particular interest as normally you are not allowed to use unsigned drivers on such a system.  The Windows-XP system has a similar NTP configuration.  Here is the current live data, where the offset reported by NTP is plotted against time of day.  Click on a graph to see the weekly, monthly and yearly data.  The Windows-XP PC Feenix has changed, and does not currently have a serial port, so is not an stratum-1 server - its plot will return, all being well.

  

PC Alta
Intel i5-760, 8GB
Windows-7 64-bit

offset µs (-)
offset µs (+)

The difference between the smoother, slower-changing but greater offset in the XP system and the smaller but more rapidly changing offset in the Windows-7 system is typical, and may be due to the difference between the software clock rates.  I would expect a system using FreeBSD to perform even better.  Success has been reported with FreeBSD by Adrian Urquhart, also using 9600 baud from the Sure board.

.. but an anomalous output (now resolved)

Although two of these boards have been working well here for some time, I recently had cause to use an NTPQ command to check the GPS sentences being sent by these units.  While the sentences were ok, the ntpq -c "cv &2" command revealed that the serial data was not as continuous as expected, and may have contained some errors.  For four PCs here:

  • PC Alta (1st Sure board): noreply=22601, badformat=7453119
  • PC Bacchus (shared GPS 18 LVC outdoors): noreply=1, badformat=0
  • PC Feenix (2nd Sure board): noreply=25061, badformat=10701606
  • PC Stamsund (GPS 18x LVC indoors): noreply=1, badformat=0

Strange that only those connected to a Sure board produced the non-zero noreply and badformat counts.  The jitter reported was quite normal, so it seems that any errors in the serial data aren't a problem, providing that the PPS line stays good.  Both of the puck antennas for the Sure boards and the GPS 18x puck were located indoors, with the GPS 18 being on the roof.  Update: In February 2012 this was reported as bug 2140, and the bug was fixed in NTP 4.2.7p258 and later.  This site has the binaries for various NTP versions, including 4.2.7.p258.
  

Testing the board function

Before making any changes to the board, you may want to test its function.  Suitable software can be downloaded here:

  http://www.sure-electronics.net/download/index.php?name=GP-GS010&type=0

I suggest you get:

First set up the board with USB power (no need for a data connection) and antenna.  Leave it for several minutes until the blue LED starts flashing.  The LED sequence is blue (short flash), yellow (longer flash), just the greens (about the same time as the yellow).  This could take 15 minutes on the first run when the whole satellite almanac may need to be downloaded.  Next: find a free serial port on your PC (mine was a USB to serial adapter on COM4), and connect the device to that port with a serial cable.  

I used this 9P male to 9S female lead from Amazon: http://www.amazon.co.uk/gp/product/B001R092VK/ref=oss_product.

Checking the board is working

Starting with download MStar MiniCDU.zip, unzip the file to a convenient location such as C:\Tools\Sure\, and double-click on MiniCDU_V1.0.5a.exe.  These screen-shots are from a Windows XP SP3 system.  Use the Mode, Setup COM port menu to match your PC's COM port, and be sure to set the speed to 9600 baud as that is what the unit uses out-of-the-box.  

Click on OK to save the COM port settings.  You should now be able to click on the connect icon, the first in the toolbar at the top:

The terminal window should start to fill with groups of NMEA sentences in one second batches, starting with $GPGGA and finishing with $GPRMC.  You should get location details and satellite signal levels recorded as well.  The very eagle-eyed amongst you will spot a formatting error in the displayed position!


Configuring your Windows PC network for NTP

For those of you less familiar with NTP, here is a very brief guide to setting up the various PCs.  I assume that you have already installed NTP for Windows, and have a working configuration.  In the notes below, I am assuming that at least the stratum-1 PC has a fixed IP address of 192.168.0.3, and you will need to alter this for your own network.  You cna also use the PCs name if it's a Windows PC or you know how to edit your HOSTS file.  I have also assumed that NTP is installed in C:\Tools\NTP\, which may also be different from your own installation.  The basic minimum configuration is shown.

Configuration for the reference PC

This PC will require to be connected to the Sure GPS unit.  Ideally, a real serial port is preferred, and COM1 is assumed in the configuration file below. 

     

No COM port on the back of your PC?  Not to worry!  Many PCs have COM port support built into the motherboard, but the 9- or 10-pin header is not wired to a 9-pin male connector on the back.  You may be able to cannibalise an old PC for a suitable back-plate and header, or get one from Amazon - search on "9-pin serial header".  Choose the right size for your PC's backplane - for example:
  StarTech.com 9-Pin Serial to 10-Pin Motherboard Header Slot Plate

If all you have is a serial port over USB that's better than nothing providing the port emulation includes the DCD line (pin 1 of the 9-pin RS-232 connector).  As the serial-over-USB built into the Sure board may not include emulation of the DCD line with the pulse-per-second signal, it is unlikely to be anything like as accurate, and I do not recommend you to use it.  

# Use drift file 
driftfile "C:\Tools\NTP\etc\ntp.drift"

# ref-clock drivers - Sure Electronics GPS board
server 127.127.22.1 minpoll 4 # PPS - serialpps.sys
server 127.127.20.1 minpoll 4 mode 18 prefer # NMEA serial port, 16 = 9600 baud, 2 = $GPGGA

# Use pool NTP servers as a backup
server 0.uk.pool.ntp.org minpoll 10
server 1.uk.pool.ntp.org minpoll 10
server 0.nl.pool.ntp.org minpoll 10
server 1.nl.pool.ntp.org minpoll 10

As mentioned above, you will want to play with using the kernel-mode serialpps.sys driver for better performance on this reference PC, as well as trying NTPD_USE_INTERP_DANGEROUS=1 on Windows Vista or Windows-7 systems, but you will not need to alter the configuration file to test these options.

Configuration for connected PCs

The aim here is to make the LAN- or wireless-connected PC talk to the stratum-1 server more frequently than normal, so that it has a better timekeeping performance.  This achieved with the maxpoll 5 option, which forces polls to be at 32 seconds intervals maximum (32 = 2^^5).  To make sure that the Internet backup servers are contacted no more frequently that is absolutely necessary, they are set to 1024 second interval (1024 = 2^^10).

# Use drift file 
driftfile "C:\Tools\NTP\etc\ntp.drift"

# Use local stratum-1 NTP server - you will need to alter this address
server 192.168.0.3 iburst maxpoll 5 prefer

# Use pool NTP servers as a backup
server 0.uk.pool.ntp.org minpoll 10
server 1.uk.pool.ntp.org minpoll 10
server 0.nl.pool.ntp.org minpoll 10
server 1.nl.pool.ntp.org minpoll 10

Have fun, and do report back on how you get on!  
 

Setting the board baud rate (not needed for NTP)

While not required for NTP use - where the default 9600 baud works correctly provided you tell NTP to use the first sentence ($GPGGA) - here is how you could set the baud rate for some other application.  Please note that at least one person (Terje Mathisen) has reported that the board loses it programming after several hours without power, so I suggest you work with the default settings if possible.

Expand the contents of the zip file GPS.zip, perhaps into the same directory you used before.  Note that there several files including GPS.exe and help.html, and three sub-directories.  Double-click on help.html to read how to change the baud rate from 9600 baud.

Double-click on GPS.exe, and you will get a dialog where you can set the initial port and baud rate.  

For my PC, as mentioned above, the port is COM4, and the initial baud rate is the default of 9600, so I have two settings to alter.  Once the settings are changed, press the Open button.  You should see the program searching at the various baud rates and COM ports.  Mine settled on 9600bps after a couple of seconds:

If you have problems with this software not recognising your GPS, it may be that you need to update your Java to a more recent version (thanks to Adam Feigin for that).  Now you can set the baud rate to the new value (115,200) and press the Set button:

At the confirmation dialog, press OK:

and you should see a success message:

You can check that the rate has changed by re-running the MiniCDU_V1.0.5a.exe program, and setting the 115,200 baud rate there before pressing the Connect button.
  

Disabling the Bluetooth

Róbert Árkosi wrote with the following tip:

Here's my tip for Sure GPS Evaluation board owners.  If they want to disable the on-board Bluetooth module, for security reasons and avoiding RF pollution, all they have to do is to cut the power line that goes to the module.

See the picture below.  On the back of the board, cut by scratching the track marked with the red arrow using a sharp tool like a knife or a small screwdriver.  That will simply disable the Bluetooth module by hardware, not giving it power. Can be restored by soldering.

You wrote that it's already inoperative on the new board, that was not my case.  It seems that the Bluetooth module starts working only after the receiver has a GPS fix, it can be found on the air by the name "Sure". 

Done the mod with two receivers, all working fine.  Please feel free to add this info to your great article, so others can use it too.

[DJT: I've not found this to be a problem with my two Sure boards, but one is in a screened metal box, and they are both from early 2011, so perhaps the design has changed slightly.]
 

Notes from Adrian Looker

Adrian kindly sent notes on his experience from using the Sure board.

Easier connection to the serial DCD pin.

I wired up the PPS to pin 1 of the serial port as per your method, except I used plastic insulated wrapping wire rather than enamelled and I stuck the wire through the board using the same hole as the serial port pin uses (there's easily enough room, just melt the solder).


Sending the DCD signal over USB

Since I was already armed with the CP2102 data sheet I had a look for a DCD input pin. Turns out it's pin 1 and is 3.3v TTL active low.  Since it needs the same signal you sourced from U5 pin 1 I connected to the negative side of D7 (that annoyingly bright blue one) to reduce clutter.  Once it is connected to U1 pin 1, the PPS signal is available from the USB serial port DCD line.
DJT notes: This may be better than no DCD signal in circumstances where no serial port is available, but it will not give quite such good performance due to the USB input being polled.

 

Linux Quirk

Hal Murray notes: 

I'm in the habit of using things like:  cat /dev/ttyUSB0  when checking out GPS that I expect to send ASCII.  When I tried that with my new toy, it went bonkers.  In particular, the firmware LED went on, and the NMEA LED switched from blinking to solid on.  The data included the stuff I expected, but it also included a lot of garbage.  I (finally) tracked that down to "echo" being set on the tty parameters.  That echoes a copy of each input character back to where it came from.  The cure is as simple as:  stty -F /dev/ttyUSB0 -echo

Of course, there are other ways to get in trouble with tty parameters.  Here is the line I have stashed away in my notes on how to set things up:  stty -F /dev/ttyxxx 9600 igncr clocal -echo -ixon

Now that I've got that sorted out, it responds to the $PTMKxxx commands.  (I've only tried one.)

The Sure card uses the ST CP2102 USB to serial chip.  It's not very common, but there is a Linux driver for it.  I assume the default bits somewhere in the driver are different from defaults in the FTDI FT23x and the Prolific PL230x chips that are quite common.  I haven't looked at the source code.

In my quest for a low cost, no-soldering GPS gizmo that works well with NTP, I tried a Transystem GM-2.  It had the same sort of garbage.  That was a while ago. I gave up and put it on the back burner.  Guess what?  It uses the same USB-serial chip.  It's working now.

Don Latham responded:

The CP2102 is featured in Chinese eBay 4 buck usb-232 adapters.  The chip suffers from serious bad-driveritis, and I've had to do 'net research to make it useful with various flavours of Windows.

(From a posting on the Time Nuts mailing list).
 

A Stratum-1 NTP server with a Raspberry Pi computer

J Beale has used this board to make a Raspberry Pi computer into a stratum-1 NTP server with sub-100 microsecond offset.  More information here:

  http://www.raspberrypi.org/phpBB3/viewtopic.php?f=41&t=1970&start=25#p142606

My own Raspberry Pi NTP notes are here.

 
Copyright © David Taylor, Edinburgh   Last modified: 2013 Aug 16 at 07:52