Pro Avia

FS ATC is far from perfect. This also holds true for many of the add-on ATC programs. When given a radar vector and told to resume own navigation, maintain the heading given until you intercept the planned route. Then turn to a heading to follow that planned route. The "resume own navigation" is not an instruction to turn to whatever heading you feel like to intercept your route or to proceed to the next fix - it's a heading to intercept your route. Once back on your planned route, if you happen to get off course, you can expect ATC to give you a radar vector/heading to re-intercept your route. Let's look at a relatively simple flight plan - KPHX to KLAS. Put the following route into the FS flight planner: KPHX DRK BLD KLAS. Use a B737 and an altitude of FL320 select IFR. After inputting the route, save the flight plan, load the flight plan and obtain your IFR clearance from clearanfe delivery. After departing Phoenix (KPHX), ATC should give a radar vector to the north to intercept the route to Drake VOR (DRK). Fly that radar vector until you intercept the planned route and follow ATC instructions for altitude. Once you intercept the route, turn to follow the route to DRK. From DRK, proceed to Boulder VOR (BLD). Somewhere near BLD, ATC will give you descent instructions and possible radar vectors to set you up for your pending arrival at Las Vegas (KLAS). Follow ATC instructions, intercept the approach course and land. Use the FS map or a moving map program (LittleNavMap, Plan-G, etc) so you can see the route and monitor your progress. I am assuming you already know how to navigate VOR to VOR and can intercept your planned route. Try the above route and let us know how it works out.

As far as I know, default ATC and all of the addon ATC programs assume you are operating in a radar environment. As such, position reporting is not done. In a radar environment, ATC knows your position and altitude at all times. Given this, in the simulator, ATC is not going to ask you your position or altitude. If you follow the radar vectors after takeoff, does ATC ever give a heading and then say "resume own navigation" or some such instruction? If so, that's your clue to begin navigating on your own. You follow their heading instructions and intercept the course/route depicted in your flightplan.

Have you searched at the Captain Sim site? https://www.captainsim.com/cgi-bin/products.pl?action=showliveries;product=c131;page=14;q= Search by Keyword. No idea if the download links are still active.

Placeholder for Google ads? On my tablet, I see a Google ad there.

Are you using rudder pedals? If so, what brand/model? When is the last time you calibrated the rudder pedals? Slight application of the pedals should allow less brake application/force to be applied, just like in a car. If that isn't the issue, and the wheels locking up are only happening on your setup, I guess you could experiment with the brake scalar settimg in the cfg file. Although you then become a test pilot and official support for the aircraft braking/anti skid system for this aircraft might become limited.

Same basic speeds in the Lear 35, Falcon 10 and Falcon 20. If the anti skid was still active below these low speeds, you wouldn't be able to brake the aircraft to a complete stop using the brakes.

This gauge sounds great! May I also get a copy of it please? Thanks in advance!!!

FSNav to PMDG module is available right here at Avsim.http://library.avsim.net/esearch.php?DLID=...hor=&CatID=rootCheersGene

I'd be interested in knowing if it's possible to change the "N" number text color also. I've tried the above with no success too.Additionally, is it possible to not display the default MS "N" number on the aircraft and paint the "N" number wherever you want it to be? If so, will ATC use the listed "N" number in the aircraft.cfg file?Thanks in advance for any assistance!Gene

Changing the gauge string from "PPH" to "pounds per hour" seems to give a reasonable FF rate - based on the fact that these are MS default aircraft.In testing:- On ground at idle thrust, showing 975 PPH/engine, 1950# total fuel onboard - engines flamed out (ran out of fuel) at 59 minutes 30 seconds.- In flight, FL350, showing 5000 PPH/engine, 10002# total fuel onboard - engines flamed out at 1 hour 0 minutes 15 seconds.While the fuel flow rates may not by exact (or maybe not even close) to the RW aircraft, at least the gauges now "appear" to show a somewhat more reasonable fuel flow - 975 PPH at idle versus 122.8 PPH at idle (same holds true in cruise).__________I'm still looking into the standby altimeter. No major breakthrough yet.__________The click spots for radio tuning do work correctly in the 2D cockpit. I'm not sure how to tweak the click spots in the VC without altering them in the 2D cockpit (at least I haven't been able to find a way). Maybe someone else can have a look and figure this out.Gene

