CheckEmoji Community · the emoji forum
🏠 Home 🆕 What's new ❓ Unanswered 🔥 Popular 📡 RSS Members 👥 0 online log in · register
Home › IT › Hardware › RFID Card Reader DIY Project

RFID Card Reader DIY Project

Started by David Gomez6 · · 👁 4 views · 13 replies

📡 Subscribe to replies

Participants David Gomez6Alexander Diaz4Jack Cook7
David Gomez6 David Gomez6 MemberOP
10 messages
joined Jan 2016
#1 ·
Hello,

I realize this might not be the most appropriate sub-forum for this inquiry, but I thought I would give it a try...

I am looking for some hardware recommendations for a device designed to read an RFID card and then trigger a small servo motor based on that reading. Additionally, every scan needs to be logged onto a memory card.

The system will be battery-powered, so to maximize energy efficiency, I don't expect the device to be constantly active for scanning. Instead, I am planning to include a push-button so that the system only wakes up once the button is pressed, performs the card read, executes its task, and then returns to sleep mode.

As an optional feature, it would be wonderful if I could integrate a component capable of transmitting the stored data to a mobile device via a wireless or RF signal, such as Bluetooth.

I am aware of Arduino, but it feels a bit over-engineered for this specific application, both in terms of capabilities and cost.
Since I plan on producing multiple units, I am searching for components that are more optimized for such a lightweight workload.

Thank you for any suggestions you might have...
Alexander Diaz4 Alexander Diaz4 Member
39 messages
joined Sep 2021
#2 ·
Raspberry Pi
David Gomez6 David Gomez6 MemberOP
10 messages
joined Jan 2016
#3 ·
Alexander Diaz4 said:Raspberry Pi

Well, isn't that thing even more overdimensioned than an Arduino... unless I am mistaken and there are some "shrunken" versions available?
Jack Cook7 Jack Cook7 Regular
376 messages
joined Aug 2017
#4 ·
What you actually need is basically a smartphone equipped with an RFID reader.
https://www.rfidjournal.com/question...read-rfid-tags
https://www.rfid-wiot-search.com/pro...erminal-reader
https://www.aliexpress.com/w/wholesa...id-reader.html

Oh, and don't forget to toss in a micro SD card so you can actually store all that data.

There’s a massive variety of RFID tags and readers out there. You've got the standard LF stuff, like 128kHz, which gets you about 4 inches of range. Then there's HF/NFC at 13.56MHz that can reach out to maybe 3 feet. If you want to go big, you've got UHF around 900MHz reaching up to 40 feet. You even have passive and active readers—those active ones send out their own signal to wake up the tag—which can hit distances up to 330 feet!

Besides just using a phone, you can grab some "out-of-the-box" solutions that are about the size of a pack of cigarettes if you want to install them. Most of them come with Ethernet, RS232, RS485, or USB ports, so you can power them directly if they're being mounted in a fixed spot. They can work totally online or stay offline—meaning they aren't tethered to a constant connection because they can just save everything locally onto a SmartDisc.
David Gomez6 David Gomez6 MemberOP
10 messages
joined Jan 2016
#5 ·
Jack Cook7 said:What you essentially need is a smartphone equipped with an RFID reader...
I am looking for some guidance regarding the process of reading various types of RFID tags. If anyone has experience with different tag frequencies or specific reader modules, I would greatly appreciate your insights...
I will show you How Easy IT is to connect DS1307 I2C RTC to an ESP32 system while integrating an RFID module for enhanced security and data logging. This project focuses on building a reliable terminal reader that functions seamlessly within a smart home environment. The setup involves interfacing an RFID sensor with an ESP32 to capture entry data, which is then timestamped using the DS1307 I2C RTC module. By utilizing the precise timing capabilities of the RTC, we ensure that every scan is recorded with accurate temporal data, making it ideal for access control logs. To begin, you will need to wire the RFID reader to the designated pins on your ESP32. Once the connection is established, the DS1307 can be added to the I2C bus. It is quite straightforward to configure the code to recognize the unique IDs from the RFID tags and sync them with the real-time clock... For those looking to expand this further, adding an Arduino could provide additional processing power or extra GPIO pins if your current setup feels a bit limited...
I found this interesting RFID reader on AliExpress that might be worth looking into for our upcoming projects...

What kind of phone are we even talking about... if the ultimate goal is to optimize the design and minimize production costs...

Jack Cook7 said:Essentially, what you really need is a smartphone equipped with an RFID reader...

You can find quite a diverse range of RFID tags and readers available today. For instance, you might work with standard Low Frequency options at around 128kHz, which typically offer a reading distance of about 4 inches. Then there are the High Frequency or NFC setups at 13.56MHz, which can reach out up to 3 feet. If you need more range, you can move into the UHF spectrum at approximately 900MHz, providing a read distance of nearly 40 feet. Furthermore, you have both passive and active RFID readers—the latter actually emitting their own signal to energize the tags—which can extend your reach up to 330 feet...

I am looking for something budget-friendly; a reading range of about 4 inches should be more than enough. Ideally, the tag or card would be a passive element, meaning it doesn't require any kind of battery...

Actually, I wasn't aware that the Arduino Nano was available for only $2... at this stage of my project, that level of optimization is exactly what I need. I had previously assumed they were priced closer to $10... 😵

