Jump to content
Hoffie3000

Version 1.2.3.0 and some thoughts

Recommended Posts

Fortunately, the first flight (EDDH-->EDDF) went without problems. The most striking are the changes in the colours of various numbers.
With the exception of the well-known "flaws" I didn't notice any new errors.
You can update to this version with a clear conscience.

 

The "flaws" I noticed:
The vPilot client (for VATSIM) is still not recognized if you load the Airbus directly from a saved "Turn Around State", or "Cold Dark State" in P3Dv4.4.

But after reinstalling the Airbus, the "Taxi State" is active and vPilot is recognized there.

Ok, if you know it, you do the known workarounds, but it's strange that after such a long time it still doesn't work. Even the old 32bit Airbus could do it.

 

Descent behavior:
Nothing has changed to good, the bus at the TOD still goes into a more or less violent nosedive, with sink rates >6000ft/min.

I looked at the map and measured why the bus is doing this and now I know that the bus has no other possibility with the current programming.

 

If you compare the distance from TOD to a given waypoint and FL, in my case KERAX /FL110, then the bus starts about 19nm too late with the descent!

So it has to go into a quasi dive to reach the desired FL at the given waypoint.

 

You can use the formula: (Flight Altitude,ft/1000)*3 calculate the TOD quite practically and usually comes to sink rates of about 2000ft/min -> 25000ft/min depending on the wind.

 

In this case the distance is to KERAX/11000ft:

TOD calculated, red arrow: (32000ft altitude- 11000ft KERAX)/1000) *3 = 63nm

TOD Airbus calculated, yellow arrows: approx. 44nm

This results in a difference of 19nm between theory and practice and is the reason for the strange descent behaviour.
I am sure, if you give the bus more distance for the descent, the descent behaviour will change positively.

 

Regards, Wolfgang

A319_ver1230_EDDH-EDDF12.thumb.png.95197d99aa17e2056dac68d65ab0b532.png

Translated with www.DeepL.com/Translator

 

 

Share this post


Link to post

This explains why I never see the 'nosedive' behaviour.  I start the descent as soon as the checklist is complete (20NM before TOD?).

Share this post


Link to post
48 minutes ago, Hoffie3000 said:

Descent behavior:
Nothing has changed to good, the bus at the TOD still goes into a more or less violent nosedive, with sink rates >6000ft/min.

I looked at the map and measured why the bus is doing this and now I know that the bus has no other possibility with the current programming.

As already said this is still under investigation as it only happens under certain conditions.

Share this post


Link to post
22 minutes ago, mopperle said:

As already said this is still under investigation as it only happens under certain conditions.

 

I experienced it last night as well; I actually started a descent (ATC instruction) well before the calculated TOD and descended in various steps.  While at about FL280 and still below the VNAV path, I was instructed to descend to FL240, upon which I entered OP DES and the a/c dove down to a max of about 6200 fpm - in the yellow so I can't believe that was intended.  This was at a CI 60, which commands roughly M0.79/337kts and it required that much of a descent rate just to finally catch the target - once I passed crossover altitude and the target stopped increasing.

 

As I've said before, it seems to me that the a/c loses a little too much speed as the A/T rolls back to idle; it "feels" as though there is too much drag.  This "feeling" is based on hundreds of hours flying the FSX version as well as other packages such as the PMDGs, all of which are/were much more slippery at higher altitude.  Take that with a grain of salt...

 

For me, I can reproduce it reliably every time.  Set CI to 60, cruise at target speed (M0.79-0.80) at FL320-360, dial the altitude back and pull.  Happens every time.  My usual workaround is a bit similar to the OP's; I usually get instructed to descent early anyway so the first phase is usually a V/S and sooner or later I get speed nags.  OP DES with a slower speed (such as say 280kts) does seem to be more reasonable.  I might play around with a different CI on my next flight later today and see if/how that affects anything.

 

 

Share this post


Link to post
7 minutes ago, Sabretooth78 said:

 

