250kts under 10,000 feet

[softreset 9]

I recently joined a VA that uses the TFDi reporting program, which if you've never used it, is hyper sensitive to the 250kts under 10,000ft rule. My experience is that just about every ACARS program inaccurately reports in-sim IAS. Usually it's +3/-3 IAS.

 

A couple of options that have worked with mixed results:

 

• Managed speed in OP Climb
• THR Climb with a preset 240-243kts (I usually give myself a little buffer)
• Manual flight, pitch for speed (usually north of 3800 FPM)
• THR Climb & OP Climb (don't know how much or less effective this is)

 

Some information about my environment (because I figure the logical, weather related questions are coming)

 

• Active Sky Next (latest version)
• Maximum cloud turbulence at 20%
• Maximum wind turbulence at 20%
• Turbulence effect scale at 20%
• Enhanced turbulence OFF
• Wake turbulence at 30% (although not applicable in this particular instance, no aircraft within 100 nm)
• Maximum downdraft rate in FPM at 300
• Maximum updraft/thermal rate in FPM at 300

 

In this evening's climb out of KPHL with winds at 030/5 and my route heading 085, I engaged OP Climb and busted the 250 managed limit (reached 258kts). Switching to THR Climb it finally settled back to 250 just as I was about to break the 10,000 barrier.

 

Issue persists in the tutorial flight as well, using Active Sky. Issue does not occur if there absolutely no winds and I disable Active Sky, although the ACARS program still reported 252 IAS. I don't think disabling Active Sky is the logical answer, I'll just deal with turning dials at that point.

 

Curious what everyone else is doing to deal with hard 250/1000 limits from ACARS programs.

 

Thanks!

[HAL-9000 10]

You say "switching to Thrust Climb". What were you in before?

[skelsey 103]

CLB/OP CLB in selected speed with a generous margin would probably be the closest thing to real operations.

Even better, however, would be for your VA to use flight data recorder with more realistic parameters! The behaviour you describe is both completely unrealistic and frankly pretty ridiculous IMHO.

Sent from my GT-I9505 using Tapatalk

[softreset 9]

3 hours ago, HAL-9000 said:

You say "switching to Thrust Climb". What were you in before?

 

I'm in MAN FLX (and whatever assumed temp) up to acceleration height which I left at the default 1500 AGL. Then I'll go to THR CLIMB after moving my throttle to the Climb detent, couple with a pitch down of the nose and I'll proceed with flaps/slats retraction schedule. If I set a manual speed the FMA will switch from THR CLIMB to SPEED based on where my IAS is relative to what is set.

 

Where things go sideways on me is what you see at the 2:56 mark of this YouTube I just filmed of my takeoff -

 

 

My understanding is that if I manually set a speed it'll hold that speed and pitch for it when the altitude is managed. It doesn't appear to obey that expected result. Upon selecting the 250 IAS it rockets past that, exceeding 260 until I bring it into managed mode and it pitches to shed that speed.

 

Frame of reference is Aerosoft documentation 

 

SYSTEMS Systems guide 
Vol 4 
04-03-13 02 September 2014

Page 25

 

1 hour ago, skelsey said:

CLB/OP CLB in selected speed with a generous margin would probably be the closest thing to real operations.

Even better, however, would be for your VA to use flight data recorder with more realistic parameters! The behaviour you describe is both completely unrealistic and frankly pretty ridiculous IMHO.

Sent from my GT-I9505 using Tapatalk

 

Sounds good, that's what has been working for me. I gave up on the BA Virtual group and the AA Virtual VA I was in specifically because both were rejecting PIREPS due to speed issues under 10,000 feet (in the 'bus). I agree on the ridiculously component. VAFS has worked out pretty well, as although it too has a hard 250/10k, the airbus has yet to trigger it (Delta Virtual).

[FraPre 89]

Hi,

 

your permanent changes of AP modes are not helpful, the Airbus is not to rest.