Things are finally starting to simplify... I have practically everything ready to go, except for one thing. I am still a bit unclear on which wireless module I should use to ensure the device can connect to a smartphone and transmit data successfully... 🤔

And one more thing... just as I mentioned previously...

The device is designed with an integrated keypad, ensuring the system remains inactive until a button is pressed. Once triggered, the unit activates to read the RFID card, completes its programmed tasks, and then returns to sleep mode...

Ideally, the device should remain powered down most of the time to conserve battery life. However, there is a slight catch... upon every activation, the system needs to know exactly what time it is...

A few questions have been coming to mind...
Can an Arduino actually keep track of the time if it's physically powered down? In other words, is there a way to provide a small amount of auxiliary power just to keep the clock running...
If the Arduino is physically disconnected from its power supply, would it be able to react fast enough to a button press to boot up and read an RFID card? It really needs to stay responsive within at least a two-second window...
I am asking this under the assumption that an Arduino might significantly drain a battery while sitting in standby mode... however, if it can remain in a standby state while acting as a negligible consumer of power, that would solve all our problems. By a negligible consumer, I mean something akin to a standard wristwatch... since its only responsibility during standby would be keeping track of the time. After all, the device doesn't actually need to independently detect when a card is near the reader; it just needs to be woken up to perform the scan...
Jack Cook7 Jack Cook7 Regular
376 messages
joined Aug 2017
#6 ·
David Gomez6 said:Man, forget about a phone... if the whole point is to optimize this thing and keep production costs super low.

I just need something cheap where a 4-inch range is plenty. The tag or card needs to be a passive element—meaning zero batteries involved.

An RFID card or tag is almost always passive. Now, RFID readers can be either passive or active. An active one blasts out a signal to find the tag, while a passive one just sits there waiting for a tag to wander into its EM field.

A passive 125/128KHz RFID reader should do the trick for you.

By the way, I had no clue an Arduino Nano even existed for $2... honestly, that’s the kind of optimization I need right now. I was totally assuming they were like $10 each.😵

Things are getting way simpler now... I basically have everything I need, except I'm still scratching my head over which wireless module I'll need to link the device to a phone and send data. 🤔

You can grab ready-made WiFi or Bluetooth modules with standard interfaces like USB-C for a PC, plus RFID readers; the real headache is the smartphone authentication part. Bluetooth is definitely the easier route there.

One more thing... like I mentioned earlier:

The device should stay powered off most of the time to save battery. But here's the catch... every time it wakes up, it needs to know exactly what time it is...

So, a few questions popped into my head:
- If the Arduino is physically turned off, can it still know the time? Like, could it have some secondary power source just to keep the clock ticking?
- If the Arduino is completely disconnected from power, can it react fast enough to a button press to boot up and read a card? It needs to be responsive within at least 2 seconds.
- I'm asking all this assuming the Arduino would drain the battery significantly in a standby mode... but what if it can sit in standby with negligible power draw? That would solve everything. (By negligible, I mean something like a wristwatch... since its only job in standby would be counting time. It doesn't even need to detect the card itself—the button press would wake it up to read the card.)

Most PCs have a real-time clock and a CMOS battery inside, which is usually independent of the main power supply (it has its own little coin cell or built-in battery). You can actually get ready-made chips with a built-in battery, like those from Dallas. (And no, you can't swap the battery out.)
https://www.maximintegrated.com/en/d...otes/5/52.html

Does Arduino Nano have a real-time clock?
These little things come with their own clock and a tiny battery, so even if you unplug your Arduino, they won't lose track of the real time. In this Instructable, i will show you How Easy IT is to connect DS1307 I2C RTC to Arduino, and then we'll grab that time data using Visuino.

Basically, most of your gear can be totally powered down (S5), or just chilling in standby or sleep mode (S1-3). Even in S4 (hibernate), that RTC is still hanging in there keeping time and counting down. Just a heads up—jumping from an S1 standby mode back up to S0 active mode takes about 2 seconds max.

https://learn.microsoft.com/en-us/wi...leeping-states

The whole "waking up" thing—like going from S1 to S0—really comes down to how you trigger the event. Since you're working with a passive RFID reader, the voltage or current spike on the reader's interface after someone waves a card has to be set up so that
a) the RFID reader stays powered up the whole time
b) the RFID reader buffers the data once the card hits it
c) the RFID reader triggers a wake-up sensor on the other side of the interface

Bottom line? That RFID needs to stay powered up constantly.
To make option (c) work, you've gotta keep that sensor at a minimum voltage level.

If you can't hit those three requirements, or if the power draw is just too much for your setup, you might have to settle for a physical button to wake everything up.

Bluetooth SoC
https://www.st.com/content/st_com/en...SAAEgJSA_D_BwE

RFID for Arduino with 1KB RAM:
https://www.aliexpress.com/premium/b...c30517b3afc35c
Using the RFID Card Memory
Like I was saying earlier, the RFID card that comes with this has 1 KB of memory. You can actually use that extra space to write your own data directly onto the card!

Bluetooth with an I2C interface:
https://www.i2cchip.com/pdfs/I2C2PC_Bluetooth.pdf

