Can the Ultimate GPS be used for High Altitude? How can I know?

Modules shipped in 2013+ (and many in the later half of 2012) have firmware that has been tested by simulation at the GPS factory at 40km.

You can tell what firmware you have by sending the firmware query command $PMTK605*31 (you can use the echo demo to send custom sentences to your GPS)

If your module replies with AXN_2.10_3339_2012072601 5223 that means you have version #5223 which is the 40Km-supported firmware version. If the number is higher then 5223 then its even more recent, and should include the 40Km support as well

HOWEVER these modules are not specifically designed for high-altitude balloon use. People have used them successfully but since we (at Adafruit) have not personally tested them for hi-alt use, we do not in any way guarantee they are suitable for high altitude use.

Please do not ask us to 'prove' that they are good for high altitude use, we do not have any way to do so

If you want to measure high altitude with a GPS, please find a module that can promise/guarantee high altitude functionality

Is the Ultimate GPS affected by the 2019 Week Rollover issue?

The ultimate GPS (all firmware versions from 20110922_GTOP_EVK01_A2.10 and higher - any sold after 2011) have been tested to work fine through 2019.

They do not pass the 2038 rollover test, so you may need to update the firmware between now and 2038. This does not affect the 2019 rollover (there's one every ~20 years)

OK I want the latest firmware!

Here is the binary of the 5632 firmware, you can use this tool to upload it using an FTDI or USB-TTL cable (or direct wiring with FTDI). We do not have a tutorial for updating the firmware, if you update the firmware and somehow brick the GPS, we do not offer replacements! Keep this in mind before performing the update process!

I've adapted the example code and my GPS NMEA sentences are all garbled and incomplete!
We use SoftwareSerial to read from the GPS, which is 'bitbang' UART support. It isn't super great on the Arduino and does work but adding too many delay()s and not calling the GPS data parser enough will cause it to choke on data.

If you are using Leonardo (or Micro/Flora/ATmega32u4) or Mega, consider using a HardwareSerial port instead of SoftwareSerial!
My GPS is giving me data but the location is wrong!

People often get confused because the GPS is working but is "5 miles off" - this is because they are not parsing the lat/long data correctly. Despite appearances, the geolocation data is NOT in decimal degrees. It is in degrees and minutes in the following format: Latitude: DDMM.MMMM (The first two characters are the degrees.) Longitude: DDDMM.MMMM (The first three characters are the degrees.)

How come I can't get the GPS to output at 10Hz?
The default baud rate to the GPS is 9600 - this can only do RMC messages at 10Hz. If you want more data output, you can increase the GPS baud rate (to 57600 for example) or go with something like 2 or 5Hz. There is a trade off with more data you want the GPS to output, the GPS baud rate, Arduino buffer/processing capability and update rate!

Experimentation may be necessary to get the optimal results. We suggest RMC only for 10Hz since we've tested it.
How come I can't set the RTC with the Adafruit RTC library?
The real time clock in the GPS is NOT 'writable' or accessable otherwise from the Arduino. Its in the GPS only! Once the battery is installed, and the GPS gets its first data reception from satellites it will set the internal RTC. Then as long as the battery is installed, you can read the time from the GPS as normal. Even without a proper "gps fix" the time will be correct.

The timezone cannot be changed, so you'll have to calculate local time based on UTC!
Do all GPS modules emit PPS pulses at the same time?

Under ideal conditions, GPS modules emit a PPS signal within 10ns of the beginning of each GPS second. That's only a best-case value though.

In practice, each GPS module's sync to the GPS clock system depends on the quality of the fix, how long the GPS module has had a fix, and the group of satellites the module uses for its fix. We've observed offsets of about 300ns between modules that have just acquired a fix, improving to less than 100ns after the modules have had a good fix (Signal-to-Noise ratio higher than 20 for the satellites the modules use for their fix) for ten minutes.

When two GPS modules used the same group of satellites for their fix, there was less than 30ns of offset between PPS pulses as soon as the modules acquired a fix.

Why am I not seeing anything on the PPS pin?

The PPS pin only starts outputting after a 3D fix. In our testing, it truly wants a 3D fix, not just a 2D fix. Therefore, the PPS output may not happen even though the FIX LED and pin are indicating a fix.

You can check the current mode via the $GPGSA sentence. The second value must be a 3, as shown below:

$GPGSA,A,3,19,28,14,18,27,22,31,39,,,,,1.7,1.0,1.3*35

If the value is a 1 (Fix not available) or a 2 (2D), then the PPS pin may not output.

How can I read the PPS signal on the Ultimate GPS USB?

The PPS line is tied to the serial port RI (Ring Indicator) pin. You can read this with your serial-port interface code. for example here's a version in Python using pyserial:

import serial

ser = serial.Serial('/dev/ttyS34')  # open serial port
print(ser.name)           # check which port was really used

last_ri = ser.ri
while True:
    if ser.ri != last_ri:
        last_ri = ser.ri
        if last_ri:
            print("\n---------- Pulse high ----------")
        else:
            print("\n---------- Pulse low ----------")
    if ser.in_waiting:
        print(ser.read(ser.in_waiting).decode('utf-8'), end="")

This guide was first published on May 17, 2016. It was last updated on Mar 26, 2024.

This page (F.A.Q.) was last updated on Mar 08, 2024.

Text editor powered by tinymce.