Having problems writing to my Garmin non-Waas card

[paulohm2]

~# jdmtool download 4 Downloading database: 100%|███████████████████████████████████████████████████████████████████████████████████████████████| 1.31M/1.31M [00:18<00:00, 71.7kB/s] Downloaded to /root/.local/share/jdmtool/downloads/dgrm78_2405_3f7deeaf.bin

~# ls -Al .local/share/jdmtool/downloads/ total 3460 -rw-r--r-- 1 root root 2228224 May 22 04:50 dgrm77_2405_5e7b065e.bin

~# jdmtool transfer 4 Found device: Bus 003 Device 006: ID 0e39:1250 Transfer /root/.local/share/jdmtool/downloads/dgrm78_2405_3f7deeaf.bin to the data card? (y/n) y Does not look like a Garmin database file.

[paulohm2]

~# jdmtool detect Found device: Bus 003 Device 009: ID 0e39:1250 Firmware version: 20071203 Card inserted: IID: 0xff00ff00 Unknown identifier: 0xff00ff00

[paulohm2]

~# jdmtool read-database db.bin Found device: Bus 003 Device 009: ID 0e39:1250 Reading the database: 8%|███████▎ | 1.29M/16.8M [00:17<03:25, 75.5kB/s] Truncating the file... Done

[paulohm2]

this also does NOT work

~# jdmtool write-database /root/.local/share/jdmtool/downloads/dgrm78_2405_3f7deeaf.bin Found device: Bus 003 Device 009: ID 0e39:1250 Transfer /root/.local/share/jdmtool/downloads/dgrm78_2405_3f7deeaf.bin to the data card? (y/n) y Does not look like a Garmin database file.

[paulohm2]

Download seems to work, but the downloaded data files is not recognized as a valid garmin database

~# jdmtool download 3 Downloading database: 100%|████████████████████████████████████████████████████████████████████████████████████████████████| 3.54M/3.54M [00:11<00:00, 320kB/s] Downloaded to /root/.local/share/jdmtool/downloads/dgrm72_2405_072061ba.bin

~# jdmtool transfer 3 Found device: Bus 003 Device 009: ID 0e39:1250 Transfer /root/.local/share/jdmtool/downloads/dgrm72_2405_072061ba.bin to the data card? (y/n) y Does not look like a Garmin database file.

[dimaryaz]

Could you post the first 64 bytes of your database file?

I have a sanity check to make sure it's a database, not something unexpected - but it's very likely the check is overly strict.

E.g., run this in Python:

fd = open("/root/.local/share/jdmtool/downloads/dgrm72_2405_072061ba.bin", "rb")
print(fd.read(64))

[paulohm2]

~# python3 Python 3.7.3 (default, Jan 22 2021, 20:04:44) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information.

fd = open("/root/.local/share/jdmtool/downloads/dgrm72_2405_072061ba.bin", "rb") print(fd.read(64)) b'\x1b\xc79`+9\x04\xf6\xc7\x1e\xa7+z,\xfcn\xf8\x06\xbc\xca\xa4\x1d0i\x88\x1b\xc7\xcf\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

[paulohm2]

looks quite different from

DB_MAGIC = ( b'\xeb<\x90GARMIN10\x00\x02\x08\x01\x00\x01\x00\x02\x00\x80\xf0\x10\x00?\x00\xff\x00?\x00\x00\x00' b'\x00\x00\x00\x00\x00\x00)\x02\x11\x00\x00GARMIN AT FAT16 \x00\x00' )

[dimaryaz]

Interesting...

Looks like you already copied the existing DB from your data card to db.bin - can you see if that one looks the same? If so, I guess that's expected. You can actually just edit the Python file and remove the DB_MAGIC check to get around it.

What kind of avionics do you have - GNS430, or something else? If you don't mind, could you post your ~/.local/share/jdmtool/services.xml? (Just censor your email, customer number, tail number, etc.; all I really want to see is unique_service_id, service_code, and version.)

[paulohm2]

