Radio Quality Issue

[Max]

Yea I focused on spekky code but sbus and sumd radio_quality is calculated the same basic way, based on how long since the last valid channel data was received.

I also noticed that spektrumCharIn() expects data at most every 7.5ms, otherwise it assumes the beginning of a new frame. Perhaps it's extra sensitive to timing issues.

-Max

[13brv3]

FWIW, I just looked at the logs from the last couple flights, and they're hanging between 96-100. Of course this is the very slightly modified code for s.bus with the telemetry receivers. I presume it's built from what's in the trunk now, since I just did an anonymous svn checkout to get it.

Rusty

[Kisssys]

7.5 ms is a lifetime to spektrum, it probably takes about 1.5 ms to send one frame.

[Jdmagoo]

Interesting that SUMD also uses the sbus connector,could this also be the reason why the signal drops on SUMD?

[chschmid]

I started getting issues when changing the Tx to a DX18 and upgrade to r196.
The DX18 supports DSM2 mode. I was binding with a 12ch Rx in DSM2 Mode.

Before with 100% Radio quality with r100 I used the "native" DSM2 JR X12.

Cheers
Christof

[Kisssys]

Yes, it's probably related. I flew a flight today logging spektrum radioData.errorCount. This tells if the frame was really valid. I plotted the RADIO_QUALITY and the radioData.errorCount on this flight. You see the quality dropping and never coming back up. You can see the spektrum error count stays at zero until the end of the flight, I disarmed and quickly turned the radio off and on. When the radio came back on it shows the number of errror counts received while off.

[chschmid]

Same here. One log I count 25000 Errors at the beginning of the log (11'096). The count drops to 0 a ms (11'100) later.
After switching off the Tx for a sec, I have some valid error counts and the same quality level @some 10%.

I checked a log more and there was NO quality loss for the whole flight with DX18 and r196.

Very strange.

[Lindbaergh]

I dont know if it is related to this topic, but yesterday i changed from fw 6.6.1 to r195. After reading this i checked the logs and found this:

AQ-FW-r195_signaldrop.jpg (137.56 KiB) Viewed 12377 times

But only in 1 out of 5 logs. My setup is a Hott TX and a GR24 RX (set to SUMO 08) connected to AQ port 14. All logs that made with fw 6.6.1 before shows nothing like that, there are some spikes here and there (like around 70000 in the picture) but no drop like that on 80000. So i hope the info is useful. I have one question does that drop mean that the AQ can switch to failsafe, or is this more a 'cosmetic' problem?.

Michael

[Max]

Michael, so this is happening to you with PPM radio type? That's the first report I've seen, so far it's been serial input types only. I've never seen that in any of my logs, and I've been using > r100 for months. But I understand the Spektrum issue doesn't affect everyone either... mystery deepens

It would be great to identify what causes the quality to drop, and/or be able to recreate it on demand. At this point neither Bill (last I heard) nor myself can repro the issue.

AQ failsafe won't engage until the radio_quality drops below 0.1 plus a 1 second delay after that. The problem is more than cosmetic but by itself shouldn't cause a loss of control (not sure I'd still fly with it like this myself though).

-Max

[Kisssys]

I spent the whole day trying different things. I just did a fresh repo and it did it first flight. Their are never any radio error's which says all the characters are getting their. I also tried the z1 to just float instead of register float in the filter.

Could it just be a logging error?