I own an ACS ACR122 RFID reader (bought from, now deceased, Touchatag) and, surprisingly, things don't go so smoothly with ACS bare bones scripting tool ACR 122U Scripting Tool "SAM" Version 1.0.0.2 (you'll be asked for your email however I wonder what's the need since the download proceeds with any email adress and ACS never sends any info nor advertisement). The scripts provided with the Scripting Tool fail miserably (status code 6300 !), in particular, when trying to write to the MIFARE 1K and Ultralight tags (only cards I tried).

At this stage, I will focus on the MIFARE 1K tags (ISO/IEC 14443A) and will be using the ACR122U in a Windows XP environment. Ultimately I want to write a small application in Visual Basic (I can roughly read C code but that's about all I can do in C). If you have some running code in VB I'll be more that happy to have a look at it.

In case you're wondering, no, this reader won't read the Navigo pass and since I don't have other types of transport cards I can't answer whether the ACR122 reads YOUR card or not so don't ask (or send an identical card).

Firmware version of the reader

First, I needed to check the firmware version of my reader. If I were to believe the ACS API documentation (API_ACR122.pdf V1.2), sending the command FF 00 48 00 00 would return a 10 bytes result which, translated to ASCII, gives the reader name and firmware version.

• the last "00" of the command is supposedly the length in bytes of the result. How "00" tells the reader we expect a 10 bytes response leaves me in great distress unless it really means "whatever you care to respond". In doubt, I tried FF 00 48 00 0A instead of FF 00 48 00 00. After digging even more documentation from ACS, I found in API_ACR122-SAM.pdf that I might be right with my 0A length. Experience shows that whatever you try, from 00 to FF, will do fine !
  • the scripting tool expects you send a pseudo field in the form [xx xx ... xx] to return the response so the command here should be
    FF 00 48 00 0A [xx xx xx xx xx xx xx xx xx xx] unless you're satisfied with a "the response returned has a different length than the expected response" nasty message.
    
    
• all commands sent to the Scripting Tool must end with a status code otherwise you get a nasty "status code is missing" message. Here we expect the command to go smoothly and the status code should be 9000 thus FF 00 48 00 0A [xx xx xx xx xx xx xx xx xx xx] (9000) seemed adequate. Unfortunately this does not work because the "get firmware version" command doesn't return a status code ! There is no easy solution unless you already know your firmware version which kind of defeats the command in the first place ! Anyway, I found that my firmware being 41 43 52 31 32 32 55 31 30 32, the Scripting Tool would not shout at me if I used the last two digits as the return code therefore I sent the command
  FF 00 48 00 0A [xx xx xx xx xx xx xx xx xx xx] (3032) and return 41 43 52 31 32 32 55 31 30 32 which translates to ASCII ACR122U102.
  
  
• finally, having the Touchatag version of the ACR122U, it has a SAM (Security Access Module) and, again, if I were to believe the ACS documentation API_ACR122-SAM.pdf I should get an ASCII response like ACR122U-SAM102 but I don't !

ID of the tag on reader

Next I wanted to retrieve the ID of the tag read by the ACR122.

I started by asking the reader to find out if any tag was present on the reader. It's the "Polling" command FF 00 00 00 09 D4 60 01 01 20 23 11 04 10 (xxxx) that, again, returns a status code you can't know in advance since it depends on the type of tag found. In my case, a MIFARE 1K fob, it returns a status code 6110 thus if I want the Scripting Tool to not shout at me again, the proper command is FF 00 00 00 09 D4 60 01 01 20 23 11 04 10 (6110)

Once done, let's get details about THAT tag by issuing the command FF C0 00 00 10 (the "10" of the command depend on the status code returned by previous command) with enough space for the response thus in Scripting Tool syntax I sent the command :
FF C0 00 00 10 [xx xx xx xx xx xx xx xx xx xx xx xx xx xx] (9000)

I was rewarded by a nice "D5 61 01 10 09 01 00 04 08 04 0E C1 7E DE 90 00" response where 0E C1 7E DE is the unique number of THAT tag number

Generic RC522 reader

These 13.56 MHz readers come in various forms however, despite the RC522 chip having an I²C port, I never found one reader with this interface enabled. They are SPI readers. And dead cheap readers!

You will find several libraries available on the Net and those I tried worked fine so I won't go over them.

A point that's never highlighted is the fact that while reading tags goes smoothly, writing to the tag may fail! When that happens to my builds (your mileage may vary), it seemed that powering the reader from the Arduino provided (I guess) too little current. The work around was to power the reader with its own power source and link the two both Arduino & reader's grounds together. Possibly, adding a capacitor close to the reader's power line may solve the issue too but I never tried that.

I found these readers to work fine (when they worked at all) however, if you work with a small Arduino, you may find that SPI "eats" too many GPIO particularly if you drive several devices depending on which RFID tag is presented to the reader.

Despite the SS (Slave Select) pin marked SDA on the reader, I never managed to run more than one reader. Some people managed to use 2 or more RC522 readers using a different MCU pin for each reader MOSI pin.

Warning

Due to the very, very low price of these readers, sometime the acronym for quality control is FU not QC. If you find yourself locked outside of your house with a RC522 reader that does not respond to your RFID tag, don't complain: you've been warned!

PN532 readers

These are also 13.56MHz readers so they're pretty much the same as RC522 readers except PN532s support NFC too. Most PN532 readers, if not all, come with the I²C port enabled. You will find tons of libraries to drive these readers with an Arduino, RPI, STM32, ...

In a hobby "production environment", I'd rather choose these PN532 readers over RC522 ones.