FS2004 AP Speed//Mach problem

#1
Hello,

I have an autopilot gauge that displays the target speed or mach with a single SPEED mode button, just like in many panels...
It has 2 display modes:
- in IAS mode, you set the target airspeed in KTS and the autothrottle controls the engines to maintain it when you press the SPEED button,
- in MACH mode, you set the target speed in Mach and press the same SPEED button to have the autothrottle maintaining the Mach speed.

The strange thing is when I switch from a IAS speed to Mach mode, with the following scenario :
1) I set a target IAS speed and engage SPEED mode, let's say 250 KTS
Events used : KEY_AP_SPD_VAR_DEC/KEY_AP_SPD_VAR_INC to set target speed, KEY_AP_PANEL_SPEED_HOLD to engage speed mode.
2) I switch to Mach mode display: the Mach target value is displayed but IAS speed mode is still active
I use a custom variable to set the display mode.
3) I set a target Mach value, let's say M0.62, whis is approx 280 KTS at 21000 feet
Events used: KEY_AP_MACH_VAR_DEC/KEY_AP_MACH_VAR_INC to set target Mach value
4) I press the SPEED mode button again. As the display mode is Mach, it engages the autotrottle MACH mode.
Event used: KEY_AP_PANEL_MACH_HOLD to hold Mach speed.

At this time, the target Mach value turns to M0.55, replacing the 0.62 value that was before !!
(this corresponds to 250 KTS, the previously set target speed)

It must be very basic but it drives me mad !! I can't understand why the target value changes when I activate the Mach mode. As soon as the target value is set, it should be taken into account to hold this value.
I saw that on fs9, don't know if FSX reacts the same...
Any help is welcome.

Eric
 
#2
Eric,

2 ideas. You could try the "non-panel" and/or "non-hold" versions of the Mach AT mode and see if they react differently.
Also a thought, was the aircraft at 250 KTS when you engaged the Mach mode?
The second idea is more forceful. At the time of Mach engagement you could, immediately after, use your custom variable
and set the internal FS Mach var. -->
KEY_AP_PANEL_MACH_HOLD + "My Custom Variable" KEY_AP_MACH_VAR_SET


(xml type)
(>K:AP_PANEL_MACH_HOLD)
(>K:AP_PANEL_MACH_HOLD_TOGGLE)
(>K:AP_PANEL_MACH_OFF)
(>K:AP_PANEL_MACH_ON)

(>K:AP_PANEL_MACH_SET)
(>K:AP_MACH_HOLD)
(>K:AP_MACH_OFF)
(>K:AP_MACH_ON)

(>K:AP_MACH_SET)

IIRC.... Take with a grain of salt.
Ran into the same scenario in our F-111 (fsx) where the Mach & IAS AT vars are isolated up until the point of of AT mode engagement.
At engagement the Mach would convert itself to the IAS AT Var based on current atmospheric conditions. (or via ratio compare? --> Current Mach speed / Current KIAS = AT Mach Var / AT KIAS Var )
When any AT mode is active the opposite var is continuously updated to it's conversion.
1) If IAS hold is on, adjusting the internal FS IAS speed var will update the not used Mach speed var
2) If Mach hold is on, adjusting the internal FS Mach speed var will update the not used IAS speed var

Checked code in our system and we used the same speed var commands but...
The F-111 had no throttle based speed system, we used the built in AT to help in pre release testing only - for ease. So the memory not so good on this.

Feel your pain - here's another idea. Use only custom vars for your display and controls then ->
1) At the time of speed mode engagement (Mach or IAS) send the needed custom var to the FS internal var ( AP_SPD_VAR_SET or AP_MACH_VAR_SET, depending on mode engaged )
2) Keep it updated!! - If the specific used custom variable does not equal the now active AT mode speed var then update it, the same as above at time of engagement.
Doing the above should isolate the built in FS internal logic allowing you to do what seems to be needed.
Downside ? (Maybe..) The ASI speed bug would now have to use the custom var(s) AND depending on what is adjusted do calculations to show the bug properly.

Sorry, the forum software does not allow attachments of Aspirin or Ibuprofen :rolleyes: :scratchch :stirthepo :banghead:
 
Last edited:
#3
You could try the "non-panel" and/or "non-hold" versions of the Mach AT mode and see if they react differently.
Also a thought, was the aircraft at 250 KTS when you engaged the Mach mode?
I already tried this, without any success. But I am not sure I tried all the possibilities, I will try again.
In fact, I like using the HOLD events because they act as toggles, it is convenient.
The aircraft was not flying at 250KTS when the MACH mode was engaged. It appears the Mach speed set when I engage the MACH mode is the Mach that corresponds to the previously set IAS speed target, which is 250 KTS in my case.

The second idea is more forceful. At the time of Mach engagement you could, immediately after, use your custom variable
and set the internal FS Mach var. -->
KEY_AP_PANEL_MACH_HOLD + "My Custom Variable" KEY_AP_MACH_VAR_SET
I already tried this. Right after engaging the MACH mode, I set the Mach target value with the KEY_AP_MACH_VAR_SET event. It doesn't work...