After takeoff, with ATC clearance to an Level or Hight you select an OP CLB (PULL the ALT Knob), with clearance at profile you select an CLB (Push the ALT Knob). But not permant change between CLB / OP CLB.

If i am not mistaken, same FCU actions are not agree with the FMA. (for example, I missed the point right of the ALT window for same moments, altough the value in the window is higher as the momentary Alt.)

In the moment of acceleration above 250 you´ve select 17000 and Push the knob = CLB mode, but this is not showed above the ALT tape on the PFD, the V/S is rapid decrease and the speed go up. The reason is an existing constraint below the actually hight, the airplane will descend (the magenta value below the alt tape i cann´t read). One moment later you pull again the ALT Knob (this selects the OP CLB without constraints) and the 17000 is showed above  the alt tape, the OP CLB mode is working and will bring the aircraft back in the correctly condition (climb with the managed speed).

[skelsey 103]

2 hours ago, softreset said:

My understanding is that if I manually set a speed it'll hold that speed and pitch for it when the altitude is managed. It doesn't appear to obey that expected result. Upon selecting the 250 IAS it rockets past that, exceeding 260 until I bring it into managed mode and it pitches to shed that speed.

 

Remember your FMAs .

 

First column is the autothrust -- which could be in a manual mode (i.e. MAN FLX/MAN TOGA), an automatic fixed thrust mode (THR CLB, THR IDLE) or an automatic variable thrust mode (SPEED).

 

Second column is the vertical mode -- which could be speed-on-pitch (CLB/OP CLB/OP DES) or speed-on-thrust (ALT/ALT CRZ/VS/FPA/GS etc). DES is a bit odd as it the nature of it means that although it is primarily speed-on-pitch, it can also revert the A/THR to SPEED mode if necessary to maintain the path.

 

Speed-on-pitch modes (CLB/OP CLB/OP DES) are associated with a fixed thrust setting (i.e. THR CLB or THR IDLE) and, as you say, vary the pitch to maintain the selected or managed speed target. Speed-on-thrust modes pitch for a selected fixed vertical rate (i.e. whatever V/S or FPA you have selected on the FCU, zero in ALT/ALT CRZ, whatever is required to maintain the glideslope in GS etc) and leave the A/THR in SPEED mode so that the speed is controlled by varying the thrust.

 

The problem you are having, as Frank says above, is that you have an intermediate altitude restriction at 7000ft. The difference between CLB and OP CLB is that CLB is a managed mode that will obey any FMGS altitude constraints, whereas OP CLB will climb directly to the FCU selected altitude and ignore any altitude constraints in the FMGS.

 

The giveaway is ALT appearing in magenta on the FMA below CLB. ALT magenta is analogous to VNAV ALT in Boeing parlance -- it should grab your attention because it means that the aircraft is going to level off at some altitude other than that which you have placed in the FCU alt sel. This may be desirable, or it may not be depending on what you are doing/intending to do.

 

As Frank says, having climbed above the 7000ft restriction in OP CLB, by pushing for managed CLB the aircraft is going "oh -- there's a 7000ft restriction up ahead which I need to meet". This means it is going in to ALT* and SPEED mode in order to capture/regain 7000ft and as a result the speed is running away a little.

 

2 hours ago, softreset said:

I gave up on the BA Virtual group and the AA Virtual VA I was in specifically because both were rejecting PIREPS due to speed issues under 10,000 feet

 

Just so as you know - we certainly do not do this at the 'original' BAVirtual 

[HAL-9000 10]

Yep, Frank and Selskey have it right. You are managing climb with an altitude constraint below your current altitude. 

5 hours ago, skelsey said:

CLB/OP CLB in selected speed with a generous margin would probably be the closest thing to real operations.

Even better, however, would be for your VA to use flight data recorder with more realistic parameters! The behaviour you describe is both completely unrealistic and frankly pretty ridiculous IMHO.

Sent from my GT-I9505 using Tapatalk

 

