Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TTGO T-Beam T22: Permanently 01.Jan 1970 #639

Closed
GeorgWolter opened this issue Sep 25, 2020 · 29 comments
Closed

TTGO T-Beam T22: Permanently 01.Jan 1970 #639

GeorgWolter opened this issue Sep 25, 2020 · 29 comments

Comments

@GeorgWolter
Copy link

GeorgWolter commented Sep 25, 2020

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

IMG_9048

IMG_9050

@cyberman54
Copy link
Owner

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

@cyberman54
Copy link
Owner

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
Copy link
Author

GeorgWolter commented Sep 26, 2020

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

IMG_9064

config.zip

@cyberman54
Copy link
Owner

cyberman54 commented Sep 26, 2020

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
Copy link
Author

GeorgWolter commented Sep 26, 2020

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.

IMG_9071

Screenshot_message1

paxcounter.conf.zip

@cyberman54
Copy link
Owner

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

@GeorgWolter
Copy link
Author

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

Result87
DL87

@cyberman54
Copy link
Owner

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

@GeorgWolter
Copy link
Author

Until now nothing but I'll try...

@oseiler2
Copy link
Contributor

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

oseiler2 pushed a commit to oseiler2/ESP32-Paxcounter that referenced this issue Sep 27, 2020
…ime in first call is invalid, then time will never get updated from GPS

cyberman54#639
@oseiler2
Copy link
Contributor

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
Copy link
Contributor

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]);
  }

oseiler2 added a commit to oseiler2/ESP32-Paxcounter that referenced this issue Sep 27, 2020
…NTERVAL_RETRY is used over TIME_SYNC_INTERVAL when GPS time was invalid
cyberman54 added a commit that referenced this issue Sep 27, 2020
Fix: issue #639, if no LORA time source available and GPS time in fir…
@cyberman54
Copy link
Owner

@GeorgWolter could you please test the fix?

@GeorgWolter
Copy link
Author

GeorgWolter commented Sep 27, 2020

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

IMG_9085

InvalidTimeFetched

@cyberman54
Copy link
Owner

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

@oseiler2
Copy link
Contributor

oseiler2 commented Sep 27, 2020

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
Copy link
Owner

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
Copy link
Author

GeorgWolter commented Sep 28, 2020

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
Copy link
Owner

@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
Copy link
Author

GeorgWolter commented Sep 28, 2020

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

IMG_9113

paxcounter.conf.txt

@cyberman54
Copy link
Owner

cyberman54 commented Sep 28, 2020

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
Copy link
Author

GeorgWolter commented Sep 29, 2020

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

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

@cyberman54
Copy link
Owner

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

@GeorgWolter
Copy link
Author

GeorgWolter commented Sep 29, 2020

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
Copy link
Owner

@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
Copy link
Author

GeorgWolter commented Sep 29, 2020

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
Copy link
Owner

cyberman54 commented Sep 29, 2020

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
Copy link
Author

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

@GeorgWolter
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@oseiler2 @cyberman54 @GeorgWolter and others