Add support for transferring G1000 databases #2
Comments
|
That error most likely means that the device is already in use by some existing driver. Does your SD card reader already show up as normal storage device? If you can already open the SD card and copy files to it, then there's no need to access the device directly. (That's not the case for GNS 430, which is why I implemented all of the USB logic.) If you can access the SD card, the next question would be: do you know how the database needs to be stored there? E.g., copy the .zip file to it, or unzip it and copy the contents, or maybe the database is a disk image that should be copied directly to the device, etc. If you know the answer, I can make |
|
The Garmin SD card shows up as a normal storage device. Below you will find a listing of the content: ls -lR ./Charts: ./Fonts: ./ldr_sys: ./System Volume Information: |
|
Well, I've made some progress here. I realized, I don't need a G1000 or any special hardware for this - just a USB drive. The biggest remaining piece is the .sff files - they seem to be generated from the downloaded files, but I don't know what they are. Signature? Checksum? Will try to reverse-engineer them. Two questions for you:
|
|
Well, I have something working, but I would NOT try it on the real SD cards just yet. Turns out, the .sff files were easy - they're just some extra downloads. But, there's
And from this forum:
So I have not yet figured out how it works - but presumably, the G1000 won't accept the database update without it. My code copies everything else, though. If you're curious to try it, it's in the g1000 branch. It can work with any directory, not necessarily an SD card. Run |
|
You are right. There is no need to use the original Garmin SD Card. I have used also a normal 32GB SD Card to transfer the database to the G1000NXI. Here is the list of files in the VFR/IFR charts DB: unzip -l 023FL01687_TCL_202308.1_202308.1.zip 233560138 2023-04-08 00:33 023FL01687_VFRCharts.bin 264294579 67 files unzip -l 023KM01684_TCL_202308.1_202308.1.zip 165845779 2023-04-07 23:28 023KM01684_Charts.bin 196580220 67 files |
|
Just a side note about the G1000NXi: I do not use the top slot for the SD card on the G1000NXi, I always use the bottom slot (where normally the FS510 is installed). With a "normal = non Garmin" SD Card and JDM I was able to upgrade the databases on the G1000NXi. I will check if the dabases can be upgraded using your newest version of jdmtool, a normal SD Card and using the bottom slot. Hopefully the feat_unlk.dat file is not checked using the bottom slot. I can give you a feedback in a week (since I probably will have no access to the plane until then). |
|
Interesting, sounds good. These are the databases that use feat_unlk.dat, by the way:
I've made some progress on reverse-engineering feat_unlk.dat. Besides the databases, it also uses the ID of the partition - I guess that's how they stop you from just copying everything to a different SD card. But of course, you can set the ID yourself when formatting the device. E.g., set it to (Or change it without formatting using Also, they were nice enough to move all copy protection code into a separate executable, Transferring the databases: Running the plugin: Sending requests for the two files: And it produces a feat_unlk.dat that's identical to the one created by JDM. If I can't reverse-engineer the plugin, I can just run it on some server. CPAAS - Copy Protection As A Service! |
|
Thanks a lot for your comments. However "g_plugin.exe" seems not work on my system. I had to copy the library GrmNavdata.dll to the wine c:\windows folder in order to use g_plugin.exe. I am using a SD card with one database: hbu@laptophbu2:/run/media/hbu/GARMIN> ll wine ~/bin/g_plugin.exe I seems that g_plugin.exe does not find the wine windows drive with the SD card. But according to winecfg the SD card is there. Do you have any hints? |
|
Oh, yeah, I'm still working on automating most of this. I couldn't decide if my goal was to just make it work on Linux (and relying on g_plugin.exe was an acceptable compromise), or fully reverse-engineer featunlk.dat and create it from Python. Anyways, a few things:
I'll try to make jdmtool actually run wine and perform all the necessary checks. |
|
Just updated the g1000 branch - it will now try to find g_plugin.exe and run everything automatically. (You can also set This is what it looks like for me: (Some of the output there actually comes from g_plugin.exe.) It produces exactly the same files as JDM, as far as I can tell (except that it doesn't create There are a couple Wine bugs to be aware of:
Let me know if this works! Ideally, compare it to the files created by JDM, and see if they're identical. If they are, then that's a pretty good guarantee that it'll work on the G1000. |
|
Oh, you'll also need to run |
|
The file feat_unlk.dat was created on my SD card! jdmtool transfer 5 /run/media/hbu/GARMIN/ ll /run/media/hbu/GARMIN/ On friday I will try to load all new databases from this card into the G1000NXi system. Keep finger crossed! |
|
So were you able to load them into the G1000NXi? |
|
Partially! However the jeppesen chart were not recognized as new and were therefore not be uploaded. I had to use the orginal JDM tool. Original Garmin SD Card using JDM: ll Charts/ ll Charts/ ll ldr_sys/ SDcard using JDMTOOL: ll Fonts/ ll ldr_sys/ |
|
Interesting. Well, it's great that feat_unlk.dat worked - that was probably the most difficult part. So simply extracting the .zip is not enough. Looks like a bunch of files need to be moved into a Charts subdirectory. Also, 023FL01687_VFRCharts.bin and 023KM01684_Charts.bin somehow get converted into charts.bin. Of course those are the two zips that I can't access myself, so it's hard to tell what's going on. I'd really like to look at them, but you probably shouldn't upload them here. Could you email me at dima [at] gmail.com, so we can figure something out? |
|
I finally cracked the format of the Charts.bin file. It's basically a Zip without compression. Documenting it here, mostly for myself:
Each entry in the table of contents is 40 bytes long, and has the following format:
It looks like ChartView is broken into multiple downloads (Europe IFR, Europe VFR, etc.). Each one is a .zip containing a charts.bin file (though with different names like 023KM01684_Charts.bin or 023FL01687_VFRCharts.bin). JDM first sorts each charts.bin file so its entries are ordered by their byte offsets, then combines them into one file. I'm assuming they wanted to let the user buy any combination of regions and VFR/IFR, but G1000 needs to have everything in a single file. The rest of the files in the .zip are mostly copied unchanged. The .dbf files might be getting merged, but it's a common file format. |
|
Great work! Just ran across this repo, and I suspect that once the G1000 issues are solved, it will be very easy to extend to other Garmin flight displays. I have a new-to-me G500 & G430W, and am using the Garmin database subscription service. I think the code here will be a great basis for extending to a tool that supports both download sources & multiple devices. Would be great to be able to process updates with out needing the Garmin DB Manager (currently running it on a Mac, haven't attempted to get running under Wine yet). I'll experiment more when I have some free time! |
|
@digivation: Thanks! Programming of the G430W should already work; I have a G430 myself. The G500 might work, too - do you use the same data cards and a USB programming device as for the G430W, or regular SD cards? Of course, you'd need to get the database file first. I haven't used the Garmin DB Manager, so no idea what it would take to reverse engineer it. If you want to do a quick test to see if anything works at all, you can read the existing database from the data card by running |
|
@dimaryaz I haven't tried the G430W but expect that to work just fine once I can get the databases from Garmin. The G500 uses SD cards, just like the G1000 - I suspect the data set is very similar. The 430 data cards are at the hangar, I'll check those next time I bring them home. |
This implements feat_unlk.dat, and hopefully fixes all G1000 services except charts. See #2
|
Hey @liviro411! I know it's been over a year... but I haven't given up yet. If you're still around, I'd love for you to try the new code. The latest released version of jdmtool should support everything but Electron Charts, and should produce results byte-for-byte identical to JDM itself. If you install the
Anyways... if you get a chance, try it and tell me how it works. |
|
@dimaryaz Are you still looking for testers for G1000? I have access to a Perspective and a JDM subscription. I will be testing the jdmtool SD card tomorrow on this avionics system. |
|
@aantonop Yes! Would love to know if it works for you. Let me know which subscriptions you have - in particular, if you use ChartView. You can try the latest release - it already contains all the G1000 features. |
|
I use ChartView - here are the subscriptions I have: I was unable to test the charts because of a 'basemap' bug that you have now fixed and I don't have access to test for the next 2 months, but I will get back to you on this. I am very interested in getting this to work. |
I am using an official garmin SD card with
lsusb
Bus 001 Device 008: ID 05e3:0745 Genesys Logic, Inc. Logilink CR0012
Therefore I modified your device.py:
class GarminProgrammerDevice():
VID = 0x05E3
PID = 0x0745
But "jdmtool detect" returns the following errors:
Found device: Bus 001 Device 008: ID 05e3:0745
Traceback (most recent call last):
File "/home/hbu/.local/bin/jdmtool", line 8, in
sys.exit(main())
File "/home/hbu/.local/lib/python3.10/site-packages/jdmtool/main.py", line 442, in main
func(**kwargs)
File "/home/hbu/.local/lib/python3.10/site-packages/jdmtool/main.py", line 66, in wrapper
with handle.claimInterface(0):
File "/home/hbu/.local/lib/python3.10/site-packages/usb1/init.py", line 1146, in claimInterface
mayRaiseUSBError(
File "/home/hbu/.local/lib/python3.10/site-packages/usb1/init.py", line 127, in mayRaiseUSBError
__raiseUSBError(value)
File "/home/hbu/.local/lib/python3.10/site-packages/usb1/init.py", line 119, in raiseUSBError
raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value)
usb1.USBErrorBusy: LIBUSB_ERROR_BUSY [-6]
Do you have any hints/suggestions?
The text was updated successfully, but these errors were encountered: