FSDreamTeam forum
Products Support => Vancouver CYVR support FSX/P3D => Topic started by: G.Bosak on March 11, 2013, 03:10:25 pm
-
Hi Umberto,
ILS 26L "IFZ" should be placed 9,2DME from NOXOB
08L doesn't have the loc course 282 anymore it is 283° meanwhile.
I didn't have the time to check all runways yet, but i hope you'll have an eye on that. thank you
I wonder why so many developers don't wanna touch the fsx airport navaids to sync them with AIRAC data, i see it as elementary to have
proper navaids when buying any addon airport. It's a primary motive i purchase them, beside using up to date AIRAC data.
regards
-
ILS 26L "IFZ" should be placed 9,2DME from NOXOB
That's exactly were it's placed, see the attached screenshot with the airplane placed at NOXOB, DME for 110.70 shows 9.2
08L doesn't have the loc course 282 anymore it is 283° meanwhile.
That's the magnetic heading. ILS course are programmed in the scenery as true headings, and they never change (unless the ILS is really reconfigured) What you see in your instruments, instead, is magnetic, so it's affected by the magvar variation database is installed in your FSX.
I didn't have the time to check all runways yet, but i hope you'll have an eye on that. thank you
We already have, before release, we went to each and every navaid of every approach, manually tuned the ILS and checked all the DME to be correct, and they were.
Check you don't have another AFCAD in conflict. What DME you read at the coordinates of my screenshot ?
I wonder why so many developers don't wanna touch the fsx airport navaids to sync them with AIRAC data, i see it as elementary to have proper navaids when buying any addon airport. It's a primary motive i purchase them, beside using up to date AIRAC data.
Who said we HAVEN'T "touched" them ?
In fact, if you open the CYVR AFCAD with any AFCAD editor, you'll will notice that ALL ILS localizers and DME HAVE been changed by us (AFX, for example, will show them all as being "user modified"), for the precise reason the default ones have usually DMEs misplaced. They were corrected. If you don't read the correct DME, seems to indicate a conflict caused by another AFCAD somewhere.
What we are (and no wonder other developers share the same view) not too keen touching, is changing other items in the area, like terminal VORs, and there are of course sound reasons for this: the first one is that only a fraction of users updates their AIRAC data. Even less now there are not so easily (=free) available as they were before. It would be very wrong to *assume* everybody would always have the latest data.
Suppose something that affects multiple things (it has happened at places we were working on, Zurich at a certain date removed most of the VORs in the area and replaced it with GPS fixes, changing ALL their published approaches AND Sid/Stars AND even lo/hi routes), it would cause problems everywhere, especially for the approaches. Or simply confusing situations, such frequencies that were present in the default scenery that in real world would be assigned to different navaids.
We are of course forced to verify all approaches, when something is changing and is affecting the airport *design*, most obvious example is when new runways are added, such the case of O'Hare. In that case, we HAVE provided new approaches too.
The only solution that makes sense, is being sure the scenery is coherent with the charts SUPPLIED WITH IT, and that's it. This means the scenery will always be usable even years from now, without requiring to supply users with new charts AND scenery updates each time there's an AIRAC update that relates to the scenery. If we were trying to follow that route, the scenery would have to be sold as a subscription.
I'd say that, since there are developers who ARE in the business of charging for regular Navdata updates, same as they supply FMC databases for popular add-ons airplane, they could also supply .BGLs containing ONLY Navaids that, when put on an higher layer in the Scenery Library, could update any airport (default or 3rd party) to be compatible with they data THEY are selling.
This would suit both users: those that are happy with the default FSX scenery and whatever updates comes from a 3rd party add-on and DO NOT subscribe to those services, and those that DO subscribe, and want everything to be current. It will work WAY better if both the FMC navdata and the navigation BGLs would be supplied by the same people, from the same data source, rather then trying to convince each and every scenery developer out there to keep all their products constantly updated with AIRAC cycles.
-
That's exactly were it's placed, see the attached screenshot with the airplane placed at NOXOB, DME for 110.70 shows 9.2
thank you for you reply. I see no screenshot attached, but i haven taken one by myself and attached it. :)
The radius is taken from FIX IFZ and should perfectly match NOXOB. NOXOB in Navigation display should be georeferenced because it is AIRAC data.
That's the magnetic heading. ILS course are programmed in the scenery as true headings, and they never change (unless the ILS is really reconfigured) What you see in your instruments, instead, is magnetic, so it's affected by the magvar variation database is installed in your FSX.
Thats one thing i missed to renew after my actual installation, i'll check it. And you're sure, after replacing the magdec.bgl it will show me the correct magnetic heading of 283? I've always been thinking this update doesn't affect the airport Navaids?? I'll give it a try later.
i have to leave for the moment , but will reply on the rest later.
regards
-
Sorry, here's my screenshot which shows the DME is spot on at NOXOB. I've took the lat/lon coordinates for it from skyvector.com and manually positioned the airplane there.
-
Sorry, here's my screenshot which shows the DME is spot on at NOXOB. I've took the lat/lon coordinates for it from skyvector.com and manually positioned the airplane there.
So then Skyvector is wrong, too ;)
here you have actual real world data taken from jeppesen:
NOXOB
Airport: CYVR
Latitude: N49° 09.5'
Longitude: W122° 56.1'
Flags: Named Intersection, Final Approach Course Fix
Magnetic Variation: 17.0°E
which perfectly matches the PMDG AIRAC data from Navigraph/jeppesen:
NOXOB 49.158636-122.934392
I also wonder, why the GS of 26L catches as it should though the DME distance is demonstrably wrong.
-
So then Skyvector is wrong, too ;)
Doesn't change much, see the updated screenshot exactly at the coordinate you reported, it's even possible that if we had that fix coordinates precise to the decimal second, instead of the decimal minutes, it might show 9.2 instead of 9.3, because it's just a bit on the threshold between the two.
here you have actual real world data taken from jeppesen:
Doesn't change much, just 0.1 nm difference, which is not like what you show on your screenshot.
I also wonder, why the GS of 26L catches as it should though the DME distance is demonstrably wrong.
The distance is correct within 0.1 NM, while your screenshot show a MUCH larger difference, so clearly the problem is not the scenery. You can verify this by simply LOOKING at the DME position in the scenery AFCAD with AFX or ADE, so you'll see it matches exactly the real world position, close to the start of the runway, a bit on the left side. In the scenery you can even see the antenna.
-
which perfectly matches the PMDG AIRAC data from Navigraph/jeppesen:
NOXOB 49.158636-122.934392
Exactly as I've thought, if I insert THESE coordinates in the FSX Map, it converts to slightly different lat/lon decimal minutes compared to the data from jeppesen in decimal minutes you posted (because of rounding issues), and the result is PERFECT, 9.2 NM and perfect alignment with the runway, as you can see from the attached screenshot.
Note the altitude and the Glidepath: as per published procedure, the glidepath intersects the NOXOB fix at 9.2 NM at 3000 ft: if this doesn't finally prove the utmost accuracy of the DME, I don't see what else does.
-
I'm not spending further thoughts on 0,1nm rounding issues, that has never been a main problem, i'm asking myself how it comes to the ~2nm IFZ DME misalignment
I'm not fit with the editors you use, i can only check with my cockpit-instruments.
I've taken the ILS position data from AIRAC now, which should be again Jeppesen/Navigraph:
IFZ ILS 49.190633-123.212544110.70T
Does it match your ILS scenery position? I am nearly running out of ideas now. If the aircraft uses its own data for every navaid the distance measuring would match again, because this is all
realworld referenced data. I've done the same with other airports like the new DubaiX and this test worked perfectly.
But if i have a look on your PFD, i wouldn't assume you are following a 3° GS, this is more likely a sarajevo approach. ;)
-
I show the IFZ GP/DME site from the ADE file as 49.190623 -123.212562 which puts you right at the TDZ in the scenery. I also looked from within the PMDG NGX and was at NOXOB at 9.2DME. The actual DME and ND were pretty much spot on.
-
I'm not spending further thoughts on 0,1nm rounding issues, that has never been a main problem, i'm asking myself how it comes to the ~2nm IFZ DME misalignment
There isn't any misalignment, the rounding issue is not in the scenery, it's the difference between the coordinates you supplied in this format: N49° 09.5', W122° 56.1' (Jeppesen), which gives 9.3, compared to the same coordinates you supplied in THIS format: 49.158636-122.934392 (AIRAC), which gives 9.2 so, the rounding issue affected only my 1st screenshot, but the 2nd, one with the most precise coordinates you also supplied, was perfect.
I'm not fit with the editors you use, i can only check with my cockpit-instruments.
You don't have to, just see my screenshot, it shows (check the coordinates) I AM in the real world NOXOB location, per your coordinates, and it shows 9.2 on the DME, tuned on 110.70, what ELSE you need to be convinced the scenery is correct ?
I've taken the ILS position data from AIRAC now, which should be again Jeppesen/Navigraph:
IFZ ILS 49.190633 -123.212544 110.70 T
Does it match your ILS scenery position?
Obviously not, because you are now confusing the Localizer position with the DME.
Your coordinates match 100% the scenery for the Localizer, which is on the far end of the runway. The DME, which is what we are discussing now, as I've said, it's on the near end of the runway, on left side.
I am nearly running out of ideas now
As I've said, in might be either another scenery in conflict OR a problem with your instrument distance circle OR the navaid position for this specific fix.
But if i have a look on your PFD, i wouldn't assume you are following a 3° GS, this is more likely a sarajevo approach. ;)
I don't know what you are trying to say here: the ILS HAS a 3° GS, which is supposed to result in the Glide signal being intercepted at 3000 ft when 9.2 miles out. Since my screenshot clearly shows that I WAS 9.2 NM out and I WAS at 3000 ft and the GS in the scenery IS 3° (like most of all GS, and yes, I've obviously checked that too), it's fairly clear that I WAS on a 3° intercept path.
-
I also looked from within the PMDG NGX and was at NOXOB at 9.2DME. The actual DME and ND were pretty much spot on.
Would you mind taking a screenshot of your situation in NGX.
I can't believe that i am alone with this effect:
-
I show the IFZ GP/DME site from the ADE file as 49.190623 -123.212562
Nope. That would be Localizer coordinates, on the far end of the runway. the DME for this ILS is NOT co-located on the Localizer, it's located on the Glide transmitter!! Those are the coordinates: N49.183868, W123.165630.
This is exact how it is in real world AND on the scenery (we also put two visible antennas, one for the glide and one for the dme), with the AFCAD we supply. Please, check the charts at page 40 of the manual, it clearly shows the Glide being located on the *near* end of the runway, shown as a box, with its DME label.
In fact, the reported 2.0NM difference looks like like runway length, that would result if another (incorrect) AFCAD, with the DME located on the localizer would be in use instead of our AFCAD.
-
I show the IFZ GP/DME site from the ADE file as 49.190623 -123.212562
In fact, the reported 2.0NM difference looks like like runway length, that would result if another (incorrect) AFCAD, with the DME located on the localizer would be in use instead of our AFCAD.
i checked it meanwhile with airport scanner:
the afcad from ORBX Vancouver is deactivated ,nothing else installed. (screenshot attached)
Btw. did the magdec.bgl update meanwhile, still wrong LOC course 08L
-
i checked it meanwhile with airport scanner:
That means you have a conflicting scenery which the scanner couldn't detect.
Check another screen, this time with the PMDG, everything shows 9.2. I can't show the same screen you have, because I don't have the latest FMC database installed, so there's no NOXOB fix in my PMDG ND, but I AM at NOXOB, from the coordinates.
-
And if it wasn't enough, here's further proof from ADE: I've added the NOXOB waypoint at the exact coordinates you reported, traced a measuring tool up to the location of the DME in the scenery and, of course, the line reads 9.2NM in lenght.
-
i checked it meanwhile with airport scanner:
I can't show the same screen you have, because I don't have the latest FMC database installed, so there's no NOXOB fix in my PMDG ND, but I AM at NOXOB, from the coordinates.
sure you can in many possible ways ;)
eg. by creating a custom waypoint in NGX CDU with the coordinates from NOXOB from above, easily manageable on ground.
input format would be: Nxxxx.xExxxxx.x
or adding the line:
NOXOB NOXOB 49.158636-122.934392
exactly as published in this textfile: wpnavfix.txt
and finally there is another way to get this waypoint into ND, this is called PlaceBearing/Distance if you use the ILS as fix. Works fine normally
This is a fresh 2 week old FSX installation, just all your/Flightbeam airports and ORBX area sceneries installed, actually patched NGX with newest AIRAC.
I haven't said that i don't trust you, I just don't really get this issue, if other pilots experience not the same as i do here.
-
eg. by creating a custom waypoint in NGX CDU with the coordinates from NOXOB from above, easily manageable on ground.
Done that and, guess what, is shows 9.2 from the DME, exactly as it should, by drawing a circle of 9.2 NM along the 263° radial from IFZ.
I think to have found your issue: see my screenshot, when you select the IFZ navaid in the PMDG FMC, there are TWO entries that match the CYVR area, the one named "ILS/DME" is the correct one, where the DME is placed, the other one is still named IFZ, but it's the *localizer*, maybe you selected THAT one, that's why you see 2.0NM more, it's the length of the runway being added, because the localizer is on the opposite side!
-
eg. by creating a custom waypoint in NGX CDU with the coordinates from NOXOB from above, easily manageable on ground.
Done that and, guess what, is shows 9.2 from the DME, exactly as it should, by drawing a circle of 9.2 NM along the 263° radial from IFZ.
I think to have found your issue: see my screenshot, when you select the IFZ navaid in the PMDG FMC, there are TWO entries that match the CYVR area, the one named "ILS/DME" is the correct one, where the DME is placed, the other one is still named IFZ, but it's the *localizer*, maybe you selected THAT one, that's why you see 2.0NM more, it's the length of the runway being added, because the localizer is on the opposite side!
Sadly not in actual PMDG AIRAC 1303, but this is a Navigraph issue. (see screenshot attached)
Great you found the issue, that finding would have caused at least a sleepless night. You are the man! Thank you Umberto, much appreciated. Great support as always!
If you can tell me finally, what steps i have to do to make runway 08L working as it is published in actual charts 083°110.55 it would be perfect.
this magdec:
http://www.aero.sors.fr/navaids.html
update from 2010 didn't really help
-
Sadly not in actual PMDG AIRAC 1303, but this is a Navigraph issue. (see screenshot attached)
Ok, that's explains it: so the issue was the current Navigraph only has the Localizer location, instead of the most useful DME location. The original data supplied with the PMDG (I have the Aerosoft CD version installed) was probably better in this case.
If you can tell me finally, what steps i have to do to make runway 08L working as it is published in actual charts 083°110.55 it would be perfect.
You might try editing the CYVR AFCAD with ADE or AFX to change the magnetic variation for the localizer. We'll check this.
-
I show the IFZ GP/DME site from the ADE file as 49.190623 -123.212562
Nope. That would be Localizer coordinates, on the far end of the runway. the DME for this ILS is NOT co-located on the Localizer, it's located on the Glide transmitter!! Those are the coordinates: N49.183868, W123.165630.
My bad, I read the ADE properties wrong in a rush to post before I went out. Well aware of where each one is though.
-
You might try editing the CYVR AFCAD with ADE or AFX to change the magnetic variation for the localizer. We'll check this.
Hi Umberto,
it'd be great if you'll check this. Thank you! I'm not nearly experienced with FS design-tools.
btw. if someone here is interested: Navigraph is informed about the issue meanwhile.
-
I for one have no problems/issues with all of the ILS approaches. Even tested them with autolands. Its spot on. Putting a DME Fix is also bang on to the ILS waypoints.
Dont know what your issue is, but I doubt its YVR. Not just NGX, its worked in all my aircraft.
-
Dont know what your issue is, but I doubt its YVR. Not just NGX, its worked in all my aircraft.
We found what his issues was: the current Navigraph update contains only the localizer location for the CYVR 26L ILS, which is on the far end of the runway, but the DME readout (that the approach procedure is based on) should be done using the more useful DME instead, which is missing from the Navigraph data.
In my screenshot, using the default database as originally provided by PMDG, I had both navaids, so I could choose the ILS/DME and have the readout correct, but G.Bosak (using the updated Navigraph) could only select the ILS localizer, which is 2.0 NM away (the entire runway length)
-
Just for clarification then which was the Navigraph file that had the error in it?
-
Just for clarification then which was the Navigraph file that had the error in it?
the official statement from Navigraph is:
Hi,
thanks for the report - understood! I have looked into the source and the IFZ DME isn´t included in the navaid record - so we will ask Jeppesen if this types of DME aren´t published from the countries or if there is any other reason for that! Will come back with an answer when we had it ... Thank you very much!
Cheers,
Richard
For me it says every cycle since they changed to Jeppesen is affected.
-
What airac provider are you using? I'm using Navigraph but haven't updated it this year yet (1211) and it works fine for me. I know other guys using up to date Navigraph airac data have no issues.
-
What airac provider are you using? I'm using Navigraph but haven't updated it this year yet (1211) and it works fine for me. I know other guys using up to date Navigraph airac data have no issues.
old Navigraph PMDG cycles aren't affected by this issue (at that time [1211] NAVTECH was the provider). It seems all newer cycles based on jeppesen are affected (1301, 1302, 1303)
They say Jeppesen does not deliver the ILS-DME information at the moment to visualize the correct distance in ND. So the issue is already confirmed by NAVIGRAPH.
If your friend doesn't have this issue he is using an older cycle, too. Because there is still only one revision of 1303 available.