Radio Quality Issue

[chschmid]

I changed my TX from a JRX12 to a Spektrum DX18 a few days ago to be able to remap some channels.
FW r196.

Now I find that the radio quality drops significant from 100% to some 10% in the LOG. The radio has full range although AQ logs 10%.

Yesterday I took my Tx and laptop and went around the corner of my house maybe 40m from the AQ and still had good control and 100% display in QGC.
Did anyone have a similar finding?

Cheers
Christof

[Kisssys]

Yes, something is screwy. I had it happen today with my 12x, R196 . I noticed no problems throughout the flight. I looked at a bunch of logs and only found one other that had a simular dropoff.

[Jdmagoo]

Good to see others are having the same problem as me, I thought it was my setup but you guys have confirmed its a bug

I originally reported the issue with R195

viewtopic.php?f=33&t=2479#p14460

[Kisssys]

I went back through about 45 flights and have 35 minutes of logs that show degradation of signal. I don't believe it because I've never noticed the problem before and I think I would in manual mode which I spend most of my time.

The fact the signal level almost always goes down to less than 20 percent and stays there with sometimes a very gradual rise makes it questionable as the signal should come back up. I've not flown more than 75 meters away on any of these flights and land them 2 meters from me and the quality stays low.

On the bench, turning the Transmitter on and off causes the response you would expect, down to zero and right back up. I do have bench logs with the same problem though. I hadn't looked at the radio code lately but see lot's of changes to accommodate signal quality with more radio protocols.

I did a bench test of 15 mins and after a while it dropped to 15 percent. At the end of the test I turned the TX on and off and it only comes back up to 15 percent. It's not a signal issue.

[bluuu]

Yeah, since that posts i thinking about problem with my RX or TX ... but I noticed that issue on my futaba RX.

After turn on radio quality jump tu 7 ot 8% and stoped. It's on r195 from google code.

Another test on self compiled r197, radio quality is 100%

[Max]

Can you guys narrow down the FW revision where the problem starts happening? PPM quality reporting is working fine (for me anyway ). Wondering if it's a serial comm issue since all the radio protocols which depend on it seem affected. Any way to recreate it consistently?

-Max

[Kisssys]

I'm at R196, since it's not something that I normally looked at it was probably around for a little while. I see all the serial changes which are suspicious but this could be since the method of looking at quality changed. If you look at the plot you see me turning the TX on and Off at the end a couple of times which makes me wonder if the filter is doing what it's suppose to do.

Does 15 mean that about 15 out of 100 characters are being decoded?

Can't see how that could happen and still fly.

[Kisssys]

Max, could you suggest a couple of points to revert to that would most likely narrow down the problem and I will give them a try.

[Max]

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

[Kisssys]

Thanks Max, must be something common to the Sbus also since the problem popped up their. With a RC Heli I can tell less than 50ms loss, with the multirotor I'm not sure, it masks so much. I'll run it in debug a while and see if anything pops up.