Vehicle rfid door lock circuit

[greengearhead]

I am working on a circuit that uses an rfid fob to unlock and lock car doors. The rfid sensor is to be placed inside the lower windshield dash area, along with a 16x2 lcd that says locked or unlocked.
To test the circuit I am using a button in place of the off the shelf rfid sensor system and leds to take the place of the lock actuator. Upon installation the rfid sensor will interact with pin2 via digital write. The rfid sensor outputs a 3v pulse when the fob is authenticated. The leds will be replaced with a 2 channel relay module that will send 12v power to the lock motor for a short amount of time in either normal polarity or reverse polarity, like a solenoid.
The two problems I am having are:

• at boot it always locks (maybe ok but I would prefer if it did not lock or unlock at boot.)
• with repeated button presses it flips between lock and unlock without observing the delay. In operation this would make the lock mechanism jiggle between lock and unlock and stop somewhere in the middle.

Thank you for any advice

[gweimer]

1. If the two flip-flops are always going to be in the same state, there is no reason to have two of them.
2. Having two nodes control one device (your two nodes for one LCD) is almost always going to end up causing problems. In this case, you manage the ACT pin, so it might be OK, but it is probably better to only have one copy of the LCD node & change the value to display. In this case, there are only two values to display on the 2nd line, so it could come from an if-else node.

We can add extra code to prevent either relay from activating at startup, but then we are not going to know the state of the lock, and we will have to randomly choose which action we will take on 1st button press (which may or may not change the actual lock position since we don’t know where it is).

The right & lower part of this patch is very close to what you had except there is only one flip-flop & the LCD has an if-else feeding L2.

The two gate nodes & the boot/delay/not nodes in the upper left are to disable the delay nodes that activate the led/relay while the system is booting. On boot, this delay is started, which disables the two gate nodes, so the other relay delay nodes cannot be started. Once this delay expires, the gates are enabled and you can start pressing the button to change lock state.

Bah…I just realized, when you enable the gate, the current value will get passed through, so the doors will just wait to lock/unlock. Since we only want a pulse to the delay node, the easy fix is to change the boolean to a pulse before we feed it to the gate node using pulse-on-true. Since the pulse will be “done” before the timer expires, nothing gets passed to gate until you start pressing the button.

[greengearhead]

gweimer,
Thank you for the expert help, I enjoyed watching your recommended improvements flash onto the arduino board,
Once my relay board arrives I will install the lock system into a vehicle and post a short video of it in action.

[greengearhead]

I swapped my rfid reader with the button (and changed button to digital in) and found an unexpected issue.

The rfid reader is this item:

RFID Reader RFID Key Access Control with relay for sale online

I am running it without the relay. When powered with 12v the rfid reader outputs a 3v pulse when proper fob is presented.
The arduino lock/unlock lights flicker when the fob is presented, then stop on one state or the other.
I have the rfid poiwered from a 12v battery
Arduino powered from a 5v cell phone charger
12v ground and arduino ground connected.

This is my xod code

[gweimer]

Sounds like the RFID device is triggering multiple times. You could reduce this issue by doing digital-read at specific intervals instead of using loop. A better solution might be debounce to ignore the flicker. The debounce node would be inserted between digital-read and flip-flop.

[greengearhead]

I ended up fixing the bounce issue. The rfid module came with a small voltage regulator and capacitor on the output. I assumed this was only needed for use with the flip flop relay board that came with the rfid kit. Once reinstalled the arduino can read the signal from rfid module (with proper debounce setting) and react reliably and predictably.

My last step in this project is to add mobile phone control of lock /unlock
I am trying to use Blynk and an HM10 bluetooth module. I downloaded the gabba people blynk and gabba people uart led libraries, reviewed the cool model garage project. I see how to add the blynk code and can connect to the hm10 module with my phone but I am lost how to output a simple true false from these nodes. So far the below sketch does not seem to output anything. When using the model garage project as a template the virtual pins confuse me.

[gweimer]

This says it is an init node… That implies it only does the initialization. There is probably another node for reading data that will have output pin.

[greengearhead]

Making progress with my xod project (thanks to this forum)

