Unfortunately, my Wilco Airbus doesn't pass the filed waypoints accurately enough. So, it quite often happens, that RC doesn't recognized a waypoint to be passed and asks me to fly back to it before it allows me to continue with my flight plan.The only way to get this solved is to ask for a direct to the next waypoint.This is quite annoying since you always need to watch for each single waypoint whether it has been recognized as passed or not.Is there a way to get RC tolerating less accurate waypoint passings or is there any other solution for this problem (apart from not flying Wilco Airbus anymore, of course;)) Thanks very much for your help in advance! Regards,Tilo

Hi Tilo, Why is the Wilco Airbus not able to fly accurately enough to give you credit for passing a waypoint? I've flown Concorde at Mach 2 with RC4 and received due credit for passing waypoints. Where is the information for the Wilco CDU coming from? The same source as you provide to RC4? Unfortunately the 'credit' distance of 2 miles within 30 miles of your departure airport and 5 miles outside that distance is hard-coded and cannot be changed by the user. The problem appears to lie with that aircraft. Perhaps it's time to consider an alternative when flying with RC4.

Hi Tilo, I have used the Wilco Airbus Evo on a flight from EGGW to EDDB and have not had any problems with the aircraft not overflying the waypoints.At times the displays are screwed but that is another problem! Norman

I have the EXACT same problem with both the PMDG MD-11 and the PMDG 747.Sometimes it does a turn within 2-1 nm and RC4 fails to recognize it.This happened yesterday as I took off from Portugal LFRB and I had to ask for a direct.Of course it happened on the flight down there too, and I had the controller yapping non stop about altitude busting, not on navigation... In fact, I shot and dumped the body of the FISDO guy so if you aren't referred to them in the future, you know why.What I have noticed is that RC4 only credits waypoints at 0nm or passing DIRECTLY overhead, which is a problem with PMDG aircraft that starts the turn earlier on.Both flight plans that are loaded into the FMC and RC4 comes from the same source, FS Commander and all have the exact same AIRAC to work with, it is out of date (July 2011) but as long as it is the same, it doesn't matter.

Reading your answers, could it be possible that the navigation information RC4 is using is different from the one stored in the Airbus FMS?If this is the case, do you know how the both versions can be synchronised?I just tried to rebuild the scenery database in RC4 (using the respective button) but this worked quite fast (just a few seconds). I received the following two notifications only: 1. rc rebuilding r4.csv, running \makerwys.exe, 2.rc finished rebuilding r4.csvIs this all?

Twilbert: If that is all you saw your scenery rebuild is not functioning. Here are some things to check: If on Win 7 or VISTA be sure you have set up RC with a shortcut having set the shortcut properties to run as admin which is a program access level, different from a user access level. That is the same as right clicking on rcv4.exe and selecting run as admin. It allows RC to talk with FS via FSUIPC and also for the scenery rebuild allow it to access the FS folder and from within RC run makerwys.exe. Be sure you have entered the correct path to FS when asked during a scenery rebuild. I keep my path in a text file so I can copy the paste (ctrl-v) into the path dialog box during the build. My RC and FS are on the same pc. Here is what my path looks like: h:\program files\microsoft games\flight simulator 9 For a non-networked RC client to an FS host (both on the same PC) answer NO to the wide FS question and proceed. For an RC networked client to a host pc with FS you must run in this case only makerwys.exe in your FS folder directly first. When complete start RC and and from within rebuild the scenery data. This time answer yes to is this a WideFS installation and then proceed entering the network path to your FS folder. You can see makerwys running first by clicking OK to its first dialog box, then watching it count up runways and airports sometimes reversing the count and then increasing it again due to the way it works in handling add-on scenery. Then click OK. In RC you should see a message r4.csv built. Click OK. Then you see a message building a4.csv. Click OK. Then you should see a message like a4.csv built. Click OK. It is a good idea to wait about thirty second for any disk writes to finish. You can then close RC and it is ready to run. After a successful new install you must update FSUIPC and makerwys since they are newer than the distribution versions. Please see the link at the forum top. Then start rebuild the scenery database again using the non-WifeFS or WideFS procedures. To check that an update worked if necessary go to your FS folder. Find r5.csv and right click on it. Check the modified date to insure it matches the date-time you ran the procedure. Then go to your rcv4 or rcv4x data folder. Right click on r4.csv and a4.csv to check their modified date-time stamps. They should be very close to the time noted in checking r5.csv. I am adding a separate reply on syncing RC with an FMC/FMS.

