Furuno GT-88 Impressions

The Furuno GT-88 is a GNSS timing receiver intended for precision timekeeping. These are my impressions after some testing, but before I've tried to build a full reference clock system based on it.

Overview

The GT-88 is a fairly new (released in 2019) multi-system GNSS receiver intended for precision timekeeping. It is apparently based on the eRideOPUS 7 receiver core, and the GT-88 is this core + some external crystals and flash ROM.

This same receiver core is also available paired with varying grades of OCXO as a fully specified module. However, these are not inside my budget and I instead used an OCXO I had laying around,

It is made by Japanese company Furuno, which is perhaps not a household name in all circles, but their products appear to generally be high quality and their much older receivers were used in a HP/Symmetricom/[Microsemi/Microchip] pole mount receiver I looked at previously. They've been around for a long time, and are one of the big players in the timing GPS receiver market, competing primarily with Trimble and uBlox to my knowledge.

The primary incentive for me buying the receiver was the availability of a 10 MHz output, and support for triple system tracking (with Galileo).

This triple system reception sets it apart from my previous GPSDO core, the obviously competing uBlox LEA-M8F (and later 9th generation receivers like the ZED types). This receiver is in a similar price class, but can only output a fixed 30.72 MHz, and it can only track two systems simultaneously.

Both these options are unfortunately both single band receivers, at the time of writing the cost of multi band GNSS receivers is far too high for my budget.

Goals

The goal of this exercise was to evaluate if this module was worth building a reference clock (one of many) for precision frequency and time information.

My plan was to attach an external OCXO to the module for use as a reference clock, and adjust this to track the modules 10 MHz output with a (slow) PLL. This OCXO signal can also be utilised by the module itself to provide extended holdover performance according to the datasheet.

Their white-papers clarify that the GT-88 with a customer supplied OCXO is not specified for any particular holdover performance, obviously the quality of holdover will be highly dependent on the stability of the external OCXO so I guess it makes sense that they can't make any guarantees here.

The module can provide quite precise frequency error measurements for the external applied reference clock, I expect to discipline the OCXO very slowly using these measurements.

Based on this I may build a full reference clock by designing a controller PCA to the GPS and OCXO, and packaging this into a nice rack mount enclosure.

My Test Setup

I built a simple PCA with the GT-88 receiver, which would be suitable for use in the final product.

This interface board takes an external 5 V biased GPS antenna feed (in my case an amplified fiber optic feed), it uses a fairly standard wide-band SAW filter as a front end filter since the GT-88 has a front end LNA (there is a SAW filter after the LNA, but due to my system setup the SAW filter is recommended).

The board has a local 3.3 V regulator and LVDS transceivers for frequency in/out, and 1 PPS outputs, as well as some coax connectors for testing.

A Li-Ion battery (CR2032, LS14250 etc.) can be connected to a pin header to allow the modules RTC to run when powered off, this also retains GNSS almanac state, allowing for a very quick TTFF (time to first fix) in most cases. It also very quickly restores the frequency output stability (less than 10 seconds) if power is only lost for a few seconds and the battery is used.

As mentioned a fiber optic distribution system is used, the relevant antenna is an AreoAntennas dual band survey grade antenna with sufficient bandwidth for all standard GNSS systems.

The Good

The GT-88 seems to have similar or better tracking performance to the LEA-M8F receiver I already have when fed with the same signal. The support for Galileo tracking was one of the major reasons I bought this receiver.

The frequency output stability appears to be quite good, especially when paired with an external OCXO, which seems to improve stability when enabled. It appears it might be slightly more stable than the LEA-M8F in this configuration, but this is difficult to measure precisely.

I expect that this will produce a good quality reference clock system when used properly, and the receiver appears to be good.

I haven't done a proper holdover precision test, but a test where I pulled the antenna fiber with a stable OCXO connected indicated it kept time and frequency very well.

The backup battery support with RTC means the receiver can output reasonably accurate time even if powered on without an initial GNSS fix.

The Bad

The GCLK frequency output is not directly usable for many applications. This output uses some kind of simple synthesizer (NCO perhaps), which produces significant high frequency jitter. My measured peak-peak jitter at 10 MHz was around 5-10 ns or so.

I expect that this jitter will have the same magnitude at lower frequencies, so if you wanted to make e.g. a 1 kHz clock it would be plenty good enough, but at higher frequencies this jitter is significant. The output frequency can be set to whatever you want in the 0-40 MHz range.

While my unit measured in spec with jitter below ±8 ns, it certainly didn't exceed spec either!

If you want to use this frequency output for anything except frequency measurement with long integration times, you should use an external PLL + VCXO at your frequency of choice to clean it up.