Real world operations, we use managed speed. There is a restriction of flight level 100 and 250kts built into the database, so i would only select speed if there were an operational reason to do any speed that wasn't 250kts, such as maintaining a speed restriction around a wrap-around that is below Green Dot, I may elect to pull S speed or 215 or 220kts and allow the autoretract, or if i knew that ATC would give me an early turn if I got above a set level (e.g. Out of gatwick going north, you would get a turn as soon as you get above the traffic coming in to Heathrow), or if i wanted to get higher more quickly in order to get above some weather i see ahead of me. Well there are a few reasons to do it, but in general there is no need to set selected speed during the climb.

[skelsey 103]

Real world operations, we use managed speed. There is a restriction of flight level 100 and 250kts built into the database, so i would only select speed if there were an operational reason to do any speed that wasn't 250kts, such as maintaining a speed restriction around a wrap-around that is below Green Dot, I may elect to pull S speed or 215 or 220kts and allow the autoretract, or if i knew that ATC would give me an early turn if I got above a set level (e.g. Out of gatwick going north, you would get a turn as soon as you get above the traffic coming in to Heathrow), or if i wanted to get higher more quickly in order to get above some weather i see ahead of me. Well there are a few reasons to do it, but in general there is no need to set selected speed during the climb.

Oh quite -- I suppose what I was getting at was that it is probably marginally more realistic to retain CLB/OP CLB and select a lower speed to allow some margin for the speed to fluctuate a few knots in the (unrealistic) situation faced by the OP rather than to routinely climb in VS with the A/THR in SPEED (not least because V/S is less well protected than CLB/OP CLB).

I suppose the other way would be to modify the managed speed constraint to say 240/245kt which would enable leaving the speed managed.

As I say though, the real issue is the unrealistic penalties applied by these flight tracking programmes in the event of a gust knocking the speed up to 251kt for a couple of seconds (or my other favourite, failing to turn the landing lights off at 10,001ft).

Sent from my GT-I9505 using Tapatalk

[softreset 9]

4 hours ago, FraPre said:

your permanent changes of AP modes are not helpful, the Airbus is not to rest.

4 hours ago, FraPre said:

Hi,

 

your permanent changes of AP modes are not helpful, the Airbus is not to rest.

 

 

Understood. I was trying to condense the frustration of a dozen flights into < 3 minute video and clearly picked the wrong departure to illustrate my point. Next time I'll pick a departure without a sub 10,000 ft climb restriction. You're absolutely right, I created too much confusion for the automation with the 17,000 programmed altitude and the 7000 ft SID restriction.

 

4 hours ago, FraPre said:

4 hours ago, skelsey said:

 

Remember your FMAs .

As Frank says, having climbed above the 7000ft restriction in OP CLB, by pushing for managed CLB the aircraft is going "oh -- there's a 7000ft restriction up ahead which I need to meet". This means it is going in to ALT* and SPEED mode in order to capture/regain 7000ft and as a result the speed is running away a little.

Just so as you know - we certainly do not do this at the 'original' BAVirtual 

 

Simon, thanks. As I mentioned to Frank, I definitely didn't pick a good SID to illustrate some of my frustrations with the VA technology. That example was more about me confusing the equipment than illustrating what I believed to be supplementary information to my issue(s). It's also very possible and likely that I'm making something out of nothing. It makes total sense why the 'computer' would be confused over my 17000 & 7000 ft discrepancies and makes total sense.

 

You're right regarding the 'original' VA, I gave them a shot as well and for non in-sim reasons, realized it wasn't the right VA for me either. Too bad too, exemplary operation.

 

4 hours ago, FraPre said:

2 hours ago, HAL-9000 said:

Yep, Frank and Selskey have it right. You are managing climb with an altitude constraint below your current altitude. 

 