About waypoint crediting and altitude monitoring: First, for large flight path direction changes, larger airliners will preemptively ahead of the waypoint start turning when navigation is coupled to an autpilot directed by an FMC or GPS. This depends on aircraft speed and the setting of the bank limitation. In RC terminal areas, that is within 30 nm of departure and 40 nm of arrival you must be within two nm of a waypoint and in the enroute portion five nm of the waypoint center. To correct the preemptive turning for large aircraft outside of these limits, try slowing the aircraft for these known high directional changes. Alternately revert to MCP control of heading to delay the turn slightly. You'll get a bit of overshoot as you manually turn on course. If you get a Resume Own Navigation command or report On Course from a NOTAMS situation, that means from your present position to the next checkpoint. This also applies to requesting the extended menu direct next checkpoint when granted by RC. Do not return to the original path because RC is monitoring your heading to see if it complies with the heading shown in the RC status area. In the case of weather detours, you can return to your original path and then declare you are back on course. For the occasional missed waypoint go to the extended menu (9), select direct checkpoint, select it from the list, and once again go directly from your present position direct to it. Know how on an FMC/FMS to move up the checkpoint if needed on the LEGS page and activate the change. Know how to do this in a GPS if necessary. The RC status area will show you the heading expected upon approval of the change. Another issue regarding waypoint credits is an outstanding ack of an ATC command. If you missed acking an ATC command, RC will not recognize a crossed credit waypoint. Yet another issue is performance of the RC/FS workstation. If a lot of resources are used by add-ons that can slow RC's monitoring and response performance be sure you have the latest add-on service packs and latest FSUIPC installed. In RC be sure on the general page that Display Text is disabled. Prerecorded Chatter should also be disabled ( it is just random stuff not related) and only AI Chatter and Interact with AI are enabled. Check out the RC manual regarding departure restriction choices preflight regarding choosing your own departure navigation within the first thirty nm. If your plan filed to RC has a waypoint within 30 nm of the departure airport you'll have to select altitude or no altutude restrictions. I this case No Departure Procedure will not be available. RC will not issue vectors and you will be expected to navigate on your own to the first waypoint outside of that boundary. For arrival after approach issues you your assigned runway you can elect to navigate an IAP to the selected runway on your own. RC will then not issue vectors and you'll have to get on final with your own navigation. If the airport has tower control the next RC response will be landing caution then clearance to land. Departure procedures with restrictions and IAP arrivals can assist in helping with terminal arrival and departure procedures stored in FMC/FMS/GPS databases. Regarding altitude monitoring: Some aircraft exhibit a tendency to delay or even briefly descend before climbing. This can trigger an RC warning. Very briefly delay an ack to an altitude command until the aircraft is properly behaving. RC must see a change in altitude of at least a hundred foot rate of climb or descent. To accommodate this you may have in the case of climbing need to slow your aircraft to allow it to pitch up to increase lift and your rate of climb. If you need to step climb to approach your cruising altitude initially file a lower altitude and then request change of altitudes enroute. Remember to put your correct class of aircraft in the RC general options page regarding prop, turboprop, jet, or heavy. To loosen RC monitoring constraints within departure and arrival check out the NOTAMS option in the manual. If you are cruising at or above 10,000 feet or FL100 for arrival about 40 nm out you will get a crossing restruction of 11,000 or 12,000 feet (FL110 or FL120) that must be met. If you do not comply RC will issue delay vectors until you do - period. The election of NOTAMS preflight in the RC controller page does NOT relieve you from this restriction. Correct altimeter pressure settings for the stage of flight is crucial to RC monitoring. See the manual section regarding local pressure and transition altitude-flight level settings. Unlike FS ATC whuich uses a global transition altitude of 18,000 feet, RC uses real world transition altitudes for each airport area. In the Controller page of RC you will see the transition altitude where altitude using local altimeter pressure is used changes to flight levels using 'standard' altimeter settings of 29.92 in. or 1013 mb in a climb or back to local pressure on descent. RC will present an audio voice stating "altimeter check" when a reference change is needed. Generally if RC commands an altitude in feet, local pressure as delivered by RC should be set. If RC commands a flight level (that's altitude in feet = flight level times 100 so FL110 is 11,000 feet with standard reference pressure) set your altimeter as appropriate. (The FS 'B' key for pressure setting is useless for areas where the transition altitude is other than 18,000 feet and with RC is not a good habit to use to set the altimeter.) Some airliner models have an EFIS control that will toggle between standard pressure and your set local pressure that let you set expected local pressure in advance such as while cruising in flight levels before you get to transition altitude on descent requiring change to local pressure. This keeps adjustment to a minimum. You can get depending on your weather application and how it applies changes your "expected" departure and arrival surface pressures from the METAR reports in advance of flying. Remember that navigation instrumentation is an aid to the pilot and navigation procedures must be adjusted to comply with ATC. For the early part of departure if receiving vectors it may be best to use MCP or manual AP control, or fully manual control. The same applies to arrivals. For syncing RC monitor waypoints to an FMC I am attaching a hint sheet based on FSBuild or similar flight planner. Pay particular attention to step 11. ----------------------FSB tips: 1. Include this line in FSbuild.cfg:NAVCHKDUPDIST=100This decreases the chance of using the wrong duplicate named local (to the airport) waypiont from a nearby airport. Local waypoint names are not exclusive. It decreases the database search when it is named in the route to within a 100 nm radius of your airport. You will find these in terminal procedures such as "D" number something within a SID or STAR to define a merge or turning point. 2. When doing a Auto Generate (Route) be sure the SR (Stored Route) button next to it is "up" that is not highlighted. Auto Generate will use a stored route if found by default and most are out of date with old waypoints and terminal procedures. Having Stored Routes off forces it to search a path with fresh data. (Now off by default in version 2.4.) **REVISED 6/16/11** 3. FS Build database updates will be exclusively released through navigraph.com. It should be part of the FMC data line. For those not familiar with Navigraph each subscription term (cycle) includes multiple format downloads at no additional cost. This is very convenient for aligning FMC/navigation equipment databases with the flightplanner so among other things ATC data and your nav equipment data should match as you send a plan to ATC and then load it including terminal procedures into your FMC. The 2.4 upgrade includes the thirteenth cycle of 2010. The FSB upgrade is free to 2.x version users and is available via your order history on simmarket.com. 4. Where an airport uses specific runways for different terminal procedures select the runway using an estimate based on weather and if the runway fits your aircraft requirements before doing the Auto Generate. This helps select the correct SID and STAR for the runway and direction of departure and arrival. 5. After the Auto Generate and/or first build look at the map created to spot any obvious errors. In the route grid look for any sudden non-sensible changes in direction or extremely long legs not in the correct direction creating a zig-zag in the map. (See item 6 following to correct). 6. Be aware there is an option you can set for each session titled "Build Route from Grid Table". It does not stick between sessions. This lets you build from an edited route grid that you may have modified without recreating the table with the same error on your next build/export. For example you might wish to drop an errant waypoint when proofing the map and rebuilding. 7. Sometimes the name of a procedure (SID/STAR) does not match the name exactly in a published route and the procedure will not expand into its plan waypoints in the grid table. You can click on the arrow in the SID/STAR box to see what close name is in the FSB database. (Another reason to keep up with AIRACS.) For example KMSP has a current real such as this one:http://flightaware.c...P/DP/WAUKON+TWObut the FSB database only has UKN2. (It does have UKN3 now with the latest available AIRAC update). If so in the route line just change UKN3 to UKN2 so it will expand. Here's a real route from flightaware.com for KMSP to KMDW: KMSP UKN3 DBQ CVA MOTIF3 KMDW that can be pasted into the FSB route line. If UKN3 or MOTIF3 does not expand in the route grid to individual way points look in the upper part of FSB in the airport section dropping down the SID or STAR box to get the available version and substitute that label in the route line and rebuild. Note that the SID and STAR dropdowns may follow the chosen runway in certain areas. 8. Sometimes it takes a second build to get the map to move and/or magnify. The mouse scroll wheel lets you magnify. Just click on the portion of the map you want to center on and scroll to magnify. 9. If you click on a line in the route grid table to highlight it, the waypoint on the map will turn red. This is useful for finding errant waypoints that cause an error in the path. That line can then be edited or deleted and a rebuild accomplished with the build option to build from the route grid table. 10. If you are running a weather program such as active sky, first build the route in FSB exporting to FS9 using an anticipated cruise altitude and specify the nearest aircraft profile. In AS get the weather you wish to use. (I always get the weather for the zulu time of the departure in FS since time of day affects weather characteristics). Import the plan into AS via the new route button, check the altitude and choose an appropriate true airspeed in knots (this is your no wind ground speed). Process the route. When it is finished click the button to print a hard copy of all. Use this AS navlog for METAR data at both ends and winds aloft and temperature aloft that can be used for FMC data. (You'll also get your estimated average wind at your specified altitude - handy for FMC data.) Leave AS running. Now go back to FSB and your chosen aircraft profile. Enter the surface temperature from your departure METAR, then estimated total taxi time, hold time, and extra time (sometimes called discretionary fuel). Now turn on again your FS9 export along with any FMC export you might use. Rebuild and you'll see the messages regarding the export completion. On the route selection on the left which brings up your route window select the navlog tab and click the .pdf to save the navlog in a file or the print button to get a hard copy so you can easily reference the estimated fuel and other data. This estimated fuel has now taken into account your winds aloft data - no need to enter it in FSB. Now that you have the hard copy and exported your route, you can first optionally save the plan by selecting flightplan window, then clicking the category tab, then select user category. Now click file, save from the menu bar. The name you might want to embellish. Click Save Route To User Flight Plans. For another session, you can recall this working plan and just build. 11. If you are using an aircraft with nav equipment that has its own terminal data procedures in its nav equipment (think FMC) you might wish to use step 6 above to take out the waypoints of the terminal procedures keeping just the transition points and build and export with just them. This easily in most cases lets you select the SID and STAR assigned by ATC on your nav equipment by providing a clean legs list in your nav equipment. If you need ATC to monitor the waypoints of the terminal procedure than just export all. To keep ATC and you nav equipment in sync, you might consider importing the full plan into your nav equipment and not using your nav equipment procedure database. This is kind of long but through experience I've described some tricks I've used watching out for any pitfalls. Be sure to check the FSBuild forum for updates. ----------------------------------

In summary I guess we can say if you do not fly a default aircraft styled aircraft (GPS FS default GPS navigation), do not use RC4...I frequently do not get credited for waypoints crossing unless I get a reading of 0 (Crossing over it.)On the 747 I was thinking of setting the bank angle to a max of 10-15 degrees but not sure how much good that will do, usually it is on automatic.

i don't think you can say that at all. there are thousands of people, flying third party planes, progressing checkpoints routinely. if this was a problem, i think there would be many more posts and emails about it to me. if you can duplicate the problem, make a log. important! click debug before loading the .pln if the .pln rc is going by, is different than the plan you are loading into your third party plane, the plane is going to different points (lat/long) than what rc thinks you are going to. but i digress after you miss some checkpoints, zip up the log, send it to me, and tell me what checkpoints you missed. i'll look at the log, and tell you where you were when you missed it, and where you were supposed to be. jd ps. i'm assuming (dangerous i know), that you are flying at 1x or 2x. never more. no 4x, or 8x

No, that is not correct. I use the PMDG 737NG series but using the sync technique options available that I described in paragraph 11. Now the PMDG will not directly import an FS flight plan. I use FSBuild as I noted and when I export to FS9 (for RC) and the PMDG FMC the coordinates in plan now match. RC gets the waypoint coordinates from the plan. PMDG does not support exporting a plan but will only save in its own format. If you want terminal procedure waypoints to match then in the case of FSBuild you can update those with a subscription to Navigraph and included are as many download formats as you want at no additional cost for that subscription period so the PMDG terminal procedures will match the FSBuild 2.4 procedures. Navigraph supports other planners as well. (FSB comes with the 13th cycle of 2010 included from Navigraph.) You can support the whole plan into RC or just the common terminal procedure waypoints - you're choice as to how you want ATC to control you. I noted that in paragraph 11 of my long post in this thread. Either way you can get RC and FS and FMC waypoints in synch. It requires having a planner that supports both the FMC and FSX or FS9. Here's a route I put into FS Build - KATL DAWGS SPA J14 RIC RAVNN1 KBWI and it expanded without editing waypoint options like this near arrival: and again without removing waypoints here is the FS9 plan for RC; [flightplan]title=KATL to KBWIdescription=KATL, KBWItype=IFRroutetype=3cruising_altitude=39000departure_id=KATL, N33* 38.12', W084* 25.41',+001026.00departure_position=27Rdestination_id=KBWI, N39* 10.31', W076* 40.06',+000146.00departure_name=HARTSFIELD_-_JACKSON_ATLANTA_Idestination_name=BALTIMORE/WASHINGTON_INTL_THURwaypoint.0=KATL, A, N33* 38.12', W084* 25.41', +01026.00,waypoint.1=DAWGS, I, N33* 55.30', W083* 43.20', +18000.00,waypoint.2=SPA, V, N35* 02.01', W081* 55.37', +39000.00, J14waypoint.3=BYJAC, I, N35* 57.27', W080* 09.02', +39000.00, J14waypoint.4=GSO, V, N36* 02.44', W079* 58.34', +39000.00, J14waypoint.5=JAXSN, I, N36* 42.38', W078* 47.23', +39000.00, J14waypoint.6=CREWE, I, N37* 01.22', W078* 13.03', +39000.00, J14waypoint.7=RIC, V, N37* 30.08', W077* 19.12', +39000.00,waypoint.8=PEGBY, I, N38* 04.43', W077* 12.03', +38000.00,waypoint.9=SABBI, I, N38* 22.54', W077* 08.15', +32000.00,waypoint.10=NICCO, I, N38* 30.53', W076* 58.35', +28000.00,waypoint.11=OTT, V, N38* 42.21', W076* 44.41', +22000.00,waypoint.12=RAVNN, I, N38* 48.15', W076* 31.04', +18000.00,waypoint.13=NAVEY, I, N38* 58.10', W076* 35.29', +15000.00,waypoint.14=LURRL, I, N39* 04.30', W076* 49.39', +10000.00,waypoint.15=ZAKTO, I, N39* 08.06', W077* 03.35', +06000.00,waypoint.16=KBWI, A, N39* 10.31', W076* 40.06', +000000.00, and from the 737NG this would be the data applied (it is from a different database source); STAR RAVNN3 FIX OTT 9000 FIX RAVNN 6000 FIX NAVEY FIX LURRL FIX ZAKTOTRANSITION CSN FIX CSN FIX SACCO 16000 FIX FIMBO 16000 FIX UDUDE AT OR ABOVE 14000 FIX REXEE 12000TRANSITION RIC FIX RIC FIX PEGBY FIX SABBI FIX NICCO 12000 The two transitions, either one or neither could be specified in the FMC. It is 41 nm after leaving RAVVN. In selecting the FMC arrival STAR you will be on course to NAVEY but RC approach will contact you before NAVEY with an assigned runway which you can acknowledge. You can then get off hnav and use MCP HDG, SPD, ALT to follow vectors from RC or choose an IAP to the assigned runway, add the transition in your FMC and the runway approach and let the FMC guide you all the way in. In this case FSB mapped the RIC trsnsition. And here it is from the 2007 STAR chart: (RAVVN3 is the current STAR. I plots the same in FSB which still has RAVVN1 along with 3 in its database from DEC 2010. This was a flight I did back in 2007 using the 738NG I believe.) You can see the synch. Now noted on the FAA chart for certain runways it states expect vectors from RAVNN which RC will do. Actually RC will pull you off the STAR shortly after RAVVN to line you up for the active runway whatever it is. It looks like RC will vector you to a base intercept right or left of KATL possibly joining s downwind first. See nearside-farside approaches in the RC manual. Now at NAVEY that is a pretty sharp turn. You'll be at around 180 knots or less and you if not taking vectors will have to use HDG to cross it within two nm but if you are getting vectors or electing to do it all with an IAP RC will not be monitoring after NAVEY. In this IAP case you would follow the complete finish stored in the FMC selecting the ILS but realistically as noted on the STAR you would probably take vectors. I still load the ILD runway approach to look at on the NAV DISPLAY or EHSI to keep situational awareness for speed and flaps schedule and where the intercept is to the localizer. I hope this clears things up.

In summary I guess we can say if you do not fly a default aircraft styled aircraft (GPS FS default GPS navigation), do not use RC4...I frequently do not get credited for waypoints crossing unless I get a reading of 0 (Crossing over it.) On the 747 I was thinking of setting the bank angle to a max of 10-15 degrees but not sure how much good that will do, usually it is on automatic.

Well I do have a missed checkpoint log where it missed the very first checkpoint, which I remember was 1-2 nm miles away from at that moment running at 1x.I do use time compression elsewhere up to 8x, but only for straight sections, RC miss that at times but 95% of the time it turns out okay.As for turns, I use 1x, otherwise PMDG might miss waypoints too and resort to a "snaking" motion like a torpedo searching for its target.For planning I used FlightSim Commander and I exported the same plan, with a spelling mistake in the name but it worked regardless.

Thank you all for your help and information about this topic. It seems there is a very friendly and supportive flight simulator scene out there.The information received was very valuable for me.So, for instance, thanks to you I managed to rebuild the DB scenery and will try whether this helps this afternoon.I think another reason could be the point not to fly faster than with factor 2 (JD mentioned that). I will try this as well (actually, I often use factor 4).I will let you know whether this both helped. Regards,Tilo

Waypoints within one or two miles from takeoff can be troublesome with large fast aircraft. They also can be inserted by some utilities even when they are not correctly in the flight path such as VORs or NDBs on the airfield. Many of these close waypoints are 'soft' to provide path limits rather fly-over points. Some are there in the case of VORs to source an intercept radial from the VOR. In a planner that subscribes to AIRACS as a digital feed, a special soft waypoint, not unique in the global navigation system, is often assigned as a merge or curve guidance intercept to a radial. They typically are labeled Dnnn. Some planners and FMCs include those in their databases. For RC purposes it might be best to drop those very close in waypoints if it is hard to navigate the path within two miles of them. Real world ATC on a case by case basis by airport may give more leeway. If you are running ASE in FSX in DWC mode, that takes a large number of windows communication resources and can slow RC's monitoring of your position. (FSUIPC4 updates and the latest ASE service packs address performance in part.) In this case even 2X can be iffy.

I think another reason could be the point not to fly faster than with factor 2 (JD mentioned that). I will try this as well (actually, I often use factor 4).I will let you know whether this both helped. Regards,Tilo

x4 won't be a problem with waypoints in a near straight line but if you are making big turns then you MUST reduce to x2 maximum and preferably x1. Try a flight at x1 and if things go well then you know the problem is time acceleration and not RC.

x4 won't be a problem with waypoints in a near straight line but if you are making big turns then you MUST reduce to x2 maximum and preferably x1. Try a flight at x1 and if things go well then you know the problem is time acceleration and not RC.

I just tried a flight with tight waypoints and x2 and it worked without problems (I used the Wilco A319) while I had the usual problem when I flew some tight turns with x4.So, for me, the reason for the issues experienced is found. From now on, I only use x4 with waypoints in a near straight line and switch down to x2 (or x1) if turns need to be flown.Thanks very much for the tip.