INAV 7 RC1, Arm signal lost during flight.

[Simba185]

Current Behaviour

Tarot TL250
SpeedyBee F405 V3 with Foxeer M10 GPS
Futaba T8J and R2008SB

Quad flies OK in all modes, Loiter mode is working. NAV RTH is working when the Home position is set correctly.

During Flight ( Alt hold or Loiter) when no settings are changed, the quad seems to have a major glitch. ( at less than 10m distance)
Arm is disabled, but also are the LED's. LED's are set to no real channel so they shoul never disable unless the FC turns them off. This proves it is not related to the RX/TX

When this returns the quad is flyable but the throttle is very touchy to descend, but when cycled to Angle and back to Alt Hold the operation is restored to normal. ( if this happens near anything its quite sketchy)

Steps to Reproduce

1.Launch in Angle more
2. Change to Alt Hold or Loiter.
3. Fly normally and glitch will occur at random

Expected behavior

Flight without random glitches.

Suggested solution(s)

I have replaced the wires from the FC to RX and insured that all F/S settings are set to hold the previous value.

is there possible there is a problem with the FC or INAV firmware? I am using the T8J on other Copters and it is working OK.

Any suggestions to resolve this issue are appreciated. ( I have made many posts on FB but cannot solve the issue)

Additional context

---

• FC Board name and vendor: SPEEDYBEEFF405V3
• INAV version string: 7.0 RC1

[MrD-RC]

Please be sure to update to RC3. You will also need Configurator 7.0 RC2.

[Simba185]

Is there a change list for RC3? I am always hopeful but can never seem to pinpoint the issue.

Thanks.

[Simba185]

So, still the same issue with RC3.

Attached is the log and screenshot.

LOG00001.TXT

I would appreciate any ideas to help debug or resolve.

Thanks.

[mmosca]

@Simba185 what channel are you using for the arm flag, and how did you setup its failsafe behavior?

[Simba185]

@mmosca Arm is set with CH5. But LED is set for ch 22 (I am only using 8ch RX so this is never used), and i cannot see why it would turn off.

Fail-safe is set for Drop ( this set to 300ms) and the T8J is setup for NOR mode that should keep sending the previous command.