the db.bin file looks as weird as the other print.

please let me know where I can find the .py file to edit, as I installed it using pip3

~# python3 Python 3.7.3 (default, Jan 22 2021, 20:04:44) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information.

fd = open("db.bin", "rb") print(fd.read(64)) b'\n\x13\xe8Vx\xe3\xb2y`mn\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

[dimaryaz]

The file location depends on how exactly you've installed it, but you can find it like this:

import jdmtool
jdmtool.__file__

(It'll show the __init__.py, but main.py will be next to it.)

[paulohm2]

everything went (almost) well - check error at the end

jdmtool transfer 4

Found device: Bus 003 Device 009: ID 0e39:1250 Transfer /root/.local/share/jdmtool/downloads/dgrm78_2405_3f7deeaf.bin to the data card? (y/n) y Erasing the database: 100%|███████████████████████████████████████████████████████████████████████████████████████████████| 1.51M/1.51M [00:24<00:00, 62.5kB/s] Writing the database: 100%|███████████████████████████████████████████████████████████████████████████████████████████████| 1.51M/1.51M [00:46<00:00, 32.7kB/s] Verifying the database: 100%|█████████████████████████████████████████████████████████████████████████████████████████████| 1.51M/1.51M [00:19<00:00, 75.7kB/s] Writing new metadata: {2405~33791439} Unexpected response: bytearray(b'\xff\x00\x0f\x00')

[paulohm2]

my avionics

data.xml.gz

[dimaryaz]

Ok, I guess it failed to write the metadata string. What happens if you run jdmtool read-metadata?

In my case, the metadata doesn't matter... But clearly, everything is slightly different for you. I'm using GNS 430; do you have a different one?

Anyways, I'm curious if the data card works successfully for you. I think there's a chance that it doesn't, so I'd say, have the "official" JDM ready if you need to fix your data card.

And thanks for the services.xml. Btw, you have IFD 400, too? That's funny - I literally just got it working a couple days ago; see bug #6.

[paulohm2]

Will try the card next friday and let you know. Don't know much about python, but the differences between what you expect from the card as a signature and mine are so different that I would guess that there is some encoding/decoding issue going on.

Yes I have an IFD440, and just purchased an IFD550, so lots of fun ahead !!! :-)

I usually use this device to write my cards and usb drives, but since it has been retired I am considering using this neat SBC and your project as an alternative.

After making things work out, will work on a neat GUI.

[paulohm2]

… and I also have a GNS430, so that’s why I am finding this all too weird

Em ter., 21 de mai. de 2024 às 20:43, Dima Ryazanov < @.***> escreveu:

Ok, I guess it failed to write the metadata string. What happens if you run jdmtool read-metadata?

In my case, the metadata doesn't matter... But clearly, everything is slightly different for you. I'm using GNS 430; do you have a different one?

Anyways, I'm curious if the data card works successfully for you. I think there's a chance that it doesn't, so I'd say, have the "official" JDM ready if you need to fix your data card.

And thanks for the services.xml. Btw, you have IFD 400, too? That's funny

• I literally just got it working a couple days ago; see bug #6 https://github.com/dimaryaz/jdmtool/issues/6.

— Reply to this email directly, view it on GitHub https://github.com/dimaryaz/jdmtool/issues/7#issuecomment-2123600707, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE7GYLP6LVFO4OUVYUJZWV3ZDPLZ5AVCNFSM6AAAAABICLSZOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRTGYYDANZQG4 . You are receiving this because you authored the thread.Message ID: @.***>

[dimaryaz]

Ok, I solved some of the mystery - it's WAAS vs non-WAAS. So I technically have GNS430W, not GNS430; sorry, didn't realize they actually used different data cards!

So anyways, the DB_MAGIC not working for you is completely expected: it's not an encoding/decoding issue, but literally a different subscription and a different DB format.

Also, my service.xml needs a 16MB card:

<card_size_min>16777216</card_size_min>
<card_size_max>16777216</card_size_max>