I2C RFID reader:
https://www.teachmemicro.com/arduino...c522-tutorial/
Jack Cook7 Jack Cook7 Regular
376 messages
joined Aug 2017
#7 ·
Check out these ready-to-go setups with RFID readers paired with Bluetooth transmitters:
https://gaorfid.com/devices/readers-...-rfid-readers/
https://gaorfid.com/product/reader-t...-125-khz-rfid/
David Gomez6 David Gomez6 MemberOP
10 messages
joined Jan 2016
#8 ·
Jack Cook7 said:...

Thank you so much for everything...👍👍👍
I cannot say that I have fully grasped everything just yet, but I intend to revisit the material and read through it all once more... 🙂

Regarding what you mentioned about RFID readers being able to be passive... from what I can see, the market doesn't really offer many options, and... This... The reader tends to be quite modest most of the time...

Should that be the passive one...?
So, based on that, would it mean that even in its passive state, it's still operating at some minimal voltage while drawing that declared "sleep current" of less than 80uA...

It is located right below the item description:...

Technical specifications regarding electrical parameters...
The operating current ranges from 13 to 26mA at a DC 3.3V...
Regarding the idle current consumption, it sits right around 10-13mA when running on a 3.3V DC supply...
3. Sleep current: 4. Peak current stays under 30mA...
5. Operating Frequency: 13.56MHz
7. Physical dimensions: the unit measures 40mm x 60mm...
The environmental operating temperature range is rated from -4°F to 176°F...
9. Operating Environment: This unit is rated to handle storage temperatures ranging from -40 to 85 degrees Celsius...
10. Relative humidity levels: ranging from 5% to 95%...
11. Module interfaces SPI Parameter 12.
12. Data transfer speed: hits a maximum of 10 Mbit/s...


You can easily find pre-made Wi-Fi and/or Bluetooth modules that come with standard PC interfaces, like USB-C, along with various RFID readers. The real question lies in how we handle authentication on a smartphone. Bluetooth seems to be a much more straightforward path for that...

If my understanding is correct, it should be possible to establish communication even with a module that only features Wi-Fi. I'll have to look into just how much more complicated that process is compared to using Bluetooth...

I'm afraid I didn't quite grasp this particular section...
The question regarding waking from, say, S1 to S0 is essentially an issue of the event trigger. Since you are using a passive RFID reader, the voltage or current generated at the interface after waving a card must be sufficient to...
The RFID reader needs to remain powered on at all times...
b) The RFID reader buffers the scanned data whenever a tag is swiped...
c) An RFID reader triggers the wake-up sensor on the other side of the interface...

The RFID reader needs to stay powered up at all times.
As for the (c) sensor, it requires a certain minimum voltage level to function correctly.


- I understand that an Arduino can be kept in sleep mode where it draws almost nothing (roughly 10uA)... I plan to go that route, though I haven't quite grasped the situation regarding the RFID reader yet.
I did realize that waving a card could wake it up and allow it to trigger the Arduino, but I am still struggling to understand the specific prerequisites you mentioned to make that happen...
Jack Cook7 Jack Cook7 Regular
376 messages
joined Aug 2017
#9 ·
David Gomez6 said:Thanks for all of this!👍👍👍
I can't say I wrapped my head around everything all at once, but I'll be coming back to reread this stuff. 🙂

Regarding that thing you mentioned about RFID readers being passive... from what I can see, the market doesn't really offer many options, and this reader seems to be the one everyone uses.

Is that supposed to be the passive one?
...and would that mean that even as a passive device, it still runs on some tiny voltage where it pulls that declared "sleep current" of "<80uA"?

It says right there in the product description:

Quote:
Electrical parameters:
1. Operating current :13-26mA/DC 3.3V
2. Idle current :10-13mA/DC 3.3V
3. Sleep current: <80uA
4. Peak current: <30mA
5. Operating Frequency: 13.56MHz
7. Product physical characteristics: size: 40mm×60mm
8. Environmental Operating temperature: -20-80 degrees Celsius
9. Environmental Storage Temperature: -40-85 degrees Celsius
10.Relative humidity: relative humidity 5% -95%
11.Module interfaces SPI Parameter
12.Data transfer rate: maximum 10Mbit/s

Oops, I went off on a bit of a tangent there... typing too fast, I guess.

So, with RFID we’ve got two parts: the RFID reader and the RFID tag. Both can be active (powered up) or passive, but at least one has to be active so it can blast out a signal—basically an EM field that the tag needs to sit in. Usually, the reader is the active part and the tag is passive—meaning no battery. The antenna inside the tag catches that EM field, which induces a little voltage/current to power the chip, and then that chip sends a signal back to the reader to identify itself.

An active RFID tag actually has its own battery and broadcasts its own signal via its antenna, which boosts the range and adds more features (like for secure authentication and stuff).