Real world operations, we use managed speed. There is a restriction of flight level 100 and 250kts built into the database, so i would only select speed if there were an operational reason to do any speed that wasn't 250kts, such as maintaining a speed restriction around a wrap-around that is below Green Dot, I may elect to pull S speed or 215 or 220kts and allow the autoretract, or if i knew that ATC would give me an early turn if I got above a set level (e.g. Out of gatwick going north, you would get a turn as soon as you get above the traffic coming in to Heathrow), or if i wanted to get higher more quickly in order to get above some weather i see ahead of me. Well there are a few reasons to do it, but in general there is no need to set selected speed during the climb.

 

 

Thanks, makes perfect sense. Follow up question, if you wouldn't mind. As I encountered this on VATSIM last week. I was cleared to 8000 on takeoff and the controller got busy and left me hanging for a bit, so I leveled off for somewhere in the neighborhood of 2-3 minutes. I was then cleared to FL220, dialed up to the new cleared FL and pushed the knob in. As I was already going 250 the throttle power ramps up considerably, over taking the pitch and my IAS spiked to just shy of 260 but quickly settled back to 250 (moments after passing 10,000) only to then climb up to my managed climb speed. In real world operations, would you switch to V/S for that 2000 foot climb or is this another example of ACARS technology creating unnecessary restrictions?

[softreset 9]

3 minutes ago, skelsey said:

failing to turn the landing lights off at 10,001ft).

 

Ah yes, that's a fool's errand. To add to those frustrations, you never know what height the ACARS is reporting, you hope it know the QNH at the arrival field but it rarely does. Thankfully that silly criteria is not considered in the current VA. I appreciate the sense of community offered by VAs, that's my primary reason for joining them but these "little things" can be frustrating. Especially if my expected behavior is inline with what I believe to be correct operation of the equipment. If I peg it to 300 kts at 6000 feet, purposely, that's different. Because I'm sure in the real world there's a lot of 251-253 IAS climbs below 10,000 and no one is getting dinged for it.

[HAL-9000 10]

3 hours ago, softreset said:

 

Understood. I was trying to condense the frustration of a dozen flights into < 3 minute video and clearly picked the wrong departure to illustrate my point. Next time I'll pick a departure without a sub 10,000 ft climb restriction. You're absolutely right, I created too much confusion for the automation with the 17,000 programmed altitude and the 7000 ft SID restriction.

 

 

Simon, thanks. As I mentioned to Frank, I definitely didn't pick a good SID to illustrate some of my frustrations with the VA technology. That example was more about me confusing the equipment than illustrating what I believed to be supplementary information to my issue(s). It's also very possible and likely that I'm making something out of nothing. It makes total sense why the 'computer' would be confused over my 17000 & 7000 ft discrepancies and makes total sense.

 

You're right regarding the 'original' VA, I gave them a shot as well and for non in-sim reasons, realized it wasn't the right VA for me either. Too bad too, exemplary operation.

 

 

Thanks, makes perfect sense. Follow up question, if you wouldn't mind. As I encountered this on VATSIM last week. I was cleared to 8000 on takeoff and the controller got busy and left me hanging for a bit, so I leveled off for somewhere in the neighborhood of 2-3 minutes. I was then cleared to FL220, dialed up to the new cleared FL and pushed the knob in. As I was already going 250 the throttle power ramps up considerably, over taking the pitch and my IAS spiked to just shy of 260 but quickly settled back to 250 (moments after passing 10,000) only to then climb up to my managed climb speed. In real world operations, would you switch to V/S for that 2000 foot climb or is this another example of ACARS technology creating unnecessary restrictions?

In the real world a 10kt speed increase would be unlikely. No we wouldn't choose vertical speed mode - it would be done in managed or open climb. The only time we use vertical speed in the Climb is if we are keeping the rate of climb low so as to avoid nuisance TCAS callouts if we are climbing towards a level 1000ft below that to which another aircraft is descending close by. Aside from that, and a specific ATC vertical speed request, there is no need for vertical speed to be used in the climb.

 

