Hi there !
I also bought the stock 9x Module & cheap Tx (nooob, wasnt even aware to look for fasilsafe behaviour)…
But somewhere else i found a good (correct me if not) solution:
I used a SIMPLE failsafe device on Channel 3 (THR) to output a value of 70 below the normal THR_LOW value and set my failsafe trigger accordingly…
Only problem was that i set the faisafe device to a very low value (900, and my 9x THR_LOW is 1070) and found APM to ignore that value. I assume APM ignores “far beyond calibration” values and set the failsafe value closer to the calibrated minum and VOILA it works.
Question: why can my cheapo failsafe detect a problem when the APM cannot ??? Is this a bug (or feature) in the PPM decoder ? can one switch this behaviour to be Turnigy 9x failsafe friendly ?
Nevertheless i saved $50 for the FrSky and it works !
Greetings,
Ender
P.S. If i am doing something dumb here please let me know, want to protect my investment !!!
If you configure your system according to the documentation, the APM will detect signal loss quite reliably.
[color=#00BF00]This is now the third time that I have to point you to reading the documentation before posting a support question. If you post another support question which could be easily answered by reading the documentation, I will block your account for 14 days.[/color]
Well give me the red card if you feel like it, i feel mistreated anyways.
You repeatedly did not try to read my questions sincerly and i DID read loads of stuff before asking.
The answers you gave at first in sevral ocasions (propably increasing your “idiot question count” for me were not hitting the mark. Again: in those other ocasions YOU did not take your time to read my Question.
Same thing here, it is NOT simple for Turnigy Users to trigger failsafe for standard setups.
In fact if you would read the thread i cited or google you would find out that is is deemed impossible.
I am talking about STOCK 9x, NOT FrSky.
So treat me like an idiot if it makes you feel good but it would help MUCH more if you would try to read my Questions and if you dont have the time simply ignore my messages.
Maybe, you are asking unclear questions… But anyways, I do not believe, it’s the moderators’ task to start googling to understand asked questions. It’s the users’ task to google, read the documentation and then put their questions in a way that they are easily understood. Please remember, that you are the one who wants something (an answer), so you should comply with the respective requirements.
Anyways, I happen to have a TGY 9x and before I flashed it with Open9x firmware and started to use OpenLRS, I used stock…
I want to point out that I am only spending an effort to explain this to you to prove that your problem is easily solved using the documentation.
What I did was set the failsafe of the 9x while pushing the throttle down pretty hard, so it would go to a value which would not be achieved in normal operations. I set this value then as throttle failsafe value as explained in the Copter documentation. YOu can get a similar effect by “miscalibrating” your 9x sticks before setting failsafe and recalibrating them properly afterwards.
But you can even much easier create a pseudo-failsafe by setting your flight mode selection switches to the position for RTL and then save this as failsafe value in the 9x.
Stefan,
it is not your task to do ANYTHING about my post, i am not that arrogant.
I am not in the power to command anyones help but i politely ask for it.
And i do not care if you are a mod or not.
But IF you decide to give me an answer, let it be a sensible one and not waste our time.
I also cited a thread in this very forum and i feel (and 99% of all forum users will agree) that this makes more sense then repeating all that is in there.
If you do not like links or google thats fine with me, just dont blame me for it.
And to assume i “did not read the docs” if i clearly did that and it was not in there or i was unable to find the info is unfair.
I am not perfect and will not understand or misunderstand or simply not find info in the docs.
But to assume in the first go that i did not even try is simply not a good attitude whoever you are.
Getting back to the point:
If you DO care to gather info before posting you will learn that either you had a VERY early 9x (Rx) or you were using a FrSky or Orange module.
The stock 9x with its recent V2 Rx will NOT act as you pointed out.
(Its a slight twitch / fault / lazyness in the Rx)
Thats not an assumption or ill-read-docs, thats a fact and anyone ACTUALLY OWNING a current device can prove that.
Again i can only offer you to google and or read but i would not know what sense that could make for you.
I specifially asked about the problem of the PPM decoder noticing a fail compared to a cheap-o device that can do so.
If you can contribute to this question (and be it a link to somewhere whre i can find more info) i would be thankful.
To get to the point - if your RX does not have any failsafe function and simply keeps outputting the last PWM, then the only way of detecting that is by checking if the PWM stays identical over a time. For a cheap system like the Turnigy, the PWM is practically always fluttering a bit, so if it’s steadily the same value, that could be an indication of a problem. The APM’s PPM-decoder AFAIK does not check this hence can’t recognize this as a failsafe condition.
But for anyone to be able to answer the question in the topic title, you would have to provide technical details, such as a signal recording from your RX out and a detailed description of the technical function of your failsafe device.
Hello Stefan,
the $3 Failsafe immediatly recognizes when i turn off the Tx.
The APM acts as if the last signal is repeated forever.
So i (and many other guys in the world) were indeed under the impression that this is a hopeless case apart from such heuristics you propose.
And i would not deem that way of detection really failsafe btw.
But one cool guy just tried it out with a cheap failsafe and the failsafe WAS able to detect the signal loss instantly (for the human eye, so at least within 1/5th of a second).
For one i do not think that this device has heuristics (and someone dares to use it) and on the other hand that detection time is too short to work even if such risky assumptions would have been applied.
I bought the same Failsafe and it works BUT i also dug in my RC stuff and found a 25 year old “HiTec” Failsafe from one of my gas driven boats.
Guess what: it also works.
So there must be a twitch in the signal when Tx is lost that is detectable by very easy means.
That sound pretty much like the PPM decoder is the “bad guy” repeating values if the signal is not allright.
I learned on the arducopter site that somewhere there is an archive of different PPM decoder firmwares but the link is dead.
As for the technical details (And people who might be ABLE to help)
Others tried the same setup too and i have not read of ONE case where the simple failsafe (of whatever brand or make) did NOT work and the only needed Hardware is a 9x (or 9XR) and the v2 8 channel receiver.
Its a widespread problem as the 9x is so dirt cheap and the subject says enough for people in the know and more is lost for people who don’t.
MAYBE the PPM decoder has no error handling except repeating the last signal which would be close to criminal.
I do not know a wide range of Rx’es, but the ones that i do know hande the Failsafe by themselves outputting a preset value.
THIS is how throttle failsafe works in its core, no PPM decoder magic involved.
But maybe there are other Rx strategies (or lack of them) that ARE handled by the PPM decoder, i cannot know this.
I do not have the tools at home to deliver signal logs but i hoped that someone reads here who has a KNOWLEDGE of the PPM decoder and where to find variations or how to modify and rebuild it.
That is obviously not the case so i am out of luck.
I think, you are missing the point here. The PPM encoder’s task is to encode a PPM signal. It’s failsafe function is to drop the throttle channel to 900 when the PWM signals stop, i.e. are not present any more. THAT is the failsafe function of the PPM encoder.
If you have an RX which just continues outputting the last PWM from before the signal loss, that’s not the task of the PPM encoder to detect.
If an operator uses such an RX, the operator did not read the hardware and accessory recommendations for building UAS based on the APM.
Normally, with those cheap RXs you don’t need heuristics to detect a radio failure. On failsafe, the last PWM value is usually repeated exactly and identical which usually never happens in normal operation. The normal pulse width in PWM is between 1 and 2 ms so if I take your estimated 200ms reaction time, your failsafe would have time to check like 50 or so pulses and if they are all identical, decide that it’s a failsafe condition.
Hi !
I don’t agree on your opinion on how the cheap-O failsafes may detect signal loss as this would be really dangerous IMHO.
Nevertheless there is nothing more to add from me or from you at this point and i will either live with my failsafe construct or study details of the PPM module or find someone who actually knows about that thing and helps me.
I will accept this as anwer as there does not seem to be an answer here that solves the problem.
Greetings,
Ender
P.S. is not entirely true and misleading to other readers. If there IS such state may makr this thread as or the like…
Hello everyone, I am adrian from Spain, greetings to all.
I’m a newbie with the APM, I just do some checking with my oscilloscope and my three 9X8Cv2 receivers (purchased on different dates).
All match same behavior maybe can be used to trigger the APM failsafe function:
After turning off the transmitter or directly extracting the transmitter module, immediately causes all the PWM trains from channels 1,2,3,6,7,8 go to GND (dutty 0ms), while channels 4,5 remain the same dutty cycle before turning off.
All channels recover the appropriate values when the transmitter back on.
Hello villamay !
Thank you for that info !
I guess thats how the cheap Failsafes on Throttle (channel 3) can detect a problem.
Again the Question is why the PWM decoder on the APM fails to detect signal loss.
IMHO its not a good idea to simply repeat after failure (from all channels except 4 & 5).
But knowing this there is hope that someone can fix it by cleaning up the PWn code.
Meanwhile my $3 Failsafe does the job but its always good to get rid of unneeded hardware…
[color=#00BF00]Joined threads together.
Please do not double- or cross-post the same issue.
Please do not add issues to an existing thread but open a new thread for separate issues. [/color]