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
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)
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!
If you are using Leonardo (or Micro/Flora/ATmega32u4) or Mega, consider using a HardwareSerial port instead of SoftwareSerial!
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.)
Experimentation may be necessary to get the optimal results. We suggest RMC only for 10Hz since we've tested it.
The timezone cannot be changed, so you'll have to calculate local time based on UTC!
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.
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:
If the value is a 1 (Fix not available) or a 2 (2D), then the PPS pin may not output.
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="")