Proxmark3 developers community

Research, development and trades concerning the powerful Proxmark3 device.

Remember; sharing is caring. Bring something back to the community.

"Learn the tools of the trade the hard way." +Fravia

You are not logged in.

#1 2020-02-02 00:43:20

Registered: 2017-06-25
Posts: 42

ISO 15693 on the MFRC522 (Limited support, work in progress)

Ages ago I posted about the fact that the MFRC522 reader chip from NXP (and possibly its clones) could be used to do "something else" than reading/writing ISO14443/MIFARE tags.

I've recently been working on reading 15693 tags with an Arduino Uno connected to the RC522 even if I thought it had little chances to work... and it eventually worked!

So I created a test sketch but it's yet very very dirty. If you want to test you may need to change the chip select and reset pins. The sketch should print the UID of an ISO15693 card.
That's the only thing it can do, next step would be some simple commands (read/write blocks), then I'll probably move to another platform (such as ESP32 thanks to its huge processing power) to do some more advanced stuff. (Maybe I'll someday try sniffing?)

There are two HUGE problems tho.
First problem, it takes 1280 bytes of RAM just to send an INVENTORY command.
Second problem, I have to disable interrupts to avoid screwing up the timing, but this might make millis() time measurements wrong.

How does it works ?.
To send the data I just flip the InvMod bit in the TxModeReg register. Doing it fast enough allows me to modulate the carrier.
To receive data I read the TestADCReg which shows the values of the two 4-bit inphase and quadrature ADCs.

Timing is quite tricky. In the 15693 standards all frequencies are 13.56MHz divided by powers of two, but on the Arduino frequencies are 16MHz divided by powers of two. To get a good compromise between timing accuracy and buffer size, I set the SPI clock divider to 8 so i have 2Mb/s / 250KB/s raw data rate. Because the ATMEGA328's SPI transmitter is not double buffered the actual datarate is actually 230.9 KB/s (and thus 230.9 Ksamples/s).

Here are the following steps this sketch performs in order to read a tag:
- Prepare a transmit buffer from the INVENTORY command (the CRC is already included)
- Prepare a receive buffer
- Transfer data to the TxModeReg to send the command
- Transfer I/Q samples from TestADCReg to the RX buffer
- Convert the I/Q samples into amplitudes
- Discretize the amplitude.
- Decode the Manchester coding
- Check CRC

And then finally print the UID.

Last edited by atmel9077 (2020-02-20 13:19:47)

Those who forget the past are doomed to repeat it.


#2 2020-02-06 09:25:56

From: germany
Registered: 2019-10-28
Posts: 19

Re: ISO 15693 on the MFRC522 (Limited support, work in progress)

Hallo atmel9077,

Your Post is quit impressive!
I couple month ago, I was interested in reading / writing iso15693 but my equipment was a MFRC522 witch is "normally" not capable of doing iso15693. Thats why I switched to the PN5180 witch can do both. ISO144443 and ISO15693. (Back when I switched it could only do ISO15693, but toeddy extended the Lib of ATrappmann to do both. Really good job done.).

Could the way you choose to implement the iso15693 reading with an MFRC522 be used to use the MFRC522 to emulate an iso15693 tag as well?
Would be great to get an exchange with you to go even further with the MFRC522.



#3 2020-02-06 16:10:46

Registered: 2017-06-25
Posts: 42

Re: ISO 15693 on the MFRC522 (Limited support, work in progress)

Thanks for your reply!
I will try to create an ISO15693 library for the RC522, and then I will see if I can implement emulation, but I don't think it's possible. Sniffing MIGHT be as the RC522' receiver is more or less a software defined radio frontend. The problem is that the SPI bus is limited to 10Mbps which gives a 1.25MHz sample rate, which is not ideal to properly demodulate 848kHz carriers.

Also, have you tried to run the sketch with your rc522 and was the range decent ?


Those who forget the past are doomed to repeat it.


#4 2020-02-19 21:09:17

Registered: 2017-06-25
Posts: 42

Re: ISO 15693 on the MFRC522 (Limited support, work in progress)

Update :

The (very partial) ISO15693 library for the RC522 is in progress and will come soon.

The two major problems are :
  - A 1280 byte buffer is requiered to store analog transmit/receive samples
  - Interrupts are DISABLED when transceiving.
  - Signals are NOT processed in realtime.
    -> Before transmitting, the first part of the buffer is set acccording to the data, and the rest is prepared for receiving
    -> The first part of the buffer is sent to the RC522's TxControlReg in order to transmit, and then samples from the TestADCReg fill the remaining part of he buffer in order to receive
    -> The remaining part of the buffer is processed in multiple steps to decode the data.
  - The sample rate is LOWER than the 423kHz tag's subcarrier. The subcarrier is thus NOT demodulated. But it still works!

Here is what I've been able to do so far :
- Transceiving
  -> Reader to card
        Data rate : Only HIGH is supported (26.67kbps, 1 out of 4 coding)
        Modulation : Only 100% is supported, but 10% should be possible
  -> Card to reader
        Data rate : Only HIGH is supported (26.67kbps)
        Modulation : Only single subcarrier is supported
  -> Airtime : 217 bytes of DSP buffer gives 1ms of airtime. (Either transmitting or receiving).
  -> DSP buffer size : a 1280-byte DSP buffer allows to transceive 17 bytes. that's enough to send a 5-byte Inventory request and to receive the 12-byte tag response.

- Inventory.
  -> Anticollision is NOT implemented.
  -> Only 1 timeslot is supported
  -> If more than one tag is present in the field, the library will report that no tag is detected.

- Select

- Read single block
  -> Only 4-byte blocks are supported
  -> I will add support for block lock status
  -> ONLY selected mode is supported.

- Write single block
  -> Only a 4 byte block can be written
  -> Because of the very limited airtime I can not get the response from the card so I need to read the block after writing it.
  -> I will try to add support for the Option flag to force the tag to respond after an EOF, rather than once the EEPROM has been written.

- Reset to ready

Last edited by atmel9077 (2020-02-20 13:15:53)

Those who forget the past are doomed to repeat it.


Board footer

Powered by FluxBB