New Features in GRINGO Beta Release 2.0.0

GRINGO

High-Speed Communication Rate
Some of Garmin's more recent receivers have been generating a large number of checksum errors in GRINGO. In some cases, rogue data packets have even beaten the CheckSum check and caused unexpected errors in GRINGO. With a great deal of help from several owners of some affected receivers, a fix is now available.

The solution is to run the Garmin interface at a higher baud rate than the default of 9600. The higher baud rate increases the bandwidth of the interface, allowing the receiver to transmit the raw measurement data at one-second intervals without error. To make use of this new feature in GRINGO, click on 'File', 'Program Options', and check the 'Use high-speed communication rate' option. You can optionally limit the maximum baud rate that GRINGO will use, in the drop down list below this option. The default maximum is 38400 baud, although it may be beneficial to use 57600 baud in cases where the receiver's processor may be under extreme load. Circumstances which may create such a situation may inlcude (although the evidence so far is limited):

if WAAS is enabled,
if there are several satellites above the horizon but masked from view (causing the receiver to search for them continuously),
if the receiver is constantly re-drawing map detail on the screen.

The maximum baud rate of 115200 is likely to cause additional communication problems, and you may actually see the CheckSum problem returning at this speed.

With the high-speed comunication option selected, GRINGO will attempt to negotiate a higher speed when you click on the 'Log RINEX' button. The progress of the negotiation will be reported in the status bar at the bottom of the screen (the topmost progress bar, which normally reports the IDs of the tracked satellites). Once a new baud rate has been established, the receiver will maintain that rate until GRINGO resets it, or until it is powered off and back on. The receiver always defaults to 9600 after a power cycle. By default, GRINGO will reset the interface to 9600 when you stop logging or quit the progam. This is to ensure that other software which expects to find the receiver at 9600 will work correctly. If, however, GRINGO crashes (!), or fails to properly connect at the new higher rate, or you disconnect the receiver before stopping GRINGO, it will be left at the higher rate, and other software will probably fail to connect with it. A power cycle will reset it to 9600.

Not all receivers can achieve the highest baud rates. Current versions of the 12XL (firmware 4.58) can manage 38400, but no higher. Early 12XLs (firmware 2.01) will not change to any other baud rate. However, none of the 12XL range suffers from the CheckSum problem that the later receivers do, and therefore don't require this option. The GPS 35 'TracPak' will go up to 19200 baud, but again it does not need to, as it produces error-free data at 9600. The eTrex Legend, the GPSMAP 76 and the GPS V will all work at 115200, although 57600 or even 38400 seem to be enough to eliminate most of the checksum errors.

If you'd like to drop me a line with your own baud rate experiences, I'd be grateful.

Extra Receivers Supported
There are a number of 'flavours' of the raw data protocols used by Garmin receivers. The two main variants are the 'original' flavour, used by the 12XL, II+, III, III+, Streetpilot etc, and the 'new' flavour, used by the eTrex, eMap, GPS 76 and GPS V. In addition, the GPS 35 TracPak range uses a third (officially documented!) flavour, and the GPS 16/17 range uses a fourth (documented and very similar) flavour. GRINGO now recognises all of these flavours.

GRINGO has been coded with as many of these receiver types as possible built in, so that when it recognises the receiver, it will adopt the correct variant of the protocols. However, there will undoubtedly be cases where GRINGO does not recognise the receiver type. In this case it will default to the 'original' flavour, and if the receiver actually uses the 'new' flavour, it will obviously not work. To assist in these cases, a new 'ini' file option has been added. The option is the 'ForceFormat' option. If GRINGO does not seem to work with your receiver, you can manually edit the file GRINGO.INI in the GRINGO folder, and add the ForceFormat option, eg:

ForceFormat = 2

There are five possible values for the ForceFormat option:
ForceFormat = 1 will force GRINGO to use the 'original' (12XL etc) format
ForceFormat = 2 will force GRINGO to use the 'new' (eTrex etc) format
ForceFormat = 3 will force GRINGO to use the GPS 35 'TracPak' format
ForceFormat = 4 will force GRINGO to use the GPS 16/17 format
ForceFormat = 0 will let GRINGO use the default format for the attached receiver, and relies on GRINGO recognising the receiver as one of the built in model types. If the receiver is not recognised, it will use format 1. ForceFormat = 0 is the same as leaving out this option altogether.

Broadcast Ephemeris
If GRINGO is using format 3, either by recognising an attached GPS 35 receiver or through the use of the ForceFormat = 3 option, then the option to log a Rinex broadcast ephemeris file becomes available. This is a documented feature of the TracPak range, but unfortunately the other receiver types do not appear to output the broadcast ephemeris.

Three ephemeris logging options are available on the Rinex Header screen:

Session Start
If this option is checked, GRINGO will download all available ephemeris records from the receiver immediately before starting to log Rinex observation data. You may notice a slight delay before the Rinex header lines appear in the data window, as it takes a second or so to download the ephemeris.
On the Hour
If this option is checked, GRINGO will download all available ephemeris records immediately after the first measurement epoch of each hour. Any new ephemeris records will be added to the ephemeris file. Note that the download takes a second or so, and that as a consequence, one epoch of raw data will be missed if logging at the maximum 1 second data rate.
Session End
If this option is checked, GRINGO will download all available ephemeris records when you either stop logging or quit the program (whichever is first, ie it won't do it twice if you stop logging first and then quit the program, but if you simply quit the program it will do it anyway - you may notice a slight delay before the program quits in this case). Any new ephemeris records will be added to the file.

The ephemeris file will be in the same folder as the raw data file, and will have the same name apart from the extension, which will take the form .YYN, where YY represents the year. The N is the convention for Rinex Navigation data files. The broadcast ephemeris file should be useable immediately for post-processing within P4.

The satellite ephemerides are updated every two hours, so a logging session that lasts around two hours needs only to record the ephemeris at the 'Session Start' and the 'Session End', to ensure that a valid epehemeris record is in the file for each recorded satellite. However, for longer sessions, it may be useful to use the 'On the Hour' option as well, to ensure that no ephemeris updates are missed.

Contact chris.hill@nottingham.ac.uk for further information.

Return to IESSG Home page

© IESSG. These pages are regularly maintained. For any further information on the IESSG, please contact the iessg.webmaster@nottingham.ac.uk. Surface mail enquiries should be made to IESSG, University Park, University of Nottingham, Nottingham. NG7 2RD. UK.

Last edited 10 March 2002