Might want to check the throttle cord connector for a loose connection.

If I'm not mistaken, you can diagnose this condition with opening the joystick calibration software utility and test the axis while moving the cord and connector. Any inconsistency will confirm this.

Found my Saitek X45 throttle cord had a loose connection at the connector. (The throttle connector which connects to the joystick's DB25? side port.)

To resolve, I sliced open the permanently sealed plastic body of the connector and cut and respliced the cord to the connector. Use tiny shrink tubing prior to soldering the wiring. Resplicing was a very tedious task. I then permanently adhered the connector to the joystick with a couple of long zip ties. Granted, I could have used liquid nail or heated glue.

Another off-topic issue I had with the X45, the joystick X/Y axis would stick due to the very stiff spring. Another hindering factor to the sticking, was the plastic parts not sliding well.

The Saitek X36 joystick was, by far, the best quality joystick Saitek ever made. Doesn't have 64 bit drivers for Windows, but still works in Linux - but the drivers contain a bug.

Thanks for the long comment! However, I don't think that the problem is caused by joystick itself because it works fine in other simulators like DCS: A-10C.

Oh. Well, I just noticed I placed an order for a Saitek X52 Pro joystick with rudder paddles and will test this when I get them tomorrow. Seeing this X52 device was first introduced in 2006 (or even 2003?), would wonder why such a bug is still even persistent to this day!

I'll follow-up shortly within a day or so with my experience.

Also, make sure you uninstall Saitek software and allow ARMA to explicitly configure and use this device. I noticed or seem to recall, within ARMA 2, if the Saitek profiles software were installed, Saitek software would conflict with the AMRA's configuration of the axis control. (I think the Saitek drivers are fine, and I currently use the Windows default drivers for my current Saitek X45 joystick.)

Like I said, I'll follow-up shortly. In the meantime, you have a few bits more of advice to maybe render your controller useful. ;-) And if this is a real bug, based on the extreme popularity of the Saitek X52 (Pro), should likely be fixed.

Same here X52 throttle is seen as Z+ and Z- so you only ever get half the throw. It should just be seen as one axis Z and report 0-255.

ok after much experimenting ive found you get the full throw of the throttle on a logitech X52 if you map both Z- and Z+ to raise collective and leave lower collective empty. You can notice it by watching the (dont know name) small needle in the smaller dial in the lower left dial (RPM) in the littlebird.

Thanks for the tip Larrow! I was trying to adjust the throttle last night and something like that came to my mind, but I had no time to test it actually. Gonna try it soon!

The regular collective functions poorly too – when throttle control is at 100 %, it's about 75 % ingame, and when the throttle control is at 0 %, it's about 25 % ingame. It makes landings almost impossible, because chopper tends to flip upside down or slide downhill suddenly just after the touchdown. Only safe place to land is land or roof that is in 0° angle compared to the Earth. In any other conditions, the chopper either starts to slide down the hill or flips upside down and you can do nothing to it because when it begins, pulling the stick to opposite direction with or without full (well, 75 %) throttle has no effect because the chopper wheel is like glued in the ground.

Ezcoo:

1. I think there's already a bug open for something such as, "Cannot get full throttle with joystick" or similar.

2. Trying to land on a hillside or angle with hover on, will tend to flip the chopper upon landing at the angle. The trick is to switch-off hover as soon as you've landed on an angle, or not use auto hover at all while landing on angles. (You'll notice, if you leave on hover while landing on an angle, the chopper will tend to want to flip-over. You can still avert the flip, up to a certain point.)

3. On take-off from angles, first warm-up the chopper to encourage a fast rise. Apply force in the opposite direction of the incline or angle using the joystick, and throttle-up fast with a warm motor. Once the chopper rises, immediately relax the joystick as the chopper will reduce it's incline almost immediately.

4. I'm not sure if there's a bug open or a bug pertinent for auto hover performance while landing.

I should have a Saitek X52 Pro & Rudders within six hours today, and be able to report something within 12 to 24 hours.

Larrow: Thanks Larrow for the info, as it will help troubleshoot asymptomatic scenarios.

I have tested the Saitek X52 Pro including Saitek Pro Flight Rudders, and the throttle axis when assigned or associated to the "Collective (Analog)", the throttle appears to function similarly to keyboard commands.

