Read if you're still having trouble with Garmin GTN basemap updates

[Vance Harral]

Earlier this year, Garmin released a new version of the basemap database for GTN series navigators, version 20M1.  That database version had a bug, see https://s23634.pcdn.co/en-US/aviationalerts/wp-content/uploads/2020/08/BasemapDataAlert_2020_08_14_basemap20m1_2092.pdf  If you updated to 20M1, you were advised to revert back to 19M1.  We got advance wind of this and never updated to 20M1.

More recently, basemap 20M2 was released to fix the bug in 20M1, but turns out there's a lesser issue with version 20M2 as well.  You can download 20M2 to an SD card, upload it to the GTN, and fly a flight with no problem.  But the next time you power cycle the unit, it will fail the database verification step on the basemap database.  I wrote Garmin about this problem and received an immediate response with a pointer to a recently released "knowledge base article" on the issue at https://support.garmin.com/en-US/aviation/faq/h4EcVRF0Nz0y2EEfl0IrT8/  That article describes a process by which you can upload the even older version 18M1 basemap to your GTN, then update to 20M2 from 18M1.

Those of you with a little bit of computer savvy may speculate as I do that "verification" of GTN databases at boot-up is simply a checksum process, wherin the unit checksums the databases and compares the computed checksum against a known good signature.  The nature of this bug suggests the known-good-signature checksum somehow depends on the previous version of the database from which the current database was upgraded.  I can't imagine why the software engineers would design it to work that way, but my speculation may be way off base - I freely admit I lack any low-level knowledge of how GTN database verification works.

Anyway, posting this here for others who may be struggling with this, and wondered like me if their SD card(s) and/or GTN unit might be faulty.  It's not pilot error - it's the software.

[DXB]

2 hours ago, Vance Harral said:

Earlier this year, Garmin released a new version of the basemap database for GTN series navigators, version 20M1.  That database version had a bug, see https://s23634.pcdn.co/en-US/aviationalerts/wp-content/uploads/2020/08/BasemapDataAlert_2020_08_14_basemap20m1_2092.pdf  If you updated to 20M1, you were advised to revert back to 19M1.  We got advance wind of this and never updated to 20M1.

More recently, basemap 20M2 was released to fix the bug in 20M1, but turns out there's a lesser issue with version 20M2 as well.  You can download 20M2 to an SD card, upload it to the GTN, and fly a flight with no problem.  But the next time you power cycle the unit, it will fail the database verification step on the basemap database.  I wrote Garmin about this problem and received an immediate response with a pointer to a recently released "knowledge base article" on the issue at https://support.garmin.com/en-US/aviation/faq/h4EcVRF0Nz0y2EEfl0IrT8/  That article describes a process by which you can upload the even older version 18M1 basemap to your GTN, then update to 20M2 from 18M1.

Those of you with a little bit of computer savvy may speculate as I do that "verification" of GTN databases at boot-up is simply a checksum process, wherin the unit checksums the databases and compares the computed checksum against a known good signature.  The nature of this bug suggests the known-good-signature checksum somehow depends on the previous version of the database from which the current database was upgraded.  I can't imagine why the software engineers would design it to work that way, but my speculation may be way off base - I freely admit I lack any low-level knowledge of how GTN database verification works.

Anyway, posting this here for others who may be struggling with this, and wondered like me if their SD card(s) and/or GTN unit might be faulty.  It's not pilot error - it's the software.

Thanks - I have this exact issue and hadn't mustered the energy to look into it further.

[alextstone]

Does this issue result in a "Terrain System Failure"  annunciation?

[ArtVandelay]

Does this issue result in a "Terrain System Failure"  annunciation?

No

[larryb]

Yup, I noticed a basemap issue last flight.  I guess I'll go through the process. But, does the worldwide basemap even matter if you have a current local nav db?

[eman1200]

daggummit, I was going nutz with this, didn't know it was a known issue.  thing is, I was able to reinstall an older version which worked once, then went rogue, then I got it to work again, then it showed 'corrupt card'....would load once then next start up give me issues again.  thanks for letting me know it wasn't me.

[Vance Harral]

3 hours ago, larryb said:

Yup, I noticed a basemap issue last flight.  I guess I'll go through the process. But, does the worldwide basemap even matter if you have a current local nav db?

How much it matters is an interesting question.  We actually have the basemap turned off in our regular map view, because we find it distracting.  More importantly, the AFMS limitations specifically reference the navigation database, but not any other databases.  The conclusion I drew for our own operations is that the basemap has essentially zero impact on our operations.  But we still keep it up to date.