Showing posts with label gps. Show all posts
Showing posts with label gps. Show all posts

Friday, May 8, 2015

Large Display for GPS Disciplined Time Server


Since building my own GPS disciplined local time server I have wanted a large display of some sort to display my super accurate clock. The primary purpose of doing this was really just because it would be rally really cool looking. I also have a personal issue with any clock that does not set itself from the WWVB or support NTP, in 2015 we shouldn't have to manually set clocks anymore. A secondary use for doing this would be for ham radio purposes. A nice large clock that is always accurate so I can easily and quickly log contacts in UTC would be very useful. Ultimately I ended up with a very nice solution and here is the result:

ESE ES-166 timecode display used for GPS clock

Searching for someone who makes such a clock was frustrating. It seems either you can have a large format clock for cheap that does not support NTP, or you can have one that does support NTP but costs hundreds of dollars. Designing and building my own was the next option that I had considered for awhile. A simple PIC based device that drives some large 7 segment led displays would be trivial to build, but I couldn't get into the project. It just didn't excite me, It's one of those things that would be so simple and mundane that I just couldn't drive myself to do it. It would be like a software engineer being assigned the task of writing a word processor. It's already been done so many times and is such an unfulfilling project you can just never get excited about it.

So on to Plan C. Let's see what's already available and either modify or make it work for my intended use. Basically I would be looking for a large LED, backlit LCD, or big VFD display of some sort that would be able to easily display time. Input can be via various means, ethernet or serial would be first choices, some other parallel type interfaces would be not ideal although I could still make it work if needed. Luckily having some experience is professional video editing when I was in college, I looked towards something I felt might me the perfect solution: Timecode displays.

Upon scrounging around I found a perfect device on eBay, an ESE-166 remote timecode display. These can be found for less than $50 at times are are beautiful pieces of gear. It is a big 2U rack mount enclosure with a nice large format LED display on the front panel. This display is designed for displaying accurate time code for video editing systems. The particular display I purchased had hour, minute, and second digits which would be perfect. Many time code displays also include a 4th digit section for frames which this one did not as I did not need it for my purpose. The inputs on these devices are typically a single 75ohm timecode serial input for SMPTE timecode. I was fine with this as designing some hardware to convert an rs232 serial stream to SMPTE timecode actually sounded pretty fun, but I ended up not needing to. This specific display also included an rs232 serial input that supports a few ASCII time formats. This would be a perfect solution, just have a script that takes my local time directly off of the time server itself and dump it out the serial port to this display. There would be some very minimal latency with this obviously, but regardless this solution would be perfect! The ASCII format I chose to use is as follows:

Format #0: (CR)(LF)I(^)(^)DDD(^)HH:MM:SS(^)DTZ=XX(CR)(LF)

As for getting the time data into the ESE, it has two runtime options set by some dip switches inside. The first is a free running clock that when the serial port receives a time string, it updates the internal clock to the time received. The second option does not free run, you simply continuously provide the time signals to update at the interval you specify. In this option, you would need to provide the time signal at least once a second to keep the display real time. For now, I went with the first option. I have the ESE free running with a cron dumping data from my NTP server sending an rs232 time string via cron every five minutes. The noticeable time drift of this clock over a five minute period is not noticeable at all and this solution keeps the clock up to date on five minute intervals without having to constantly send it serial data.

For those that are curious what is inside the ESE ES-166, it is pretty basic:


There is a whole lot of room in that chassis with not very much there. Just a mains transformer and simple analog rectified power supply with a handful of logic to decode the SMPTE / serial port data and drive the display. I'm planning on moving my Trimble GPS receiver inside of this case as there would be plenty of room for it. This would consolidate some of the hardware laying in the back of my server rack.

Additionally the manual for the ES-166 includes a schematic which is also nice to see. There was one part of the design that I really loved, the rs232 to TTL translation:


There is no serial driver there, MAX232 or equivalent. Just a simple level converter based on a 2n2222 with a diode and resistor. I love it! You see MAX232s in everything these days when they are often just not needed for serial RX conversion.

Further plans include racking this unit in my server rack and possibly getting a second unit so I can display both local time and UTC.

Friday, December 5, 2014

Stratum 1 Time Server Based on a Trimble Placer GPS 450 with PPS Output

Setting up GPS disciplined stratum-1 timeservers are not a new or technically difficult task, plenty of articles are already available including some excellent ones from David Taylor's satsignal.eu site. The basic idea behind using a GPS device as a stratum-0 reference is the ability to have a very low latency and low jitter accurate local time source. The only complicated part is finding or modifying a GPS receiver that can provide a precise 1 pulse per second source.