>> ...............>>***** Hi Chris>>>>Thanks for pointing out these two items. After looking at>the>>default ECAMS files, the FF data as "%" is easily changed by>>editing the appropriate BMP file.>>>>I think the fuel flow indicators are totally incorrect. It's>>not just a decimal point error. Obviously a fuel burn of>only>>122.8 PPH on the ground it way too low. But I thought that>>1228 PPH was a little too high. After looking at the ECAMS>XML>>file and referencing Arne Bartel's tutorial again, it>appears>>the "GaugeString" line referencing fuel flow in the>>"ecams.xml" file contains an incorrect parameter. I'm still>>playing around with finding the correct entry. So far I can>>get the FF per engine to 975.0 PPH (notice the decimal>>location) at idle on the ground at LAX.>>>>>Gene>>> I had mentioned the "backwards arrow" in the A321 and wrong>TAS in the 737 in my "Good, Bad, Ugly" thread. Others noted>you had fixed them.>> The correct fuel flow should be easy to set from the>appropriate XML A: fuel flow variable. However, I wouldn't>be surprised but what it shows too high in cruise (possibly>also a bit high in idle). Zero Lift Drag of the A727 and B737>are about 3X realistic at cruise Mach. >> The correct indication will drain the tanks in the>appropriate time. If there is 10,000 lb of fuel remaining, and>each turbine is using 5000 lb/hr then the tanks should run dry>in one hour. >> Ron>Hi RonThanks for refreshing my memory on your "Good, Bad, Ugly" thread. I had remembered reading about the B738 TAS and A321 wind arrow, but couldn't find your post. If it's okay with you, I'd like to credit you with finding these errors in the readme of my download (if/when I release an update).The fuel flow gauge string is as follows in the default:%((A:TURB ENG1 FUEL FLOW PPH, PPH) abs)%!5.1f! I can't find a valid reference in the "units.txt" file in Arne's tutorial for the second "PPH" in the above string. However, there is a "pounds per hour" reference. If I substitute as follows:%((A:TURB ENG1 FUEL FLOW PPH, pounds per hour) abs)%!5.1f! I no longer show an idle FF of 122.8, but of 975.0. This new value seems more plausible as it's in the same ballpark as the B738 at idle and 122.8 is way off. I still need to do more testing though over the coming weekend. I'll start by using your method above...Again, thanks for bringing to light the B738 TAS and A321 wind arrow anomalies.Gene

>>***** Hi Rhett>>>>I believe the standby altimeter is indicating the correct>>altitude. However, the digits are moving while the altitude>>needle is rotating (which is not correct). The digits should>>stay fixed until the next thousand/ten thousand foot>>increment. I'm looking into it, but not having much success.>>>>On closer inspection, I too have noticed this behavior with>the stby altimeter. But, do you think the digit moves slowly>by design? Or do you think in real life, the gauge is>supposed to wait until you hit 30000 feet to tick over to>'3'?>>Rhett>>AMD 3700+ (@2530 mhz), eVGA 7800GT 256 (Guru3D 93.71), ASUS>A8N-E, PC Power 510 SLI, 2 GB Corsair XMS 3-3-3-8, WD 250 gig>7200 rpm SATA2, CoolerMaster PraetorianHi RhettHere a link to another A.net picture - http://www.airliners.net/open.file/0859042/L/In this pic, the standby altimeter is indicating about 20,500'. The zero to the right of the "2" is not rotated at all. In the FSX default A321 it would show about half way between "0" and "1".I'm hoping to have time this weekend to look into this further.Gene

***** Hi RhettI believe the standby altimeter is indicating the correct altitude. However, the digits are moving while the altitude needle is rotating (which is not correct). The digits should stay fixed until the next thousand/ten thousand foot increment. I'm looking into it, but not having much success.In your example above, the ten thousand foot window has moved the number "2" ninety percent of the way toward the next digit ("3"). In so doing, when the standby altimeter is trying to display 29,000', it appears that the "2" has already become a "3" (and looking as if it's displaying 39,000'). Okay, so I've almost confused myself in trying to explain what is happening - but just try it out and I think you'll see what I mean (I hope - :-) ).***** Hi ChrisThanks for pointing out these two items. After looking at the default ECAMS files, the FF data as "%" is easily changed by editing the appropriate BMP file.I think the fuel flow indicators are totally incorrect. It's not just a decimal point error. Obviously a fuel burn of only 122.8 PPH on the ground it way too low. But I thought that 1228 PPH was a little too high. After looking at the ECAMS XML file and referencing Arne Bartel's tutorial again, it appears the "GaugeString" line referencing fuel flow in the "ecams.xml" file contains an incorrect parameter. I'm still playing around with finding the correct entry. So far I can get the FF per engine to 975.0 PPH (notice the decimal location) at idle on the ground at LAX.***** AllIf I can successfully "fix" the fuel flows and the standby altimeter, I'll release a new version of the fix. I guess I should clarify that I know very little about how to program any of these gauges. So far I've just been lucky in finding the errors and correcting them. No promises on if/when the new "fix" will be available.Anything else in the A321 gauge set that might need tweaking?CheersGene

Hi RhettThis is my first post here at Avsim. I'll admit to being a long time lurker here though - for the better part of five years. :-shyThe file you reference is my "fix". In addition to correcting the track indicator on the A321 ND, I also corrected the wind indicator arrow. Here's the reference picture on A.net that I used - showing the MFD (ND) and PFD on the copilot's panel of an A321.http://www1.airliners.net/open.file?id=0437763&size=LThe wind on the ND displays the wind direction in relation to the aircraft's nose (heading). Displaying the wind relative to true north would diminish situational awareness for the crew.Forecast winds aloft are given in degrees true. However, a pilot would report the wind in degrees magnetic. And, the wind given by ATIS/ATC for an airport is in degrees magnetic also.The "fix" changes the displayed wind from degrees true to degrees magnetic (which is what the aircraft heading is displayed in). Additionally, it also corrects the wind arrow display from relative to north (360