I experienced it last night as well; I actually started a descent (ATC instruction) well before the calculated TOD and descended in various steps.  While at about FL280 and still below the VNAV path, I was instructed to descend to FL240, upon which I entered OP DES and the a/c dove down to a max of about 6200 fpm - in the yellow so I can't believe that was intended.  This was at a CI 60, which commands roughly M0.79/337kts and it required that much of a descent rate just to finally catch the target - once I passed crossover altitude and the target stopped increasing.

 

As I've said before, it seems to me that the a/c loses a little too much speed as the A/T rolls back to idle; it "feels" as though there is too much drag.  This "feeling" is based on hundreds of hours flying the FSX version as well as other packages such as the PMDGs, all of which are/were much more slippery at higher altitude.  Take that with a grain of salt...

 

For me, I can reproduce it reliably every time.  Set CI to 60, cruise at target speed (M0.79-0.80) at FL320-360, dial the altitude back and pull.  Happens every time.  My usual workaround is a bit similar to the OP's; I usually get instructed to descent early anyway so the first phase is usually a V/S and sooner or later I get speed nags.  OP DES with a slower speed (such as say 280kts) does seem to be more reasonable.  I might play around with a different CI on my next flight later today and see if/how that affects anything.

 

 

 

Would you kindly try this with a CI of 35?

 

Share this post


Link to post
1 hour ago, aaflyboy777 said:

What exactly is the vPilot error?

Jeremy

 

Only some people see this, if you're not having it (and you'd know right away), then I wouldn't worry about it my friend.  But if you really need info on it, it's described fully in the initial post in this thread.

 

Best wishes!

 

Share this post


Link to post
2 hours ago, Hoffie3000 said:

Fortunately, the first flight (EDDH-->EDDF) went without problems. The most striking are the changes in the colours of various numbers.
With the exception of the well-known "flaws" I didn't notice any new errors.
You can update to this version with a clear conscience.

 

The "flaws" I noticed:
The vPilot client (for VATSIM) is still not recognized if you load the Airbus directly from a saved "Turn Around State", or "Cold Dark State" in P3Dv4.4.

But after reinstalling the Airbus, the "Taxi State" is active and vPilot is recognized there.

Ok, if you know it, you do the known workarounds, but it's strange that after such a long time it still doesn't work. Even the old 32bit Airbus could do it.

 

Descent behavior:
Nothing has changed to good, the bus at the TOD still goes into a more or less violent nosedive, with sink rates >6000ft/min.

I looked at the map and measured why the bus is doing this and now I know that the bus has no other possibility with the current programming.

 

If you compare the distance from TOD to a given waypoint and FL, in my case KERAX /FL110, then the bus starts about 19nm too late with the descent!

So it has to go into a quasi dive to reach the desired FL at the given waypoint.

 

You can use the formula: (Flight Altitude,ft/1000)*3 calculate the TOD quite practically and usually comes to sink rates of about 2000ft/min -> 25000ft/min depending on the wind.

 

In this case the distance is to KERAX/11000ft:

TOD calculated, red arrow: (32000ft altitude- 11000ft KERAX)/1000) *3 = 63nm

TOD Airbus calculated, yellow arrows: approx. 44nm

This results in a difference of 19nm between theory and practice and is the reason for the strange descent behaviour.
I am sure, if you give the bus more distance for the descent, the descent behaviour will change positively.

 

Regards, Wolfgang

A319_ver1230_EDDH-EDDF12.thumb.png.95197d99aa17e2056dac68d65ab0b532.png

Translated with www.DeepL.com/Translator

 

 

Hi, can you post your fplan please? I would like to test it myself.

Share this post


Link to post

Hello Bob,

that was the flight plan:

 

EDDH (Rwy23) to EDDF (Rwy07L)
AMLU9B AMLUH UM852 HLZ T157 KERAX KER07N

 

Alternate: EDDK

Distance: 334nm + 80nm (Alternate)

 

FL320

 

Cost Index: 80

ZFW: 55.1 / 20.1(ZFW%MAC)

Pax: 124

