freddy_

I am running EZDOK 3 (specifically v3.0.1.84) with P3D v4.5 HF3. As a user of P3D v4.5, I am unable to use a higher version of EZDOK, but the v3.0.1.84 works perfectly fine with my setup and gives me no issues whatsoever. I have had no issues wit EZDOK and the latest Windows Updates. Be aware there is a bit of a learning curve with EZDOK if you're not familiar with it, but the default settings work well enough if you don't want to dive right in. That said, once you get the hang of it, it is extremely flexible and you are able to get very realistic results with it.

"...not some garish multi colored mess stuffed with browser ads" I could not have said it any better. 🙂

Ha. You're welcome. 10 years later huh! 👍

@albar965 OK. It's disappointing, but it is also understandable and fair enough. 👍 Once again, thanks for a fantastic program. Keep up the excellent work!

Sorry for revisiting an old thread. I have only just discovered Little Navmap. Wow, I have been missing out. This is a fantastic program! As someone who works in the IT industry, I know how much work has gone in to this. Thanks Alex! I am also experiencing this hieroglyphs/corruption issue with my Majestic Dash 8 (Training Edition) v1.025a in P3D v4.5 with HF3. I am using Little Navmap 2.8.12. Intriguingly, the first time I used Little Navmap with my Dash 8, flight plans made with Little Navmap, using the supplied Navigraph Airac cycle 1801 which comes installed by default with Little Navmap, did load in to the Dash 8 perfrectly. A few days later, it made sense to update Little Navmap and my sim with the latest Navigraph Airac cycle ... that being 2401 at the time ... to get everything synchronized nicely ... and from that point, flight plans made with Little Navmap have had the hieroglyphs/corruption issue with the Dash 8. A week or so later, I updated the Navigraph Airac cycle again to 2402, but the same result persists ... flight plans made using Little Navmap continue to show this hieroglyphs/corruption issue when loaded in to the Dash 8. A quick experiment shows that if I create a direct flght plan with only a departure and arrival airport (ie, no navaid or waypoint routings in the plan), then the flight plan appears to load correctly in to the Dash 8 (but, just because I see no hieroglyphs/corruption in such a short flight plan, with no navaids or waypoints in the routing, I can't really be sure). That said, as soon as you add any navaid or waypoint routing in to that flight plan, the hieroglyphs/corruption issue occurs when you load the flight plan in to the Dash 8. Based on these obvservations, I assume this issue could have something to do with the Navigraph Airac data and how the navaids and waypoints are exported by Little Navmap in to the associated Dash 8 compatible .fpr file? At the moment, I am happy to use Little Navmap to create the flight plans, and then manually enter them in to the Dash 8. But, I look forward hopefully to any updates on this issue, or fixes which may come with one of the next versions.

A quick search of these forums will find you some information. And, of course, there is the FCOM ("PMDG-NGX-FCOMv2.pdf" is installed on your PC in the /PMDG 737 NGX/Flight Manuals folder). And, here's a few web pages which should also help to get you started: http://support.precisionmanuals.com/kb/a109/weather-radar-troubleshooting.aspx This one is "Boeing specific" but provides good information nonetheless: https://www.rockwellcollins.com/~/media/Files/Unsecure/Products/Product%20Brochures/Radar%20and%20Surveillance/Weather%20Radar/WXR-2100/MultiScan%20ThreatTrack%20Quick%20Reference%20Guide%20-%20Boeing.aspx http://www.smartcockpit.com/download.php?path=docs/&file=Collins_WXR-2100_Operators_Guide.pdf

Thankyou kevinh for the correction. Always learning, always learning. The FCOM says "At or above 10,000ft MSL, set LANDING light switches OFF". The Airbus FCOM is similar, and, from memory the Dash-8 as well. There are other checks performed at 10,000ft as per the FCOM(s) as well. But you can see why I mentioned the horn at 10,000ft as a reminder to switch off the external lights. As for the cabin altitude warning horn being different from the altitude alert C chord ... hmmm, the pitch of each of the sounds is quite similar ... I just assumed. Now that I think about it, yes, the altitude alert C chord probably is a little more subtle (I'm not in the cockpit right now to test, so I'm going from memory). And, yep, I think they are indeed named differently ("Cabin Altitude Warning" versus "Altitude Alert C Chord") in the FCOMs as well. As I said, always learning, always learning. :smile:

I think Ralgh has it correct. From what you describe, it is the altitude warning horn. A horn will sound (sounds like a car horn) when the cabin altitude goes over 10,000ft, AND also when you are approaching your preset autopilot altitude. At 10,000ft it is a reminder not only about cabin altitude, but also about external lights that are on after takeoff (such as takeoff lights) ... you're at 10,000ft so it's time to turn those lights off. The horn should sound once, and once only, each time an altitude is reached (ie, once at 10,000ft and then once at any subsequent preset autopilot altitudes). If the horn continues to sound, constantly, then that is a warning about a cabin pressure problem and indicates immediate action needs to be taken to rectify the problem. In this situation the flight crew would put on oxygen masks and then do the CABIN ALTITUDE WARNING OR RAPID DEPRESSURIZATION checklist.

No, you did not miss an update. If you are referring to the Navigation Display (ND) and the different colored shading that's showing in the YouTube video in the original post, then it is showing TERRAIN, not weather.

Kostas, Thanks for your (valued) input. "Predictive" versus "Reactive" windshear alerts. I was not aware of that. Always learning, always learning. Interesting. Based on what you've said here, it does sound like my suggestion above may not work. But, then again, might. Hmmm.

Locate the "C:\...Flight Simulator X\HiFi\ASNext_FSX\as_srv\Voice" folder on your PC. In there you will find a file called "pwsalert.wav". If you play that file you will hear that it is the ASN windshear alert sound. All you need to do is rename that file (in other words, keep that file as a backup) and then replace it with the one from the PMDG NGX. The one from the PMDG NGX is in the "C:\...\Flight Simulator X\Sound\PMDG\737NGX\CAWS" folder and is called "PMDG_737_egpws_sirwsh.wav". Copy the PMDG one to a temporary location such as the desktop, rename it to "pwsalert.wav" and then move it from your temporay location and put in to the "C:\...\Flight Simulator X\HiFi\ASNext_FSX\as_srv\Voice" folder. I haven't tested this, but I think that should do it.

Why is it used? I found this post in the Tech/Ops forum on the Airliners.net web page. I still don't fully understand ISA DEV, but this post does clear up some of the questions. Temperature Deviation (I apologise this is not a clickable link; but for some reason I am unable to get the "insert link" option working when posting.)

Another reason for starting engine 2 first is as follows ... If there has been a reason to use the APU for an extended period of time, then usual practice is to turn a LEFT fuel pump on to supply fuel under pressure to the APU to extend the service life of the APU fuel control unit. If the fuel quantity in the center tanks is sufficient, then the left CENTER tank fuel pump is used to prevent a fuel imbalance before takeoff. However, if the fuel quantity in the center tank is not sufficient, then the left AFT tank fuel pump is used. In that case, whilst the APU is running, a slight fuel imbalance would be created. Starting engine 2 first subsequently draws fuel from the opposite (RIGHT) tank(s) first, and therefore helps to correct the fuel imbalance before takeoff. Although, that said, using the APU for extended periods of time these days is something most airlines do not do (for economy reasons), and most airports also have set rules advising against it as well (I believe for noise abatement and probably pollution reasons).

Hilarious indeed! Excellent work! ROFL.

Question: During pushback, how does GSX handle the situation where ATC advises, "Orbit 737 hold position, caution other traffic" when maybe another AI plane or other airport vehicle is approaching? In such a situation, does GSX recognise this and momentarily stop the pushback to wait for the plane/vehicle to safely pass? Or, does it ignore it and continue regardless? Or, perhaps the pilot (me) has to do something to initiate a temporary stop? Etc etc.