Is it worth setting to land to prove it is not failsafe? ( i don't think it is as Arm is lost).

Thanks,

[sensei-hacker]

But LED is set for ch 22 (I am only using 8ch RX so this is never used)

Does that mean you have something set up in the Programming tab for channel 22?

[mmosca]

The question is in your radio setup, not in inav. Is channel 5 (your arm channel) fail safe behavior set to hold or to a fixed value?[]s,Marcelo Bezerra ***@***.***>On 23 Nov 2023, at 14:46, Simba185 ***@***.***> wrote: @mmosca Arm is set with CH5. But LED is set for ch 22 (I am only using 8ch RX so this is never used), and i cannot see why it would turn off. Fail-safe is set for Drop ( this set to 300ms) and the T8J is setup for NOR mode that should keep sending the previous command. Is it worth setting to land to prove it is not failsafe? ( i don't think it is as Arm is lost). Thanks, —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Simba185]

@mmosca, The Futaba T8J ( all channels) is set for NOR mode that holds that last value under fail-safe conditions.

I am almost tempted to just power off the TX while at a low alt and see if what happens is the same as this chart.

Is there any images of what is expected to happen when a failsafe occurs?

Thanks,

[Simba185]

@sensei-hacker, Yes I have LED set for CH22 (but this is just a dummy mode to enable the LED), The RX I have only supports 8ch.

Thanks!

[Simba185]

@mmosca is there any way to enable some kind of debug mode that could log errors from the FC or INAV?

I want to solve the issue but I'm not sure what part is at fault.

Thanks!

[sensei-hacker]

Since you mentioned the LEDs turn off (and stay off?), can we see how those are set up, please?

[Simba185]

@sensei-hacker No the Led's turn off then back on after the "glitch" recovers.

Attached is a picture of the modes.

According to the log, it seems like the RCOUT stops first, then all other signals drop afterward.

Thanks.

[MrD-RC]

Have you tested failsafe on the bench? Does the parachute turn red when you switch off the transmitter?

[MrD-RC]

@sensei-hacker No the Led's turn off then back on after the "glitch" recovers.

Attached is a picture of the modes.

According to the log, it seems like the RCOUT stops first, then all other signals drop afterward.

Thanks.

This is not set up correctly. Your quad will always be armed, which is not safe. There should be a portion of the arm mode that does not have the blue bar. You need to be disarmed at some point. I’m actually surprised this works at all, seeing as you have GPS.

[Simba185]

@MrD-RC In that picture the Arm modes are not shown.

Attached is the arm modes, you can see the arm and pre-arm are not enabled at all times. ( only angle is always enabled)

The red parashoot is shown when rc link is off. (also shown in OSD).

Any suggestions are greatly appreciated, Thanks.

[MrD-RC]

Sorry. But why have Angle always active? There’s no need. You only need it at the same time as althold. Not with poshold or rth.

Ok, so if the parachute goes red when the transmitter id switched off. It’s detecting failsafe. The parachute should also go grey again when you power on your transmitter.

Did you have this problem on 6.1.1?

I’d recommend using channel 17 rather than 22 for the LEDs. Only Jeti has 24 channel support. All others stop at 18. Which screens is allowing you to use 22?

[Simba185]

Ok so I will remove angle + PosHold ( Could that cause this issue?)

Yes parachute goes grey when RC link is restored.

this Unit was pretty much unflyable with 6.1.1 (I tired to troubleshoot the issue but the quad would not respond to RC Inputs, and crashed a lot (badly). When I saw the timers were fixed with 7.0 I tried again and it worked correctly (at least flyable)

Sry in the he pic the LED's are Set to CH10, Is this ok? ( I have only 8ch RX)

Is there any way to log the FC messages? In Ardupilot there are messages over the MAVlink.

Thanks again!

[b14ckyy]

Is this still an issue? Have not seen any other reports with that problem. If this still happens even with 7.1, @ me and I will reopen.

[Simba185]

@b14ckyy Yes this is still occuring.

I have lots of logs showing the random crash or w/e is happening.

Is there any messages in INAV like ardupilot?

I currently fly it as is, and have to be very cautious when this happens.

[b14ckyy]

INAV has no serial protocol messages as Ardupilot but I doubt that this will help anyway.

One thing I noticed is, that the Log shows still a valid RC signal and very specific output values per channel when the glitch happens. the gap is ~70ms (with some aliasing error from the logging rate). The Channel update rate is around 74Hz with some fluctuation. That means about 6-7 RC channel updates in a row have the exact same false values.

channels are permanently valid and no RxLoss packet was sent to INAV over sbus. From all the given info I can only conclude that your RC link itself has issues and the receiver is acting weird.

I have no experience with Futaba. But if you have a way to change the RC Update rate, maybe try a lower value. This might change the behavior or solve it.

[Simba185]

Thanks for the in-depth dig into it.

I'm glad to hear it is not related to some settings in INAV,

It seems according to some threads about this RX/Tx combo, it is already set for 13.6ms update rate. The only other option is HS mode, but this is 6.8ms and is supposed to be for digital servos only.

There is a setting for S-FHSS/FHSS but FHSS is only 4ch so not much help there.

Looking at RSSI, It has a cyclitic flucuation between 99% and 93% at about 1.5hz, but it does show some functions so it is working.

I had seen this value in the 60's with my FPV ON but these logs all show in the 90's with the FPV OFF and showing the same issues.

Thanks.

[b14ckyy]

the problem with RSSI is, it does tell you nothing about actual quality of the link. Also even if the link OTA is perfect, if your receiver acts up it can drop frames to send to the FC.
Afterall I would assume this is an issue with the RC link but with that I can't help.