ESP32_RFID_Reader: reading a pet microchip with a converted RDM6300

134.2kHz FDX-B for pet microchips, 125kHz EM4100 for everything else

Two protocols, one board. The first is FDX-B, the biphase encoded protocol used by microchipped pets in the UK and EU, running at 134.2kHz. The second is EM4100, Manchester encoded and running at 125kHz, which is what the hardware in this project speaks out of the box. When a tag is decoded, the ID goes to two places: a web page served by the ESP32 itself, and an optional I2C LCD1602 display if one is wired up. That is the entire output of the application. There is no database, no logging of who was scanned and when, and no network service beyond the pages on the board, so what you build on top of the ID is entirely your own work.

The RDM6300 arrives at 125kHz and has to be converted by hand

The instructions assume you either build the circuit or buy a cheap 125kHz EM4100 reader and rework it, and the reworking is specific. The board's own microcontroller and the voltage regulator, both marked with red crosses in the diagram, are removed or disabled, because from then on the ESP32 generates the antenna clock and decodes the raw data itself. Raising the antenna to 134.2kHz is done two ways: reduce the value of the capacitor ringed in cyan, or remove turns from the supplied antenna to cut its inductance. A spreadsheet called `antennaFreq.xlsx` in the `extras` folder exists to help you pick values. The raw signal leaves at the resistor end marked by the green arrow, the input clock arrives at the pink one, both connections to the ESP32 go through 5V and 3V3 level shifters, and the bare connection points can be rewired to repurposed header pins. Signal conditioning is the job of an LM358 dual op amp, configured as a Schmitt trigger so that noise on the antenna edge does not produce spurious transitions.

Built for a catflap, settled on a handheld reader

The project's origin explains both its scope and its limits. The library was written for a microchip controlled catflap, where an ESP32 would open a flap for a registered pet. That goal was not reached with this hardware: the text says plainly that the RDM6300 did not have sufficient range to be reliable for a flap mounted in a door, while remaining fine as a handheld reader you hold against the animal. That is the honest shape of the project, a short-range reader presented as a handheld device rather than a fixed installation. The README also carries a warning in its own heading: only use this app if you are familiar with electronics and can fix issues yourself.

Drop the files into a sketch folder and delete the -master suffix

There is no package manager step. The GitHub files are downloaded into the Arduino IDE sketch folder, and the application folder name has to lose its `-master` suffix, because the Arduino IDE will not compile a folder whose name does not match the sketch inside it. The build then needs an Arduino core of version 2.x or 3.x, with 3.0.3 named as the minimum, and the partition scheme set to `Minimal SPIFFS`, which is what leaves room on the flash chip for the web pages and data files the application expects to find. Nothing pins the libraries, so the versions the IDE resolves are the ones you get, and the file layout in the repository is what the IDE expects to find inside that sketch folder.

First boot is an access point, and the board fetches its own web pages

There is no configuration file to write before the first run. On installation the application starts in WiFi access point mode, so you join the SSID that begins with `ESP32_RFID_` and open the web page at 192.168.4.1, where the router and password details are entered. The configuration data file is created automatically, with the single exception that passwords are not written into it, and once the board has an internet connection it downloads its own web pages from GitHub into the `/data` folder on the SD card. That is worth understanding before you debug anything: the interface you are configuring the board through is a set of files that arrived over the network rather than something compiled into the firmware.

Firmware and data reach the board over OTA, GitHub or WebDAV

Three separate routes push new content to the device, and they are not interchangeable. The OTA Update tab updates the application firmware itself, using a bin file or files held in the `/data` folder. The Reload /data button on the Edit Config tab fetches the data folder from GitHub again, which is how you recover a corrupted or edited web page set. A WebDAV client pointed at `ip_address/webdav` does the same job over a file-transfer protocol, and the text offers it as an alternative to the button rather than as an extra feature. So an update to the interface and an update to the firmware are separate operations, and the first of the two does not require reflashing anything.

The Edit Config tab is where the pins and the credentials live

The IO Extender page is organised as four tabs, and each one does a small set of jobs. The RFID tab shows the selected encoding type, the tag ID when something has been read, a control for choosing the encoding type, and a button that clears the tag from the display. Show Log opens a web socket so log messages appear as they happen. Edit Config is the substantial one: Reboot ESP restarts the board to apply some changes, Reload /data pulls those files from GitHub, Clear NVS wipes the stored passwords, Wifi holds the network and web server settings, Peripherals takes the pin numbers for the RDM6300 connection, the optional LCD1602 and an optional button to clear the display, and Save is what makes those changes survive a reboot.

One .ino and nine .cpp files, compiled by the Arduino IDE

The source is laid out as an Arduino sketch with the parts split by concern, and the names say what each file is for: RFID.cpp for the decoding, periphsI2C.cpp for the optional display, prefs.cpp for stored settings, setupAssist.cpp for first-run help, webServer.cpp and webDav.cpp for the two network surfaces, utilsFS.cpp and utils.cpp for the filesystem and odds and ends, with appGlobals.h and globals.h holding shared declarations. Alongside them sit a `data` directory and the `extras` folder with the antenna spreadsheet. There is no platformio.ini, no CMakeLists.txt and no library.properties in the tree, so the Arduino IDE is the build system and the repository is a sketch rather than a library. The licence is AGPL-3.0, the newest release is v2.3 dated January 17, 2026, and the last push to the master branch carries the same date.

Editorial conclusion

Use this project if you specifically want to read a UK or EU pet microchip or an EM4100 tag on an ESP32, you are prepared to modify an RDM6300 board or build the antenna circuit yourself, and you are comfortable with web configuration, SPI flash partitions and level shifters. Do not pick it as a finished product, as a range-limited catflap controller, or as an attendance or NFC system, since the decoded ID is all it produces and the text itself warns that you need electronics knowledge to fix your own faults. Before you solder, confirm your board really needs converting, read the AGPL-3.0 terms before you publish anything derived from it, and check the current tag against v2.3, the release dated January 17, 2026.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes