Disable Throttle Input when A/T is armed

[diegov]

Hi Fellow FSUIPC users,

I am hoping someone can assist me with my query. I am using FSX without Project Magenta

I have built a throttle unit with servos for the autothrottle and I have a small issue that when the Autothrottle is enabled, the actually unit goes a little crazy because the input sensors conflict with the throttle value that the AutoPilot is applying. This results in the thottle unit going back and forth violently.

I know that i need to disable my throttle input by writing to offset 310A. But i do not have any software with logic that can do this, like PM

Ive noticed that FSUIPC has the option to "Disconnect elevator trim axis for A/P". Does anyone know whether it is possible to disable the throttle axis when the A/T throttle is armed from within FSUIPC or maybe Peter, if you do read this, is there any possiblity to add this to your next release?

Thank you kindly

Diego

[Pete Dowson]

I know that i need to disable my throttle input by writing to offset 310A. But i do not have any software with logic that can do this, like PM

You can add logic to FSUIPC using Lua plug-ins, activated either by external evens like buttons and so on, or internal ones.

However, I don't think that is relevant to this problem:

the actually unit goes a little crazy because the input sensors conflict with the throttle value that the AutoPilot is applying. This results in the thottle unit going back and forth violently.

Surely the problem there is that the throttle should simply do what it is told. The "input sensors" are irrelevant as their values aren't being used (or shouldn't be).

Ive noticed that FSUIPC has the option to "Disconnect elevator trim axis for A/P". Does anyone know whether it is possible to disable the throttle axis when the A/T throttle is armed from within FSUIPC

I don't understand. The throttle axis is normally disregarded by FS in any case when the autothrottle is armed. What makes you think it isn't?

Are you sure your motor is not simply reacting to all the silly little throttle changes the FS A/T makes? What you probably really need is a partial smoothing action on the throttle read-outs.

Regards

Pete

[diegov]

Woa! Thank you for such a quick responce Pete and thanks for writing such a wonderful program that has bought my cockpit alive :)

I might have to have a look at LUA to fix my issue.

The problem is absolutely that for some reason arming the A/T does not disengage or ignore my input pots. I believe that FS9 does ignore the inputs once the A/T is armed, but FSX does not. I have also read some documentation that PM will disable the inputs by using 310A, which makes sense as PMs MCP does not use FSX's built in MCP.

My setup is as follows:

My input sensor pots write to offset 089A and 0924 respectively. If i disconnect the servo's and leave my input sensors engaged then place my physical throttle in the IDLE position and then arm the A/T and put it in TOGA mode I can see that as the virtual throttle advances to MAX and as i move my physical throttle near the IDLE mark, the virtual throttles jump back to IDLE again and then try to move back N1. So hence i get this fluterring. If i connect my servos and disable my sensor inputs for the throttle and arm the A/T.. i have no problems. If i have both the Servos AND the inputs connected and i assign a temporary button to set bit 3 of 310A, this works and disables the input throttles from writing to the throttle offsets. This however is not an elegant solution as I loose a button and i must remember to press this button before a press the A/T button.

My understanding is that 089A copies its values to 088C until 310A bit 3 is toggled. So i believe when the A/T is armed FSX does not make 088C read only (if thats even how it works), so as my physical throttle moves to catch up the the virtual throttles it overwrites these offsets with its current position and i get this fluttering.

Again i do not have any software that i can write logic in... IE when A/T is armed set 310A bit 3, so I may have to rely on LUA. I was hoping though if this was a common problem you may include it as a feature request :).

Thanks again

Diego

[Pete Dowson]

The problem is absolutely that for some reason arming the A/T does not disengage or ignore my input pots ...

My input sensor pots write to offset 089A and 0924 respectively.

Ahwhy? That may be the problem. Can't you configure them as normal throttle axes? And why write throttle 1 via the disconnectable offset, 089A, but throttle 2 via the direct offset? The correct pair would be 089A and 0932!

I have also read some documentation that PM will disable the inputs by using 310A, which makes sense as PMs MCP does not use FSX's built in MCP.

And, in any case, PM is disconnecting real throttle axes, not some program interface writing to offsets.

Again i do not have any software that i can write logic in... IE when A/T is armed set 310A bit 3, so I may have to rely on LUA. I was hoping though if this was a common problem you may include it as a feature request :).

No, it is not a common problem. I don't understand how you have an interface program for offsets which can do one thing but not another. Most throttle implementations would use joystick axes in any case.

And it would only be about three or four lines in Lua, and much more elegant. I added Lua plugin facilities deliberately so that folks could do clever things for their cockpits etc. It is better than continually making the offset interface more complicated and adding options to the user interface or INI.

If I have both the Servos AND the inputs connected and i assign a temporary button to set bit 3 of 310A, this works and disables the input throttles from writing to the throttle offsets.

But 310A has to be refreshed every few seconds.

This however is not an elegant solution as I loose a button and i must remember to press this button before a press the A/T button.

Actually that argument doesn't wash -- one button can do many things, you don't need to use two. The problem you have is not the writing to 310A it is the continued re-writing to 310A.

How are the throttle values being written to 089A and 0924 (or, better, 0932)? Not a program?

Regards

Pete

[diegov]

Ahwhy? That may be the problem. Can't you configure them as normal throttle axes? And why write throttle 1 via the disconnectable offset, 089A, but throttle 2 via the direct offset? The correct pair would be 089A and 0932!

Pete, I apologise i am indeed writing to 089A and 0932. I originally wrote to offset 088C and 0924 with the same results.

How are the throttle values being written to 089A and 0924 (or, better, 0932)? Not a program?

Yes, maybe if i explained my setup it may assist you in determening the issue. I use a phidgets interface card to detect the position of my pots which are connected to the throttle lever. To translate the pot readings to FS values i use Alan's great program FS2Phidgets. I tell FS2Phidgets that the readings coming from the throttle sensors should be writen to offsets 089A and 0932.

Actually that argument doesn't wash -- one button can do many things, you don't need to use two

FS2Phidget does have the ability to interface with push buttons, but unfortunately I cannot assign multiple "functions" to the button. IE For my TOGA button i have it write to 080C which when it is pressed will activate TOGA. I can then not give this button a secondary assignment in FS2Phidgets to write to 310A, but as you mentioned this would be pointless as 310A needs to be continually writen to.

hmmm.. Are you maybe suggesting that i use offsets 3BB2 and 3BBA to write to the quadrant axis instead?

I appreciate your assistance.

[Pete Dowson]

FS2Phidget does have the ability to interface with push buttons, but unfortunately I cannot assign multiple "functions" to the button. IE For my TOGA button i have it write to 080C which when it is pressed will activate TOGA. I can then not give this button a secondary assignment in FS2Phidgets

I was thinking more of setting a bit in the Virtual buttons offsets (3340 following) to activate a "button" which could then be programmed in FSUIPC to do anything you liked. I've always found it more flexible to operate facilities this way rather than directly.

hmmm.. Are you maybe suggesting that i use offsets 3BB2 and 3BBA to write to the quadrant axis instead?

That's one way, certainly. If you write to any of those axis value areas they will be seen as Joystick #16 axes in FSUIPC's Axis Assignments, then you can assign them to throttles and calibrate them in FSUIPC, or just have them go direct to FS controls. I use this method for my GA28R driver (a Piper cockpit from Aerosoft Australia). Alternatively, if FS2Phidgets can write 8 bytes you could consider sending the appropriate axis controls and parameters via offset 3110, though this seems less likely.

Regards

Pete

[diegov]

Hi Pete,

Thanks for your help. Setting my offsets to 3BB2 and 3BBA worked a treat. When the A/T was armed my inputs were indeed ignored..

Recent news has seen that FS2Phidget is now discontinued, so i have taken your SDK and started writting my own interface software.

So far the FSUIPC has been the easiest part. Thanks for that.. I have also been able to interface to my phidget servo card and able to query its stats with the Phidget libraries, so im almost there. I now just need to map 088C and 0924 as a % of the servo position range limits.

Thanks again for your responses.

Diego