The install process I have used, I first downloaded & installed the latest Saitek drivers for both devices as Windows 8 didn't detect much by default without Saitek's drivers. Also, likely only Saitek drivers will configure such optional features as the lights. During the Saitek driver install, Saitek thoughtfully opened the joystick and rudder calibration menus. I DID NOT install Saitek Profiling software, as it is known to conflict with ARMA 2 controller assignments. I then tested in game or flight simulation, counting seconds after using full collective up until I reach a 50 ft/km high. I again tested using keyboard collective keys, and found the heights reached to be seemingly exact between the two joystick and keyboard keys. I roughly guessed going down was also extremely similar.

A better test for collective lower; hover about a mile or so up, and then compare the time for a safe descent (exact altitude in ft/km above ground) for the down collective keys or joystick associations.

I did notice, assigning the joystick throttle to the first collective assignment option within the AMRA 3 Controller Assignment menu (ie. NOT "Collective Analog" within Controls > Helicopter) only appeared to give me partial throttle.

This sounds like an already known issue. Also, I just installed the latest Saitek Profiling software and will check on my next boot into Windows, whether the Saitek Profiling software continue to conflict with ARMA 3. (More exactly, ARMA 2 will not recognize device axis while the profiling software is installed.)

My suggestions, if you have Saitek profiling software installed, try uninstalling it, and assign the throttle to the Collective Analog axis. My model or Unit ID at the bottom of this joystick/throttle, M124901853. Doubt if this number will help to rule out hardware model revisions at the consumer information level, which might have also alleviated this issue.

If this problem still persists, you'll likely need to wait for others to duplicate your issue.

OFF-TOPIC: As far as the performance of this Saitek X52 compared to my old X36 and X45, although I miss the rudder control embedded within the throttle handle, the X52 seems to give me more exact control while flying/aiming or not realistic flight dynamics. The X36/X45 provided more real flight dynamics, but an extremely more difficult time aiming or landing safely at an exact spot. After a while and against my initial impressions, I'm starting to like the X52 & rudder pedals a little more than the older controllers, as long as I don't break a leg in the future.

Bug #7416 should likely be marked a duplicate of this bug, leaving this bug open based on better description or responses?

Bug #7416 MIGHT be a duplicate of this bug, suggesting closing this bug in favor of Bug #7416, based on this bug report's feedback.

I've noticed this same problem with my Saitek x52 (non-pro).

I had Z- mapped to "Collective Increase (Analog)" and Z+ to "Collective Decrease (Analog)". While this seems strange, for whatever reason Saitek designed this stick to be at a value of 255/255 when in the 0% throttle position and 0/255 when at the 100% throttle position.

While in this configuration, 50 percent was neutral (gravity caused decrease in altitude), 25% started decrease in collective, and 75% started increase in collective. From 25% throttle to 75% throttle it was neutral and no increase or decrease in collective was observed (gravity naturally caused slight descent).

I applied the fix above to map both Z- and Z+ to "Collective Increase (Analog)" and found this to function as expected with 0% being 0% throttle applied, 50% throttle being 50% throttle applied, and 100% being 100% throttle applied. However at first configuration, something strange happened.

When you map Z+ above Z- in the keybinds for "Collective Increase (Analog)", the throttle behavior is reversed (0% throttle is 100% throttle being applied and vice-versa). When I switched the two keybind positions (Z- being atop), the throttle functioned as expected. I'm not sure why this is. If anything, I would have expected that there was throttle applied at 100% all the time or that a deadspot would be present around 50%.

Thanks for the workaround, definitely upvoted.
Just thought I'd provide some food for thought...

Quote PTW-105 : "When you map Z+ above Z- in the keybinds for "Collective Increase (Analog)", the throttle behavior is reversed (0% throttle is 100% throttle being applied and vice-versa)."

If the mapping are going to remain as they are i actually like this. I prefer my collective to be full when pulled towards me. I can then reverse this in the settings for aircraft.

@ rogerx
I am going to have to disagree with your findings on the collective.
To put things into perspective first, I have a X52 (non pro) using driver version 6.0.4.1 and profile version 6.6.6.9. I have never had any problems assigning axis in either ARMA 2 or 3, although I'm am not sure if these inconsistencies exist in ARMA 2 as i have not done much flying in it.
I have used DIView to make sure my X52 is calibrated correctly and that I am receiving no spurious data. Throttle is RAW 0 to RAW 255 and steady.
In game I have +Z and -Z assigned to analogue collective raise as discussed above and analogue collective lower empty. I also have Q assigned to collective raise and Z to collective lower.