Cargo: 5000kg

Fuel: 6509kg

Trim: Up0.9

 

Airbus FMC normally calculate with the whole KER07N-Transition. But ATC online will see your Aircraft always at FL110/KERAX for better spacing and pick up planes to final Approach.

So I was set manuell for KERAX: 320/11000

 

But the nm difference between theory and practice can also be seen in every other flight. This is not limited to this route. 

 

Regards, Wolfgang

 

 

 

Share this post


Link to post
21 hours ago, DaveCT2003 said:

 

Would you kindly try this with a CI of 35?

 

 

Did another flight, this time with a CI of 35 and the behavior was overall similar.

 

The targeted descent speed was 296 knots this time, so the effects were lessened as the a/c didn't have to chase as high a speed above crossover altitude and therefore ended sooner, but it was the same basic behavior.

 

Specifically, my cruise was at FL370 and I was instructed to descend to FL330 somewhat prior to TOD.  So I entered DES at 1000 fpm until about just past FL340 when I was instructed to descend to FL280, so I pulled for OP DES (this was incidentally just about at the point where I would have met the VNAV profile - for most of the remaining descent I was only 500-1000 feet below profile).  The same behavior as before; the a/c reached a peak rate of descent of 5500 or 5600 fpm until around FL290 when crossover occurred and it leveled out somewhat to maintain 296 kts at a rate of around 3300 fpm.

 

Flight:

KFLL/10R N0458F370 BEECH5 BAHMA Y353 ZIN Y398 JOSES UA315 DUSAN TUGUL TUGU1A TNCA/11

ZFW 122.5 klbs

Block 19.2 klbs

Share this post


Link to post
1 hour ago, Hoffie3000 said:

Hello Bob,

that was the flight plan:

 

EDDH (Rwy23) to EDDF (Rwy07L)
AMLU9B AMLUH UM852 HLZ T157 KERAX KER07N

 

Alternate: EDDK

Distance: 334nm + 80nm (Alternate)

 

FL320

 

Cost Index: 80

ZFW: 55.1 / 20.1(ZFW%MAC)

Pax: 124

Cargo: 5000kg

Fuel: 6509kg

Trim: Up0.9

 

Airbus FMC normally calculate with the whole KER07N-Transition. But ATC online will see your Aircraft always at FL110/KERAX for better spacing and pick up planes to final Approach.

So I was set manuell for KERAX: 320/11000

 

But the nm difference between theory and practice can also be seen in every other flight. This is not limited to this route. 

 

Regards, Wolfgang

 

 

 

thanks, will check and give feedback

Share this post


Link to post

Today I have another flight from ESSA --> EDDF at FL380.

Again passing KERAX at FL110.

Now the difference between theorie and practice:

Theorie: TOD should be 81nm before KERAX.

Bus calculate TOD only 52nm before reaching KERAX.

So the Bus was 29nm to late starting descent and ends in the well known extrem sink rate.

 

For me, the descent looks behaved like in the picture.
Please excuse the crooked line 😎

Red line should be the best descent phath. 

The blue line show the actual Airbus behaviour.

descent.png.98b075a91d01b29e16413098766e2696.png

 

 

Share this post


Link to post

Moved out of the "General chatter (NO SUPPORT)" area.

Share this post


Link to post
On 1/31/2019 at 3:18 PM, Hoffie3000 said:

Fortunately, the first flight (EDDH-->EDDF) went without problems. The most striking are the changes in the colours of various numbers.
With the exception of the well-known "flaws" I didn't notice any new errors.
You can update to this version with a clear conscience.

 

The "flaws" I noticed:
The vPilot client (for VATSIM) is still not recognized if you load the Airbus directly from a saved "Turn Around State", or "Cold Dark State" in P3Dv4.4.

But after reinstalling the Airbus, the "Taxi State" is active and vPilot is recognized there.

Ok, if you know it, you do the known workarounds, but it's strange that after such a long time it still doesn't work. Even the old 32bit Airbus could do it.

 

