> > 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](https://github.com/dimaryaz/jdmtool/issues/28#issuecomment-3258033031)_
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
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
Some forensic work to give us more insights to the FlightPlan Migrator Kit [https://www.garmin.com/en-US/p/35228/](url)
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](url))
- 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](https://github.com/user-attachments/files/22196319/FlighPlanDataCard.dmp)
Dump of my erased Nav Data Card. jdmtool reports the card as 16MB (silver) Data Card
[NavDataCardWAASemtpy.dmp](https://github.com/user-attachments/files/22196317/NavDataCardWAASemtpy.dmp)
Dump of my Nav Data Card, now a Flight Plan Data Card with the same FPL in Slot 1
[NavDataCardWAASwFPL.dmp](https://github.com/user-attachments/files/22196318/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.
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'
```
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.
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.
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.
<img width="400" height="279" alt="Image" src="https://github.com/user-attachments/assets/9e3426cb-e674-4b78-a58a-a61fb2c9d929" />
@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](https://github.com/user-attachments/files/22196786/3fpl.dmp)
> 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](https://github.com/user-attachments/files/22196786/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
```