while yours needs 4-8MB:

<card_size_min>4194304</card_size_min>
<card_size_max>8388608</card_size_max>

This also explains the failure when writing the metadata: in my case, the metadata is written right at the 16MB mark - which doesn't exist on your card. (Does it need to write metadata at some other location on your card? I guess we don't know that... but the metadata is unused, as far as I can tell.)

Also, jdmtool detect shows this for me:

  IID: 0x1004100
  Unknown identifier: 0x38001000

and this for you:

  IID: 0xff00ff00
  Unknown identifier: 0xff00ff00

so I guess I could tell which card it is. Do you have 4MB or 8MB by the way?

I think the biggest remaining question is: other than the size, are the two data cards compatible? The WAAS data card has a strange memory layout: it uses 16KB pages, and each page has an ID that falls into one of these eight ranges.

The fact that writing the database worked at all for you means the 4MB and 8MB cards probably just use the first two or four ranges instead of eight. Could Garmin do something insane like use the same page IDs, but in a different order? Hopefully not.

But, here's how you can test it: pick one of the services, e.g. 3, and program the data card using JDM - then run jdmtool read-database db.bin, and see if db.bin ends up the same as ~/.local/share/jdmtool/downloads/dgrm72_2405_072061ba.bin. Except that the data card doesn't know the size of its own data, so there will be trailing \xFFs; jdmtool automatically removes them when reading from the data card, but you'll have to ignore them in dgrm72_2405_072061ba.bin. I.e., pick the smaller file size, and only compare that many bytes.

[dimaryaz]

Also, I'm really curious, from seeing your subscriptions: do you fly from Brazil to the US?? That's pretty far :)

[paulohm2]

:-)

The US package is mandatory, even for Brazilian customers

But I indeed flew this trip last year - awesome experience over the Amazon jungle and the Caribbean

Will work on the remaining issues tonite.

Em qua., 22 de mai. de 2024 às 04:28, Dima Ryazanov < @.***> escreveu:

Also, I'm really curious, from seeing your subscriptions: do you fly from Brazil to the US?? That's pretty far :)

— Reply to this email directly, view it on GitHub https://github.com/dimaryaz/jdmtool/issues/7#issuecomment-2124062083, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE7GYLJAM35JDO6COTXXESTZDRCJFAVCNFSM6AAAAABICLSZOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRUGA3DEMBYGM . You are receiving this because you authored the thread.Message ID: @.***>

[paulohm2]

According to this, my card is 8Mb

so I guess I could tell which card it is. Do you have 4MB or 8MB by the way?

[dimaryaz]

Nice, thanks. I'm also curious if JDM writes the metadata the same way as it does on 16MB cards.

Could you edit device.py, change METADATA_PAGE to 0x02FF, run jdmtool read-metadata, and show me the output?

Then try 0x037F, and re-run it. That should fail - unless you actually have an 8MB card.

[dimaryaz]