Ran into the same scenario in our F-111 (fsx) where the Mach & IAS AT vars are isolated up until the point of of AT mode engagement.
At engagement the Mach would convert itself to the IAS AT Var based on current atmospheric conditions.
Checked code in our system and we used the same speed var commands but...
The F-111 had no throttle based speed system, we used the built in AT to help in pre release testing only - for ease.
I know what you're talking about, it was the same for my CRJ and Airbus Series: as I re-coded the authothrottle with my own controller, I had no such problem. This time, I want to do something easier by using the existing auto-throttle system, and I am blocked by this problem...

Thanks for your help !!
Eric
 
#4
I already tried this. Right after engaging the MACH mode, I set the Mach target value with the KEY_AP_MACH_VAR_SET event. It doesn't work...
Just checking, most likely you did.. Did you multiply the needed Mach speed var by 100 before sending it to the set command? (integer rqrd, maybe only XML?)
Here's a sync code for mach -
XML:
if{ (A:AIRSPEED MACH, mach) 100 * (>K:AP_MACH_VAR_SET) }
 
#6
I have just tried to use KEY_AP_MACH_ON/KEY_AP_AIRSPEED_ON to engage Mach/speed mode: doesn't work any better.
Using KEY_AP_PANEL_MACH_ON/KEY_AP_PANEL_SPEED_ON : doesn't work any better.
The behavior is exactly the same: when I engage the Mach mode, it changes the value of the target Mach when engaging :(
 
#8
In order to debug isolate the problem and debug it more easily, I developed a sample gauge that manages auto-throttle. I can send it to you if you wish.
Here is what I get (4 steps):
1) The auto-throttle is engaged with speed mode, it holds 250 KTS. The Mach display shows 0.55, which corresponds to 250 KTS at this altitude.
ScreenShot168.png


2) I disengage speed mode without changing any value (this step is optional)
ScreenShot194.png

I tried this to make sure these is no "interference" between speed and mach but it doesn't change anything.

3) I change the target Mach value to 0.60
ScreenShot196.png


4) I engage the Mach mode, hoping it will take 0.60 as the target value
ScreenShot201.png

No luck !! When I press the button, the display changes back to 0.55, which becomes the target Mach.

I don't know why this happens and it drives me mad...
 
#9
I work around this by converting target IAS into target mach and then setting mach hold based on that result.
Yes, this is an option, but it can't work in my case because in my final panel, I implemented a Flight Level Change mode (FL CH) to manage climb by controlling the pitch while thrust is constant. So the typical use case, like in a real aircraft, is the following:
- At low altitude, auto-throttle manages the speed with IAS in KTS. Speed mode can be used. (this corresponds to Step 1 in my previous post)
- When cleared by ATC, the FL CH mode is engaged. The FS speed mode is disengaged, my controller manages the pitch to hold the target speed (IAS in knots)
(this corresponds to Step 2 in my previous post)
- As the aircraft climbs, often between FL260 and FL270, the pilot has to switch to Mach, using around M0.70 to climb. The target Mach is displayed but the standard FS Mach mode is not engaged because my FL CH mode is still active (this corresponds to Step 3 in my previous post).
- When the target altitude is reached, the speed mode is engaged again to maintain the speed using N1. In fact, as the pilot turned to Mach, the MACH mode is engaged (this corresponds to Step 4 in my previous post).
This is where the bug appears, the displayed Mach value suddenly changes to a much lower one (around M0.55, corresponding to the latest target speed used at low altitude), causing an erratic behavior.

If I convert the IAS into target mach before setting mach hold as you suggest, it will override the target Mach value entered by the pilot during the climb in FL CH mode and I don't want that.
What a nightmare for something supposed to be so simple...
 
#10
Another idea..
Upon engaging Mach hold, wait one or two gauge cycles before forcing your custom mach value.
Can almost bet there's an internal subroutine that takes over on the PANEL_MACH_HOLD command overwriting a simultaneous Mach hold var forcing .
Ugly yes.. might work.
 
#11
I work around this by converting target IAS into target mach and then setting mach hold based on that result.
I'm sorry, I realize I misunderstood what you wrote, I corrected myunderstanding and I have just coded it and... it works !! You deserve the gold medal :)

When pressing the MACH button, I first change the target IAS to the value that corresponds to the target Mach, then I engage the MACH mode.
Conversely, when pressing the SPEED button, I first change the Mach to the value corresponding to the target IAS. It works but sometimes I have a little difference (2 or 3 KTS) because of the IAS/Mach conversion rounding (IAS is set in integer).

Thanks to everyone for your help !!
Eric
 
#12
Another idea..
Upon engaging Mach hold, wait one or two gauge cycles before forcing your custom mach value.
Can almost bet there's an internal subroutine that takes over on the PANEL_MACH_HOLD command overwriting a simultaneous Mach hold var forcing .
Ugly yes.. might work.
I thought about doing this. It is not so ugly but much more difficult to implement. Even if the solution described above works (with a 2-3 KTS error sometimes), I may give it a try.
I will let yo know.

Eric
 
#13
I have just solved the rounding problem, it now works prefect :)
It seems the problem is solved. I can share my C code if someone is interested.

Thanks again to all of you for your great help !!
Eric
 
Top