This post is going to focus on a simple, inexpensive, and somewhat elegant solution based on a Trimble Placer 450 GPS receiver. The Trimble 450 is by no means a modern device. It was originally produced in the 1990s and used within vehicles for fleet management purposes. It is large compared to modern units and is also only an 8 channel receiver that uses only satellites in the US GPS satellite constellation. The reasons why I really like the Trimble 450 are that is is very rugged and well designed (as it was to be used in the field). It can also run off of a wide voltage supply range and it is easily modified for a true precise 1 pulse per second (PPS) output which is the key part to having an accurate stratum-1 time server.



Trimble Placer GPS 450s are plentiful (there are available on eBay all the time for less than $15 including shipping). I had a unit myself sitting in a parts box for maybe 10 years that I picked up somewhere for free, this is why I went with this unit to begin with as my time source. I also love re-purposing old and somewhat obsolete inexpensive hardware. You will need an external active GPS antenna to use with it, any cheap ones from China will work, the one I purchased was $6. Note you will need an antenna with an MCX connector (or adapter) to interface to it. One additional nice thing about the 450 is you can easily replace the on-board MCX connector with an SMA, BNC, etc if you wish.

By default the Placer 450 outputs a Trimble ASCII Interface Protocol (TAIP) serial datastream, but this is easily changeable to NMEA-0183 strings. Going through the docs I believe gpsd is capable of decoding TAIP messages, but I didn't spend the time to try. TAIP is a binary format and while it is a brief and compact data format, I like the human readable NMEA output strings as they can provide visual output of  your GPS devices status. The Placer 450 can be switched to NMEA with the following commands:

       
>SPR:NMEA=TT<
>SRTSAVE<


Once switched to NMEA, it will provide the following standard strings: GPZDA, GPGGA, GPGLL, GPGSA, GPVTG, and GPRMC. I recommend reading the Trimble Placer 450 manual as it does have good information if you are unable to successfully communicate to the device via RS-232. There is also an old dos based configuration utility available that you can use to program it and switch its output to NMEA format. You will need a machine running win98 or older to run it though. I keep an ancient Pentium 133 machine around for programming old Motorola radios and I had no issues using it for programming the 450.

If your Placer 450 has been sitting around for years without being used, its internal GPS almanac is going to be extremely outdated. This resulted in a cold start of mine taking about an hour to finally acquire four satellites for 3D navigation and update its GPS almanac. Any subsequent warm starts after this will lock on within about 60 seconds. This would also be a good time to check the internal lithium battery. The memory in the Placer 450 is volatile and if the battery is bad every power on will result in a cold start. Checking on my receiver, the battery was fine.

PPS Output

Utilizing the PPS output of a GPS receiver is really the most important part of having a truly disciplined stratum-1 time server. Not all GPS receivers offer a true 1-PPS reference, fortunately the Placer 450 does, it just isn't where it needs to be. While the NMEA strings that come off of the GPS receiver contain accurate time data, various delays through the serial communication result in a time reference that has significant latency and jitter. This usually ends up being no better time keeping than just pointing your time server to another stratum-1 server. That said, the GPS time is still useful for events where internet connectivity is lost or unreliable.

The PPS output provides an extremely accurate time pulse that occurs once per second. Ntpd ( or your time server software of choice) can use this pulse to keep extremely accurate time. I will only be discussing the integration of ntpd in this post. The Placer 450 does indeed have a PPS output, unfortunately this output is on a separate DB-9 data connector. Probing its output on a scope, this pulse is clearly visible and has a very fast falling edge when it occurs (1.1 microseconds on average).



Now that we know we have an accurate PPS pulse, we need to get it into the computer running ntpd as quickly and with as little latency as we can afford. The solution to this is to send the pulse across the serial port on an unused pin (data carrier detect is standard to use in this case) which will drive an interrupt on the ntpd machine. In regards to the Placer 450, I decided to take this negative edge pulse, feed it into a max232 serial driver and send it down the unused DCD pin on the serial port. This worked perfect as the max232 inverts the data and results with a positive ~+15V RS-232 compliant pulse. The final setup of this is shown here:


The small blue board I added contains the max3232c serial driver and necessary charge pump capacitors. I pulled +5 volts off of a positive rail on the Placer 450 along with ground. Since the DCD pin on the RS-232 connector was unused, this modification was very simple. I also removed the original 3 pin power connector and hardwired it to +12v as there is no reason to worry about sourcing an original power cable. Since these devices are usually pulled from service, the original wiring harnesses usually never stay with the unit. Here is the resulting outgoing pulse through the max3232c:


Now that we have the pulse going to the NTP server via the DCD pin over RS-232, we need to verify its operation. Any modern Linux distribution will have PPS support built into the kernel, the serial module for PPS will just have to be loaded. To verify the arriving pulses, you can use pps-tools which is available for most distributions. The following output from ppstest shows my arriving 1 PPS pulse indicating my hardware modification is working.

       
[root@time01 ~]# ppstest /dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1417642033.999999820, sequence: 226503 - clear  1417642033.000028598, sequence: 173333
source 0 - assert 1417642035.000000722, sequence: 226504 - clear  1417642034.000021949, sequence: 173334
source 0 - assert 1417642035.999999642, sequence: 226505 - clear  1417642035.000022821, sequence: 173335
source 0 - assert 1417642036.999999339, sequence: 226506 - clear  1417642036.000023328, sequence: 173336


One note regarding serial to USB adapters. I was using one initially and was not seeing the pulse arriving on my machine. Once I switched to the onboard serial port (/dev/ttyS0) my pulses were immediately visible. If you are going to use a USB adapter, make sure that it supports the DCD pin as mine did not.

A few more prerequisites are needed including having gpsd installed along with ntp. The ntpd configuration is really the last critical step, in the case of my Placer 450, the following configuration is used:

       
# GPS reference
server 127.127.28.0 prefer
fudge 127.127.28.0 refid GPS

# PPS reference
server 127.127.22.0 minpoll 4 maxpoll 4
fudge 127.127.22.0  flag3 1  refid PPS


How this configuration works and what it should be set to could be an entire separate discussion, luckily it is documented very well. Basically the ip addresses shown above are driver interfaces to the gps NMEA serial interface and the kernel PPS. Once ntpd is restarted, checking ntp's status you will see the following:

       
[root@time01 ~]# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
-time3.chpc.utah 198.60.22.240    2 u    2   64  377   71.766   14.708   0.200
-time.tritn.com  66.220.9.122     2 u   39   64  377   71.081    2.188   3.051
+segfault.boom.n 216.218.254.202  2 u   25   64  377   45.549   -4.891   0.548
+50.7.72.4       128.138.141.172  2 u   31   64  377   58.978   -4.452   0.654
*SHM(0)          .GPS.            0 l    8   64  377    0.000  -71.444   4.780
oPPS(0)          .PPS.            0 l   12   16  377    0.000   -0.001   0.001


A few things to note in the above output:

1. Both the GPS and PPS sources now show up in the ntp output.
2. The tally flag for the GPS source is '*' indicating it is a system peer.
3. The tally flag for the PPS source is 'o' indicating the system sync is derived from a PPS signal.
4. Jitter on the PPS source is significantly lower than the other network based sources.
5. The jitter and offset for the GPS source are higher than other sources, this is expected as the serial communication latency between the Placer 450s NMEA strings and server is not guaranteed.

The next steps are to monitor and log the time servers accuracy and precision over time to see how much drift there is with the GPS source and without. After some basic testing it seems to be much improved but only time will tell.

Sunday, June 2, 2013

Lowrance Globalmap / LMS GPS Antenna Replacement Modification

The older Lowrance Globalmap and LMS series of marine electronics are terrific GPS receivers. The only common issue I see with them is that the GPS antenna units for them often go bad. The antenna are about 4" round white pucks that you mount high up on your boat that actually contains the GPS antenna / receiver along with an optional DGPS receiver. This then connects to the back of your Lowrance unit supplying power and communication to the antenna from the head unit itself.

There are two series of these GPS antennas depending on how new your Lowrance unit is. The older ones are NMEA-0183 based while the newer stuff is NMEA-2000 based (most models support both). The advantage of the older 0183 protocol is that is uses a simple RS-232 serial interface, while the 2000 protocol is CAN-bus based (not that this is bad, CAN is a great protocol, but for the point of interfacing these units the RS-232 protocol is significantly easier to work with). Both of my units (A Globalmap 3000 and LMS-480) support NMEA-0183.

Repairing the antennas themselves is a huge pain. I have a dead Lowrance LGC-3000 GPS CAN bus antenna that I cracked open to take a look inside, these units are definitely designed to not be opened, it took some serious cutting to get inside.

Inside Lowrance LGC3000

