777 OOM - depleted VAS (my brand)

[CaptKornDog 284]

Some additional data:

 

KJFK-KLAX with the 1502 NAVDATA folder installed, but 1309 SIDSTARS folder installed: VAS leaking observed

KJFK-KLAX with the 1309 NAVDATA folder installed, but 1502 SIDSTARS folder installed: VAS leaking observed

KJFK-KLAX with the 1309 NAVDATA and SIDSTARS folders installed: VAS leaking NOT observed (just checking again here for repeatability, which appears to be successful)

 

Back in town, will continue to whittle down and isolate files within those folders.

[CaptKornDog 284]

Last data point for the evening:

 

KJFK-KLAX with

 

airports.dat only including:

 

"KLAX 33.942495-118.408070
KJFK 40.639750 -73.778925"

 

remainder of NAVDATA folder is from AIRAC 1502; and ONLY KJFK.txt and KLAX.txt in the SIDSTARS folder from AIRAC 1309: VAS leaking NOT observed

[pcubine 143]

airports.dat only including:

 

"KLAX 33.942495-118.408070

I am about 2 hours from the end of EDDF-KIAH with FSX scenery settings very high to see how far I can push it without an OOM. Anyway...

 

Back to EDDP-KLAX or maybe VHHH-KLAX. I can try that tonight using 1502 with airport.dat from 1407 for KLAX. What's the idea behind changing KJFK.dat and the SIDSTARS .txt files for KLAX and KJFK?

[CaptKornDog 284]

Really just trying to figure out if I can identify which file(s) are creating the problem.

 

Letting the following scenario run while I'm in the office today:

 

KJFK-KLAX with the 1309 airports.dat file (manually edited so that only KJFK and KLAX are the only two airports listed), remainder of NAVDATA folder files are straight 1502. All airport .txt files in SIDSTARS folder reinstalled and are 1502 EXCEPT KLAX.txt, which is 1309. No VAS leaking when I left it an hour in, was a solid 2.50-2.55 GB.

 

So maybe for this test scenario I've narrowed it down to airports.dat and/or KLAX.txt. Doing a find difference between 1309 and 1502 KLAX.txt, naturally, has about 100-200 differences from waypoints, procedure changes, etc.

[downscc 1,327]

You hypothesis is 1502 KLAX sidstar file is causing VAS leak?  Interesting and I look forward to your results.  Please refresh my memory, are you using FSX or P3D?

[CaptKornDog 284]

You hypothesis is 1502 KLAX sidstar file is causing VAS leak?  Interesting and I look forward to your results.  Please refresh my memory, are you using FSX or P3D?

FSX SP2 (non-Acceleration)

[CaptKornDog 284]

Letting the following scenario run while I'm in the office today:

 

KJFK-KLAX with the 1309 airports.dat file (manually edited so that only KJFK and KLAX are the only two airports listed), remainder of NAVDATA folder files are straight 1502. All airport .txt files in SIDSTARS folder reinstalled and are 1502 EXCEPT KLAX.txt, which is 1309. No VAS leaking when I left it an hour in, was a solid 2.50-2.55 GB.

 

So maybe for this test scenario I've narrowed it down to airports.dat and/or KLAX.txt. Doing a find difference between 1309 and 1502 KLAX.txt, naturally, has about 100-200 differences from waypoints, procedure changes, etc.

 

Completed this test successfully, no VAS leaking observed.  2.51 GB when I reached California.

 

Next test this evening will be KJFK-KLAX with full 1502 airports.dat and 1309 KLAX.txt, full 1502 remaining SIDs/STARs.

[CaptKornDog 284]

Alright, two more tests this evening:

 

KJFK-KLAX with full 1502 NAVDATA (including airports.dat) and SIDSTARS except KLAX.txt (which was 1309): No VAS leaking observed, stable at 2.53 GB for 2 hours before I ended the test.

KJFK-KLAX with full 1502 NAVDATA AND SIDSTARS: VAS leaking observed at about 225 MB/hour.

 

Between those two tests, that pretty much is suggesting that something in KLAX.txt is causing VAS to bleed when filed as the destination in the FMC with newer AIRACs.  This could be true for other airports, who knows, but haven't seen any other ones yet in my experience.

 