Whilst in game with a steady horizon and as little speed as possible :-

KA60 :
There is a dial in the centre console that shows climb and descent (not sure what the official naming is for this display) 9o'clock position is 0 @ 50% throttle, it is also shown in the HUD just to the right of your cross hairs.
At full collective on the X52 my climb rate is +12, if I then hold Q to override with the keyboard this value will decrease to +10.
At collective fully lowered on my X52 my descent will display -8, if I then override by holding Z my descent rate will change to -10.

There is a discrepancy between analogue collective and collective of +2.

climb    descent

X52: +12 -8
keyboard: +10 -10

This discrepancy is Visually noticeable especially when descending. You can see exactly the same behaviour in the Littlebird although the dials are somewhat different.

Can the others reading this thread please test this out as well whether you have an X52 or some other analogue method. Is this a discrepancy for the X52, maybe related to how the axis are assigned, or is this a problem with analogue collective in general.

(Think I covered everything I wanted to. Second time of writing due to account being signed off/session discontinued, and on posting losing everything doh)

@rogerx

"2) Trying to land on a hillside or angle with hover on, will tend to flip the chopper upon landing at the angle. The trick is to switch-off hover as soon as you've landed on an angle, or not use auto hover at all while landing on angles. (You'll notice, if you leave on hover while landing on an angle, the chopper will tend to want to flip-over. You can still avert the flip, up to a certain point.)"

I've flown in Arma for hundreds of hours and almost never use auto-hover. The flipping and sliding of chopper is caused by the malfunctioning collective if its mapped to regular collective in controls, because despite of any setting, with or without Saitek SST or axis tweaks, the collective stays always between 25 % and 75 %. When raw input from throttle is 0 % (tested!), the collective in game is about 25 %. When raw input from throttle is 100 %, the collective in game is about 75 %. With 25 % collective the chopper is almost hovering, that causes the flips and slides because there's a force pulling the chopper up when you land, that makes the chopper to flip (wheels feel like they were glued on the ground, that's why it's flipping) or slide. To my knowledge, it can't be fixed with any SST or axis tuning software because the axis should be extrapolated – raw input can't go under 0 % or over 100 % (I think...) – so only developers can fix it.

@Larrow

I got the collective to work pretty well with the Larrow's tip though, thanks for that! The minimum descend rate is still little bit higher if I press Z, but it's much better now. :)

Title and description of ticket updated.

I performed some testing last night, and found the reason why there is a slowing of the throttle when the Saitek Profiling software is active with ARMA3.

It is likely because both are fighting to provide input/output for the axis. I started to disable the axis within the Saitek Profiling software, the axis which were already successfully configured within ARMA3, and was having some limited success until Windows 8 started crashing. Just prior to the operating system crashing, the Saitek Profiling software was spawning many .NET errors.

I'm going to avoid the Saitek Profiling software, as I've usually done within the past several years for awhile, in an attempt to focus on stability.

Bottom line, disable the Saitek Profiling software until somebody figures out the exact problems with the Saitek Profiling software. For those adventurous, suggest clicking on buttons and axis within the profiling software and selecting "disable" in an attempt to prevent software conflicts. (I'm stumped on the pinky switch, as it cannot be disabled, and enjoy using it as a zoom button. ;-)

Likely, I'll try to send an EMail to Saitek sometime within a week or so, with reference to this bug.

Reference:
DIView
http://www.leobodnar.com/products/BU0836/
http://www.leobodnar.com/products/BU0836/DIView.zip

Im sorry rogerx but i do not have a clue what you are talking about "slowing of the throttle" ??

My X52 works fine in ARMA with or without the profiler running, the only problem is game side where the analogue collective is shifted versus using keyboard on digital collective. There is talk on the forums showing the same thing with banking, analogue does not bank as much as digital (using keys) does. There is obviously something wrong with BIS's conversion of analogue axis to ingame thresholds/values.

Sounds to me like you have a separate problem related to the profiler and windows 8?? Im getting no .NET errors in my system log on WIN7 64 (Home edition).

Yeah, having the Saitek SST / Profiling software on or off has no effect on my system.

On the other hand, while the collective might behave oddly, I have to say that flying with the actual cyclic / joystick feels damn good. I think that it's somehow very responsive and exact compared to Arma 2. And it'll get even better later! :)