Also, there's around a 10kt buffer that ATC will be expecting you to stay within. I mean, best if you don't go 10kts above, and much better if you don't go 10kts below, but it shouldn't pose any problems. You're not going to have questions raised if you're 4kts fast, although on approach with another aircraft 2.5nm in front of you, you'll want to stick to the speeds given unless you want to go around. Remember that during the descent, in managed mode, the speed is automatically given a buffer by the computer, which you can see on the PFD. Even below FL100 you will see the speed range is 240-255kts.

 

As an addendum, in the real aircraft I have been below FL100 at 345kts in class A airspace (straight and level, I reduced speed to green dot, then pulled Open Descent and selected 345, which was fun). 

 

I tend to avoid use of vertical speed in the Climb as a matter of airmanship - remember that selecting vertical speed will override any speed selection (either pilot selected or managed), and instead the aircraft will keep lowering the speed to maintain a desired climb rate, which is very dangerous particularly at higher flight levels. Well technically it shouldn't pose danger, as the aircraft protections will kick in when you hit vAlphaProt and Alpha Floor and it'll go into TOGA lock, but you'll be explaining yourself to FDM and being put back into training, if you're lucky! Best to be avoided.

[softreset 9]

21 hours ago, HAL-9000 said:

Remember that during the descent, in managed mode, the speed is automatically given a buffer by the computer, which you can see on the PFD. Even below FL100 you will see the speed range is 240-255kts.

 

I tend to avoid use of vertical speed in the Climb as a matter of airmanship - remember that selecting vertical speed will override any speed selection (either pilot selected or managed), and instead the aircraft will keep lowering the speed to maintain a desired climb rate, which is very dangerous particularly at higher flight levels. Well technically it shouldn't pose danger, as the aircraft protections will kick in when you hit vAlphaProt and Alpha Floor and it'll go into TOGA lock, but you'll be explaining yourself to FDM and being put back into training, if you're lucky! Best to be avoided.

 

Thanks for your perspective, all very helpful and appreciated. Makes a lot of sense and helpful! The good news, I was able to convince the VA that the 250/1000 rule needs some relaxing and as many of them also enjoy the Aerosoft Airbus, apparently share in my frustrations.

 

Noted on the descent via managed mode. I've seen the parallel bars around the triangle buffer and in a couple of situations have definitely had it pegged on the top end at 255.

[softreset 9]

Well the good news, the overspeed has only happened once in the last 6 flights. While it's still 'a thing' it's definitely better if I hand fly up to 10k. The image below is from my recent departure out of KSAN on the FALCC 1 SID. That overspeed is during the the left turn back towards MZB after taking off from 09. Autopilot was engaged at 4000 ft AGL and as there was no SID restricts the cruise alttitude was set at takeoff.

 

THR CLIMB & CLB & NAV on FMA.

 

Just as it finished the turn (with a slight tailwind component) that overspeed appeared.

 

Please login to display this image.

[skelsey 103]

I think the issue is that the nose tends to drop in the turn (naturally) and the AP can sometimes be a bit lazy in picking it up. As a result the speed starts running away a bit until the nose comes back up.

It might be that there could be some adjustments made to the AP pitch gain or something to make it a bit more responsive (looks hopefully at developers).

Sent from my GT-I9505 using Tapatalk

[softreset 9]

5 hours ago, skelsey said:

I think the issue is that the nose tends to drop in the turn (naturally) and the AP can sometimes be a bit lazy in picking it up. As a result the speed starts running away a bit until the nose comes back up.

It might be that there could be some adjustments made to the AP pitch gain or something to make it a bit more responsive (looks hopefully at developers).

Sent from my GT-I9505 using Tapatalk

 

Makes sense, my only other premium/payware aircraft I can compare to is the PMDG 737 NGX and I do notice that during significant banks during < 18,000 feet that there's a slight reduction in N1% (2%) and a compensation in pitch to hold airspeed at the preset VNAV climb speed. I also found a couple of videos on YouTube where the PFD is visible during the climb phase and you can definitely see the creep over 250 IAS that HAL talked about from an IRL perspective. Sadly that banking turn at about 8000 ft. gets cut for a direct comparison.

 

