I have a project that needs many rfid readers, but using the network is not an option.
Would it be possible to reliably run 36 of these readers from 1 windows PC with powered hubs?
Maybe this is another option but I need to ideally have a buzzer
1 Like
With a tech hat on… yeah why not 
With an “out of the box” hat … yeah but some thought and challenges need to be addressed.
While I have not used the reader, based on a quick read it works as follows
- Connect to USB port of a PC, shows up as a serial/comXX port.
- USB provides power for it to run
- Card tapped, if readable will have its card id send out the TX pin then into the PC via USB to what ever is listening on CommX
So, questions/thoughts.
- How many ports can your software deal with. if writing your own, I would assume this would be ok,
- How far away are the readers? from memory USB is about 5 m, greater then that you need some powered repeaters.
To have long runs you really need to drop the USB and run the readers uart into an RS485 cable (2 wires) and power (2 wires).
You should be able to then connect a collection of readers onto the one “4 wire” bus (2 data, 2 power).
For each bus, you would then have a RS485 convert into the PC and a power supply to power the readers.
This would allow the comms to work (at a high level), but would not easily Address each “reader”.
Other needs of the design will depend on your purpose.
e.g.
Do you need to know what card was tapped onto what reader, or are you just logging if someone tapped on somewhere.
Thanks Michael for your detailed response.
Yes I’ll write the software.
Distance I need to confirm. They’ll vary but I was planning on powdered USB hubs.
In software I need to receive an id of the reader and tapped RFID card. Will it be tricky to receive the reader id?
Would the pico be a better option for my purposes? Keeping in mind all the raspberry pis and power required for those.
Hi all
That makes sense.
RS485:
That depends on what is required.
Full duplex - 2 way coms simultaneously. 1 power and 2 RS485 data circuits (6 wires). Terminate data circuits (120Ω between A and B) at the receiver end of both data lines.
Simplex - 1 way coms. 1 power and 1 RS485 data circuit (4 wires). Terminate data circuit (120Ω between A and B) at the receiver end of data line.
Half duplex - 2 way coms. 1 direction only at a time. 1 power and 1 RS485 data circuit (4 wires). Terminate data circuit (120Ω between A and B) at BOTH ends.
Power can be local if easier.
Theoretical maximum “drops” is stated at 32. Actual recommended is something less than this. Application notes for these chips (Maxim ??) contain a lot of practical installation information.
Don’t forget that RS485 is only the transport medium and all drops receive all data on the line. Any addressing and/or decoding is the responsibility of the data equipment itself.
Cheers Bob
All good points Bob, I was really expecting some more detail and actual layout would result in multiple runs… and you can also do bi-directional half duplex.
real readers run OSDP for all this now (over 2 wire bus), but data is polled from the controller as apposed to each end just sending when a tap happens… then I noted it was getting a little more complex with the nominated readers (without something in front of them)
As I have not used that reader, does it send its ID ? They way I read the spec was it simple sends out the scanned ID, as that data the reader sends may not have a reader ID.
This is what I was just referring to above; and as such may be better reviewing the choice of reader deeding how what you can break out (more homework needed).
In my head, what I am seeing is more inline with how OSDP (what’s used in real world door access sytems).
e.g.
Have a reder with a logic level output (e.g. UART/i2C etc) like the one of choice above, but tap into that UART before it goes into the USB.
Run that into a small controller, that will receive the scanned cards ID.
that controller can the do what every you feel works best.
e.g. append a reader ID to the scanned ID, then forward that to the central system.
Depending on the layout you can use some local comms (wired or wireless; but I did not you did not want wireless). back to the central hub (as pre bobs comments within a working level and spec. and setup to meet the standards.)
If you do a store and scan, the edge controller simply stores the tapped ID. when the central controller polls that units ID it would forward the stored ID, so the controller is in full control thus should not have an bus collisions.
You can then have more then one “bus controller” to spread the load and poll loop time. Each of these controllers would have its own interface into the PC.
Since the edge controller is hard wired to the reader, you can add what ever is needed. e.g. encrypt the data over the comms back to the controller PC. trigger a buzzer, led flash etc.
Do you need to send anything back to the reader ?
The way I see the project, I think this is a better reader (I do not this is 13.56 Mhz v the other one being 125Khz … but if you have not issued any cards yet this should not be an issue.
this has the low level IO broken out to much simpler to then connect that to a controller of choice.
i.e. $11.30 for this reader then add something like an ESP32-Mini ESP32-S3 Mini Development Board | Buy in Australia | WS-25081 | Core Electronics
for $9.30 and you now have a $20 reader and a micro to make do what ever is needed.
the ESP32 mini will have wifi built in, so if you were allowed wifi then setup an Access Point and you could have 2 way wifi comms, just need to power the reader and controller.
If you are allowed to go the wifi to its own AP then the only other edge cost is the power,
If not, added a uart to RSxxx tbc (once we get into the detail design). and run power and comms over a cable.)
e.g.
MAX485 - TTL UART to RS485 Converter Module | Buy in Australia | CE05154 | Core Electronics $3.70
So not including power or cables, you have a $25 edge node with HF RFID v the $90 starter kit.
If you can rough out a floor plan and reader placements, I think it would help with a detailed design and parts list.
Hi Michael
Be a bit careful with that converter (CE05154) as it has got some strange resistors on board.
Don’t know what R5 and R6 are for (and it seems nobody else does either) except unbalance a normally balanced line. I think I did notice somewhere that it is to do with the idle condition and making sure the line goes into a predetermined state. might be good for 1 device but several effectively in parallel could not be a good thing.
R7 is a terminating resistor and should only be on the END of a cable. NOT on every drop.
This leaves me with the impression that this device is only intended for 1 unit at each end of 1 circuit and NOT for multiple drops.
I have used RS485 on several situations but for the most instances it has been incorporated into a purpose built board. These have had connected A/B IN and A/B OUT terminals is a cable run can be looped through and the termination resistor can be easily fitted at the end of a circuit.
Cheers Bob
Hi Michael
Just had a look at this web site
to find out what OSDP was.
There are some contradictions and strange statements here.
I don’t think RS485 is really a Protocol. It is the transport medium using balanced line thus great comm distances possible.
The second statement concerning the wires is a direct conflict. Looks more like RS232 without the ground return.
Some of this leaves one wondering
4 Key Best Practices for Implementing OSDP
In order to implement OSDP successfully, there are four key best practices that should be followed. These practices will help organizations maximize the benefits of OSDP and ensure an efficient and secure access control system.
1. Install End of Line Terminating Resistors
To ensure proper functioning, the transmission line impedance should match the hardware impedance of the connected interface, which is 120 Ω. Termination is necessary to achieve this. Attaching a resistor between the signal lines at both ends of the transmission line accomplishes proper termination. When termination is not implemented, reflection can occur, causing the voltage to bounce back onto the line and distort the signal.
2. Use a Twisted Pair Wire
Twisted pair cables consist of two insulated copper wires twisted together to minimize electromagnetic interference (EMI) and crosstalk. Any external interference or noise is canceled out by twisting the wires, ensuring reliable and high-quality data transmission. This makes twisted pair cables ideal for OSPD applications, where data signals need to be transmitted over long distances outdoors.
3. Use an Overall Low-Capacitance Wire
By using a low-cap wire, which refers to a wire with a lower capacity for electrical current, helps reduce potential interference or signal degradation. This is crucial for ensuring reliable and robust communication between devices within an OSDP system.
4. Use Stranded Cable
Stranded cables are made up of multiple smaller wires twisted together, which provides flexibility and durability. This ensures that the cable can withstand frequent movement or bending without breaking. It also provides greater resistance to breaking when terminating wires into a Terminal Block connector (which is common for Access Control panels). Stranded cables are also less prone to signal interference and offer better transmission quality than solid cables.
End Quote
Items 1 and 2 are valid.
Item 3 has a strange statement
“which refers to a wire with a lower capacity for electrical current”
As does item 4
“Stranded cables are also less prone to signal interference and offer better transmission quality than solid cables.”
Makes one (me anyway) very confused. Leaves me thinking how much of this article would stand up to any more scrutiny.
I will not bother as I don’t think I will be involved in access systems anyway.
Just thought others might be interested as anyone could dial up this site believing all could be gospel and walk away more confused than ever.
Cheers Bob
Yeah, the actual standard document is a pay for document from SIA.
I have the latest and wrote more own software to talk OSDP to a 3rd party reader (like this project) as well as wrote my own server software to talk to HID SIgno Readers.
Im not suggesting this project go that fair, simply referencing how they do it to give an idea what may be needed for this project.
Thanks for the heads up on that reader. If I was doing it, I would be tempted to simply buy the driver chip and bits for it to work and make a PCB to supply the links and power etc. I built an 8 node + controller a few years back. end to end was about 45 M of cable and the terminate was added to the remote end with a special end cap (as apposed to running a cable to the next unit).
To do this today, with all the cheap micro controllers, i really would be tempted to go down a “radio” path. But need to see how far and what could block the RF.
Alot of retro fit door access now have a local “ap” somewhere hidden, but with in range of a group of door access controllers. that “ap” then is wired back to the data network and back to the door access controller system. i.e. people don’t like running cables now and one to once cables get expressive.
Of course we can explore all sorts of radio links, Wifi and APs, zigbee, lora , but for a higher number like this (36) dumping the comms onto a data network allows good use of existing infrastructure and easier deployment. You can then “double protect” the comms. end to end, use some form of per reader key (issued at commissioning) and then the WiFi encryption. the ESP32 WiFi will suport PSK and 801.1x enterprise. So an existing wifi and data network could be used, or a bring your own.
But I digress as the discussion was more around it being wired.
Thanks for your input all!
It’s gotten quite technical very quickly 
I’m an interactive software dev, with some distant and relatively small experience with arduino and sensors, so you will have to dumb it down for me!
Below is a floor plan. Measurements in mm. The yellow circles are the RFID scanners.
I really like the sound of cheaper hardware, and I think the ESP32 mini would give good flexability.
What scanners can I use with the ESP32 mini? Would it get to overly complicated running 3 scanners from one ESP32? See the scanner groupings of 3 in the floor plan.
With this room layout what would be the most robust way to link them all for power and communication?
There will be 1 central Windows PC/Database collecting all RFID Scanner IDs and the RFID card ID that taps them.
This is all just to give an idea to a design and verification of parts and final solution should happen prior to ordering anything (outside of testing).
I would hold off on actual parts until the detail requirements have been worked out.
How man readers could run off a single micro controller will mainly depending on the signal/comms protocol the readers have V how many of those can be connected.
The ESP32-S3 has 2 i2c ports,
i2c uses addresses to ID the target chip, so you could have a small collection of i2c devices on the one bus.
The 13.56/HF Rfid reader uses i2c and can be set to 1 of 4 addresses.
So based on all of that, in theory a simple solution should support 8 readers per ESP32-S3.(not other chips can have different support ports).
To support those 8 readers you will now be using 4 Pins (outside of power) maybe more if you need control of some other things like reset etc (I would need to do a full read of the reader data sheet to make sure).
You would then need a connection to the uplink wire (if not going wireless). Normally that would be 1 of the uarts.
So at a quick response the ESP32-S3 should be able to run 8 readers, BUT the mini may not have enough pins presented, so a move to a bigger board from my pins exposed would address that.
What scanners can I use with the ESP32 mini?
Really any “scanner” that supports the common low level signals e.g. SPI, I2C, UART.
That linked to the above, at low speeds you can also “bit bang” a port if you need.
(i.e. you, via your code set and read the start of general io pins to send and read data), but ideally you tend to avoid that unless really needed and let the controller do it and worry about the timings.
With micro controllers, its normally a chip type that has features (ESP32-S3 …) and then you have that chip on a dev board that will have other bits added and expose some pins (e.g. Mini is nice and small, but may not have the pin count needed)
Im not sure on your timeline, but I might get some of those Pico Rfid readers and confirm how the operate. I find some of these pre-made devices, while sound great sometimes lack in detail and/or have some other weirdness (as bob pointed out with the RS485 interface). So always good to compare.
I have plenty of cards and ESP32 devices and should be able to confirm operation fairly quickly after the bits arrive. Just need to keep in mind, I am still working full time, so lots of this is weekend work, so could take a little bit of time to 100% confirm things. I have a solid background in RFID readers and different cards; so for a few $$ I more then happy to have a play and confirm things that is one of my hobbies.
Back to your detail:
Pending test results, I would tend to go with 3-4 readers per “edge controller” i.e. on set per bay.
Given the open area of the setup. Would you consider 2.4 Ghz Wifi Link back to the central PC ?
edit: should have been i2c not spi
Thanks Michael I appreciate your offer and input.
Where are you based?
I am hoping to use the project as a learning opportunity as much as possible.
Spec-ing the hardware is probably the trickiest thing for me, hopefully putting it together a bit easier. But I may well need pro help down the line.
For ease of use (for me), and connectivity options I’m now thinking raspberry pi with the PiicoDev RFID Module.
Looks like I could get 3 readers on there using the PiicoDev Adapter for Raspberry Pi, and depending on which PI it could have wifi and/or LAN connectivity.
I think that keeps things simple 
let me know what you think.
Hi Michael
I wasn’t referring to the “reader” as in card reader.
I was talking about the extra resistors fitted to that RS485 converter SKU CE05154.
BUT
This makes me think we are on the same page and you are actually referring to SKU CE05154 as a “reader”.
Just a bit of confusion
Cheers Bob
I based east of Melbourne.
A few high level things to keep in mind (good for general knowledge and may or may not make any difference to this project).
The are 3 main type of RFID in common use.
- LF - 125Khz, this is largely old tech getting replaced with HF.
Most (not all) LF tags are “read only” tags, with a pre-programmed ID. when the tag is presented to the reader, the tag powers up and spits out its ID in a loop until it looses power. This would seem to make it an easy tech, but there are many types of modulations and encodings. But with the right tools (proxmark3) most can be cloned without too much trouble.
- Main exception would be Hi Tag as used in some cars.
-
HF 13.56 Mhz. These are more common with new developments happening today. Mifare Classic is very common and is mostly been cracked, but a bit harder to clone. In the HF tags there are standards that should be followed meaning that once you understand the lower level protocol of the standard (e.g. 14a) you can spend more time in the protal data packets.
-
UHF, mainly used for long range reading.
for “local access” rfid HF would be the way to go. e.g. Door access, Print release etc.
HF cards are a bit more complex then a raw read but allow data to be stored on the card and read back with the correct access keys.
In theory HF cards can have more then one on a reader and the anti collision process is used to get a list of card IDs and then select ONE card to talk to.
Part of the Anti Collision process is to get the cards public ID (goes by a few names) 4 and 7 Byte IDs are common. Mifare Classic is a 4 byte ID.
This ID if the only thing used is no more or less secure then an LF tag. But if more security is needed, then access a secure part of the card and reading back a secured ID adds a new layer of security that can be harder to clone/copy, and in some card tech, is still considered very secure.
All that said, not everything needs the best security.
E.G. while someone can copy your physical key, they would need access to it (to get its profile, e.g. photo of a key). the same can be said for most LF and UID only HF tags. if someone can get access to your card (or sniff at the reader) they can then use that data to “copy” the card.
Older wired readers commonly used a wire level protocol call wiegand. i.e. 2 Data wires + power + a separate wire to trigger the door latch. with this if you can tap into the two data wires you can record and clone, then play back the ID on the wire, thus removing all the security from the card tech. e.g. the reader uses keys to read the a secure id off the card then encodes that in a wiegand format, and sends over the wire to the central control. and that data is the same as its always one way.
OSDP was developed to replace that but use the same 4 wires. Vcc Gnd D1 and D2. but this was RS485 and two way, with a central controller controlled comms. Since this is two way, the central controler can talk to the card and other local things like door latch release, LEDs and buzzers. OSDP also added encryption to the wire level comms as a recommended/included option.
While all of that is interesting… its just to give an idea and some food for thought. e.g. Some people will say go with HID SEOS cards or Mifare Desfire EV2/3 cards. And yes thats a good idea for higher security, but it most cases, unless the security is managed end to end correctly, the cost starts to outway the actual level of security.
E.g. If you just care if a customer stopped at a kiosk, then more common tech can be used for much less $$.
Coming back to the core pico hf reader, if you look on the product page there is a link to some sample python code to show how to talk to a card (mifare classic)
the high level apprach is like above.
- Poll the reader to see if a card is present.
- If a card is present, get its ID (anti collision process)
3a. If we only want a unique ID, where done, so reset and wait for the next card.
3b. If we want a more secure ID, then setup a read sector command with the sector ID and key and read the bytes from the secured sector.
, now exit and wait for next card.
If any more complex then that, then that needs to be part of the design specs for the project, which may lead to different card techs, thus different readers.
I suspect for your needs, a simple “ID” is all that is needed.
1 Like
You are correct, Its an electrical standard
Rgds
John
Client-Server Setup for 36 RFID Readers (WiFi-Based)
Use a PC as the central server and ESP32-based microcontrollers (with WiFi) as clients.
- Server (PC):
- Runs database software (SQLite, MySQL, PostgreSQL, etc.).
- Aggregates data from all clients, writes to databases.
- Clients (ESP32):
- Connect to RFID readers (UART/SPI).
- Send scanned tag data to the server via WiFi.
- No hubs required; direct WiFi communication.
Setup Steps:
- Program ESP32s to read RFID data and transmit via WiFi.
- Host a server script (Python/Node.js) on the PC to receive and store data.
- Assign static IPs to ESP32s for stable connections.
Benefits:
- Scales easily to 36+ readers.
- Reduces PC load by offloading RFID management to microcontrollers.
- No USB hub bottlenecks or cabling clutter.
Use ESP32 modules for their low cost, WiFi reliability, and UART/SPI compatibility with RFID readers.
Thanks John. Yeah that’s pretty much the idea.
Not sure if I can get away with wifi yet. Will find out soon.
Most info online suggests using lan over wifi for more stable, safer, and faster connection, but I do like the freedom of wifi option.