Nothing unexpected found, a basic GPS receiver, small micro, and an impressive watertight enclosure. Typically I see the micro and/or GPS receiver itself is dead. I'm not sure if heat is the cause or possibly static discharge is, but repairing usually isn't really feasible. Just getting into the thing pretty much destroys the nice water-tight enclosure.

So what to do if your GPS antenna is dead and don't want to spend $100+ for a new one? Simply use any GPS receiver that outputs NMEA-0183 data and feed it directly into the Lowrance spare serial port. This is pretty much every GPS receiver / module ever made.

Each device within the Lowrance family has an optional NMEA-0183 input (and sometimes output depending on device) that allows you to daisy-chain units together. So a single unit connected to the GPS antenna can send the GPS information via NMEA-0183 through multiple units allowing you to need only one antenna. Now the cool thing about this is in the Lowrance configuration menu, you can set which serial input you wish to receive the GPS information from along with what GPS strings you want to receive. This means you can feed NMEA-0183 GPS strings directly into the units spare serial input from any 0183 compatible receiver, not needing to use the Lowrance expensive antenna.

My solution as to use an old 12 channel Cirocomm receiver that I have had laying around which cost about $12. This receiver runs off of 3.3V- 5V and outputs TTL level NMEA-0183 GPS strings. The original GPS  module in the LGC puck can also be used as long as it is not dead itself. To use this with the Lowrance, I added an RS-232 level converter and small power supply to run directly off of 12V. I had these boards already designed and built for Xbee use, it was just a matter of wiring in the GPS unit to make it work. The only downside of this is you need to power the GPS unit directly as the Lowrance does not supply power on the spare serial interfaces like it does on the direct GPS interface. The serial interface requires only two wires, TX from the GPS antenna to RX on the Lowrance unit and ground. You could also interface this into the GPS input connector on the Lowrance, but if you are missing the antenna and cable, wiring to the spare serial interface avoids sourcing the expensive twist-lock connector. Once the new receiver is put together the only thing remaining to do is to mount it in a sealed watertight enclosure, something nice looking so it doesn't look stupid. Also preferably something plastic and white to reflect heat and be transparent to the GPS signal.


To use, set the Lowrance to use the NMEA-0183 input for GPS, then set the correct baud rate and GPS strings your receiver supports ($GPGGA and $GPGLL are the important ones). That is all, the Lowrance should respond indicating it is receiving GPS data and begin to populate you satellite information screen. Multiple units can then also be daisy-chained in the exact same manner.

Lowrance Globalmap 3000 NMEA Config
My Cirocomm GPS unit defaults to 4800 8N1, which is fine and sends $GPGLL, $GPGGA, $GPGSA, and $GPRMC strings, so make sure those are selected in the GPS configuration. If daisy-chaining, make sure the NMEA outputs are also enabled and set to the same baud rate on the sending units.

Lowrance LMS-480 NMEA Config
Note that again almost any GPS receiver can be used to supply GPS information to the Lowrance. Something like an old Garmin GPS 12 also works great as a spare if your antenna dies, simply take its NMEA-0183 output and feed it directly into the input of the Lowrance in the exact same manner.

Both units are daisy-chained off of my GPS receiver. Note testing was in my basement, so no GPS lock here





Tuesday, June 17, 2008

Homemade GPS Antenna

I needed a very small, lightweight passive GPS antenna for an ET-301 USGlobalSat GPS module, but didn't have anything to use on-hand. I started some research to make one but information on this topic is very limited... so I figured a good option would be to make my own. As far as passive antennas go, there doesn't look to be very much too them. I looked at lots of pictures of antennas online and reverse engineered them as best as I could. The result was an antenna made out of a thin piece of metal that is 24mm x24mm located 2mm over a 30mm x 30mm ground plane.

Now i'm not an RF engineer, and basic antenna math fails me on this antenna design (1/4 wavelength at a gps frequency on the L1 band of ~1.5Ghz would be 50mm) which is much larger than the antenna I designed mine after... but upon power up I had GPS lock.

So it works... which really shows how sensitive modern GPS receivers are. This is really amazing since this module is sitting inside, on my bench, located about 6 feet away from the nearest window... and I made the antenna by copying antenna designs I found online. The NMEA $GPGGA string shows that there are only 4 satellites in view (which is expected since I am indoors) so I am really looking forward to testing it outside.

At some point I hope to find a good resource for GPS antenna designs to really make a proper antenna the right way, but for now it works... and I am still impressed by the sensitivity of this receiver.