Hello!
I am working with a sort of a problem setting properly the FailSafe values in configuration as mentioned in subject.
I set the values for every channel in the receiver, and it just doesn't work.
I read the article in FAQ ( https://www.msh-electronics.com/faq/ ) that's telling not to set Failsafe as in airplanes - OK, I agree with that, except the one detail:
In case of momentailry loss of signal, set the trottle to 0 (CUT position) will lead me out with slow, long softstart, and it's not good.
I would prefer, to set the throttle FS to HOLD position - engine off, but in case the link re-establish - short quick softstart will occur (as in bailout case).
Beside that, i have two helicopters. One with the old Brain1 FBL, and the second one with the Brain2.
And the problem occurs only with Brain2, so I guess the Old Brain1 just ignores the "frame lost" flag sent from receiver in a link lost situation.
Is there any way to force Brain2 to ignore "farme lost" bits received from the receiver via S.BUS (the same way as Brain1 does it)?
Or maybe any other way, to set FailSafe throttle value different than just 0 (complete cut-off)??
I'll be grateful for any help.
Regards, fly high!
First, you must eliminate the cause and not the effect.
It is not normal for your model to have a Fail Safe in flight.
Ely RC receivers are the same receivers used on airplanes and gliders that fly at much greater distances than Ely RCs and are designed to not have fail safe even at long distances.
If you have fail safe, you have to check that the supply voltage of the receiver is stable and "clean", then you have to check that the antennas are not shielded by the model frame that being conductive carbon shields the signal, then you have to check that the cable that connects the receiver to the flight control unit is not defective, is not stripped and touches against an edge of the conductive frame and that it is far enough from the sources of electrical noise of the model (motor, motor leads <=> ESC, ESC battery leads).
In the meantime, although we strongly advise against it for your and others' safety, if you want to risk continuing to fly while trying to discover the cause of the Fail Safe, activate the autorotation Bailout by setting the Bailout Timeout to 5 seconds.
Well, alright, from the begining:
First, you must eliminate the cause and not the effect
That's what I've just done - meaning of inside cause to failsafe works this way not another.
The cause of just occurance of failsafe is ... me, switching off my RC Transmitter.
In a controlled environment, blades taken off and so on.
And that is exactly what I am affraid of flying in reality.
My RCFM airport unfortunately it lies in a place quite electromagnetically polluted.
Some short breakings in RC-transmission just happens sometimes... Not too often, and never while flying "by the leg", so there is not much to worry about, except that, the failsafe can just CUT my motor out permanently (in fact) the way it works right now).
Beside that, there are no other possible causes of its occurence I would be particularly afarid of (none of those You name).
It is not normal to get failsafe in fligt - RIGHT.
BUT the failsafe, exist as an istitution for a reason, and for the same reason i SHOULD NOT CUT-OFF the engine!! It should set it to HOLD.
Now, moving to Your proposal:
activate the autorotation Bailout by setting the Bailout Timeout to 5 seconds.
Correct me if I'm wrong, but that solution is possible while using Brains Governor. And startup... And full control of motor actual power is on Brain side, the ESC is set to "Linear" or "Airplane mode".
Right?
Well, i don't use it that way - never mind the reasons.
I use governor from ESC.
Now, another way to get of this problem is to connect ESC Directly do RX - yes, I know, and I will consider that if You tell me, that there is ABSOLUTELY NO WAY, to Brain2 act just like the old Brain1 in situation of failsafe.
(or just to set the level of FailSafe Throttle different than 0 in Brain2 it self - of course either way is fine).
If the ESC governor is used, the ESC autorotation bailout can be activated.
Please note that several frames must be missing or invalid before the failsafe is activated in our flight control units.
Please note that as soon as a valid frame is received by our flight control units, the failsafe is deactivated.
Please note that the thrust and energy of the motor is removed for SAFETY reasons towards people, animals and things and we will NEVER mondify this feature.
Please note that thanks to the one-way bearing, if the signal comes back and you regain control of the model, even if the soft start is active you can control the model and land it using classic autorotation maneuvers.
PS: We have just tested an old Brain (1) flight controller with the latest available firmware (3.2.060) using a T16SZ and Futaba R70008SB receiver and switching off the transmitter the Fail Safe brings the throttle to zero as it has always been since our flight controllers were released. If your old flight controller Brain (1) behaves differently, you probably have not set the Throttle In and Throttle Out values correctly.
If the ESC governor is used, the ESC autorotation bailout can be activated.
Correct - that's what i thought.
Please note that several frames must be missing or invalid before the failsafe is activated in our flight control units.
Correct! I know. I Agree.
Please note that as soon as a valid frame is received by our flight control units, the failsafe is deactivated.
Correct, and it doesn't change a fact, that in the situation it works right now, the motor is cut off, and needs to spin up... It takes time, which i might not have being perhabs on the height 5 meters AGL.
Please note that the thrust and energy of the motor is removed for SAFETY reasons towards people, animals and things and we will NEVER mondify this feature.
OK, I Acknowledge, but if I might ask, please explain me, what is a good of CUT over HOLD in the SAFETY reasons which You are talking about?
Because, what good is HOLD over a CUT - I've explained already.
Twice:)
Please note that thanks to the one-way bearing, if the signal comes back and you regain control of the model, even if the soft start is active you can control the model and land it using classic autorotation maneuver
Right, but still, there could be not enough time (related to altitude) to properly and safely autorotate, and moreover, autoratation landing on ploved field or bushes is extremely unlikely to be successful.
So perversly speaking, please note that autorotation is NOT normal flight mode (except for training of course), therefore it sholud be avoided rather than provoked.
please explain me, what is a good of CUT over HOLD in the SAFETY reasons which You are talking about?
Electrically powered models have no clutch and the electric motors in our models have a high torque that can do damage even at low rpm (ever heard of the destructive "chicken dance"?).
So perversly speaking, please note that autorotation is NOT normal flight mode (except for training of course), therefore it sholud be avoided rather than provoked.
Fail Safe is NOT normal flight mode as the resulting autorotation.
Electrically powered models have no clutch and the electric motors in our models have a high torque that can do damage even at low rpm
Throtle HOLD, and throttle CUT is exactly the same state regarding to actual power of the electric motor - it is ZERO.
The motor IS NOT running in both cases.
The only difference is how fast the motor can start.
Beside that, with ICE there is exactly the same problem: I can add power to the engine running idle (not to be confused with idle-up!!), not to completly shutted off.
(engine running idle - means running slow, not transfering any power through clutch)
So still: what is the advantage of CUT instead of HOLD?
Don't get me wrong, I really try to understand Your reasoning, but so far - I'm doubt.
(ever heard of the destructive "chicken dance"?).
Of course. It is usually domain of ICE exactly.
The case of for example drained out avionics battery, that leaves throttle servo in high position and doesn't give any control, OR, some disconneted wire (throttle servo, or whole avionics power supply) ... The engine, especially nitro engines (self-ignition - no eletric spark needed to run) can then run for themselves no matter what.
(actually there ARE some methods of securing against this, but - it's not the point here).
I cannot imagine chicken dance in electric powered helikotper made any other way, then "intentionally" by the pilot (crashed the model, but refrained to click hold - and YES - HOLD, not CUT - why? Because it's easier - the HOLD button is the easiest one to use - just like Rescue. CUT - I use it when i land, no intend to fly anymore, going to unplug the battery(eletctric), or refuel (ICE)).
So again: when i lost RC link, and there will by failsafe set to HOLD - there will be NO chicken dance.
No way!!
You know, it's a little bit of similarity to adult aviation: when You have some problem, shutting down the engine and forcing yoursefl to make an emergency landing is rather the last, than first thing to do.
Avaite -> Navigate -> Communicate - heard about that?
🙂
So again and again and again, please convince me, that there is actually legitimate reason to have CUT-OFF instead of HOLD in a fail-safe situation.
We do not want to convince anyone.
If you want to be able to use the autorotation bailout with our FCUs even after a fail safe, you just need to use the governor bailout function of our FCUs, which also allows during a fail safe to totally remove power from the engine and avoid the risk of a chicken dance in case a fail safe is prolonged.
If you do not want to do this, it does not depend on our flight control units.
The Throttle Cut and Throttle Hold values (whether they are the same or different) are set in the transmitters and associated to different switches and when the communication between transmitter and receiver is interrupted (Fail Safe), the receiver is not able to know which Throttle Cut and Throttle Hold values are and which switch of the transmitter has been actuated. Different brands of receivers automatically set the Throttle value to zero (normally the throttle value during binding) in case of a fail safe, regardless of whether the same or different Throttle Cut and Throttle Hold values are set on the transmitter.
In order to do what you are asking for, a new value "Throttle Fail Safe" in the flight control unit but in this case there is the risk that some user would set a high value and in case sooner or later he would turn off the transmitter before powering off the model the carbon blades would start and could hit and hurt him. Also this is a risk to be avoided because it concerns safety.
We do not want to convince anyone.
OK, I acknowlegle, but remember, it was me, asking about it.
🙂
In order to do what you are asking for, a new value "Throttle Fail Safe" in the flight control unit but in this case there is the risk that some user would set a high value and in case sooner or later he would turn off the transmitter before powering off the model the carbon blades would start and could hit and hurt him. Also this is a risk to be avoided because it concerns safety.
Alright - that seems logical.
It really seems, though I'm not convinced anyway.
So, this is my last question:
How is that possible, that with Old Brain (Brain1 as You may say) there was NO such risk, (as You describe above), but i does exist with Brain2?
(well, as I said in the begining, identical configuration with Brain1 works just fine for me!!)
Do You assume, that Brain1 was used only by smart people, and Brain2 is sometimes used by idiots?
🤣 😎
Already explayned:
PS: We have just tested an old Brain (1) flight controller with the latest available firmware (3.2.060) using a T16SZ and Futaba R70008SB receiver and switching off the transmitter the Fail Safe brings the throttle to zero as it has always been since our flight controllers were released. If your old flight controller Brain (1) behaves differently, you probably have not set the Throttle In and Throttle Out values correctly.
Well... I just checked that too and You are ONLY partially right.
PARTIALLY.
Just take a look at the movie:
https://www.youtube.com/watch?v=InIzhv5_HRI
As You can see:
1. the throttle values are set correctly
2. firmware version is the same.
3. and - YES - Brain actually sets the throttle to CUT, BUT it doesn't do it immediately! It takes some time, between these events
- signal loss
- set failsafe with throttle HOLD
- set failsafe with throttle CUT.
And that behaviour is quite OK.
Moreover, as You can see, I can even set any servo in any position I want (doesn't matter whether I want and should do that, or not - IT IS possible).
In Brain2 whereas, the throttle is set too CUT position IMMEDIATELY, and all the servos stay where they are (no matter what I set in FS in RX).
Want another movie with Brain2 behaviour?
Sure. Just say and I will make it tomorrow.
As already explained, the Throttle behavior in case of Fail Safe of all our Flight Controller Units (old or new) has always been the same (same firmware routine used) since we made them available on the market several years ago and has never been changed.
We have already explained that some receivers (including Futaba receivers) set the Throttle value to zero in case of Fail Safe, which is normally the Throttle value of the transmitter during binding or the value set in the Fail Safe menu of the transmitter or set in the transmitter's failsafe menu.
We have also explained that our receivers, in order to prevent short term disturbances from bringing the Throttle to zero, activate the Fail Safe only after several frames are missing or invalid.
On the other hand, Futaba receivers (unlike other receivers such as Spektrum receivers), as soon as only one frame is missing or invalid, activate their failsafe by bringing the throttle to the value recorded during binding or set in the transmitter's failsafe menu.
Therefore, if you are satisfied with the behavior of your old flight controller Brain (1) because in case of a fail safe of very short duration (glitch) the throttle is not immediately set to zero, this does not depend on our flight controller but on the receiver setup. It depends on the Throttle value recorded during binding of the receiver or set in the Fail Safe menu of the transmitter.
If you want the same behavior of the old flight controller also with the new flight controller, re-bind the Futaba receiver connected to the new flight controller with a different (higher) throttle value or change the Fail Safe Throttle value for the active model in the transmitter.
As already explained, the Throttle behavior in case of Fail Safe of all our Flight Controller Units (old or new) has always been the same (same firmware routine used) since we made them available on the market several years ago and has never been changed.
As I said - that's not truth.
But lets move right along:
We have already explained that some receivers (including Futaba receivers) set the Throttle value to zero in case of Fail Safe, which is normally the Throttle value of the transmitter during binding or the value set in the Fail Safe menu of the transmitter or set in the transmitter's failsafe menu.
Like i already said - that is also not truth.
In these two helicopters i mentioned about, there are two identical Futaba receivers. I also switched the receiver that is connected to the Brain2 (which i have FS problem with) to exlude receiver-related issue.
And actually ineed - that's not receiver fault.
We have also explained that our receivers, in order to prevent short term disturbances from bringing the Throttle to zero, activate the Fail Safe only after several frames are missing or invalid.
On the other hand, Futaba receivers (unlike other receivers such as Spektrum receivers), as soon as only one frame is missing or invalid, activate their failsafe by bringing the throttle to the value recorded during binding or set in the transmitter's failsafe menu.
Oh now you are saying this... Here is what You said before:
Please note that several frames must be missing or invalid before the failsafe is activated in our flight control units.
So how about that??
Are you actually trying to explainin anything, or are you playing around with the convenient answers that send the customer to /dev/null until you are pushed to the wall by hard evidence in the form of a movie?
And what does it even mean "Out receivers"??
We are talking about Futaba receivers from the beginning.
Oh yes! I have some other experiences with other receivers, for example with Graupner HOTT.
And I didn't even mention about it.
Gues why...?
Because in that case, failsafe worked just as I expected!
It worked properly!
That's why!
Therefore, if you are satisfied with the behavior of your old flight controller Brain (1) because in case of a fail safe of very short duration (glitch) the throttle is not immediately set to zero, this does not depend on our flight controller but on the receiver setup. It depends on the Throttle value recorded during binding of the receiver or set in the Fail Safe menu of the transmitter.
If you want the same behavior of the old flight controller also with the new flight controller, re-bind the Futaba receiver connected to the new flight controller with a different (higher) throttle value or change the Fail Safe Throttle value for the active model in the transmitter.
And there we go again... I told You with my previous post: Want movie with Brain2 - just ask. I will record it and send it.
NO!
Instead you just have to stick to some imaginary fact, that is just NOT on the movie I send.
You think it is just not in our interest to really help me (or at least try) - no no. First of all, You just have to assume, that it is me, who did something wrong.
But it isn't so. This is You who is wrong, not me, and right now I will show You exactly where You are wrong.
So here we come to the point: You are genius engineers. You have created a brilliant FBL system.
(generally - yes, that's what I think)
But something like customer service is just a fake.
The bottom of meter of shit in the swamp.
And okay - I'm not satisfied, but it's good to know.
I just know from now that FBL Brain is something I take as it is, from the shelf, from the supermarket and either I like it, or I manage it somehow, or throw it in the trash.
End of story.
What do you think ... Now I will record another movie in which I will prove that the FS is set identically on both receivers (Identical receivers !!!), and then you will say that one of the receivers is faulty?!?!
And if I make another movie for five receivers, you will come up with another fairy tale!?!?
I do not care!
I have a solution.
I connect the ESC signal cable directly to the receiver.
Oh yes - that brings another risk: if something wents wring in communication between receiver and Brain, I totally loose control over the model, and the motor will run at full speed ...
... unless I manage to click hold in time.
Well - yes, such a risk exist.
And guess whose fault it will be if an accident occurs because of that.
Whether mine - because I tried the best I could to ensure safety, or yours, because YOU SAID that you were trying to ensure safety, and in reality didn't even bother. You just assumed that the stupid customer doesn't even know what is he talking about.
This is not an adult aviation - there will be no NTSB investigation here.
But the RC models community will judge it and it will be merciless.
And THIS. This is the point, where You are wrong.
Maybe we'll never know.
And i really hope so.
(Yes, I really do! The safety of me, my colleagues, the public, and ultimately my models is more important than proving my point.)
Nevertheless your attitude in this situation, your disgustingly puffed-up and condescending attitude towards the client, is reprehensible!
Below any criticism.
Now you can delete this post, the whole thread and ban my account - looking at your overall attitude I won't be surprised.
I already have my own copy and will distribute it wherever I can.
I whish you luck.
Obviously our previous explanation was not sufficient.
It is not enough to swap the receivers because as explained with Futaba transmitters there is not only the Fail Safe recorded in the receivers during binding.
There are also Fail Safe values set in the transmitter.
In transmitters each model has its own set of values set in the various parameters. Changing the model changes the parameters.
So you have to load the model you are using the old flight control unit with, go to Linkage => Fail Safe and write down the settings.
Then you have to load the model with which you use the new FCU, go in the menu Linkage => Fail Safe and set the same values of the other model.
At this point you will see that the behavior of the old and the new controller is identical (and this is not in "theory" but as we wrote to you having re-tested and re-verified with old and new controllers: "using a T16SZ and Futaba R70008SB receiver and switching off the transmitter").
Obviously our previous explanation was not sufficient.
Oh really...
It is not enough to swap the receivers because as explained with Futaba transmitters there is not only the Fail Safe recorded in the receivers during binding.
There are also Fail Safe values set in the transmitter.
In transmitters each model has its own set of values set in the various parameters. Changing the model changes the parameters.
So you have to load the model you are using the old flight control unit with, go to Linkage => Fail Safe and write down the settings.
Then you have to load the model with which you use the new FCU, go in the menu Linkage => Fail Safe and set the same values of the other model.
Are You serious?!?! DO You really think I don't know about it?
Well - as I said - You just treat me as I'm an idiot.
And guess what that means.
Just pathetic.
At this point you will see that the behavior of the old and the new controller is identical (and this is not in "theory" but as we wrote to you having re-tested and re-verified with old and new controllers: "using a T16SZ and Futaba R70008SB receiver and switching off the transmitter").
Yeach... Well maybe - there is ONE LAST chance, that You actually did the tests, and it gave a results as You say.
It's possible, that it's true for the receiver You are talking about., means R70008SB.
I don't know - I don't have such a receiver.
However as I said, I use Futaba R3004SB.
