Flight plan transfer support via data cards for GNS units

[zyv]

P.S. By the way, W-units (at least) support an alternative use of the terrain datacard. You can write flight plans to it and load them into the unit. I'm really wondering what a dump of such a card looks like…

I got one of these Flight Plan Data Cards. In deed they are not Terrain Cards, but Nav Data Cards, which will be used to load the Flightplans from the Terrain Slot of the W-Units. Sounds weird but thats the way they run.

If needed, I could try to dump an image from this card with a valid Flight Plan on it.

Originally posted by @Mountain-wg in #28

[zyv]

I have created a new issue out of this discussion. I think it would be interesting to see what the card looks like. Maybe write it with some markers and then use the migrator; hopefully, you can then see clearly what gets written and why. Sadly, I don't have a W-unit, and according to the documentation, non-WAAS units cannot do it. I wonder if there is a way around that.

The official software still seems to be available from here:

https://www8.garmin.com/support/download_details.jsp?id=4471

[Mountain-wg]

Only W-Units can handle the Flight Plan Data Cards. I tried it with my non-waas. Regarding the documentation, it depends/based on the following:

• Flight Plan Data Card is a native Orange 16MB Nav Data Card, not readable in non-waas Units
• Software 5.02 and higher

[Mountain-wg]

Some forensic work to give us more insights to the FlightPlan Migrator Kit https://www.garmin.com/en-US/p/35228/
The kit consists of:

• Garmin Reads (which we all have)
• Software (free Download from Garmin available https://www8.garmin.com/support/download_details.jsp?id=4471)
• Flight Plan Data Card

I found out, that the Flught Plan Data Card is a 16MB orange WAAS Nav Data Card relabled by Garmin.

I created some backup to help us analyse what Garmin is writing to the cards and it was a proof that any WAAS Nav Data card can be used. I used jdmtool for this tests.

Dump of my Flight Plan Data Card with one Flightplan in Slot 1. jdmtool reports the card as 16MB (orange) Data Card
FlighPlanDataCard.dmp

Dump of my erased Nav Data Card. jdmtool reports the card as 16MB (silver) Data Card
NavDataCardWAASemtpy.dmp

Dump of my Nav Data Card, now a Flight Plan Data Card with the same FPL in Slot 1
NavDataCardWAASwFPL.dmp

Conclusion: you can use a spare 16MB WAAS Nav Data Card (silver or orange) to use the Migrator Kit. As long as Garmin provides the software for free, we are fine. But its a Windows only software. If we like to use any other OS, it would be good to analyse the images and try to bring it into jdmtool.

[zyv]

Hey @Mountain-wg, great research, thank you!

It seems that it's simply a specially formatted card in FAT16, and the flight plans are the normal FPL files in the FPL subdirectory.

Can you put some more FPL files in this directory and see what it looks like on the unit? If this works, then... I guess we’ve got it :) It can’t be that simple, can it?

$ file FlighPlanDataCard.dmp 
FlighPlanDataCard.dmp: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "GARMIN10", sectors/cluster 8, FAT  1, root entries 512, sectors 32768 (volumes <=32 MB), sectors/FAT 16, sectors/track 63, heads 255, hidden sectors 63, serial number 0x1102, label: "GARMIN AT  ", FAT (16 bit)

$ file NavDataCardWAASwFPL.dmp 
NavDataCardWAASwFPL.dmp: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "GARMIN10", sectors/cluster 8, FAT  1, root entries 512, sectors 32768 (volumes <=32 MB), sectors/FAT 16, sectors/track 63, heads 255, hidden sectors 63, serial number 0x1102, label: "GARMIN AT  ", FAT (16 bit)

$ sudo mount -o ro,loop NavDataCardWAASwFPL.dmp /mnt

$ ls -alsR /mnt/
/mnt/:
total 20
16 drwxr-xr-x.  3 root root 16384 Jan  1  1970 .
 0 dr-xr-xr-x. 18 root root   235 Jan 11  2025 ..
 4 drwxr-xr-x.  2 root root  4096 Dec 31  1989 fpl

/mnt/fpl:
total 28
 4 drwxr-xr-x. 2 root root  4096 Dec 31  1989  .
16 drwxr-xr-x. 3 root root 16384 Jan  1  1970  ..
 8 -rwxr-xr-x. 1 root root  4184 Dec 31  1989 'Bonn-Hangelar - Texel.fpl'

[Mountain-wg]

If this is so simple, it would be easy to add to jdmtool!
I can upload more .FPLs to the card easily. We have to find out, how the "Slot Nr." is recognized on the card. In the FPL Migrator Tool, you can specify in which GNS FPL Slot you like to have a specific FPL.

[zyv]

