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.

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.

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..

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

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 :-(

Oh ok, understood!

Comment deleted

Do you have the problem? What can we do?

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

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.

Did you try to change this constant:

define THRCHK_DEADBAND 16

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

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.

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/

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

Fixed in r1943