The example you gave was a 13.56MHz RFID reader for Arduino. (That's an active one, obviously.) It draws power from the Arduino and needs to stay powered up so it can keep emitting that EM field for the tags to move through.

In the scenarios I was talking about, the RFID reader is always active, while the tag can be either passive or active.

In rare cases, you could make an RFID reader passive (no power supply), if, say, you don't want it broadcasting an EM field everywhere. In that case, the tag would have to be active.

Jack Cook7
You've got ready-to-go WiFi and/or Bluetooth modules with interfaces for a PC like USB-C, etc., just like those RFID readers; the real question is how they handle authentication on a phone. Bluetooth is definitely the easier way to go here.

David Gomez6
If I'm following you right, we could actually set up communication using a module that just has Wi-Fi. I'm gonna look into how much more of a headache that is compared to Bluetooth. lol

Yeah, the concept is pretty much the same, it’s just that Wi-Fi reaches way further (which means it eats up more juice) and there are way more options to play with. Basically, you've got the chip and/or an Arduino module for the Wi-Fi part. Like 802.11g—it's a bit old school, but totally plenty for what we need.
https://www.alibaba.com/premium/wifi...yAAEgJW4vD_BwE

David Gomez6
But wait, I didn't quite catch this specific part:
Quote:
Jack Cook7
The whole thing about waking up from, say, S1 to S0 is all about the event trigger. Since you're using a passive RFID reader, the voltage/current spike on the reader's interface after you wave a card has to be enough so that
a) the RFID reader stays powered up the whole time
b) the RFID reader buffers the data once the tag is scanned
c) the RFID reader triggers a wake-up sensor on the other side of the interface

The RFID setup needs to stay powered up constantly.
For (c) to work, the sensor needs at least a tiny bit of power.
- So I get that an Arduino can sit in sleep mode where it barely pulls any power (like 10uA)... I'll go with that, but I'm still a little lost on this RFID reader business.
I figured the card swipe would wake it up and then it could wake the Arduino, but I don't really get the requirements you laid out to make that actually happen.
Think of S0 (fully on) through S5 (completely shut down) as the different sleep levels for a PC. An Arduino and a Bluetooth or Wi-Fi client can hang out in sleep mode S1 or even S2 or S3, so they're sipping power instead of gulping it.

BUT, that RFID reader has to have power regardless of what the Arduino is doing. It's gotta be running full tilt all the time, unless you're going the route of using a physical button to wake the Arduino. A reader like that usually has a built-in buffer (usually about 1kB of RAM) that temporarily holds the data from the scanned tag, and at the same time, it sends a pulse over the bus (usually via serial I2C) to "wake up" the Arduino, which can take a second. Once the Arduino wakes up, it sends a signal to read that buffer (via serial) and clear it out. Could be RAM, could be Flash.

Of course, the Arduino needs to have a "sensor" on the bus where the RFID reader is attached so it can "listen" for that wake-up call. That's basically how all peripherals work on PCs—like when you touch a keyboard or mouse and it "wakes" the PC via the USB interface. That "sensor" needs some minimum power, or it can grab it from the RFID reader once the tag is read.

Generally speaking, the standard for sleep modes S0-S5, wake-up methods, and all that is ACPI.
These are the sleep modes for the Arduino.

Once the Arduino grabs the data from the RFID reader's buffer, it dumps everything onto a local micro SD card, kicks off a Bluetooth session to blast those details over, and then heads right back into sleep mode.

So, look—unless you’re going the route of using a physical button, that RFID reader absolutely needs its own buffer. It’s gotta be able to hold onto the tag info while the Arduino is snoozing.

You also mentioned the Arduino might need some kind of control or a relay for a stepper motor (?), which would probably kick in once a tag is successfully identified. That’s standard stuff for access control systems—I’ve seen plenty of off-the-shelf units used for things like office doors that have dedicated connectors for doorbells, relays, and all that. Basically, once the tag is cleared, they just send a pulse to the relay output or whatever trigger you've set up.

Just a heads-up though: reading a tag is one thing—that’s the easy part—but actually authenticating and authorizing it—basically checking if that specific tag is actually allowed through the door—is a whole different ballgame.
David Gomez6 David Gomez6 MemberOP
10 messages
joined Jan 2016
#10 ·
Jack Cook7 said:...

👍

I am making some slight progress https://photos.app.goo.gl/edaTAzoorLU1weqdA 🙂...

So far, I have been using this second RFID reader, simply because I was able to track one down in Washington, D.C. to run some tests. I haven't fully investigated the specific differences yet, but it seems like the "basic" model mentioned earlier in the thread should be sufficient for my needs.

Regarding the PC setup, I am currently using an Arduino UNO for testing purposes, though I plan to switch over to an ESP32 later on. That board includes built-in Wi-Fi and Bluetooth, plus enough flash memory so that I won't have to deal with the hassle of an SD card module.

As for sleep mode, it looks like the wake-up trigger will be a button press. This little gadget will be battery-powered, so energy efficiency is a major priority for me. I found that the ESP32 draws about 10uA in deep-sleep mode, which is perfectly acceptable. For the RFID reader, I would ideally want it to sit around 10uA as well... the declared 80uA in IDLE mode is just a bit too high for my liking.

Regarding the buttons, I still need to figure out a few things:
1. how to put the Arduino into sleep mode
2. how to wake it up using a button
3. how to use the Arduino's digital outputs to control the ON/OFF state of a component, such as the RFID reader. For instance, if I want to programmatically cut power to the RFID reader, I could do it crudely with a switch controlled by a servo motor. (That is just a figure of speech; I assume that isn't the standard way to go about it, haha) ... what are my actual options?
It occurs to me that I might need a transistor for this purpose, where applying a small voltage to the third pin determines whether it conducts or not. Does that make sense... or is there a different way to handle this? Perhaps there are ready-made relays designed for Arduino for this exact use case?

