TTGo-T-Beam: GPS time sync not working (but solved)

[dl5dla]

Hi, not really an issue, but some learnings what I did to find out why my TTGo T-Beam did show "1. Jan 1970" all the time. The version of the TTGo T-Beam is T22_V1.1 20191212, and it is equipped with newer Neo-M8N module.

Some debugging showed, that in gpsread.cpp the statement "if (gpstime.isValid() && gpsday.isValid())" around line 115 was never become true and therefore the time never adjusted. I checked the plain NMEA output, and the GPZDA sequences did not occur and therefore the structures "TinyGPSCustom" in lines 15-18 were never filled.

In the ublox tool "u-center" I could enable the sequence "GNZDA" but not "GPZDA" (as used in gpsread.cpp). Now the GNZDA sequences occur in the output. After changing the strings "GPZDA" to "GNZDA" in gpsread.cpp everything is fine now.

The move from "GPxxx" to "GNxxx" was introduced by ublox with the newer version "Neo-M8N". There are also other NMEA sequences affected, but those are handled correctly by the TinyGPS+ library. Even if one is using the older Neo-M6N version and having problems with the time output, it make sense to check whether the GPZDA sentences are present in the NMEA stream.

[cyberman54]

Thanks for your investigations.

What's at the end missing here, is some code which detects the gps chipset of the board while starting it up and then initializes the gps in a appropriate manner to work with TinyGPS. E.g., if it's a U-Blox series 8 then configure it's NMEA output to device ID "GP", not "GN".

There is already a function prepared for this in gpsread.cpp (see belowe), but not yet filled with code.

A PR would be welcome here.

// detect gps chipset type and configure it with device specific settings
int gps_config() {
  int rslt = 1; // success
#if defined GPS_SERIAL

  /* insert user configuration here, if needed */

#elif defined GPS_I2C

  /* insert user configuration here, if needed */

#endif
  return rslt;
}

[hekopath]

In the ublox tool "u-center" I could enable the sequence "GNZDA" but not "GPZDA" (as used in gpsread.cpp). Now the GNZDA sequences occur in the output. After changing the strings "GPZDA" to "GNZDA" in gpsread.cpp everything is fine now.

Interesting that you found exactly the same workaround as i did! https://www.thethingsnetwork.org/forum/t/wifi-ble-paxcounter-project-with-esp32-boards/13175/467?u=engelking

[hekopath]

Are there other already used GPS Chipsets other than M6 and M8? In other words do we have a list of Chipsets that have to be recognized?

Are there other already used GPS Chipsets other than U-Blox Neo M6 and M8? In other words do we have a list of Chipsets that have to be recognized?

The Source of this specific problem with t-beam 1.1 boards the preinstalled "meshtastic" is a explanation. Due to this a bugfixing reset script as alternative to the GPS Chipset detection is an option.

[cyberman54]

There is already code for support of Quectel L76 I2C chipset in paxcounter.

But i think paxcounter never can (and should) have all the logic for gps in it's code. We need some appropriate library which does the heavy lifting here.

[dl5dla]

Interesting that you found exactly the same workaround as i did!

Yes, that's true - looks like a copy ;-) Reading that thread and your post before would have saved me alot of time.

[cyberman54]

This issue is solved with v3.2.0, since NMEA ZDA sentence is no more used for timesync now. Time is now pulled from GGA / GLL sentences, both are processed by TinyGPS for Device ID GP as well as GN. Time synchronisation is now triggered by PPS signal on interrupt and timestamping. This way sentence delay is now handled straight forward, that's why we don't need ZDA sentence any more.