Throttle alarm does not work on 9XR

[GoogleCodeExporter]

When I received my 9XR i noticed that the throttle alarm would always come on 
at startup, even if I had the throttle turned off. I don´t use throttle alarm 
normally, so I just turned it off and thought nothing more of it. Since then I 
have seen several complaints on the varying forums that people have problems 
with the throttle alarm. I checked my transmitter yesterday and it turns out 
that the raw values for the throttle stick show slightly more extreme values 
when pushed to the left and right and held down than what it does when held 
down in the middle (i.e. throttle off).

My assumption is that the calibration uses the most extreme value.

In practice the less than perfect stick of the 9XR breaks the throttle alarm 
feature. I hate to fix hardware flaws with software, but I do not really see 
any other way around this than to update either the calibration function or 
make the throttle alarm a bit less sensitive. The latter sounds like the best 
solution to me.

I will update the case with the exact raw data values from my transmitter when 
I get home tonight.

Original issue reported on code.google.com by kjell.kernen on 16 Jan 2013 at 11:27

[GoogleCodeExporter]

I have 9xr with latest version of open9x and my throttle alarm seems to work 
just fine.  

When I calibrated I only moved one axis at a time, and not moving my sticks 
into the corners.

Original comment by parsada...@gmail.com on 16 Jan 2013 at 5:24

[GoogleCodeExporter]

I have now tested my 9xr. The pot values are quite unstable. 
The end values for channel A2 fluctuate between 0266(middle)  and 028E (right 
corner) at the worst. 
That is a difference of 24h = 36.
I looked in the code and the compensation variable is set to 16 (DEATHBAND).  

No wonder people are having problems .

Perhaps a separate compilation flag for 9xr would be a solution to the not 
quite compatible hardware..

Original comment by kjell.kernen on 16 Jan 2013 at 5:50

[GoogleCodeExporter]

Should I understand that the sticks can only send 72 different values? It's a 
big regression then!!!

Original comment by bson...@gmail.com on 16 Jan 2013 at 7:55

[GoogleCodeExporter]

No, you missunderstan me.
I have made a number of tests where i have turned the radio on and off and 
repeatedly set the throttel stick in the lowest position. I have tried to hold 
it in different positions sidewise.

The lowest value i have seen is 0266
The highest value i have seen is 028E

So the variance is 36

In the alarm function a constant is used to compensate for variance. The 
constant is called DEADBAND of something similar. I think the value was 16, 
which explains why the throttle alarm does not work.
I do not know why the values vary more than on my 9x (around 10 steps on 9x), 
but they do.

The resolution:
A quick test of the upper limits show around 05C0
That gives a resolution of over 800 decimal steps for the throttel channel.

My 9x has better resolution, about 07A0 steps in hex.

Let us hope the potentiometers are better mechanically than the older ones. The 
measured data seems worse :-(

Original comment by kjell.kernen on 16 Jan 2013 at 9:19

[GoogleCodeExporter]

Oh ok, understood!

Original comment by bson...@gmail.com on 16 Jan 2013 at 9:35

[GoogleCodeExporter]

Original comment by bson...@gmail.com on 18 Jan 2013 at 9:59

• Changed state: Duplicate

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Do you have the problem? What can we do?

Original comment by bson...@gmail.com on 7 Feb 2013 at 7:33

[GoogleCodeExporter]

Mine doesn't have this problem. I didn't flash it with latest open9x though...

Original comment by bson...@gmail.com on 7 Feb 2013 at 7:34

[GoogleCodeExporter]

Yes, my transmitter has the problem. According to a lot of forum posts,  I am 
only one of many who has the problem. 
It has nothing to do with open9x. The throttle alarm does not work with the 
original firmware either.  The problem has to do with the gimbals. On some 
tgy9xr you get a higher or lower value from the pot in the corners,  than in 
the middle position. 
The easy solution is to change the alarm function and increase the tolerance.  
This does not solve the problem,  it only hides it. 
The better solution is to change the calibration functions so that values from 
the corners are disregarded in calibration.

Original comment by kjell.kernen on 7 Feb 2013 at 8:27

[GoogleCodeExporter]

Did you try to change this constant:

#define THRCHK_DEADBAND 16

We could have a new option in the Makefile for handling this problem ...

Original comment by bson...@gmail.com on 7 Feb 2013 at 8:36

[GoogleCodeExporter]

When I use Linux I am generally using Ubuntu. That means that am not able to 
compile open9x to binaries  any longer (worked until about March). As I 
understand it you use Fedora and an older version of the compiler than is 
installed by default in Ubuntu.
I never got around to trying to fix the problem since the open9x simulator 
compiles just fine.

As to the idea of increasing the deadband constant. That would suppress the 
throttle alarm, but there is a catch. On my 9x a measured the resolution on the 
throttle channel to 1954 steps(I need to check that, seems very high). That 
means that the deadband is 16/1954 = 0.008, i.e. less than one percent. That is 
OK. 1% throttle will not cause problems. 1% will never start a motor.
Increasing the deadband to 36 has the effect of having the alarm go off at 
about 1.8% throttle output. Perhaps acceptable, but a bad thing.

On my 9xr the throttle channel has a max resolution of only 858 steps (seems 
very low, have to check this again). If you increase the deadband to 36 steps 
the impact is 36/858 = 0.042. This means that the alarm will not go off until a 
throttle channel output of over 4%. That is kind of high.
On the other hand the gimbal problem always causes my transmitter to output at 
least 4% on the throttle channel after calibration. That also works after ESC 
calibration.

I absolutely think you should add a 9xr compilation option in companion. If you 
do that I can have a look at either increasing the deadband or (preferably) 
change the 9xr stick calibration.

Original comment by kjell.kernen on 7 Feb 2013 at 9:45

[GoogleCodeExporter]

A friend of mine has made me some packages of the right versions of the tools 
for ubuntu 12.04, you might want to try them:
http://andrebernet.ch/divers/index.php?path=avr-gcc-4.7.2-ubuntu/

Original comment by bernet.a...@gmail.com on 8 Feb 2013 at 10:56

[GoogleCodeExporter]

I added new compilation PCB options:
- PCB=9X         => define PCB9X
- PCB=9XR        => define PCB9XR
- PCB=9X128      => define PCB9128
- PCB=9XR128     => define PCB9XR128

PCB=STD / STD128 are kept for compatibility

Original comment by bson...@gmail.com on 9 Feb 2013 at 8:20

[GoogleCodeExporter]

Fixed in r1943

Original comment by kjell.kernen on 10 Feb 2013 at 9:37

• Changed state: Fixed