Now going through the hundreds of differences between the two files is going to be quite a challenge to isolate it further...not to mention explaining why it's fine on my NGX.

[pcubine 143]

Between those two tests, that pretty much is suggesting that something in KLAX.txt is causing VAS to bleed when filed as the destination in the FMC with newer AIRACs.

Tomorrow night I will do VHHH-KLAX with the 1407 KLAX.txt and see what happens.

 

Question. Earlier today I tried to copy/paste the 1407 KLAX.txt to SIDSTARS. It would copy but not paste to SIDSTARS. If I open KLAX.txt all the line will copy and I imagine they will paste to KLAX.txt in 1502. I wanted to verify this before I pasted 1407 KLAX.txt all over the place.

 

Thank you.

[CaptKornDog 284]

Hmm, that's an odd one. I'm able to interchange KLAX.txt in my SIDSTARS folder without problems.

[pcubine 143]

Hmm, that's an odd one. I'm able to interchange KLAX.txt in my SIDSTARS folder without problems.

I don't see anything on the Internet that concerns this situation. When I copy the file name or contents of the file, the paste option is grayed out. If I do the copy, paste is not even listed on the right click context menu when I go to paste it. So I guess I will install 1407 again. I thought this was 2015 not 1955.

[pcubine 143]

Hmm, that's an odd one. I'm able to interchange KLAX.txt in my SIDSTARS folder without problems.

I had to select the file, click on Edit in the folder menu, select Move To Folder...and then navigate to sidstars and click copy. Seems okay now.

[CaptKornDog 284]

Flying KJFK-KLAX currently with full 1502 NAVDATA AND SIDSTARS except KLAX.txt.  However, I'm running with 1502 fix and runway entries with 1309 SIDs, STARs, approaches, and gate entries in KLAX.txt.  No VAS leaking observed about 2 hours into flight.

[MAXM958 2]

As noted above this is about my brand of OOM (depleted VAS) issues that I've seen recently.  I stress this because as we all know FSX's VAS challenges can be personal as hairstyles (in my case, no hair, as dictated by nature).

 

I just wanted to post this in case someone else is experiencing something similar, this is an option to try. 

 

I am on Windows 7 64bit, and I use:

Many ORBX regions and airports as well as Global and Vector (not updated yet)

FS2 Crew (NGX & 777)

GSE

UTX

ASN (networked) w/ REX 4 textures (1024 x 1024)

