Inav: GPS - Get date and time from GPS receiver and record them to blackbox

[digitalentity]

[fiam]

@digitalentity I'd like to get this done to log my flights with blackbox, rather than using telemetry as I'm doing right now. I'd like to do it in the following steps:

• Add a proper API for time, which would track both real time (i.e. the current time in UTC) as well as fly time (fly time is currently tracked in osd.c, which seems a bit out of place).
• Add an MSP command to set the current real UTC time with nanosecond resolution. We might not use nanosecond resolution for real time in the FC right now, but it's important to make the external API as precise as we might want to get in the future to avoid introducing another MSP command if we want more precision.
• Add time-related fields gpsSolutionData_t in io/gps.h
• Allow GPS drivers to retrieve the current time from the GPS
• Change gps.c to update the global real time from the GPS time if its validity and accuracy are good enough.

Once the real time is set (either via GPS or MSP) the FC will count time from there. If time is set again, it will override any previous stored real time. The use case for this is e.g. a GS or phone/table app which sets the time via e.g. bluetooth or setting the time from the radio via smart port, then let the FC count elapsed time from there.

[digitalentity]

@fiam

Add a proper API for time, which would track both real time (i.e. the current time in UTC) as well as fly time (fly time is currently tracked in osd.c, which seems a bit out of place).

There is some timekeeping defined in drivers/time.h, we could add RTC timekeeping there. Flight time could be tracked by adding a generic timer with enable/disable API used by arm/disarm procedures.

Add an MSP command to set the current real UTC time with nanosecond resolution. We might not use nanosecond resolution for real time in the FC right now, but it's important to make the external API as precise as we might want to get in the future to avoid introducing another MSP command if we want more precision.

Nanosecond resolution is an overkill. For RTC I would prefer something with less (but still sufficient) resolution. Millisecond resolution is more than enough IMO. If you want nanosecond resolution on API - that's probably ok, but I still think it's an overkill.

Add time-related fields gpsSolutionData_t in io/gps.h
Allow GPS drivers to retrieve the current time from the GPS

Agreed.

Change gps.c to update the global real time from the GPS time if its validity and accuracy are good enough.

Once RTH clock is set (either by GPS or MSP via some setRealTimeClock API) we should avoid time jumps (especially backwards in time). Consecutive calls to setRealTimeClock API should adjust the time using smarter logic - by speeding up or slowing down the RTC (making seconds tick faster or slower).

RTC should also be decoupled by system timers, it shouldn't affect counting "on time", "flight time" or anything else.

[digitalentity]

@fiam I wonder why you didn't join INAV Slack channel yet :wink:

[digitalentity]

I think this issue can be closed now. We have date/time in blackbox logs now - TZ-related stuff is out of scope for this issue.