Yes, the question about slots is an interesting one. I have never seen Migrator. Can you create a card with one FPL in Slot 1 and another in Slot 2? Or a card with two FPLs in slots 1 and 2 and slots 2 and 1? By comparing the dumps, we could try to find out how slots are encoded.

[eld400]

For me Slot number is use only to order FP in your list

From help file :
You may change the slot number of a flight plan.
The slot number is the place in the order within the Flight Plan Catalog of your Garmin GPS unit where the flight plan will be placed.
Click on the slot number of the flight plan file. A drop down menu will be displayed.
Click on the desired slot number. Duplicate slot numbers are not allowed.
When the flight plan file list is complete, click on the Next button.

[Mountain-wg]

@eld400: the Slot number is relevant for the import into GNS. If you set the slots in the FPP Software in the right way, you can just import it in the same slots into the GNS. If you do not, you have to decide in which slot you like to import the FPL while in the import dialog on the GNS. So it's convenience and easy of use not to fiddle around on the GNS.

here we go, 3 FPLs in Slot 1,2,3. I was lazy with the file names, but so we see if there is any limitation
3fpl.dmp

[zyv]

here we go, 3 FPLs in Slot 1,2,3. I was lazy with the file names, but so we see if there is any limitation 3fpl.dmp

Well, this is not very helpful... I can see 3 files in the fpl directory, but no obvious information about slot number is present in the files, file names, or file attributes. It certainly must be present somewhere, but it's a lot of work to dump the complete partition & file system structure according to public documentation of MBR/FAT16 and try to find by eye where did they sneak the slot numbers.

So, as I suggested above, it's much easier to do a binary diff of two dumps with just one file: one with Bonn-Hangelar - Texel.fpl in Slot 17 and one with Bonn-Hangelar - Texel.fpl in Slot 19 (weird numbers to make them easier to notice). This way, we can hopefully easily catch what they misuse for slots.

If it's impossible, then one could make two dumps:

• Dump 1
  • Bonn-Hangelar - Texel.fpl - Slot 17
  • Bonn-Hangelar - Texel - Kopie.fpl - Slot 19
• Dump 2
  • Bonn-Hangelar - Texel.fpl - Slot 19
  • Bonn-Hangelar - Texel - Kopie.fpl - Slot 17

$ fsck.fat -v -n -l -F 1 NavDataCardWAASwFPL.dmp 
fsck.fat 4.2 (2021-01-31)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "GARMIN10"
Media byte 0xf0 (5.25" or 3.5" HD floppy)
       512 bytes per logical sector
      4096 bytes per cluster
         1 reserved sector
First FAT starts at byte 512 (sector 1)
         1 FATs, 16 bit entries
      8192 bytes per FAT (= 16 sectors)
Root directory starts at byte 8704 (sector 17)
       512 root directory entries
Data area starts at byte 25088 (sector 49)
      4089 data clusters (16748544 bytes)
63 sectors/track, 255 heads
        63 hidden sectors
     32768 sectors total
Using first FAT.
Fixing first cluster in FAT.
Checking file /fpl (FPL)
Checking file /fpl/Bonn-Hangelar - Texel.fpl (BONN-H~1.FPL)
Label in boot sector is 'GARMIN AT', but there is no volume label in root directory.
  Auto-removing label from boot sector.
Checking for unused clusters.
Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.

Leaving filesystem unchanged.
NavDataCardWAASwFPL.dmp: 2 files, 3/4089 clusters

$ fsck.fat -v -n -l -F 1 3fpl.dmp 
fsck.fat 4.2 (2021-01-31)
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "GARMIN10"
Media byte 0xf0 (5.25" or 3.5" HD floppy)
       512 bytes per logical sector
      4096 bytes per cluster
         1 reserved sector
First FAT starts at byte 512 (sector 1)
         1 FATs, 16 bit entries
      8192 bytes per FAT (= 16 sectors)
Root directory starts at byte 8704 (sector 17)
       512 root directory entries
Data area starts at byte 25088 (sector 49)
      4089 data clusters (16748544 bytes)
63 sectors/track, 255 heads
        63 hidden sectors
     32768 sectors total
Using first FAT.
Fixing first cluster in FAT.
Checking file /fpl (FPL)
Checking file /fpl/Bonn-Hangelar - Texel - Kopie (2).fpl (BONN-H~1.FPL)
Checking file /fpl/Bonn-Hangelar - Texel - Kopie.fpl (BONN-H~2.FPL)
Checking file /fpl/Bonn-Hangelar - Texel.fpl (BONN-H~3.FPL)
Label in boot sector is 'GARMIN AT', but there is no volume label in root directory.
  Auto-removing label from boot sector.
Checking for unused clusters.
Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.

Leaving filesystem unchanged.
3fpl.dmp: 4 files, 7/4089 clusters