Hmm, I'm not really sure which versions to try. Might be easier to debug it
The radio error handling has not changed for the Spekky stuff, and only a minor change for SBUS. r95 was the last time the radio module changed "significantly" (and pretty minor stuff, at that). Since then almost all the radio module-specific changes have been for PPM (and to add SUMD), which shouldn't have affected SBUS or Spektrum handling. I can only test PPM so I try not to touch (break
) the other stuff.
From what I can tell, the only time radio_quality is reduced for Spektrum radio type is when the data isn't coming in fast enough or not in the expected order. The quality value is not any kind of actual count, but in this case roughly reflects the amount of time that data is, or is not, available. Meaning: If the radio module doesn't detect any new channel data coming in after 60ms (RADIO_UPDATE_TIMEOUT), it starts reducing the quality from 100, which eventually (in a second or two) drags it down to zero. When data is available again, it starts raising the quality counter back to 100. For it to detect that data is available, both serialAvailable(s) and spektrumCharIn() need to return non-zero, which only happens when a valid channel value has been decoded (spektrum.c, line 81-94).
So unless I'm missing something (possible), the radio quality reduction indicates that while it does get valid channel data fast enough to maintain control of your multi, there is some error in the data stream that is causing packets to be lost at a steady rate. Or something like that. Theoretically your control reaction time should be reduced, but we're talking millisecond differences, and if you're not flying 3D stunt maneuvers then you'd probably never notice.
So to debug I'd focus on figuring out what data the AQ is actually getting and trying to trace the source of the packet loss from there. That's getting beyond my comfort zone, but entering "layman's completely wild speculation" mode...
sounds like the input timing on the serial port is getting messed up due to some influence. I guess my first step would be to see if the time loss between valid packets happens because serialAvailable() returns false, or because of spektrumCharIn(). Or another possibility is that something is blocking the radioTask (radioTaskCode()) from executing fast enough.
-Max