As can be seen above, the output is quite noisy, with a primary 1 MHz spurious spacing. As such you could also consider cleaning up the signal with a narrow band pass filter. In the narrow band plot you can also note some minor spurs at 250 and 500 kHz spacings. A 10 MHz filter with a bandwidth of less than 200 kHz would clean the signal up nicely.

I have tried using this clock to drive a STM32F103 (with built-in PLL active), and found no issues. The STM32 PLL has a low enough loop bandwidth that it seems to clean up the signal fairly well.

The provided control software "GNSS Conductor T2" is a surprisingly resource heavy Java application, using 30% of my GPU when running for some reason, in addition to significant CPU loading. While it does look nice, it is severely lacking in functionality compared to uBlox or Trimble software.

As an example, it does not provide any way of viewing arbitrary command outputs from the GNSS module, the only option for e.g. looking at the external frequency measurement of the receiver is to look at a continuously scrolling NMEA data log (with no freeze option).

Some parameters like the "Receiver status" and "Frequency mode" fields are simply displayed as a hex bitmask, instead of something human understandable.

For some reason most of the displayed parameters have no units, while usually implicit this is an odd omission. For example, the DoP parameters are presumably in meters, while the "Estimated accuracy" field is apparently in ns on the 1 PPS output (you might think it would be a Figure of Merit, for example).

This software also has no real support for configuring the module, the way you do this is by opening the eSIP protocol specification, then manually writing the commands into a little text box. It does at least generate the NMEA checksum for you. In order to save my desired configuration, I had to break out a hexadecimal calculator to compute what bitmask I needed to provide for this command.

The module has fairly limited configuration storage support, with only a select few (though mostly well chosen I guess) parameters available for storage.

For example the module can output frequency measurement of the external clock signal (typically an OCXO). This needs to be enabled every time the module is powered on (even when battery backed) by sending a specific command, which seems unnecessary, but there's no documented way to save this parameter.

The consequence is that in my case, I will need to implement writes to the GNSS module to set up parameters, which is something that I didn't need with the LEA-M8F module.

The timing modes supported (NAV, SS, CSS, TO) are not very well explained, and in particular SS mode (the default) seems to cause a ton of frequency wander during initial acquisition. CSS seems better. It's supposed to switch to TO mode (fixed position) when criteria (time and/or position stability) are met. With a 15 meter sigma and no minimum time this occurred some time between 6 and 12 hours after power-on.

The Neutral

Furuno does not appear to support BeiDou reception, meaning one GNSS system is not available when you use their modules. On the other hand, the equivalent uBlox option (LEA-M8F) doesn't support Galileo so it's not clear which is better.

The decision not to support BeiDou is likely political in nature.

This is fine for me, since my uBlox receiver uses NavStar/BeiDou, and this receiver can therefore be primarily Galileo/Glonass based, giving full GNSS system coverage.

While Furuno boasts of achieving 5 ns or better 1 PPS performance, my module mostly reports accuracy estimates in the 10-30 ns range. However, my antenna is not ideally sited and only provides good coverage over a 90° azimuth.

Oddities

I may update this section as I start implementing more features in my software.

I've noticed that enabling the PERDCRJ command output (jammer frequency list) causes the generation of an additional start byte for the next command. This is odd but unlikely to cause issues.

The correct method for configuring the module is to input commands then await an acknowledge message (PERDACK). Waiting for 1.2 seconds after each command seems to be a sufficient delay between commands. This delay is also sufficient for switching the UART speed.

It's slightly strange that the xxZDA message is high priority, but the TPS1 message which contains more information is not.

gpsd Support

The standard NMEA output data is compatible with gpsd, though I will note that a bug exists in (at time of writing) current gpsd releases, up to and including 3.24.1. A fix for this issue was committed on 2022-07-31 to the main branch.

The bug relates to GNGSA messages in Galileo mode, where Galileo satellites are not marked as tracked, and may also be confused with SBAS or GPS satellites in some cases.

Specifically if a tracked SBAS satellite with (PRN-87) or a GPS satellite has the same PRN as a tracked Galileo satellite, then the SBAS or GPS satellite will be reported as tracked even though it may not actually be tracked.

This bug has been reported to the developers, and a simple patch can be applied manually for now.

Link to issue: https://gitlab.com/gpsd/gpsd/-/issues/210

NTP Interfacing

The GT-88 can be hooked up to a Raspberry Pi with UART and 1PPS as usual. I use gpsd for the UART interfacing (SHM driver), and driver 22 for kernel-1PPS.

See also this excellent article: https://gpsd.gitlab.io/gpsd/gpsd-time-service-howto.html

The section below can be used in ntp.conf to configure the NTP server: