inconsistent use of micros()/millis() in getPacket()?

[philj404]

While trying to figure out how to get up to 100% received packet reliability, I came across something that confused me:
In RX.cpp getPacket(), lastRadioPacketeRecievedTime and nextAutomaticChannelSwitch seem to be set to sums of millis() added values in microseconds and then sometimes set to micros(). This seems inconsistent.

Are lastRadioPacketeRecievedTime and nextAutomaticChannelSwitch supposed to be in microseconds or milliseconds, or what?

(That said, just consistently using micros() doesn't yet help my packet success rate.)

[soligen2010]

Well, it has been a very long time since I looked at this code, so I don't recall what I was thinking. At a quick look at the code , using Micros seems to me to be appropriate, but I don't recall if there was something subtle making me use millis instead. Probable warrants a deeper dive.

That said, I don't know if 100% reliability is a realistic goal in a dynamic environment - all the motion, varying antenna orientations, and very cheap radio modules. Servos and electric motors make electrical noise. The frequency space is shared with Wifi and other 2.4 GHz devices. I only achieved it when testing at very short range.

Most RC control servos only update every 20 ms, and we send packets every 3 - 4 ms, so as long as every 5th packet gets through, you should never notice the difference.