(P.S. I can easily Google points 1 and 2, but I would truly appreciate any advice regarding point 3)

I am also considering adding a small solar panel to supplement the battery and offset this minor power draw. How much complexity does that add?
Will I need to worry about overcharging the battery with a small solar setup? Or can I simply connect it to the battery and let it contribute whatever it can...
Jack Cook7 Jack Cook7 Regular
376 messages
joined Aug 2017
#11 ·
David Gomez6 said:👍

Just easing my way along. I can't actually open external links like that! My eyes aren't working on Google Photos links today, haha. Drop the details or just tell me what's going on in the pics—I'm all ears! What are we looking at? A crazy new build? Some fried components? Lay it on me! 🙂

I’ve just been messing around with this other RFID reader for now, mostly because I could actually track one down here in Washington, D.C. to run some tests. I haven't really dug deep enough to see what the actual differences are yet, but honestly? It looks like that "basic" one mentioned earlier is gonna be more than enough for what I'm doing.

Way to go! Nice work! 👍

Look, picking your reader—whether you're going with 128KHz, 10.56MHz, or whatever else is out there—isn't just about the hardware. You're basically deciding on the whole tech stack, the read range, how much battery juice you're gonna burn through, and even the price per tag. It’s definitely not some trivial "pick one and forget it" kind of thing!

Right now, I'm just using an Arduino Uno to test things out from my PC, but that's only temporary. Pretty soon, I'll be switching over to an ESP32. It’s got built-in Wi-Fi and Bluetooth, plus enough flash memory that I won't have to deal with the headache of messing around with an SD card module.

So, about that sleep mode stuff—it looks like I’m gonna be using a button to wake the whole thing up. Since this little gadget is running on a battery, saving power is basically my top priority right now. I did some digging and found that the ESP32 only pulls about 10uA in deep-sleep mode, which is totally fine by me. But man, the RFID reader? That's the headache. It says it draws 80uA just sitting there in idle mode, and honestly, that's way too much juice for what I need. I really need to get that down to somewhere around 10uA if this is actually gonna work!

Look, that fix definitely solves the power issues with the RFID reader, but it kind of kills how useful the whole setup actually is. Honestly? Having an RFID reader that "wakes up" the Arduino is way more elegant and practical—it’s just a total trade-off because the reader has to stay powered on constantly... unless, of course, you're planning on using active RFID tags.

As for the keyboard, I've still got that one thing left to tackle:
So, how do you actually get an Arduino to go into sleep mode?
2. So, how do you actually wake that thing up using a keyboard?
So, how do we actually use an Arduino's digital outputs to flip an ON/OFF switch for something like an RFID reader? Like, if I want to kill the power to the reader through my code, I could always go the "primitive" route and just have a servo motor physically slam a switch. (I’m being hyperbolic here, obviously—I don't think that's exactly the pro way to do it, haha!) ... so, what are my actual options?
I've got a hunch that maybe I should be using a transistor here? Like, if I hit that third pin with a little bit of voltage, does that decide whether it conducts or stays shut? Does that even make sense... or am I totally off base? Is there a better way to handle this? Also, I bet there are already those ready-to-go relay modules made specifically for Arduino for stuff like this, right?

(P.S. I'll just Google points 1 and 2 myself, but for point 3, I'm totally open to any advice!)

I sent you that link because, honestly, saying an Arduino "goes to sleep" isn't exactly accurate. Calling it sleep mode is a bit of a stretch—it’s way more primitive than that. It basically just hits an 8-second snooze, wakes up via software to check its registers, and then immediately crashes back into "sleep" again. It's got a few different operating modes, sure. They aren't technically part of the ACPI standards, but the logic is pretty much the same concept!

So, we were just geeking out over real-time clocks. The cool thing about them is that they’re totally independent if you set them up with their own power source. One of the best features is that you can program them to kick the voltage up on a specific pin every X seconds—which is perfect for triggering relays or whatever else you've got running. It's actually pretty similar to how you'd handle things with an Arduino.

I was thinking about adding a tiny little solar panel to top off the battery and basically cancel out that tiny power draw. How much of a headache is that going to be?
Do I need to worry about overcharging the battery with a small solar setup? Or can I just hook it up to the battery and let it trickle charge as much as it wants?

Whoa, hold up! You’re getting a little ahead of yourself there. There are plenty of pre-made modules that handle battery charging and discharging, but man, you gotta nail the basics first.

Look, you seriously need a game plan. Something like this:

1. The core build—Arduino, batteries, RFID reader, tag scan triggers the servo motor (you’ve already got this part down)
2. Logging the access data to an SD card.
3. Getting that data sent over Bluetooth/Wi-Fi to something else.
4. Setting up authentication for the Bluetooth/Wi-Fi connection.
5. Authenticating the RFID tag against the RFID reader.
6. A Real Time Clock that keeps ticking even after you kill the power.
7. Authorizing the RFID tag itself.
8. Logging all those successful and failed RFID auth attempts.
9. Remote access to the Arduino for firmware updates and reconfiguration.
10. Managing Arduino sleep/wake modes and controlling peripherals.
11. Using a button and/or the RFID reader as a wake-up trigger.
12. Solar battery charging.

