Different iid for "orange" IFRW data card: 0x89007e00

[bemowski]

I have a garmin 530W, and with it I have 2 data cards: one "silver" and one "orange" (see pictures).

When I run transfer with the orange datacard I'm getting this output:

jdmtool transfer 0
Found device: Bus 001 Device 007: ID 0e39:1250
Unknown data card IID: 0x89007e00 (possibly 8MB non-WAAS?). Please file a bug!

[bemowski]

A bit more debugging information - it seems there are 2 versions of G2 adapter (orange and black label), and 2 versions of IFRW card (orange and silver label).

https://support.jeppesen.com/article?pc=Tools&pid=JDM_Windows&aid=kA260000000CdZ9CAK

[dimaryaz]

Oh interesting. If you're lucky, the orange card still has the same interface, so try adding its ID to with_data_card in main.py, e.g.:

        elif iid == 0x89007e00:
            # 16MB orange WAAS card
            print("Detected data card: 16MB WAAS, orange label")
            dev.set_memory_layout(SkyboundDevice.MEMORY_LAYOUT_16MB)

Before actually transferring anything, try reading its contents first, e.g.:

jdmtool read-database db.bin

If it succeeds, see if it looks reasonable - should be a few MBs in size, and file db.bin should report it as a "DOS/MBR boot sector".

These data cards use somewhat arbitrary memory regions to store the data (see this). 4MB cards use a subset of 16MB cards. I'd hope that silver and orange cards use the same layout, cause why wouldn't they - but who knows. If the layout is different, then writing the database will fail, or you will end up with bytes in the wrong order.

To be 100% sure that the layout is the same, you can:

• Run jdmtool download - the DB will end up in ~/.local/share/jdmtool/downloads/
• Download and transfer the new DB using the official JDM
• Run jdmtool read-database db.bin
• Run cmp db.bin ~/.local/share/jdmtool/downloads/[name].bin. The last few KBs will differ because of some trailing \xFF` bytes - but other than that, they should be the same.

If the above succeeds, then it should be safe to transfer the database using jdmtool, too.

[bemowski]

I would be happy to take the steps to try this out - but before I do i'd like to confirm one thing: I won't damage the card? If i can just use the windows based jdm tool to overwrite whatever garbage I would potentially write. (to the best of your understanding is fine).

I have an older Silver and newer Orange card - and I rotate them. So the silver is in the plane at the moment, and i can ply with the orange.

I can try this stuff out tomorrow and post details here. I'm pretty comfortable tweaking the python. I would even create a PR to fix this in code if I make it work.

I have a personal vested interest in this - JDM is the last reason I have to run windows in virtual box. I've been 100% linux user for almost 10 years now.

Let me know about your best guess as to the possibility of damaging the card - and i'll give it a try, probably tomorrow.

[dimaryaz]

I'm fairly confident it won't damage the cards - I've tried reading from / writing to wrong memory regions, and even reading from TAWS cards (which of course doesn't work, but I had to try...) So far, no damage.

I'd say, read-database is completely safe. write-database or transfer could leave you with bad data, but that can be fixed using JDM on Windows.

Or, if you can record USB traffic using Wireshark while transferring the database in JDM, that would give me all the data we need. It's fairly straight-forward:

• Give yourself access to usbmon, e.g. chmod a+rw /dev/usbmon*
• Run Wireshark (in Linux). You will likely see multiple usbmon devices - usbmon0, usbmon1, etc. - you'll have to try and figure out which one shows the data card traffic. (Also, if you're using a USB keyboard/mouse, watch out for that, too.)
• While Wireshark is capturing, transfer the database in JDM in VirtualBox.

That's how I reverse-engineered all of this in the first place. I then used usbrply to convert pcap files to Python.