At work, we’re upgrading our sixteen-year-old physical access control (keycard) system. We went with a newish Cisco solution in part because our reseller promised the whole works could run from Power over Ethernet (PoE), so we wouldn’t need separate power supplies.
It turns out the subcontracted hardware installer had never seen this done before, the Cisco documentation doesn’t even reference powering door strikes from the access gateways, the contractor and subcontractor couldn’t stop the gateways from locking up when the door strikes open and/or close, and migration to the new system didn’t happen last week while I was on vacation like it was scheduled to.
I came in yesterday afternoon to have some quiet time to apply a little rigor to the testing. In a couple of hours, I had a bench system broken in the same way as the installed systems, and then the bench system fixed.
Probably the most annoying part of the process is the 70 seconds it takes from powering up the gateway until the gateway powers up the card reader, and another 60 seconds until the gateway is ready for the reader to read. That’s a long wait when you’re frequently rebooting the gateway to try different things.
Basic Wiring
The Cisco physical access gateway has a PoE input for network plus power. It breaks out the power and provides 12V nominal to power the card reader. The subcontractor used these same pins to provide door strike power, with the ground connection interrupted by the gateway’s NO relay output.
I removed all of the electrical tape and twisted wires and provided gator wires for my own testing.
Cisco Power Injector, Short Patch Cord
Works fine with a Cisco power injector and a 1.2m patch cord.
Cisco Power Injector, Long Patch Cord
Works fine with the Cisco power injector, 265′ of cable, and two patch cords.
Rack Power Injector, Long Patch Cord
It fails with the same setup but powered from our regular PowerDsine rackmount power injectors in the wiring closet. The moment the door strike energizes to unlock (it’s fail-secure), the whole gateway loses power and reboots.
Okay; now we’re getting somewhere — now we have the same problem on the bench that we have in the wild, so I can fix it and it’s meaningful. (As far as I can tell, in all of their searching for solutions, the contractor never recreated the same problem on the bench that was occurring at the installed doors, so their solutions probably weren’t likely to translate well to the real world.)
Capacitor
I installed a 1000μF capacitor across the reader/strike power terminals … and the reader went dead. Whaaaaa?
Further experimentation with the voltmeter, the capacitor, and numerous 130-second reboots suggests that the gateway internally switches the power feed to the reader port (and doesn’t turn it on until 70 seconds after booting), monitors the load, and disables it if it exceeds a threshold. And the inrush current to charge the capacitor is enough to trip the disable.
Capacitor, Resistor, and Diodes
Mmmokay, need to limit the current into the capacitor to charge it, sounds like a series resistor. But need instantaneous power from the capacitor, sounds like a couple of diodes.
Worked great! I ran a bunch of successful “entries” yesterday afternoon with no more glitches.
Making More
Last night I soldered up a couple to try on some real doors today.
Heatshrinked and ready to go.
Catch Diode
This morning I put one into the bench test setup in place of the loose components I had used yesterday and it worked several times in a row — but one time when the door strike relocked, the whole gateway rebooted.
All righty, we’ll put a catch diode in there yet to shunt the back EMF from the strike coil. Ran a few dozen consecutive simulated entries with no problems. Looks like we’re good.
The contractor is back on site and testing with different strike hold-open times. I’ve explained how to use my capacitor assemblies with extra 1N4001s (reversed), and he’s just added the capacitor and diode to one of the troublesome pilot doors to test in situ. After that we’ll regroup and figure out whether and how to deploy this widely.
As Jeremy would say (approximately), “Science. It works.”
Is This Even Reasonable?
Power over Ethernet is supposed to give you 12.95W to use at the device. The only power specification I can find for the gateway says to budget 1.5A for the gateway, which would be at least 18W and already more than PoE delivers.
The gateway is supplying about 13V to the reader (and strike). The reader’s datasheet says 90mA maximum average current at 12V, so let’s say 100mA, thus 1.3W. The strike says .45A at 12V, so figure about 5.9W. I don’t have figures for the motion sensor and closure contact, but I expect they’re pretty minimal.
Component |
Power |
gateway |
18W |
reader |
1.3W |
strike |
5.9W |
total |
25.2W |
And that’s well over the 15W nominal, ~13W delivered that PoE promises — but we already were with just the conservative figures from the gateway.
Going the other way, the reader and strike require 7.2W of the ~13W available, leaving only 5.8W for the gateway at the end of a long cable, or maybe 7.8W for the gateway right next to a power injector on a short cable.
Kind of sounds like it’s not a reasonable expectation and it just happens to work right now, which is a little disappointing. Cutting the strike power in half would make a significant difference — but it’s hard to know whether it would truly be enough to fall within spec without knowing the actual power consumption of the gateway, and these are already brand new, low-power strikes.
I don’t want to install the system and have it work intermittently, nor fail quickly. Sounds like a call to Cisco is in order to see what they think of all this.