FIX made microsAtLastPulse volatile ; NEW added failsafe procedure in latestValidChannelValue()

[dantiel]

this PR fixes a bug which caused noise in the signal and adds an (opinionated) failsafe procedure.

[dimag0g]

I think 10 seconds is way too much for failsafe timeout, in many cases your model will simply crash within that time. A typical comm loop frequency is 50 Hz, and I would say >10 missed frames in a row warrant a failsafe, so 0.2s, 0.5s or 1s timeouts make more sense.

[dantiel]

ok, i let the decision to the maintainer of the repo. i agree 1 second is probably a better timeout, but 10s seemed more failsafe to avoid false positives when turning off the motor would result in a crash. i used the failsafe preferably to prevent my model flying away, which has happened already by a loose receiver cable.

[dimag0g]

@dantiel The failsafe coming from PPM should in my opinion be the equivalent of "stage 1" in betaflight terms, when the drone simply stops getting further away uncontrollably (if possible). What you're talking about is the equivalent of "stage 2" failsafe, when the drone soft-crashes or tries to get back using GPS, and for which 10 s (or even more) sounds appropriate. I assumed that the comm library should implement only "stage 1" kind of functionality.