I'm pretty certain with being able to reproduce, having the Saitek Profiler software set to an active profile within Windows 8, will provoke a slow throttle or only half throttle when the collective is assigned to collective analog as well. Deactivating the Saitek Profiler, returns throttle to full thrust within the game/simulation. (ARMA2 within Windows 7 here while using the Saitek Profiler software, also has an axis detection issue, as witnessed by others.)

Like I said, I tried going into Saitek's Profiler software and deactivating/disabling axis to determine if Saitek's software was outputting conflicting commands, and that is where I had to cease my troubleshooting due to application and operating system instabilities. :-/

Due to the odd changes between Windows 7 and Windows 8, can only guess some extravagant libraries or functions pulled into the Saitek Profiler software could have been changed. Also playing around debugging alpha quality software is not a good mix. ;-) Only provides more confusion.

As of now, my scenario is off-topic under the current bug description, but will aide others to further troubleshoot their slow throttle problem to determine a solution, or to advise others while debugging, disable any external applications which might provide conflicting data.

Ezcoo: I presume you have Windows 7 as well.

Based on my stated previously known problem, the developers are likely going to request you to confirm your extra data (ie. DIView) without the Saitek Profiling software active. Other than this, the bug description currently looks extremely accurate. And the main bug described within the topic persists on my platform even without the Saitek Profiling software active.

Again, off-topic, but to further clarify.

The likely reason for the instability with Saitek Profiler, is because the Saitek Profiler uses an additional Direct Input Driver. (You'll likely see one or two of these drivers installed while installing the Saitek Profiling software. These Direct Input driver(s) are in addition to the joystick device driver, and not usually required to provide normal joystick function unless the application cannot map to the additional joystick buttons or axis.)

This Saitek Profiler Direct Input driver likely conflicts with many applications, and has a known history of causing application crashes as well as many operating system crashes. This is both, based on my experience with many versions of Windows and can be found searching Google. (saitek profile|profiler direct input driver crash|bug|bsod|"blue screen")

I have tried Larrow's suggestion of binding both of the +Z and -Z throttle axis to the Collective Rise (Analog) and omitting setting the Collective Lower (Analog) to the throttle axis, and the helicopter would rise at 20 ft/minute x 100, but only lower 10 ft/minute x 100. (Corrected 2013-04-20 16:04)

Think the dial Larrow is talking about is the Instantaneous Vertial Speed or Rise dial. (ft/minute x 100)

At a stand still hovering above ground, I see a rise rate of +20 ft/minute x 100 and a lower rate of -20 ft/minute x 100 when using the keyboard.

I get duplicate output with the throttle mapped to +Z and -Z respectively to the Collective Rise (Analog) and Collective Lower (Analog). I am using Windows 8 64 bit with recent drivers with a recently purchased Saitek X52 Pro Flight without the Saitek Profile software loaded. (Or, if you do have it loaded, simply click exit on the icons within the toolbar suffice here to not have it conflict.) I'm also using the Developer version of ARMA 3 Alpha.

From what I'm seeing, I am no longer experiencing this bug without the Saitek Profile software running. With the Saitek Profiler software running, I experienced only getting +10 or -10 feet/minute x 100, on one or both +Z/-Z axis.

If this bug still persists for you, I speculate Saitek may have modified the X52 Pro Flight hardware recently, to provide different values. I do not believe users would see differences between Windows 7 and Windows 8 drivers, but would expect differences in stability concerning the Saitek Profiling software. I have seen the X36F and X45 throttles, provide different values when using the Linux jstest utility.

Linux jstest shows the Throttle axis as Axis Number 2, and moves from a range of -32767 to 32767 here. Bottom of throttle is registering as +32767, while top of throttle is -32767. (Centered is 0.)

Example:

jstest /dev/input/js0

Saitek's Profiler or Programming software makes everything so extremely unstable on Windows 8, I just encountered another O/S reset while the game wasn't even running, so I uninstalled the Saitek application software. I'm on a pretty stable motherboard too, GA-Z77X-UP7 connected through the Intel USB-2 bus. So very likely the Saitek Profiler/Programming Direct Output (or Direct Input) drivers are the problem here. I am unable to troubleshoot with their software any further, until they've fixed it, which is likely never, as it's always been buggy for me. :-/

Ok, closing as "unable to reproduce". Probably was never a game problem.