Failsafe not dropping throttle about flyskyrxfirmwarerssimod

[Cleric-K]

It depends a lot on what flight controller firmware you are using.
I would recommend let the failsafe settings be made by the FC itself. With flysky this means that you have to make one of the channels to go into invalid range (that is below 1000 or above 2000). At least with betaflight, it will notice the invalid value and trigger failsafe. Then the failsafe values that are configured in BF itself will be used.

Here's one of the guides: https://www.propwashed.com/ibus-betaflight-guide/

[CaptainYags]

That's exactly what I want to do. How do I get one of the channels to go below 1000 when the signal is lost? Right now the receiver keeps sending the same signals when it loses signal. That seems like something that the receiver needs to do, not the FC.

…

On Mon, Jun 29, 2020, 4:00 AM Cleric-K ***@***.***> wrote: It depends a lot on what flight controller firmware you are using. I would recommend let the failsafe settings be made by the FC itself. With flysky this means that you have to make one of the channels to go into invalid range (that is below 1000 or above 2000). At least with betaflight, it will notice the invalid value and trigger failsafe. Then the failsafe values that are configured in BF itself will be used. Here's one of the guides: https://www.propwashed.com/ibus-betaflight-guide/ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKEU6N3ORVA7G5OSTAOTZ7DRZBC27ANCNFSM4OKF6UGA> .

[CaptainYags]

Sorry, I replied before fully reading your link. I tried similar steps without success, but I'll give that a try again. My other FlySky receivers (unmodified) drop the throttle below 1000 without me having to set trim on the radio, but if it will work, it'll work.

…

On Mon, Jun 29, 2020, 4:00 AM Cleric-K ***@***.***> wrote: It depends a lot on what flight controller firmware you are using. I would recommend let the failsafe settings be made by the FC itself. With flysky this means that you have to make one of the channels to go into invalid range (that is below 1000 or above 2000). At least with betaflight, it will notice the invalid value and trigger failsafe. Then the failsafe values that are configured in BF itself will be used. Here's one of the guides: https://www.propwashed.com/ibus-betaflight-guide/ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKEU6N3ORVA7G5OSTAOTZ7DRZBC27ANCNFSM4OKF6UGA> .

[Cleric-K]

I use x6b myself and have not problem with failsafe. But my transmitter is fs-i6x.

Flysky receivers are two types:
1/ the cheaper ones without failsafe like a8s. They simply stop sending frames over IBUS when there's no connection with the transmitter. The FC detects the absence of frames and triggers failsafe
2/ x6b, ia6b, etc. Support failsafe - that is, when link is lost, the receiver continues to send IBUS frames to the FC with the channel failsafe values as set in the tx.

The RSSI mod does not change anything in this - as I said, I also use use modded x6b and it works fine. I would guess there is something still to be done at the tx side.

As a last resort you can try flashing the original x6b firm again and confirm if the problem really comes from the patch - although at this point I don't see how this is possible.

[xctmaf]

I have same issue on ia10b (when I switch a radio off all values keep staying where it were before). I have fs-th9x and tried different firmwares, and it doesn't help.

I am sure that receiver can determine moment when connection have been lost, because it starts blinks with LED. So now I see only 3 solution:

• try to find any another radio (newer, at least fs-i6) and try co configure failsafe behavior, then bind it back to mine th9x (very hard in my case, due some personal reasons)
• try to reverse original firmware and write some new logic with force send default ppm at least to THR channel (3rd in my case and I think it is on of common). Unfortunately I am newbie in reverse engineering
• try to follow hardware way. To build anything simple, which can be soldered to LED and detect 'blinking' mode and then.. just break 5+ line

If repo owner or somebody else can help with reverse original firmware OR share firmware from his receiver with working failsafe option it will be very useful!

note: didn't try to write original firmware from this repo yet, because just ordered programmator and it didn't come yet. Will let know if it will help, but during last 1.5weeks of searching I understood that is not so seldom problem. Quite enough guys have same, and maybe some separate patch with hardcoded method to send predefined values to channels can help to at least dozens (but I think hundreds) people. something like

#define CH1_DEFAULT_VALUE 900
#define CH2_DEFAULT_VALUE 900
#define CH3_DEFAULT_VALUE 900
... //I think 4 will be enough, but if possible it can be 10

void failsafe_hack()
{
    setChannel(1, CH1_DEFAULT_VALUE );
    setChannel(2, CH2_DEFAULT_VALUE );
    setChannel(3, CH3_DEFAULT_VALUE );
}

void original_method_for_failsafe_or_which_one_detect_radio_off_and_start_blinking()
{
   /*original code*/
  failsafe_hack();
}

[Cleric-K]

I looked at the TH9X manual and it seems that it should be possible to configure that failsafe behavior.

The procedure should be the same as with fs-i6(x):

1. Set the ENDPOINT of some channel (for example THR) to some high or low value for example 120%
2. Set the FAILSAFE value for that channel to this high/low value
3. Restore the ENDPOINT to its original value (FAILSAFE value will remain at the high/low value)
4. Configure betaflight (or whatever you are using) to activate failsafe when any channel has invalid value