My LOD is set at 4.5 and I use DX-10 (Steve's DX10 fixer)

 

UT2 100%

Road, Shipping, and Airport Vehicles set at 14%

I use Scenery Explorer (I think that's the name) to disable regions/sceneries I'm not flying into.

 

I have my VAS under control, but occasionally I will experience a VAS leak, as in I can sit in one place (parked at a gate) and watch my VAS usage grow until the FSX OOMs. 

 

-When I have this problem it typically affects both the NGX and the 777.

-It affects both default and addon airports (VAS "leaks" at default airports at a slower rate).

 

 

I first noticed the problem trying to fly into KSEA with the ORBX PNW region enabled - I got the "ding, ding" warning and my monitor almost lost its life (thank goodness I calmed down)

 

After much frustration, and slow elimination of the usual suspects I narrowed my version of the VAS creep to only occurring when using ASN.  I could run the T7 or NGX for 24 hours with my set up with FSX Real time weather with no issues, but if I used ASN, my VAS would grow from the initial load of around 3.043 (used VAS) to OOM in about an hour or so.  I talked to the Hi Fi guys and they were not able to help me. 

 

Long story short I ended up having to uninstall ASN and reinstall it and bingo, my VAS usage sitting at KSEA in the T7 or NGX w/ UT100%, FS2Crew, GES, UTX, and ORBX PNW grows from 3.043 to about 3.389 and stays stable (max period I tested was 24 hours)  After this I was able to fly in and out of KSEA PNW, or any of my other add-on airports with no issues. 

 

Then I upgraded the T7 to SP1b and C and purchased the 300ER and boom the problem came back - I was on my way from KWMH PNW to New Orleans default (KMSY) in the T7 and "ding ding" OOM, my monitor's life was threatened once again.  I checked a few things and finally said "last time uninstalling and reinstalling ASN worked to cure my VAS "leak", let's try it again"  Happy to report the annoying VAS hole is plugged (little humor ) and no longer leaking. I'm back in the air and flying where ever I wish and landing with no OOMs.

 

So bottom line for me is this, on my setup FSX appears to want something that ASN installs to be installed after the T7 is installed/upgraded on my system.  I hope this helps someone if they are experiencing something similar or maybe gives them some ideas to try or sets off the "aha" light bulb for some reason.  OOMs are extremely frustrating and investigating them is equally frustrating so I just wanted to throw a little bit more knowledge onto the knowledge pile. I know there is nothing new in here, but sometimes just seeing the same info presented in a different fashion can make the difference.

 

Let me tell you of the ultimate flight simmer's fantasy - ok, maybe the second ultimate. The ultimate fantasy is that you're over the Atlantic at FL360 and all of a sudden you are somehow transferred from your simming set up with the PMDG 777 to a real 777 flight deck and to boot you have 20,000 hours in type.

 

Barring that, and closer to reality, is the fantasy that we wake up one morning, go to the AVSIM frontpage and see Tom Allensworth's post "BREAKING NEWS, BREAKING NEWS!!!" FSX VAS limitation solved!!!!!

 

Maybe...

 

Richard

Hi Richard,

 

Congratulations to your useful and well written post !

 

After PMDG SP1d  has been installed along FTX vector and FS Global 2010 I've passed to have OOM issues ( VAS beyond 3.45..... ).

 

I'm going to test what you have been POST here.

 

 

Thanks for sharing with us.

 

Warmly,,

 

 

Marco Aurélio

[JRBarrett 3,078]

Flying KJFK-KLAX currently with full 1502 NAVDATA AND SIDSTARS except KLAX.txt. However, I'm running with 1502 fix and runway entries with 1309 SIDs, STARs, approaches, and gate entries in KLAX.txt. No VAS leaking observed about 2 hours into flight.

Here is something interesting from real world aviation. I maintain several aircraft for a 135 charter operator. I am responsible for loading the monthly FMS database updates - which are supplied by either Jeppesen (for Rockwell Collins systems) or Honeywell for their own FMS models.

 

One of the aircraft is a Gulfstream G-200 with a Collins Proline 21 FMS - pretty much state-of-the-art, though this particular installation is 6 years old. We subscribe to the Jeppesen worldwide database for this aircraft, as it does a lot of international trips.

 

Never had an issue loading the Nav Data updates until last month, with cycle 15-01. I normally download the data from the Rockwell Collins web site to a USB thumb drive, which is then plugged into the data port in the aircraft. I then configure the two FMSs to load the new database from the thumb drive, and walk away. It typically takes about 45 minutes, after which the FMSs reboot, and the new database shows on the Ident screen.

 

But... Not this time. After 45 minutes, I went back to the aircraft to find... The two FMS CDU screens blank, except for a single text message "OUT OF MEMORY"!!

 

After an initial "WHAT THE..." moment, all I could do was to start laughing, considering the utter irony of the situation - which only a devoted simmer could appreciate. I had just literally OOMed a real aircraft!

 

Anyway, a call to Rockwell Collins tech support revealed all. The worldwide navigation database has been growing enormously over the past few years, with dozens of new RNAV procedures being added every month. The long and short of it is that the world database will simply no longer fit in the available NVRAM memory of specific Proline 21 FMS modules manufactured before approx 2010. We are now facing a very expensive hardware update to the two FMS modules to add more NVRAM if we want to use worldwide Nav databases on this aircraft. The short term solution is to either load a regional database (North and South America only) or one of two truncated worldwide databases that Rockwell Collins has made available for aircraft operators in our situation. Unfortunately, the truncated databases make it impossible to have western and eastern hemisphere airports loaded at the same time - which makes trips from North America to Europe impossible - so we have no choice but to do the hardware upgrade.

 

In any case, if the 15-01 database is the "straw that broke the camel's back" for real aircraft FMS systems, I wonder if something similar could be going on in the simulated FMS for products like the 777?