Reducing GPS database costs

That's very good.

I wonder if SD accepts an airway route, like FliteStar, e.g.

EGKA DCT MAY R8 DVR L9 KONAN L607 GILOM M624 REMBA/N0139F150 M624 DIK/N0142F140 M150 KRH Z729 LBU L173 RIXED Y161 MUN L603 OBEDI/N0139F150 L172 VIW/N0142F140 L608 DOL P173 KOMAR L187 IDASI M867 KOGAT N130 TALAS/N0130F180 Z508 ELPIS/N0133F170 P20 ABLON/N0142F140 B1 ATV L617 MIL A14 ATLAN LGST

and decomposes it into the waypoints, prints them off (for loading the GPS), plots them, and then prints off the enroute strip charts, like this.

A long time ago I suggested all this to SD, explaining to the man he could so easily have a tool which would do what in practice Flitestar IFR Europe (€500/year) gets used for, but it was met with ridicule along the lines of "how many people fly IFR?" It's good to see him see the "IFR light".

I suggested the same to Navbox, even earlier, who have the advantage of a pan-European database coverage, but they haven't done it.

Now, years later, we have other ways of doing the same job. For example the free FlightPlanPro can perform exactly this function so, if you just fly simple IFR all the way, you don't actually need any other tool.

But if SD does this all correctly, it could also be used as the enroute moving map GPS. Currently, Jepp FliteDeck does that. In an emergency, SD could be switched (I assume) to show a VFR (topo) chart. Jepp FD can/could do that too but it would probably crash several times if you tried...

What about a KNS80?
Then there is no database costs and is RNAV legal

It may be legal (with the £700 antenna filter to make it legit FM immune) but it's useless because IFR ATC hand out DCT [VOR name] waypoints which are out of the DOC of the terminating navaid by half an order of magnitude

GPS is the only way...

One could "hack it" with a KNS80 by estimating up a temporary heading, flying in the HDG mode, while working out the RNAV settings for a string of intermediate VOR/DMEs all the way to the waypoint, and flying them one after the other.

I know a retired airline pilot who says that is what they used to do. They used to fly in HDG all the way across the Bay of Biscay, ending up say 10-20nm off track, and then sort it out when they picked up some VOR.

But, single pilot IFR, I don't fancy it. Also modern ATC would get awfully nervous if you were a few miles off track. They expect precision, and they expect it set up within not too many tens of seconds.

Picking up this old but relevant thread, following this discussion of Garmin GPS programming:

What do Garmin do to prevent a flash card being duplicated in a normal CF or SD writer and be used in multiple GNS/GTN boxes?

Kind did this on the KLN89/KLN94 by using a standard CF card (a 48MB Sandisk one, for the KLN94) but

• setting up a nonstandard file system on it (non DOS, possibly a hacked FAT16 or whatever)
• storing a unique key on it (not in the GPS itself although it can look that way) which needs to be entered into their database download website
• selling a Sandisk CF writer with firmware hacked to make the hacked CF card look DOS/Windows compatible while it is being written to by their programming software
• encrypting the data on the CF card, probably with the above key

From earlier in this thread, it appears that the GNS uses the same scheme as the KLN94 i.e. a hacked flash card (is it CF?) and a unique key stored on the card. What about the GTN and the IFD boxes?

The basic point is that if the database was locked to the serial number (or some other property) of the GPS then the database card cannot be used in another GPS if somebody was happy to fly 1 cycle behind.