(As for flying over the Amazon - that is so cool. Maybe I'll get to do that some day...)

[paulohm2]

Seems that my card is 4Mb after all ... see below: Seems that most of the first 2Mb are the same

But, here's how you can test it: pick one of the services, e.g. 3, and program the data card using JDM - then run jdmtool read-database db.bin

~# jdmtool read-database db.bin Found device: Bus 003 Device 002: ID 0e39:1250 Reading the database: 25%|███████████████████████████████▊ | 4.24M/16.8M [00:56<02:46, 75.2kB/s] Truncating the file... Done

~# ls -Al db.bin -rw-r--r-- 1 root root 4239360 May 23 06:52 db.bin

~# jdmtool refresh Downloading services... Downloading keychain... Success root@unihiker:~# jdmtool list ID Name Coverage Version Start Date End Date Downloaded 0 Avidyne EX5000, EX600, EX500 - NavData Americas 2405 2024-05-16 2024-06-13
1 Avidyne IFD 400 Series, Bendix King AeroNav Series - NavData Americas 2405 2024-05-16 2024-06-13
2 Avidyne IFD 400 Series, Bendix King AeroNav Series - Obstacles Americas 2405 2024-05-16 2024-06-13
3 Garmin GNS 400/500 Series - NavData United States & Lat… 2405 2024-05-16 2024-06-13 Y
4 Garmin GNS 400/500 Series - NavData Latin & South Ameri… 2405 2024-05-16 2024-06-13 Y
5 Garmin GNS 400/500 Series - NavData Northern United Sta… 2405 2024-05-16 2024-06-13 Y
6 Avidyne EX5000, EX600, EX500 - Electronic Charts Brazil IFR 11-2024 2024-05-24 2024-06-07

~# jdmtool download 5 Downloading database: 100%|███████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 2.23M/2.23M [00:15<00:00, 143kB/s] Downloaded to /root/.local/share/jdmtool/downloads/dgrm77_2405_5e7b065e.bin

~# ls -Al /root/.local/share/jdmtool/downloads/dgrm77_2405_5e7b065e.bin -rw-r--r-- 1 root root 2228224 May 23 06:55 /root/.local/share/jdmtool/downloads/dgrm77_2405_5e7b065e.bin

~# cmp /root/.local/share/jdmtool/downloads/dgrm77_2405_5e7b065e.bin db.bin /root/.local/share/jdmtool/downloads/dgrm77_2405_5e7b065e.bin db.bin differ: char 2097153, line 24541

[paulohm2]

No change ~# jdmtool read-metadata Found device: Bus 003 Device 002: ID 0e39:1250 Database metadata:

change METADATA_PAGE to 0x02FF ~# jdmtool read-metadata Found device: Bus 003 Device 002: ID 0e39:1250 Traceback (most recent call last): File "/usr/local/bin/jdmtool", line 8, in sys.exit(main()) File "/usr/local/lib/python3.7/dist-packages/jdmtool/main.py", line 479, in main func(*kwargs) File "/usr/local/lib/python3.7/dist-packages/jdmtool/main.py", line 70, in wrapper f(dev, args, **kwargs) File "/usr/local/lib/python3.7/dist-packages/jdmtool/main.py", line 237, in cmd_read_metadata value = b''.join(blocks).rstrip(b"\xFF").decode() UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe8 in position 1: invalid continuation byte

Then try 0x037F, and re-run it. That should fail - unless you actually have an 8MB card. ~# jdmtool read-metadata Found device: Bus 003 Device 002: ID 0e39:1250 Database metadata:

[paulohm2]

trying to write the card

jdmtool transfer 5

Found device: Bus 003 Device 002: ID 0e39:1250 Transfer /root/.local/share/jdmtool/downloads/dgrm77_2405_5e7b065e.bin to the data card? (y/n) y Erasing the database: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 2.42M/2.42M [00:38<00:00, 62.5kB/s] Writing the database: 86%|████████████████████████████████████████████████████████████████████████████████████████████████████████████▉ | 2.10M/2.42M [01:08<00:10, 30.8kB/s] Traceback (most recent call last): File "/usr/local/bin/jdmtool", line 8, in sys.exit(main()) File "/usr/local/lib/python3.7/dist-packages/jdmtool/main.py", line 479, in main func(*kwargs) File "/usr/local/lib/python3.7/dist-packages/jdmtool/main.py", line 70, in wrapper f(dev, args, **kwargs) File "/usr/local/lib/python3.7/dist-packages/jdmtool/main.py", line 209, in cmd_transfer _write_database(dev, path) File "/usr/local/lib/python3.7/dist-packages/jdmtool/main.py", line 339, in _write_database dev.write_block(block) File "/usr/local/lib/python3.7/dist-packages/jdmtool/device.py", line 97, in write_block self.write(data) File "/usr/local/lib/python3.7/dist-packages/jdmtool/device.py", line 36, in write self.handle.bulkWrite(self.WRITE_ENDPOINT, data, self.TIMEOUT) File "/usr/local/lib/python3.7/dist-packages/usb1/init.py", line 1389, in bulkWrite return self._bulkTransfer(endpoint, data, sizeof(data), timeout) File "/usr/local/lib/python3.7/dist-packages/usb1/init.py", line 1359, in _bulkTransfer self.handle, endpoint, data, length, byref(transferred), timeout, File "/usr/local/lib/python3.7/dist-packages/usb1/init.py", line 127, in mayRaiseUSBError raiseUSBError(value) File "/usr/local/lib/python3.7/dist-packages/usb1/init.py", line 119, in raiseUSBError raise __STATUS_TO_EXCEPTION_DICT.get(value, __USBError)(value) usb1.USBErrorTimeout: LIBUSB_ERROR_TIMEOUT [-7]

[dimaryaz]

So cmp failed exactly at the 2MB mark... That's what I was afraid of. Each list in DATA_PAGES represents exactly 2MB - so the first entry is the same for 4MB and 16MB cards, but the second one is not.

I was also assuming it would fail when reading an invalid location, but I guess it doesn't. But the write fails - and transfer 5 also failed at exactly 2MB.

Let me write a script that tries reading various pages, and finds the location of the second 2MB for you.

(Or, in the off chance that you have JDM working on Linux - in either wine (don't know if that's even possible) or in VirtualBox - it's possible to record all USB traffic. That's how I originally reverse-engineered the 16MB card.)

[paulohm2]

Now ... this is weird ... I can write the card with the original db.bin file.

jdmtool write-database ~/db.bin

Found device: Bus 003 Device 004: ID 0e39:1250 Transfer /root/db.bin to the data card? (y/n) y Erasing the database: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 4.39M/4.39M [01:10<00:00, 62.5kB/s] Writing the database: 100%|██████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 4.39M/4.39M [02:09<00:00, 33.8kB/s] Verifying the database: 100%|████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 4.39M/4.39M [00:58<00:00, 75.6kB/s] Done

[paulohm2]

(As for flying over the Amazon - that is so cool. Maybe I'll get to do that some day...)

[dimaryaz]

It's possible that reading an invalid location just returns \xFF bytes - and writing \xFF to an invalid location does nothing. The way these data cards work is pretty weird.

[paulohm2]

So cmp failed exactly at the 2MB mark... That's what I was afraid of. Each list in DATA_PAGES https://github.com/dimaryaz/jdmtool/blob/main/src/jdmtool/device.py#L19-L28 represents exactly 2MB - so the first entry is the same for 4MB and 16MB cards, but the second one is not.

I was also assuming it would fail when reading an invalid location, but I guess it doesn't. But the write fails - and transfer 5 also failed at exactly 2MB.

and it failed miserably. I had to unplug the device and replug it again in order to make the usb port become available again

Let me write a script that tries reading various pages, and finds the location of the second 2MB for you.

(Or, in the off chance that you have JDM working on Linux - in either wine (don't know if that's even possible) or in VirtualBox - it's possible to record all USB traffic. That's how I originally reverse-engineered the 16MB card.)

this is a little bit above my paycheck, but challenge accepted, if there is no other way and you walk me through. I believe I already tried to use wine to run JDM, but without success. I have virtualbox installed, but no Windows image to run on it :-(

— Reply to this email directly, view it on GitHub https://github.com/dimaryaz/jdmtool/issues/7#issuecomment-2125936642, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE7GYLK5N2NCY7ZL5VLMVALZDUSMTAVCNFSM6AAAAABICLSZOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRVHEZTMNRUGI . You are receiving this because you authored the thread.Message ID: @.***>

[dimaryaz]

Ok, here's a script for scanning data on the card: https://gist.github.com/dimaryaz/2bb353f93ae1ec11a9335519ffe96e21

It reads every 16th page (just to be faster; in my case, all page ranges are divisible by 16), and if it appears to contain data, it saves it into a file. Each file will be 64KB.

So 00E0.bin should be the first 64KB of your database file. The goal is to find the first 64KB of the second 2MB chunk of the database (and then confirm that the rest of it is there, too.)

Here's the fun part... When reading invalid pages, you sometimes get random data, sometimes contents of other pages - so figuring out what's going on isn't trivial. In my case, page 0x00C0 returns the same data as 0x00E0. So I guess try adjusting the numbers, and find the correct blocks. Or even adjust the script to compare the blocks to your database file.

[paulohm2]

~# python3 dump.py Found device: Bus 003 Device 002: ID 0e39:1250 Trying page 0000... Found data! Saving to 0000.bin Trying page 0010... Found data! Saving to 0010.bin Trying page 0020... Found data! Saving to 0020.bin Trying page 0030... .... Trying page 03E0... Found data! Saving to 03E0.bin Trying page 03F0... Found data! Saving to 03F0.bin

each file is 64k

used this to find one binary file inside a bigger one https://gist.githubusercontent.com/thommyj/3403088/raw/27c91d49a538d2479ddd2a6988d950c314c2c5aa/blobfind.c

here are the outputs of only the FOUND blobs

./a.out db.bin 0030.bin

Found blob2 at offset 0x00100000

./a.out db.bin 0050.bin

Found blob2 at offset 0x00100000

./a.out db.bin 0080.bin

Found blob2 at offset 0x00000000

./a.out db.bin 0090.bin

Found blob2 at offset 0x00100000

./a.out db.bin 00A0.bin

Found blob2 at offset 0x00000000

./a.out db.bin 00B0.bin

Found blob2 at offset 0x00100000

./a.out db.bin 00C0.bin

Found blob2 at offset 0x00000000

./a.out db.bin 00D0.bin

Found blob2 at offset 0x00100000

./a.out db.bin 00E0.bin

Found blob2 at offset 0x00000000

./a.out db.bin 00F0.bin

Found blob2 at offset 0x00100000

./a.out db.bin 0230.bin

Found blob2 at offset 0x00100000

./a.out db.bin 0250.bin

Found blob2 at offset 0x00100000

./a.out db.bin 0270.bin

Found blob2 at offset 0x00100000

./a.out db.bin 0280.bin

Found blob2 at offset 0x00000000

./a.out db.bin 0290.bin

Found blob2 at offset 0x00100000

./a.out db.bin 02A0.bin

Found blob2 at offset 0x00000000

./a.out db.bin 02B0.bin

Found blob2 at offset 0x00100000

./a.out db.bin 02C0.bin

Found blob2 at offset 0x00000000

./a.out db.bin 02D0.bin

Found blob2 at offset 0x00100000

./a.out db.bin 02E0.bin

Found blob2 at offset 0x00000000

./a.out db.bin 02F0.bin

Found blob2 at offset 0x00100000

On Thu, May 23, 2024 at 12:05 AM Dima Ryazanov @.***> wrote:

Ok, here's a script for scanning data on the card: https://gist.github.com/dimaryaz/2bb353f93ae1ec11a9335519ffe96e21

It reads every 16th page (just to be faster; in my case, all page ranges are divisible by 16), and if it appears to contain data, it saves it into a file. Each file will be 64KB.

So 00E0.bin should be the first 64KB of your database file. The goal is to find the first 64KB of the second 2MB chunk of the database (and then confirm that the rest of it is there, too.)

Here's the fun part... When reading invalid pages, you sometimes get random data, sometimes contents of other pages - so figuring out what's going on isn't trivial. In my case, page 0x00C0 returns the same data as 0x00E0. So I guess try adjusting the numbers, and find the correct blocks. Or even adjust the script to compare the blocks to your database file.

— Reply to this email directly, view it on GitHub https://github.com/dimaryaz/jdmtool/issues/7#issuecomment-2126146772, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE7GYLL5C42J5JXLNBMGZO3ZDVMIDAVCNFSM6AAAAABICLSZOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRWGE2DMNZXGI . You are receiving this because you authored the thread.Message ID: @.***>

[paulohm2]

Also, be advised that the card is written through a device like this