Feel free to tweak the steps, but you gotta have a roadmap. Otherwise, you're just gonna wander around aimlessly and never actually finish anything.
David Gomez6 David Gomez6 MemberOP
10 messages
joined Jan 2016
#12 ·
Jack Cook7 said:Using a dedicated power supply definitely solves the issues with powering the RFID reader, though it does make the overall solution a bit less practical. An RFID reader that can "wake up" the Arduino is certainly a much more elegant and versatile approach, but there is a trade-off: it needs to stay powered on—unless, of course, you decide to go the route of using active RFID tags...

I am fully aware of the compromises involved... It seems to me that I should probably develop both versions, allowing the user to choose whichever system best suits their needs. Besides, I would need to build both options anyway just to get a realistic sense of the power consumption, especially since I've realized that an 80uA draw is actually quite manageable...

I believe you have strayed a bit too far from the mark. There are several established circuits designed specifically to manage battery charge and discharge levels, but I would suggest addressing those initial issues first...

I don't mean to jump straight into the deep end here... I am simply weighing my options at the moment, as my final direction depends heavily on what is available to me. I was merely curious to know if I can truly rely on this component, or if it would be more prudent to leave it out entirely...

First, you really need to establish a solid work plan. For instance...

The core setup involves an Arduino, some batteries, and an RFID reader. When a tag is scanned, it triggers the servo motor drive...
2. Saving the login data to the SD card...
3. Establishing a wireless connection via Bluetooth or Wi-Fi to an external device...
4. Authenticating the Bluetooth and Wi-Fi connections...
5. Authenticating an RFID tag using an RFID reader...
6. A real time clock that continues to function even after the device is physically powered down...
7. Authorizing the RFID tag...
8. Logging both successful and failed attempts for RFID authentication and authorization...
9. Enabling remote access to an Arduino for firmware updates and reconfiguration...
10. Managing sleep/wake cycles on an Arduino; controlling peripherals...
11. Using a keyboard and/or RFID reader as a wake-up signal...
12. Solar battery recharging...

Please feel free to refine the steps, but you really need to maintain a clear plan. Without one, you risk losing focus and drifting aimlessly without actually accomplishing anything...

Yes, exactly... that is how I approach all my projects. I start with a solid plan, break everything down into simple, manageable steps, and then tackle them one by one. It saves me from having to rely on memory... 🙂
When the actual thinking part of a project is done, most of the heavy lifting happens on paper... after that, it’s just a matter of executing the individual tasks without having to worry too much about the logic... 🙂

Regarding the list above, I believe I have already determined a viable solution or approach for many of those items...

I expect this to be quite trivial, especially since the ESP32 comes equipped with its own internal memory...
3./4. Once that's set, I'll have plenty of time to play around while I get the ESP32 up and running...
5. / 7.
Handling user authorization once I've read the tag ID shouldn't pose much of an issue... however, what I am still struggling to wrap my head around is the actual authentication of the RFID tag itself. I am trying to figure out how to prevent someone else from simply scanning the card, reading the data, and then just creating their own custom clone... Hmm...

I nearly overlooked a crucial detail here, assuming the ESP32 would continue tracking time while in sleep mode. I also neglected to account for what happens when the battery runs out... specifically ensuring the clock doesn't reset itself... 🙂 All right... I find myself needing one more component equipped with a clock battery.

8. This falls under category 2 when accessing memory... this part is simply inserting a record.
9. I hadn't actually considered this yet... but once I establish Bluetooth communication, I shouldn't have any trouble developing a mobile app capable of reconfiguring application parameters. Regarding updating the entire code via a wireless connection, I don't think I truly need that. Unless it turns out to be quite simple, why not include it...🙂

10./ 11. I'll have to do some Googling regarding sleep/wake functions.
12. Is there any reason not to include that in the plan? I would simply love to get a rough estimate of how much it might assist with battery life (or perhaps cause issues with other potential complications)...

