Since Acidus got me intrigued by this mag card reader business I've acquired 4 card readers: Omron track-2 TTL; Omron track 1+2 TTL; Cherry PC keyboard with built-in track 1+2 reader ; Magtek track 1+2+3 RS232. The first was purchased new from Digikey, the last three on eBay (none being more expensive than the first).
The latter two require no rewiring, automatically translate all supported track data into ASCII with one swipe, and produce far fewer "bad swipes" than the TTL readers. And for Linux I don't need to run as root.
The disadvantage of the Cherry and Magtek is they don't have the capability of sending raw output for non-standard tracks
(e.g., one library copy card I have, but I've yet to get two consistant raw swipes from that card with the TTL card readers either).
So while TTL card readers can sometimes be acquired for a pittance and it's fun to get them working, if all you want is the capability to read mag cards it's a lot easier to look for one of the PC keyboard (or keyboard wedge) or RS232 models.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been working on making Stripe Snoop more reliable with its swipes. Did you figure out how to configure the Cherry keyboard to insert some type of delimiter between tracks 1 and 2? The Cherry keyboard I had were too old for me to find a manual. I want to add full support for Cherry Keyboards.
Also, what about the Magatek RS-232 ? Does it do the same thing as the keyboard? (ie do all decoding inside and send the ASCII over the line?) Does it insert start characters? What settings did you use? 8N1?
Thanks for the info!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here's the info about the Magtek RS232 (Cherry to come later).
This is a Magtek model 21040074 mini-swipe reader which reads all three tracks. It's powered by the RS232 port and requires no separate power supply. It has an integral 6-foot cable with a molded 9-pin type-D ("DB-9") female connector (very convenient!). Here's the Magtek web page: http://www.magtek.com/products/card_reading/magstripe/swipe/mini/specs_rs_232.asp
Note: I understand some newer motherboards provide a cheapened "RS232" serial port which operates only between +/-5V instead of the standard +/-12V. I have no idea whether this reader would work with such a serial port.
The serial parameters are 9600 8N1
The output (for the only track 1+2+3 card I have) is strung together and looks like this:
%XXXX?;YYYY?+ZZZZ?<CR>
where XXXX, YYYY, ZZZZ are the card data for tracks 1, 2, and 3 repectively. <CR> is the Carriage Return character (0x0D). If a track is missing, it's omitted from the output string, e.g., a track 1+2 card would be displayed as %XXXX?;YYYY?<CR>.
The reader internally converts the binary data read from the card into ASCII. (One disadvantage is there is no optional "raw" mode for non-standard card encodings.)
If there is a read error, the bad track data is replaced by an 'E', e.g., for the library copy card previously mentioned with a non-standard track 2, the output is just
;E?<CR>
Note that the Magtek manual says that the "Start Sentinal" for track 3 which is '+' for ISO format will instead be '#' for AAMVA format or '!' for CDL format. (The latter two are driver license
formats - CDL for California.)
Two other documents (99875065-4.pdf and 99800004-1.pdf) available from Magtek's website indicate the ISO 4909 track 2 and track 3 Start Sentinal is 'Hex B ;' (without the apostrophes). If true, I assume the reader translates these into the displayed ';' and '+'.
For Windows users, Magtek provides a GUI demo program on their website which will set up the serial port and provide a minimal parsing of the card data. (Nothing like StripeSnoop's actual lookup of the bank name.) They also provide Windows drivers, but i haven't investigated them.
For Linux, I've just been setting the serial port parameters with 'stty' and reading the cards with:
$ cat /dev/ttyS0
/dev/ttyS0 is a buffered device driver and in order to flush the buffer to the screen with each read I have to have the driver translate the <CR> to a Unix Newline character by specifying 'icrnl' with the 'stty' setup string. For other Linux users who have a similar RS232 reader, here's the concise form of the 'stty'
command I've been using (unwap the line before using):
$ stty -F /dev/ttyS0 100:0:cbd:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
Regards,
Charles Sullivan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Cherry KBD info:
This is a Cherry model G81-8000LABUS/03. The exact model does not appear in Cherry's product list but as far as I can tell it's the same as their other G81-8000 tracks 1+2 PS/2 keyboards but with an AT-style DIN connector instead of the PS/2 mini-DIN connector. An AT->PS/2 adapter works fine.
The keyboard has just the slot across the top for swiping mag cards and no smart-card reader or connector for a barcode scanner. I requested a copy of the manual from Cherry's support web page and they kindly emailed me a copy in PDF format. This manual covers all their G80/81-7XXX/8XXX keyboards. The factory default for this KBD is to concatenate the data from the mag card tracks into one long string, without any '%', ';', or '?' separators, e.g., XXXXYYYY<CR> But headers and terminators for each track can be programmed. The conversion from binary to ASCII is performed internally by the keyboard. I don't know what happens if there's read error with a track or if a non-ISO formatted track 3 is read, i.e., like driver licenses where the track 3 "Start Sentinal" is '#' or '!' instead of '+'. (I get no output at all with my library copy card with the non-standard track 2.)
The following may be hard to read when sourceforge's posting engine scrunches all the line together but I'll try to compensate with single-quote (') characters - ignore them in all that follows. After my programming, swiping a track 1+2 card results in the following two lines: 'csnoop -1 "%XXXX?"<newline>' followed by 'csnoop -2 ";YYYY?"<newline>'. Where 'csnoop' is my yet-to-be-written parser program for Linux, and I enclose the track data in double-quotes (") because track 1 data at least can contain ASCII space characters.
To enter programming mode, simultaneously press and hold both left and right <ctrl><alt><shift> keys (six keys) for 3 seconds or more, until the keyboard beeps. To exit programming mode, press the spacebar.
While in programming mode, enable all three tracks (the firmware doesn't care if your keyboard model supports less than three) by touching keys 'v1y' then 'v2y' then 'v3y'.
(The KBD will be issuing response messages and beeps as you're doing this.) Now define the the terminators for all three tracks. The definition string is terminated by hitting the Enter key on the numeric keypad. I use '?"<main-kbd-Enter>' for the terminators.
While still in programming mode, touch keys 'w5?"<main-kbd-Enter><numeric-kbd-Enter>' then 'w6?"<main-kbd-Enter><numeric-kbd-Enter>' then 'w7?"<main-kbd-Enter><numeric-kbd-Enter'.
Now define headers for each track. While still in programming mode enter 'v5csnoop -1 "%<numeric-kbd-Enter>'
then 'v6csnoop -2 ";<numeric-kbd-Enter>' then 'v7csnoop -3 "+<numeric-kbd-Enter>'.
Finally, exit programming mode by hitting the spacebar.
Note: When I just tried re-programming this Cherry KBD my Linux X-windows locked up - the KBD seemed to be sending a bunch of control characters and wants to read or execute a file named ./0000.txt. It works OK in the text console. I hadn't noticed this problem the first time I programmed it, but recall that I then had the KBD plugged directly into the PC rather than via a KVM switch (IOGEAR GCS612A) as I have it now. I'll have to investigate further.
Regards,
Charles Sullivan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding the Cherry programming problem I mentioned in my last message: I still haven't figured out exactly what the KBD is transmitting, but it's affecting only my PC running Red Hat 9. There's no real problem on my other PC running Fedora Core 2.
The KBD does send the string '<BEL> *** Menu Entry ***' and if
programmed at the command line, Linux 'bash' will attempt to execute the ***, which is expanded as the first file in the current directory, which in the previously mentioned situation happened to be 0000.txt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since Acidus got me intrigued by this mag card reader business I've acquired 4 card readers: Omron track-2 TTL; Omron track 1+2 TTL; Cherry PC keyboard with built-in track 1+2 reader ; Magtek track 1+2+3 RS232. The first was purchased new from Digikey, the last three on eBay (none being more expensive than the first).
The latter two require no rewiring, automatically translate all supported track data into ASCII with one swipe, and produce far fewer "bad swipes" than the TTL readers. And for Linux I don't need to run as root.
The disadvantage of the Cherry and Magtek is they don't have the capability of sending raw output for non-standard tracks
(e.g., one library copy card I have, but I've yet to get two consistant raw swipes from that card with the TTL card readers either).
So while TTL card readers can sometimes be acquired for a pittance and it's fun to get them working, if all you want is the capability to read mag cards it's a lot easier to look for one of the PC keyboard (or keyboard wedge) or RS232 models.
Good report!
I have been working on making Stripe Snoop more reliable with its swipes. Did you figure out how to configure the Cherry keyboard to insert some type of delimiter between tracks 1 and 2? The Cherry keyboard I had were too old for me to find a manual. I want to add full support for Cherry Keyboards.
Also, what about the Magatek RS-232 ? Does it do the same thing as the keyboard? (ie do all decoding inside and send the ASCII over the line?) Does it insert start characters? What settings did you use? 8N1?
Thanks for the info!
Here's the info about the Magtek RS232 (Cherry to come later).
This is a Magtek model 21040074 mini-swipe reader which reads all three tracks. It's powered by the RS232 port and requires no separate power supply. It has an integral 6-foot cable with a molded 9-pin type-D ("DB-9") female connector (very convenient!). Here's the Magtek web page:
http://www.magtek.com/products/card_reading/magstripe/swipe/mini/specs_rs_232.asp
Note: I understand some newer motherboards provide a cheapened "RS232" serial port which operates only between +/-5V instead of the standard +/-12V. I have no idea whether this reader would work with such a serial port.
The serial parameters are 9600 8N1
The output (for the only track 1+2+3 card I have) is strung together and looks like this:
%XXXX?;YYYY?+ZZZZ?<CR>
where XXXX, YYYY, ZZZZ are the card data for tracks 1, 2, and 3 repectively. <CR> is the Carriage Return character (0x0D). If a track is missing, it's omitted from the output string, e.g., a track 1+2 card would be displayed as %XXXX?;YYYY?<CR>.
The reader internally converts the binary data read from the card into ASCII. (One disadvantage is there is no optional "raw" mode for non-standard card encodings.)
If there is a read error, the bad track data is replaced by an 'E', e.g., for the library copy card previously mentioned with a non-standard track 2, the output is just
;E?<CR>
Note that the Magtek manual says that the "Start Sentinal" for track 3 which is '+' for ISO format will instead be '#' for AAMVA format or '!' for CDL format. (The latter two are driver license
formats - CDL for California.)
Two other documents (99875065-4.pdf and 99800004-1.pdf) available from Magtek's website indicate the ISO 4909 track 2 and track 3 Start Sentinal is 'Hex B ;' (without the apostrophes). If true, I assume the reader translates these into the displayed ';' and '+'.
For Windows users, Magtek provides a GUI demo program on their website which will set up the serial port and provide a minimal parsing of the card data. (Nothing like StripeSnoop's actual lookup of the bank name.) They also provide Windows drivers, but i haven't investigated them.
For Linux, I've just been setting the serial port parameters with 'stty' and reading the cards with:
$ cat /dev/ttyS0
/dev/ttyS0 is a buffered device driver and in order to flush the buffer to the screen with each read I have to have the driver translate the <CR> to a Unix Newline character by specifying 'icrnl' with the 'stty' setup string. For other Linux users who have a similar RS232 reader, here's the concise form of the 'stty'
command I've been using (unwap the line before using):
$ stty -F /dev/ttyS0 100:0:cbd:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
Regards,
Charles Sullivan
Cherry KBD info:
This is a Cherry model G81-8000LABUS/03. The exact model does not appear in Cherry's product list but as far as I can tell it's the same as their other G81-8000 tracks 1+2 PS/2 keyboards but with an AT-style DIN connector instead of the PS/2 mini-DIN connector. An AT->PS/2 adapter works fine.
The keyboard has just the slot across the top for swiping mag cards and no smart-card reader or connector for a barcode scanner. I requested a copy of the manual from Cherry's support web page and they kindly emailed me a copy in PDF format. This manual covers all their G80/81-7XXX/8XXX keyboards. The factory default for this KBD is to concatenate the data from the mag card tracks into one long string, without any '%', ';', or '?' separators, e.g., XXXXYYYY<CR> But headers and terminators for each track can be programmed. The conversion from binary to ASCII is performed internally by the keyboard. I don't know what happens if there's read error with a track or if a non-ISO formatted track 3 is read, i.e., like driver licenses where the track 3 "Start Sentinal" is '#' or '!' instead of '+'. (I get no output at all with my library copy card with the non-standard track 2.)
The following may be hard to read when sourceforge's posting engine scrunches all the line together but I'll try to compensate with single-quote (') characters - ignore them in all that follows. After my programming, swiping a track 1+2 card results in the following two lines: 'csnoop -1 "%XXXX?"<newline>' followed by 'csnoop -2 ";YYYY?"<newline>'. Where 'csnoop' is my yet-to-be-written parser program for Linux, and I enclose the track data in double-quotes (") because track 1 data at least can contain ASCII space characters.
To enter programming mode, simultaneously press and hold both left and right <ctrl><alt><shift> keys (six keys) for 3 seconds or more, until the keyboard beeps. To exit programming mode, press the spacebar.
While in programming mode, enable all three tracks (the firmware doesn't care if your keyboard model supports less than three) by touching keys 'v1y' then 'v2y' then 'v3y'.
(The KBD will be issuing response messages and beeps as you're doing this.) Now define the the terminators for all three tracks. The definition string is terminated by hitting the Enter key on the numeric keypad. I use '?"<main-kbd-Enter>' for the terminators.
While still in programming mode, touch keys 'w5?"<main-kbd-Enter><numeric-kbd-Enter>' then 'w6?"<main-kbd-Enter><numeric-kbd-Enter>' then 'w7?"<main-kbd-Enter><numeric-kbd-Enter'.
Now define headers for each track. While still in programming mode enter 'v5csnoop -1 "%<numeric-kbd-Enter>'
then 'v6csnoop -2 ";<numeric-kbd-Enter>' then 'v7csnoop -3 "+<numeric-kbd-Enter>'.
Finally, exit programming mode by hitting the spacebar.
Note: When I just tried re-programming this Cherry KBD my Linux X-windows locked up - the KBD seemed to be sending a bunch of control characters and wants to read or execute a file named ./0000.txt. It works OK in the text console. I hadn't noticed this problem the first time I programmed it, but recall that I then had the KBD plugged directly into the PC rather than via a KVM switch (IOGEAR GCS612A) as I have it now. I'll have to investigate further.
Regards,
Charles Sullivan
Regarding the Cherry programming problem I mentioned in my last message: I still haven't figured out exactly what the KBD is transmitting, but it's affecting only my PC running Red Hat 9. There's no real problem on my other PC running Fedora Core 2.
The KBD does send the string '<BEL> *** Menu Entry ***' and if
programmed at the command line, Linux 'bash' will attempt to execute the ***, which is expanded as the first file in the current directory, which in the previously mentioned situation happened to be 0000.txt.
I had a friend surprise me and order a 3 track Magtek serial reader for me. I should receive it early this week, and will code in support for it