[Feature request] Add support for alternative time adjustment sources, such as DCF77

[ColoMAX]

Currently accurate timekeeping is based on (to the best of my knowledge);

• Auto-detecting an RTC available via I2C, with fallback to system clock (inaccurate)
• (optional) an added GPS receiver to periodically adjust the chosen "RTC"-clock

or alternatively the user or external application issues an time adjustment via serial to the device.

To typically when one wants accurate time over a longer period, you link a secondary clock source, al be it via serial or via I2C, to issues adjustments on your local clock (the "RTC")

The best long-term solution is a source which sources its time from an atomic clock, al be it indirectly.
To this end, we have GPS, but GPS can consume quite a lot of power.
For example the uBlox MAX-M10M-00B will consume by the datasheet something in the ~5mA range.
Which can negatively impact network availability in adverse situations, and puts more strain on our power sources.

To solve this, we can turn to other means of accessing an accurate clock, which uses less power (for the receiver); e.g. DCF-77.
A DCF-77 receiver might use less than hundred uA (e.g. dcf 77 641138 (https://www.reichelt.com/nl/nl/shop/product/ontvangstmodule_dcf_77-57772) in contract to mA's for GPS.

There are other similar sources for different parts of the world e.g.;

• US: https://en.wikipedia.org/wiki/WWVB
• UK: https://en.wikipedia.org/wiki/Time_from_NPL_(MSF)

This could extend battery life for stationary devices, if these would be fitted with such an receiver instead of GPS.

---

(DRAFT) Initial work being done on: main...ColoMAX:MeshCore:dcf77-support

Code

Some suggested class alterations:

Where GPS is both a location and time provider.
But the DCF-77 for example will be a TimeProvider.

class TimeProvider {
protected:
  bool _time_sync_needed = true;

public:
  virtual void syncTime() { _time_sync_needed = true; }
  virtual bool waitingTimeSync() { return _time_sync_needed; }
  virtual long getTimestamp() = 0;
  virtual void reset() = 0;
  virtual void begin() = 0;
  virtual void stop() = 0;
  virtual void loop() = 0;
  virtual bool isEnabled() = 0;
};

class LocationProvider : public TimeProvider {
public:
  virtual bool isValid() = 0;
  virtual long getLatitude() = 0;
  virtual long getLongitude() = 0;
  virtual long getAltitude() = 0;
  ...
};

CLI

I do not see the need to (initially) support multiple clock adjustment sources at the same time, so gps sync and clock sync can remain, similarly the for time <epoch>. But it already shows we are supporting different sources for the clock, and adding manual overrides to when or how these are adjusted.

Ideally for the long term, I suggest only the time command remains, but it allows for an epoch argument, or the clock source us use; gps, ppm, host.

I would suggest to aim to support only one RTC clock (one internal reference) and support multiple clock adjusters, for redundancy. By using a priority mechanism; if one becomes unavailable, let the next take over.