On another note, if anyone could please provide a hint on which direction I should be thinking in:
3. how to use Arduino digital outputs to control the ON/OFF state of an element, such as an RFID reader. For instance, if I want to programmatically cut power to the RFID reader, I could do it crudely using a switch controlled by a servo motor. (That's just a figure of speech, I assume that isn't how it's done, haha) ... what are my actual options?
It occurs to me that I might use a transistor for this purpose, where applying a small voltage to the third "pin" determines whether it conducts or not? Does that make sense... or is there a different way to handle this? There are probably ready-made relays for Arduino designed specifically for this task?
Jack Cook7 Jack Cook7 Regular
376 messages
joined Aug 2017
#13 ·
David Gomez6 said:Look, I’m totally aware of the trade-offs here... honestly, it feels like I should just build both versions and let the user decide which system they actually want. Besides, I’d probably have to prototype both anyway just to see how much juice they're actually pulling. Now that I've crunched the numbers, I realized an 80uA draw isn't even that big of a deal—I can definitely live with that!

Look, I'm not saying I'm gonna dive headfirst into this right this second... I'm just weighing my options, you know? Everything hinges on this because it dictates which direction I actually take with the whole project. I was just curious if I can actually bank on this being a solid choice, or if it’s one of those things that’s better off just scrapped entirely.

Yeah, exactly... that's how I tackle every single project. First, I map out the whole plan, break everything down into simple little steps, and then just knock them out one by one. No point trying to cram everything into my brain at once! 🙂
The heavy lifting—the actual thinking part—is mostly just staring at a blank sheet of paper. Once that’s done? It's all downhill from there. You just knock out the tasks one by one without having to stress your brain too much. 🙂

Looking at that list above, honestly? I feel like I’ve already cracked the code on a good chunk of it. I've pretty much got a solid plan for most of those.

I mean, honestly? I’m expecting this to be a total breeze since we're working with an ESP32 that's already got built-in memory. It should be a walk in the park!
3./4. Honestly, once I get this ESP32 fired up, I’m gonna have a blast messing around with the timing settings!
5. / 7.
Handling user authorization once I’ve grabbed that tag ID should be a breeze... honestly, not a huge deal. But what's actually tripping me up is the whole RFID authentication side of things. Like, how do I stop some random person from just scanning the card, ripping the data, and then making their own fake clone? Ugh, man... 🤔

Man, I almost totally blew this one! I was sitting here thinking the ESP32 would just keep track of the time while it’s in sleep mode, like, "no problem, right?" But then it hit me—I completely forgot to account for what happens when the battery dies. If that power drops out, the whole clock just resets itself. Total rookie mistake! 🙂 Alright... looks like I need to hunt down another component that comes with its own clock battery.

It falls under section 2... when I actually try to access the memory... honestly, it’s just an entry insertion.
I haven't really sat down to think about this one... but hey, once I get the Bluetooth communication up and running, it shouldn't be a huge headache to whip up a mobile app that lets me reconfigure all the settings on the fly. And honestly? As much as I'd love to say I could push full code updates over a wireless connection, I don't think I actually need to go there. Unless it turns out to be super easy—because man, if it's not too complex, why not just go for it? Why not have that power? 🙂

I'll probably just Google how that sleep/wake stuff works on the 10th or 11th.
Is there any actual reason not to bake this into the plan? Honestly, I’m just trying to get a ballpark idea of how much of a difference it'll make for the battery life—or if it’s gonna backfire and cause some other headache for us.

So, hey, if you could please give me a little hint on which direction I should be heading with this one:

Just keeping it brief.

Look, let me clear something up right now because people mix this up all the time: authentication is NOT the same thing as authorization. Seriously.

Authentication is basically just identifying who someone is, and honestly, it needs to be done securely if you actually care about your setup. Take RFID, for example. If you're just running a basic reader, anyone could walk up and wave some random compatible tag—say, a standard 125kHz one—right in front of it. Your reader would just go, "Yep, that's a tag!" and instantly save that ID to the disk. And let me tell you, that is a terrible way to do things. You can't just leave the door open like that! There has to be some kind of restriction on which specific RFID tag gets through and how it proves its identity. In other words, you need a protocol.

Once that ID is properly authenticated, someone’s gotta step up and decide if that person actually has the green light to, say, walk through the door. That whole part of the process? That’s what we call authorization.

It works just the same for your Wi-Fi or Bluetooth, logging into your Windows setup, or even just hitting up the forum login.

b) "sleep mode"

It’s basically like putting parts of your computer into deep sleep. You take all that data or current state from different components and stash it away in permanent storage—think CMOS battery, flash memory, or even a hard drive—so when everything wakes back up, it can just reload everything exactly where it left off. Otherwise, everything is just gone. Poof. When we're talking processors, we're looking at register contents; for memory, it's the stuff sitting in RAM. Then you’ve got a whole mountain of other components like UART, PIC, DMA, and MMU, which on an Arduino are usually just baked right into the same chip anyway. Peripherals are where things get a little tricky, though. It really comes down to how they actually talk to the processor—whether they're using I/O or memory mapping—and how they flag the CPU to say, "Hey, I've got data for you!" That's where the PIC (interrupt controller) comes in, letting the processor jump straight over to the specific routine needed to handle that peripheral's data.

c) solar battery charging
That can happen, but we gotta nail everything else first—especially sleep mode. That’s basically its own separate beast entirely.

d)
David Gomez6
how do I use the Arduino digital outputs to switch an element ON or OFF, like an RFID reader? Like, if I want to programmatically cut power to the RFID reader, I could do it the primitive way with a switch controlled by a servo motor. (Just being descriptive here, I'm guessing that's not how people actually do it, haha) ... what are my actual options?

I have a feeling I should be using a transistor for that, where a little voltage on the third "pin" decides if it conducts or not? Does that make sense... or is there a better way to handle this? There probably are ready-made relays for Arduino meant for this kind of thing, right?

I don't know all the gritty details, but it boils down to this: "someone" (the processor, aka the code) tracks time (ticks) for so-called "idle time" (when nothing is happening), and then at a specific predefined moment, it sends a command (a bit or a byte) to a specific IO port or memory location. That's tied to a relay or a transistor that controls the power for a device—which could even include the board itself.

