Three of them: Matek F405-Wing, F405-WSE, and a mRo x2.1 Rev 2.
Edit: I should add the mRo has been removed from service thanks to a direct hit from a scale warbird… But the two Matek boards are still in service.
Three of them: Matek F405-Wing, F405-WSE, and a mRo x2.1 Rev 2.
Edit: I should add the mRo has been removed from service thanks to a direct hit from a scale warbird… But the two Matek boards are still in service.
I built a code to measure the time since the last valid rc-value (that’s the decision base of the message).
On desk the regular value is lower than 20ms in every case, so >200ms seems to be a good threshold.
But unfortunately I couldn’t reproduce the “critical warning” on desk to measure a value higher than 200. - so I need to fly.
Maybe the warning is correct and just a little more quick/sensitive then the RSSI?
After I have a warning and a corresponding value in flight, I will change the orientation of the antennas and test again. Currently they are 90° on one side and it’s possible to fly out of sight - but for a test I will e.g. pull them just out under the canopy.
Sorry for being OT but how do I get that “Wind warning” to show up in Yaapu, and where can I set a threshold? I wasn’t able to find anything on it, could be very useful to me.
This is a LUA script:
Thanks, in that case I won’t be able to use it on my current planes (all only 1MB flash).
As an interim conclusion I would say:
So my next step is to measure continuously the values and to manipulate the system step by step:
@Allister It seems you have that issue with all your FCs. So you should also have a look at your transmitter. (What transmitter/receiver are you using?)
If anybody has that issue, too, he should have a closer look at the radio connection and possible hash - and post the result here
Sorry, but that guess has been wrong:
Today in the morning I tested the system and the result has been very clear:
That big numbers are a “negative” result of an unsigned subtraction (-1 or -2).
So the current timing of the calls of millis() and plane.failsafe.last_valid_rc_ms is wrong. Because when millis() is called and after that a taskswitch with an update of RC is done, the value of plane.failsafe.last_valid_rc_ms is bigger than the former fetched millis() (see line 118).
To fix that, it’s necessary to correct the chronological sequence. First fetch plane.failsafe.last_valid_rc_ms, then fetch the current time millis() and then substract (see lines 118/119).
I’ll start a PR to correct that issue after a positive flight-test.
I’m using a Radiomaster TX16S. The issue is only showing up on Planes using the Jumper R8 receivers. I have a copter using a Radiomaster R161 and no issues there. And depending on how far you want to go in the troubleshooting: I’ve also been using CRSF MicroTXV2 and RFD900 TXModV2 and of course no issues with those.
Thanks for looking into this!
It’s just an issue of plane-code.
I tested my fix in the morning in real flight and no more CRT:NoRCReceiver warnings popped up.
Yes, I had forgot that when I wrote my reply. Good thing, because I have a student project coming up and they’ll be using R8s in copters so this is one less thing I need to worry about.
PR #17808 has been merged into master today
Is this change present in the latest beta 4?
Today I flew on beta 4 for the first time, this message appeared again, though only once.
Willy, I just wanted to say thank you! This message was really annoying