I'm playing around on the garmin_login branch since I'm working with a G3X system. Managed to get TAW files downloaded and extracted using my own subscription. Nice work!
The TAW extractor seems to be producing slightly different results than the real Garmin Aviation Database Manager. This may be by design, so I did not create a pull request.
1. Ignoring destination path: When extracting TAW files, it looks like you are ignoring paths and just extracting the base filename. TAW regions like 0x01 (ldr_sys/avtn_db.bin), 0x14 (fc_tpc/fc_tpc.dat) and 0x1A (rasters/rasters.xml) show files living at a relative path. Indeed, when I check the SDCard after GADM finishes with my own subscription, the output files are located at their relative paths. If you want to change this, here's a diff:
```
diff --git a/src/jdmtool/main.py b/src/jdmtool/main.py
index 1d3adf8..54d17c3 100644
--- a/src/jdmtool/main.py
+++ b/src/jdmtool/main.py
@@ -1043,7 +1043,7 @@ def cmd_extract_taw(input_file: str, verbose: bool, list_only: bool) -> None:
debug(f"Database size: {s.data_size}")
if dest_path:
- output_file = pathlib.PurePosixPath(dest_path).name
+ output_file = pathlib.PurePosixPath(dest_path)
else:
output_file = f"region_{s.region:02x}.bin"
```
2. You have two TAW regions named terrain.odb: 0x22 and 0x27. When I inspected what my GADM produced, 0x22 got extracted to "terrain_9as.odb". If you want to change this, here's a diff:
```
diff --git a/src/jdmtool/taw.py b/src/jdmtool/taw.py
index a0b9c55..eb44ea3 100644
--- a/src/jdmtool/taw.py
+++ b/src/jdmtool/taw.py
@@ -38,7 +38,7 @@ TAW_REGION_PATHS = {
0x14: "fc_tpc/fc_tpc.dat",
0x1A: "rasters/rasters.xml",
0x21: "terrain.tdb",
- 0x22: "terrain.odb",
+ 0x22: "terrain_9as.odb",
0x23: "trn.dat",
0x24: "FCharts.dat",
0x25: "Fcharts.fca",
```
3. I found an unknown TAW region (0x0c) in one of my subscription TAWs. Out of caution I'm not going to link it here. Do you have any tips on how to reverse engineer what it is?
> Ignoring destination path: When extracting TAW files, it looks like you are ignoring paths and just extracting the base filename. TAW regions like 0x01 (ldr_sys/avtn_db.bin), 0x14 (fc_tpc/fc_tpc.dat) and 0x1A (rasters/rasters.xml) show files living at a relative path. Indeed, when I check the SDCard after GADM finishes with my own subscription, the output files are located at their relative paths. If you want to change this, here's a diff:
It was somewhat intentional: the point of `extract-taw` was to just get the data out of the .taw files, and, at the time I implemented it, I didn't even think about transferring to SD cards. In fact, for GNS 4xx/5xx, file paths don't even make sense - the files are written to a data card with no filesystem.
But also, just extracting to the correct file paths is not enough anyway; you also need to:
1) update `featunlk.dat` (the logic for this is [already there](https://github.com/dimaryaz/jdmtool/blob/main/src/jdmtool/featunlk.py) - just need to connect it to Garmin subscriptions - or have the user manually input the info)
2) create .sff files (for newer Xi devices) - I have no idea how GADM handles this
So realistically, this should be either a new command, or part of the existing `jdmtool transfer` command.
> You have two TAW regions named terrain.odb: 0x22 and 0x27. When I inspected what my GADM produced, 0x22 got extracted to "terrain_9as.odb". If you want to change this, here's a diff:
Sure. I can update it, or if you want to send out a PR, go for it.
> I found an unknown TAW region (0x0c) in one of my subscription TAWs. Out of caution I'm not going to link it here. Do you have any tips on how to reverse engineer what it is?
I think I've used rip_taw (see [this discussion](https://github.com/dimaryaz/jdmtool/issues/9#issuecomment-2619157852)). Btw, if the filename is listed [here](https://fly.garmin.com/fly-garmin/support/avdb-files), then don't need to link it - just write the filename :)
Yea, I guessed that ignoring the relative paths was due to the generic nature of jdmtool. My application is limited to G3X devices so I'll keep the path in my downstream work.
PR sent for the file name.
For region 0x0c, it's in the G3X jg3xtva-us-2509.taw, which also contains ldr_sys/avtn_db.bin. I'll play around with the binary data to see if I can figure out its purpose. On my own system, GADM doesn't seem to be doing anything with it, so it's kind of low priority for my application.
As I understand it, the paths are important in the context of newer devices that use SD cards, as they won't pick up databases placed in the wrong path.
Well, I don't actually have a strong opinion here - you can send out a PR for the relative path, too.
(I was originally worried about paths like `.System/...`, where the user might not even see the directory with a dot. But if jdmtool prints out the extracted paths, that should be ok.)
> [@eld400](https://github.com/eld400): I just did some testing, and looks like you're right! ([@ryandrake08](https://github.com/ryandrake08) - can you check if it's "tdb" or "odb" in your case?)
You're right, it's terrain_9as.tdb for me. Sorry about the mistake.