Descent behavior:
Nothing has changed to good, the bus at the TOD still goes into a more or less violent nosedive, with sink rates >6000ft/min.

I looked at the map and measured why the bus is doing this and now I know that the bus has no other possibility with the current programming.

 

If you compare the distance from TOD to a given waypoint and FL, in my case KERAX /FL110, then the bus starts about 19nm too late with the descent!

So it has to go into a quasi dive to reach the desired FL at the given waypoint.

 

You can use the formula: (Flight Altitude,ft/1000)*3 calculate the TOD quite practically and usually comes to sink rates of about 2000ft/min -> 25000ft/min depending on the wind.

 

In this case the distance is to KERAX/11000ft:

TOD calculated, red arrow: (32000ft altitude- 11000ft KERAX)/1000) *3 = 63nm

TOD Airbus calculated, yellow arrows: approx. 44nm

This results in a difference of 19nm between theory and practice and is the reason for the strange descent behaviour.
I am sure, if you give the bus more distance for the descent, the descent behaviour will change positively.

 

Regards, Wolfgang

A319_ver1230_EDDH-EDDF12.thumb.png.95197d99aa17e2056dac68d65ab0b532.png

Translated with www.DeepL.com/Translator

 

 

Ok, now flying your route. First I had ToD at ~KERAX,

2019-2-1_22-19-8-440.jpg

then I set alt cstr KERAX FL110, now I have it at the same point as your yellow one.

2019-2-1_22-23-38-435.jpg

 

Can confirm the steep DES.
When DES, it was first ok with 3500ft, but then I had a very steep segment with 7400ft, then it was normal with 2200ft towards KERAX.
I sent it to the DEV.

Share this post


Link to post

Some possibly similar behavior I've experienced periodically periodically in the past happened again today.  I was descending on the DADES6 arrival into KTPA, passing KOKOH at 250kts (per STAR speed restriction landing south) and 11000 feet when I was cleared down to the IAF for rwy 19L.

 

By this time, I was slightly high on the path, and after dialing the altitude down to 2000 and pushing the button, the Bus entered DES and dove down for the green dot completely disregarding the speed bug, getting up to 280 kts and -4700 fpm while blasting past 10000 feet before I was finally able to arrest it at 9400 feet and regain control.  It seems that DES places a higher priority on the green ball than it does the speed - isn't it supposed to be speed protected (or am I misunderstanding it)?  For the record, I did manually enter the 250/13000 restriction at OLENE.

 

I've had similar incidents on initial approach when switching to DES prior to G/S capture while a little high, but this was the first time it happened where I was pretty sure it wasn't something I caused to go wrong.

Share this post


Link to post
4 hours ago, Mathijs Kok said:

is that with 1.2.3.0 or 1.2.3.1?

1.2.3.0 "base" installation, and obviously the various past times I experienced it would have been certain older versions, so it seems to be a long-running issue (probably not unrelated to the documented issues).

 

I'm on vacation/holiday until the end of next week so I won't get a chance to play around with the recent update until I get back home.

Share this post


Link to post

First flight with version 1.2.3.1 and I was really pleasantly surprised, the TOD was well calculated, it sank first with about 4500ft to reach the 340 KIAS target Speed in descent and then normalized.
I didn't need the speedbrakes for the first time :rolleyes:
Let's see what the other flights show :)

Share this post


Link to post

I've run a few flights with 1.2.3.1 and so far so good.  After passing TOD and initiating descent (i.e. from above the green ball), I've been getting a maximum -4400 to 4700 fpm in DES and about -3700 to 3900 fps in OP DES, which definitely "feels" much better.

 

I also haven't seen any low altitude DES dives ignoring speed restrictions that I mentioned earlier, although it's possible I haven't exactly recreated the situations that cause them.

 

TOC prediction on CLIMB PERF is still way off, though, as I had posted in another thread.

Share this post


Link to post

Indeed, please report in specific posts, a 'bundle' makes it very hard to handle it.

Share this post


Link to post
Guest
This topic is now closed to further replies.

×
×
  • Create New...