Archive for July, 2013

RFID card ID formatting

July 10, 2013

I keep intending to blog more, and I keep getting side-tracked.  There will be more regular updates after the Open Access Control 3.0 system is hacked together had installed at i3 Detroit, you can follow along with the updates as they are made here.  This update is a small part of that project.

RFID card reading systems have three main formats they return/accept IDs in: 1 26-bit numbers, 2 16-bit numbers, or 7 4-bit numbers.  The first method  is the most obvious, you take a 26 bit binary number and represent it as a decimal value.  This is usually the number displayed on the side of the badge or key fob.  The second method for identification pads the 26-bit number out to 32 bits with leading zeroes, splits it into two numbers, and represents each of them in decimal form (usually with a colon in between them).  The maximum value for this system is 1023:65535, that is a 26 bit number, all of whose bits are 1.  This method for identification has been seen on some older cards and in off-the-shelf RFID door systems.  The last method of representation is to convert the 26- bit number into a 28-bit number by padding it out with leading zeroes and splitting it up into 4-bit hexadecimal digits.  This method is frequently used as a compact visual representation by embedded processors (I use this method, ok).

Example: the above tag reads: 0005280984, that’s the decimal representation.  from that we can easily get the binary representation as: 00010100001001010011011000 (note the leading zeroes that make it 26 bits).  padding this with 6 zeroes we get 0000000001010000:1001010011011000, or 80:38104 in the second notation.  The third notation gives us 05094D8 (note the leading zero).  All this being said, it’s extremely important that you note there are no trailing zeroes in your binary numbers (as in you have more than 26 bits), otherwise your value will be shifted and unrecognizable in decimal or hexadecimal notation.  The code used by the Parallax serial RFID reader outputs in hexadecimal digits (as characters), the code from the wiegand26 library I use outputs a trailing zero at the end of a binary sequence (but it’s stored in a long, no characters so can be rendered as anything), and as such must be shifted back off the number.