I am currently a bit confused setting up relays that will operate door actuator motor. This vehicle does not have factory power locks so I will be setting up relays to operate an aftermarket door lock actuator.
The relay is a 5v 2 relay module sold as an accessory to arduino. It has diodes and opti couplers neatly installed on the small relay board.
The relay actuates with a low signal. The relay node in xod seems to do the opposite. I played with the various settings on the relay node to no avail.

Should I use a different node.
The led lights are behaving properly, the relay coils (low signal) should be activated in conjunction with the leds. One thing worth mentioning:
If both relays actuate simultaneously it will create a direct 12v short and blow a fuse. Once relays are acting like leds I hope to program some type of fail safe against both relays ever acting simultaneously. Alternatively I could install a self resetting circuit breaker in place of the fuse to reduce the amount of trouble this potential short would cause.

Thank you

[gweimer]

Both flip-flops always have the same state, so you only need one of them.

From the flip-flop output, pulse-on-true should set one delay and resets the other (so both cannot be on at the same time). Pulse-on-false will reset the one delay and set the other (reverse of how pulse-on-true is wired). Now only one delay can be active at a time. To make sure there isn’t even a brief overlap with both on, you can add a “defer” node before the delay-SET so you know reset will happen first.

If relay turns on when you want it off and off when you want it on, add a “not” node before the relay input to reverse the signal.

[greengearhead]

Everything seems to be working well
I will be installing on vehicle soon!
Just one last small thing to ask. Is there a way to inhibit multiple consecutive presses from flip flopping the state numerous times. State (lock and unlock ) change should be inhibited until the delay time is complete. This is because presenting the rfid fob can at times act like a few button presses. I am not refering to de bounce but it acts more like multiple presses spaced out by a half or whole second if the fog is jiggled just right. This causes a fast lock-unlock-back to locked scenario.

[gweimer]

If debounce doesn’t work for you, you can start a delay timer when the button is pressed. Negate the delay-ACT output (using “not” node). You can now use this signal to either activate a “gate” node, or just “and” it with the button press output. Either solution will cause button press to be ignored while the delay is active.

Usually “gate” would be used to disable a button like this:

But in this case, a simple “and” has the same affect:

In both cases, the “defer” node is used only because you are feeding output back up the program, creating a loop. XOD will not allow loops like this without the “defer” because it would create unstable output depending on order of execution.

You want the button to be active when the delay node is not active, hence the “not” node to invert the output that is fed back up to the “gate” or “and” node.

Note that the delay and flip-flop are triggered by a pulse. In this case, we are feeding boolean output to them. There will be an implicit “pulse-on-true” used to convert boolean to pulse. This means they are only triggered on change from false to true. If your FOB reader is glitchy, and tends to turn off and back on while the card is present (or if you remove the FOB and return it shortly after), that is when another pulse is sent to flip-flop & delay. If you want the delay to keep resetting as long as the FOB reader is pulsing, you can connect the delay-SET directly to the reader instead of feeding it from the “gate” or “and” node. As long as the reader glitches before the delay timer expires, it would reset the delay timer. You would have to remove the FOB for the timeout period, then place it in the reader again to change lock state a 2nd time with this modification. As written above, the 1st glitch after the delay timer expires would change lock state again (which will happen even with the modification if the glitch doesn’t happen within the timeout period to set the delay timer again).

FYI: You will have less risk and probably save memory if you only use one lcd node and change the input pins instead of having multiple lcd nodes.

Since there are only two choices, you can change the text using an if-else. The flip-flop output will be the if-else-COND

If you wanted more choices, you could use “switch-case”, but in this case, “select” would probably work better. The same input that you now tie to your lcd-ACT pins would instead link to the select-S# pins.

By having only one lcd node, you also make it easier to modify the program in the future since there is only one place to change lcd configuration and all possible lcd values feed to the same location. Your implementation is not “wrong”, but it probably uses more memory and is higher risk (bad things happen if both become active at the same time–a low risk in this case…).

If the 1st line of text also changes, you can change it using the same technique.

There are exceptions, but as a general rule, if you have a single piece of hardware like LCD, there should probably be one node controlling it. If the LCD ends up hidden inside a patch used multiple times, you will end up with multiple LCD nodes and controlling the ACT pin becomes crucial. With only one LCD node, you can just leave ACT True; the node doesn’t “fire” unless one of the pins changes and ACT is True.