d1) First off, how does the processor even know nothing is happening if it's running constantly? I mean, it has to stay active to monitor things, right? So you basically need a sub-routine that "does nothing" except check if something else *is* happening.

d2) Second issue: where and how do you stash all the necessary data when the processor goes to sleep, especially since it's spread across different parts of the computer?

d3) Third question is how to actually shut down a specific device. I don't know the specifics, but I think something was mentioned in that link I sent you about Arduino sleep modes, so let me go dig that up.

d4) Fourth question: how does an external event trigger the Arduino to "wake up."

d5) Fifth question: how do you pull that saved data from step (d2) back so the computer can pick up right where it left off? And honestly, do you even *need* to resume, or can it just reboot from scratch? For the kind of device we're talking about, starting fresh might be enough. Since this device is essentially "memoryless," it makes things way easier.

It's pretty obvious that "sleeping" isn't exactly trivial.
David Gomez6 David Gomez6 MemberOP
10 messages
joined Jan 2016
#14 ·
Jack Cook7 said:It is important to clarify that authentication and authorization are two distinct concepts...

I believe I have grasped the situation... 😉 I don't see authorization being an issue at all. It really just comes down to the underlying code logic—defining exactly which tag ID interacts with which specific function. That way, I can program various cards for different purposes, such as ones that trigger Bluetooth data transfers or master cards that unlock every door on the premises... it’s all about how you decide to engineer it at that level of sophistication...

I am somewhat perplexed by the lack of authentication protocols to verify that the user actually possesses the specific card details I provided, rather than some fraudulent data... it leaves quite a few unanswered questions for me. However, I shall attempt to outline a few possibilities that come to mind...

In principle, I would need to possess some sort of secret key to verify that the card was actually programmed by me—essentially a way to validate my own recorded data. However, I see a significant security flaw here: anyone could potentially scan the card, intercept that secret key, and then the entire system becomes completely compromised...
It seems my only viable path forward is to implement a unique secret key that is tied directly to the specific Tag ID. This means every single card will possess its own distinct secret key, while my software remains the sole entity capable of calculating the relationship between the two... Consequently, once a card is scanned, I will capture both pieces of data and perform a logical validation to ensure the decrypted secret key matches the Tag ID based on our predefined parameters...
If the information matches, the card should be perfectly valid... 🙂
Would that be possible...? 🤔

The only minor oversight remaining is that a user could potentially duplicate or copy cards that successfully pass authentication... however, I do not view this as a significant issue. Since a user cannot use this method to hijack the authority level of someone else's card—they can only replicate their own and perhaps gift it to another—it doesn't pose much of a concern in my estimation...

Furthermore, one could theoretically dismantle the device to inspect the underlying code—assuming that is even feasible—to determine the specific relationship between the secret key and the tag ID. Once that logic is uncovered, it would be possible to manufacture any card one desires. However, I am certainly not designing an ATM security system, so I have no intention of wasting my time on such matters... 😁

...
...
One thing I am still pondering is how much experience serves as our most powerful tool... I find myself wondering how I will truly gauge the long-term stability of these components when exposed to various weather conditions. I am not entirely certain that I will have an adequate testing window, which would be quite inconvenient if everything were to fail prematurely...

During the summer months, one can expect significant exposure to intense heat paired with a certain degree of humidity in the air...

Regarding the current heatwave... It won't be under direct sunlight, but they will still be outside where the summer heat is going to be absolutely brutal. I am not entirely convinced that adding any foam insulation would make much of a difference... If my experience with the local HVAC contractors serves me right, the temperature inside would reach the same level whether the insulation is there or not; the only real change would be a slight delay in how quickly the indoor climate shifts toward the outdoor temperature...

The issue of moisture is likely to be even more problematic...
I am optimistic that humidity levels will remain manageable, though I have noticed a small clip that seems to be "slipping" out from the electronics housing. This suggests that the enclosure cannot be completely airtight. While there will likely be some sort of protective system in place to manage the clip's position, I suspect it won't be perfect, which might allow for some moisture infiltration...

To ensure the design functions correctly, the servo motor must be housed within the casing with a mechanical output that interfaces directly with the clip. However, this specific requirement creates a challenge, as it prevents the servo itself from being hermetically sealed. Once you move past the servo, the ESP32 and the RFID reader can be completely sealed off for protection...

Aside from that, there will also be a collision sensor integrated into the setup—something similar to this: shorturl.at/jnpy0. It won't be possible to keep it completely isolated, as it needs to be positioned right next to the piston to verify its final position...

The sensor is my primary concern because it houses the electrical contacts, and I suspect those components will be particularly vulnerable to humidity.
If we opt for a version with a keypad, those buttons will also be subject to contact issues.
Furthermore, I have doubts regarding whether a standard servo can withstand high temperatures and moisture levels... especially since it relies on moving parts and plastic housing if we were to use this: shorturl.at/HLQW3

It is quite difficult to determine if utilizing a servo under these specific environmental conditions makes sense, especially when expecting a lifespan of at least three years.

I realize these questions might be better suited for a different discussion thread and may feel out of place here... nonetheless, these are the uncertainties weighing on my mind. It would be incredibly helpful if anyone could share insights from practical field projects regarding how these components actually performed in such settings.

You must log in or register to reply here.

Log in Register

🔗 Similar threads