Reputation: 315
I'm hoping for some help with trying to write a piece of software that will allow me to read data from a serial magcard reader I have.
we have this card reader which it a very old piece of equipment we use to capture our members membership card details in our venues. The card reader has a piece of software that downloads the card details (that are stored on the card reader) the software then places the details in a text file on the C drive. I want to write some software that will do exactly the same thing.
I may be barking up the wrong tree or hoping for too much but any help at all would be great.
I have so far attached the card reader to the serial port of my machine and ran the legacy software and used a com port monitor to capture the communication. this is where im a bit stuck and was wondering if anyone could tell me if what Ive capture is useful in anyway and hopefully will point me in the right direction.
I ran the download sequence when the card reader had no card information stored on it and capture this.
[12/06/2012 18:28:55] - Open port COM4
[12/06/2012 18:29:02] - Written data
31 00 01 00 00 00 32 1.....2
[12/06/2012 18:29:04] - Read data
31 00 06 00 0c 06 0c 00 00 00 00 55 1..........U
[12/06/2012 18:29:04] - Written data
33 00 01 00 00 00 34 3.....4
[12/06/2012 18:29:05] - Read data
33 00 14 00 06 03 00 00 0c 00 00 0d 00 00 42 00 3.............B.
00 43 00 00 63 00 00 00 01 51 .C..c....Q
[12/06/2012 18:29:06] - Written data
34 00 01 00 00 00 35 4.....5
[12/06/2012 18:29:08] - Read data
34 00 01 00 00 00 35 4.....5
[12/06/2012 18:29:08] - Written data
35 00 07 00 0c 06 0c 12 1c 36 00 00 be 5........6..¾
[12/06/2012 18:29:10] - Read data
35 00 01 00 00 00 36 5.....6
[12/06/2012 18:29:11] - Close port COM4
Then I swiped 1 card so the card reader had this stored in its memory and ran the download again, this time I got this
[12/06/2012 18:31:23] - Open port COM4
[12/06/2012 18:31:48] - Written data
31 00 01 00 00 00 32 1.....2
[12/06/2012 18:31:50] - Read data
31 00 06 00 0c 06 0c 00 00 00 00 55 1..........U
[12/06/2012 18:31:51] - Written data
33 00 01 00 00 00 34 3.....4
[12/06/2012 18:31:53] - Read data
33 00 14 00 06 03 00 00 0c 00 00 0d 00 00 42 00 3.............B.
00 43 00 00 63 00 00 00 01 51 .C..c....Q
[12/06/2012 18:31:55] - Written data
34 00 01 00 00 00 35 4.....5
[12/06/2012 18:31:57] - Read data
34 00 01 00 00 00 35 4.....5
[12/06/2012 18:31:57] - Written data
35 00 07 00 0c 06 0c 12 1f 16 00 00 a1 5...........¡
[12/06/2012 18:32:01] - Read data
35 00 01 00 00 00 36 5.....6
[12/06/2012 18:32:01] - Close port COM4
Finally I swiped 3 cards and ran the download again and captured this
[12/06/2012 18:30:21] - Open port COM4
[12/06/2012 18:30:22] - Written data
31 00 01 00 00 00 32 1.....2
[12/06/2012 18:30:24] - Read data
31 00 06 00 0c 06 0c 00 03 00 00 58 1..........X
[12/06/2012 18:30:24] - Written data
32 00 04 00 03 00 01 00 00 3a 2........:
[12/06/2012 18:30:26] - Read data
32 00 1c 00 03 00 01 00 12 1e 58 28 54 08 33 00 2.........X(T.3.
12 1e 58 28 53 96 95 00 12 1e 58 28 54 12 32 00 ..X(S–•...X(T.2.
05 07 ..
[12/06/2012 18:30:27] - Written data
33 00 01 00 00 00 34 3.....4
[12/06/2012 18:30:29] - Read data
33 00 14 00 06 03 00 01 0c 00 00 0d 00 00 42 00 3.............B.
00 43 00 00 63 00 00 00 01 52 .C..c....R
[12/06/2012 18:30:30] - Written data
34 00 01 00 00 00 35 4.....5
[12/06/2012 18:30:41] - Read data
34 00 01 00 00 00 35 4.....5
[12/06/2012 18:30:41] - Written data
35 00 07 00 0c 06 0c 12 1e 15 00 00 9f 5...........Ÿ
[12/06/2012 18:30:43] - Read data
35 00 01 00 00 00 36 5.....6
[12/06/2012 18:30:43] - Close port COM4
All I know is that the legacy software checks to see if the device is connected to the com port selected then downloads the data then clears the data from the card reader
And in case it helps.. If I don't have the card reader attached and try and download I get this error
Command 0x31 Not Sent
Can anyone shed any light at all on this?
Thank you in advance.
Upvotes: 2
Views: 1537
Reputation: 941407
It is a pretty typical serial port protocol. Byte order is least-endian. The first two bytes are the block number, that's how the response is matched to the request and how loss of a packet can be detected. The next two bytes are the length of the message, in bytes. The bytes in message follow. The last two bytes are the checksum, the result of adding the bytes in the entire message. Big-endian for some weird reason, afaict.
That's just the protocol frame spec, imperfect for one because it doesn't show what happens when the data gets scrambled. What really counts is the data bytes in the message. No way to find out what those bytes mean without contacting the manufacturer and get the spec.
Upvotes: 3
Reputation: 21409
Being very familiar with these kind of protocols, the only ways I can think of to deal with this are:
Upvotes: 2