Fix GHST telemetry #6462
Fix GHST telemetry #6462
Conversation
|
@Christoph-Hofmann you might want to take a look |
|
I checked your changes. It work now fine. |
| @@ -163,7 +163,7 @@ bool checkGhstTelemetryState(void) | |||
| // Called periodically by the scheduler | |||
| void handleGhstTelemetry(timeUs_t currentTimeUs) | |||
| { | |||
| static uint32_t ghstLastCycleTime; | |||
| static timeUs_t ghstLastCycleTime; | |||
There was a problem hiding this comment.
32-bit microtime overflow, ta-daaah!
There was a problem hiding this comment.
Nice Find! thanks to everyone involved in finding this, looks like it wasn't easy to find.
So.. looking at the BF driver, I guess the behavior is different because timeUs_t is 32 bits in BF?
At least I can't find anywhere that defines USE_64BIT_TIME.
There was a problem hiding this comment.
Yes, AFAIK BF is 32-bit only, therefore even if uint32_t overflows, this doesn't mess with scheduling because uint32 - uint32 will always yield a correct result even if overflow happens.
Here it's different, after crossing the 2^32 boundary uint64 - uint32 will always yield a result larger than 4294 seconds which causes the telemetry driver to think "Oh shit, I sent the last telemetry packet over 1 hour ago" and schedule the new one immediately.
Fixes #6457
After overflow, telemetry was generated every 2ms instead of 100ms. That was slowly clogging serial port so failsafe was triggered.
@tonycake you might be interested in this one