Either way, I love flying the aircraft and I've just learned that on departures where it's questionable to not just go full "autopilot" and ultimately I'm alright with that.

 

But yeah, it'd be neat if there was some future development consideration on it. Ironically there's even a page dedicated to "How to avoid overspeed issues in the Aerosoft Airbus" in the VA's tutorial section.

 

 

[HAL-9000 10]

18 hours ago, skelsey said:

I think the issue is that the nose tends to drop in the turn (naturally) and the AP can sometimes be a bit lazy in picking it up. As a result the speed starts running away a bit until the nose comes back up.

It might be that there could be some adjustments made to the AP pitch gain or something to make it a bit more responsive (looks hopefully at developers).

Sent from my GT-I9505 using Tapatalk

 

There's no 'naturally' about it. In a regular aircraft you can expect a secondary effect of roll to be yaw, but with the Airbus that is handled by the flight computers, so that you don't need back pressure to maintain pitch. The nose should not pitch down unless it is a very large bank. The N1 will increase, and if it doesn't increase quickly there will be a slight drop in speed, but there should be no pitch down.

[softreset 9]

We'll add the the the EWR2 SID out of KEWR (04L). Winds were 358/7kts

 

I manually completed the departure:

• Heading 039 to 500 ft
• Right turn to 060 to 3.6 DME from the ILS (110.75)
• Left turn to 290 at 2500 ft (it's suppose to be on the R214 radial from Teterboro but I was a little late). Autopilot engaged at 210 IAS and about 3000 AGL

I'm completing my retraction schedule at 203 kts, pitched down to the climb thrust speed and as the plane is banking south it's cooking towards 250 kts at about 2000 FPM. THR CLB & CLB on FMA. Final IAS before it pitched up for speed was 263 IAS and then the plane pitched for 3200+ FPM (from about 1900 FPM). Never once let off the "gas" on thrust and just blew by 250.

 

I reset the flight (I saved it right before takeoff) and redid the departure procedure, only this time set OP CLB and a manual speed of 240 kts and everything was fine to 10,000 ft.

 

So the speed management is definitely an issue with real weather and significant turning below 10,000 and during the transition from MAN FLEX & THR CLB. I'm just going to continue to document that here.

 

[skelsey 103]

18 hours ago, skelsey said: I think the issue is that the nose tends to drop in the turn (naturally) and the AP can sometimes be a bit lazy in picking it up. As a result the speed starts running away a bit until the nose comes back up.

It might be that there could be some adjustments made to the AP pitch gain or something to make it a bit more responsive (looks hopefully at developers).

Sent from my GT-I9505 using Tapatalk

 

There's no 'naturally' about it. In a regular aircraft you can expect a secondary effect of roll to be yaw, but with the Airbus that is handled by the flight computers, so that you don't need back pressure to maintain pitch. The nose should not pitch down unless it is a very large bank. The N1 will increase, and if it doesn't increase quickly there will be a slight drop in speed, but there should be no pitch down.

In the real thing absolutely (although my understanding is that the pitch correction is good but not quite as good as the FCOM would have you believe). However in the Aerosoft bus the pitch correction is not terribly effective and we are also talking about with the AP engaged.

The real one and the virtual one will surely both naturally drop the nose slightly in a turn (that's just physics) -- whether that tendency is apparent to the pilot is a different matter and the job of the FCCs to correct. The real one is a bit better at it than the Aerosoft, and in addition the Aerosoft AP and autotrim system is (I would suggest based on what I have read from those like yourself with real world experience) not quite aggressive enough in pitch. The other situation where this is apparent is in a big AP-flown HDG SEL turn with a shallow VS descent, where the rate will increase quite significantly and for quite an extended period of time.

Sent from my GT-I9505 using Tapatalk