Fix EDTv2 Logging

[andyp1per]

No description provided.

[mbuzdalov]

Maybe I'm not understanding something, but what exactly was the bug?

If no telemetry arrives (e.g. at all), no new EDTv2 data arrives as well, so no log entries are written (as they are only written when there is new data), that was the idea. On the other hand, in a rate-limited environment one may enter the loop when (a) the previous telemetry data was processed but not written due to rate limiting, but (b) time passed and one can now write the packet. So doing the EDTv2 thing outside of the telemetry timing check was part of the design.

What am I missing?

[andyp1per]

@mbuzdalov it was outside the check for logging.

[mbuzdalov]

@andyp1per are you sure? It used to be inside just the check for logging (https://github.com/andyp1per/ardupilot/blob/006aea67e54e640c8d3c519434b9e53389b976b6/libraries/AP_ESC_Telem/AP_ESC_Telem.cpp#L691), and now it is also inside the check for having recent telemetry (https://github.com/andyp1per/ardupilot/blob/006aea67e54e640c8d3c519434b9e53389b976b6/libraries/AP_ESC_Telem/AP_ESC_Telem.cpp#L692), which is somewhat redundant, because new EDT2 entries are only generated when there are updates.

So if logging is disabled altogether, the EDTv2 path was never entered even before this commit. I've double-checked this with the local branch which does not have this commit merged.

[andyp1per]

@mbuzdalov what is the problem you are seeing now?

[mbuzdalov]

@andyp1per theoretically, it's the fact that updates may arrive slightly later to the logs in rate-limited environments. The delay is obviously at most the reciprocal of the rate limit frequency, so - not so much.

Methodically, I am a little bit worried that two core people converged on fixing a bug which is apparently not a bug.

I admit that currently the code looks more homogeneous, and the disadvantage it introduces is really really minor, so leaving it as is now is safe.