TTGO T-Beam T22: Permanently 01.Jan 1970

[GeorgWolter]

Everything fine but the display permanently shows 01.Jan 1970.
Any advise?

[cyberman54]

Set TimeSyncInterval to zero in paxcounter.conf, then time display will be suppressed.

[cyberman54]

If GPS is not working, check

• use appropriate HAL-file for your board (ttgobeam10.h according to your picture)
• check GPS antenna is connected
• check red LED is flashing (meaning GPS has a fix)

If you don't get a fix, go outside and wait some minutes.

[GeorgWolter]

Board ttgobeam10.h is (was) configured.

GPS is working...red LED is flashing...I kept the T-BEAM outside for 15 minutes: 7 satellites.
But still only 01.Jan 1970 on the display.

Just attached the archive config.zip which contains:

• paxcounter.conf
• platformio.ini

config.zip

[cyberman54]

You set #define TIME_SYNC_LORAWAN 1 in paxcounter.conf, meaning that primary time source is LORA. Thus, GPS time will only be used as a fallback, and this takes a while. Set to 0 and try again.

[GeorgWolter]

Changed to #define TIME_SYNC_LORAWAN 0 accordingly but still 01.Jan 1970 with Sats:05 on the display.
Can / will keep it running for 1h or more.

Attached message found during RUN.

paxcounter.conf.zip

[cyberman54]

Message is normal, has no impact. To enforce a time sync, send rcommand 0x87 on port 2 (see readme.md).

[GeorgWolter]

Still 01.Jan 1970. Attached screenshots from the TTN Console.

[cyberman54]

Then it's a bug, probably in timekeeper.cpp, timesync.cpp or gpsread.cpp.
Can you spot it?

[GeorgWolter]

Until now nothing but I'll try...

[oseiler2]

I'm getting the same issue and think I have found a fix. Will post details later.

[oseiler2]

This is what happens:

• no LORA time source is configured (TIME_SYNC_LORASERVER = 0, TIME_SYNC_LORAWAN = 0), only GPS time is available
• the first time calibrateTime is called (and no GPS fix is available = GPS time invalid) the code in timekeeper.cpp sets timeSource = _gps;, but the time is not set
• all later calls to calibrateTime(void) fail to get the GPS time at if (timeSource == _unsynced)

Proposed fix:

• only set timeSource to GPS if gps time was acutally valid

    if (t) {
      // only set time source to GPS if GPS time was actually valid - otherwise
      // this will never synchronise.
      timeSource = _gps;
    }

• in case no LORA time source is configured, update time from GPS even when timeSource != _unsynced

  // (only!) if we lost time, - or when no other time source is available - we try
  // to fallback to local time source RTS or GPS
  if (((!TIME_SYNC_LORASERVER) && (!TIME_SYNC_LORAWAN)) ||
      (timeSource == _unsynced)) {

[oseiler2]

On another look, it might be better to set the time source to _gps and still call setMyTime even when the time is invalid, because that will do a check if the time is valid anyway and, if not, schedule a retry after TIME_SYNC_INTERVAL_RETRY. Otherwise the retry will only occur afer TIME_SYNC_INTERVAL, which can be a lot later.

// no RTC -> fallback to GPS time
#if (HAS_GPS)
    t = get_gpstime(&t_msec);
    timeSource = _gps;
#endif
    setMyTime((uint32_t)t, t_msec, timeSource); // set time

  // do we have a valid time?
  if (timeIsValid(time_to_set)) {
...
  } else {
    timesyncer.attach(TIME_SYNC_INTERVAL_RETRY * 60, timeSync);
    ESP_LOGI(TAG, "[%0.3f] Timesync failed, invalid time fetched | source: %c",
             millis() / 1000.0, timeSetSymbols[mytimesource]);
  }

[cyberman54]

@GeorgWolter could you please test the fix?

[GeorgWolter]

Yes, but retest failed.
And did somebody remove the "PAX : " from the display?

[cyberman54]

Please wait 10 minutes, then time should sync.
Yes, "PAX:" was removed from display, to allow display of larger counter values.

[oseiler2]

Can you please check that TIME_SYNC_INTERVAL_RETRY is set to 1 in paxcounter.conf?
Then you need to wait for 1-2 minutes after GPS fix and should get the time set.
Please post the log from start up to 2 minutes after GPS fix.

[cyberman54]

TIME_SYNC_INTERVAL_RETRY = 1 is okay for testing and GPS, but we need to be careful not to use short sync cycles for time sync via LORAWAN (duty cycle limitation).

[GeorgWolter]

I Set TIME_SYNC_INTERVAL_RETRY = 1 and created the attached logfile by capturing it from serial.
I hope this is what you have asked for. Otherwise pls. advise 😊
I am available for a remote session (e.g. Teamviewer).

log_PXC001.txt

[cyberman54]

@GeorgWolter you have LORA timesync enabled, thus using LORA network / LORA server as primary timesoure, not GPS. As explained above, please disable. Otherwise GPS will act as fallback timesource only.

[GeorgWolter]

If you do it right...Retest passed: 28. Sep 2020
(Afterwards reset TIME_SYNC_INTERVAL_RETRY = 10)

paxcounter.conf.txt

[cyberman54]

but... there should be a "G" on the display, behind the time/date row. If not, you're probably using OneBitDisplay Library > v1.5.0; those newer versions have a bug. I corrected it already, but we need to wait until v1.7.2 or greater is out.

[GeorgWolter]

Just checked this here in my VSC / Platform.io IDE:

• Adafruit SSD1306 (2.3.0)
• Adafruit GFX Library (1.8.5)

[cyberman54]

Bug is located in OneBitDisplayLibrary > v1.5.0, not in the Adafruit libs.

[GeorgWolter]

I am having here a second T-Team board (v.1.0) where both LEDs blue and red aren't shining anymore.
(This is of course no caused by Paxcounter)
So the idea is to check / flash latest firmware from TTGO. But do you know the related download URL?
I am still waiting for an answer from TTGO support dept.

[cyberman54]

@GeorgWolter Sounds like a power issue. A possible root cause could be a misconfigured Power Management Chip AXP197. The chip controls all supply voltages on the board, including VDD for the ESP32. The chip has non volatile registers so settings
are persistent. If the AXP chip is programmed to set the ESP32 power to off after power on, you have a kind of chicken-and-egg problem, because the I2C bus of AXP chip is controlled by the ESP32...

[GeorgWolter]

Other anomalies with this board are:

• Display is ca. 20% darker than with board 1
• Paxcounter is running...but there is never a GPS fix
• Buttons react only slowly

Q: What would you do?
btw.: I have just ordered a T-BEAM v1.1

[cyberman54]

Display is darker is when AXP192 set wrong voltage for the display VDD (output DCDC1)
GPS may not work if AXP192 did not power on voltage for it (outputs LDO3 and LDO1)

Paxcounter software does program the appropriate settings during power on (see ttgobeam10,h), but of course the ESP32 on the board needs power to run the software. If some kind of software sets output DCDC3 to off, the board is bricked, because this is the ESP32 power line.

[GeorgWolter]

But Paxcounter is running. I can see the activities on the display.
How can this be when ESP32 is w/o power?

[GeorgWolter]

Found this: Deep-sleep
Regarding deep sleep, except for DCDC3, power off all channels of AXP192, the current consumption is about 580μA

Source: https://github.com/Xinyuan-LilyGO/LilyGO-T-Beam