ERR at DM LN

[stephenbgs 169]

Anyone know what this is about.

 

Im guessing its more to do with a navigraph issue but my current cycle is up to date.

 

 

[scandinavian13 5,192]

ERRor at DM (I'm guessing a fix or navaid) at LiNe 53.  It seems to be a navdata issue.

 

While up to date is a good thing, it doesn't mean that it was formatted properly.  Take it up with Navigraph.  I'm sure they'd appreciate knowing that there's an issue that they should correct.

[stephenbgs 169]

Thanks Kyle. I was thinking it was something along those lines.

 

I'll let Navigraph know.

[scandinavian13 5,192]

Welcome!

[icemarkom 59]

Speaking of that.

 

I noticed quite a few approaches I flee recently have i correct altitude restrictions when compared to FAA charts. Is this something Navigraph usually corrects, or is this a fact of live we have to deal with?

 

I find it an interesting pastime to go through the flight plan and crosscheck the chart and legs in my FMC, but I suppose discrepancies should be few and far between…

[Fabo 213]

There is a difference between "expect altitude" and "altitude restriction". Beyond that... I don't know. Maybe the navigraph supplier is not as thorough as should be.

[icemarkom 59]

I perfectly understand that, but if there's and underlined 4800 on the chart, that doesn't mean 2800… (ILS 25L for KLAS for example has a similar issue).

 

Also, when the chart says "expect X" and has altitude specified next to the fix apart from the text instruction, data should be there regardless of whether ATC clears you or not :-)

[scandinavian13 5,192]

 

 

Also, when the chart says "expect X" and has altitude specified next to the fix apart from the text instruction, data should be there regardless of whether ATC clears you or not :-)

 

Navigraph is hit or miss on this.  My general rule is to always check, and I generally expect the hard altitudes (restrictions) to be in there.  The expected altitudes I generally don't expect to see there, and will add them in.  They are occasionally in there, though.

 

In any case, you should always verify that the data is correct.  Even in the real world, there may be discrepancies.  When the FAA (or other agency) comes knocking on your door because you didn't check the data and were off by a few thousand feet, causing a CA, they're not going to let you off with "turns out the altitude data wasn't properly set..."

 

Nope.  They're coming after you, because the flight was your responsibility.  The FMC is just there to help you do your job, not do it for you, and so on.

 

Long story short: always check it, and Navigraph isn't consistent in its implementation of hard (restriction) and soft (expected) alts.

[icemarkom 59]

Don't get me wrong, but I know how to handle it in-flight. I actually LOVE the fact the data is incorrect, so I get more work of reading the charts, making sure it's all as it should be, etc. But... is Navigraphs fixing these based on user reports, or would I be wasting my time reporting the errors?

 

Your answer was spot-on and fantastic, it just doesn't correspond to the question I asked ;-)

[scandinavian13 5,192]

 

 

Your answer was spot-on and fantastic, it just doesn't correspond to the question I asked ;-)

 

Haha - sorry. I'm definitely not with it today.

 

 

 

But... is Navigraphs fixing these based on user reports, or would I be wasting my time reporting the errors?

 

That's a good question.  My thought would be yes.  Certain things would affect how they process future updates (depending on how they do it all).

[LRW 42]

It looks like the problem is with some (all?) non-runway specific approaches, e.g. VDMA instead of VDM09, at the point where the missed approach begins.  When it's parsing the line and sees RNW, it apparently expects the next characters to be a runway.  But in these approaches the next characters are DM.  I found 63 files with RNW DM.  I entered 5 of them as DEST and they all blew up at the line where that occurs.

 

I'll post it on the Navigraph forum now to let him know.

[stephenbgs 169]

It looks like the problem is with some (all?) non-runway specific approaches, e.g. VDMA instead of VDM09, at the point where the missed approach begins.  When it's parsing the line and sees RNW, it apparently expects the next characters to be a runway.  But in these approaches the next characters are DM.  I found 63 files with RNW DM.  I entered 5 of them as DEST and they all blew up at the line where that occurs.

 

I'll post it on the Navigraph forum now to let him know.

 

Interesting info there Larry.

 

You would imagine they would have discoverd/told about this by now.

[LRW 42]

You would imagine they would have discoverd/told about this by now.

 

It does seem a little odd.  63 sounds like a lot but there are 6518 airports in the current cycle so that's less than 1%.  I did post it on Navigraph's forum.  I was looking at the Navigraph files for those airports in other products, like Aivlasoft's EFB and the AirbuX A320.  The airport files were either empty or missing.  

 

I went back to the PMDG set for EIWT and I copied the 3 approaches, VDMB, VDMC, and VDMD.  I replaced the DM in the first three with 07 and in the second three with 25.  Now the CDU shows 6 VOR approaches, 3 for each runway.  So that would be a work-around for any airports that you want to use with the NGX.

[stephenbgs 169]

Wow that is some work-around i never in a million years would have thought of that.

 

Great work Larry.

 

Is there any chance you could paste that section of the EIWT file. I followed your advice as above and it worked but the format looked a little odd in the CDU

[LRW 42]

I don't want to inadvertently (or advertently for that matter) violate the copyright by posting a complete line. But this is what my approach page 1 looks like with the work-around:

 

 

If you go over to the Navigraph support forum you can follow my post over there and see how Ian or Richard respond.  It's "NGX error on approaches with RNW DM".