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.
Is there any particular reason you have D1 in series with R1? I guess it would work just as well without it (D2 shorts R1 in any case when current is flowing from the capacitor)
Tomaž –
I can tell you what’s going to happen when you call Cisco – if you CAN find someone to give you a straight answer, they are going to mention that you should be using one of their enterprise PoE switches that can do “High-Power” PoE. Cisco has quite a few devices anymore that surpass the standard 802.11ad such as the Aeronet 1250 access points that have this same problem – they are specced at 18.5W when using both radio modules.
From what I remember cisco calls theirs “Enhanced PoE” and claims they had to do it because IEEE is late on their “PoE Plus” standard.
Have you looked at the guts of the PowerDSine injectors? Maybe you can juice the current in those with some of your wacky electrics, or perhaps they have a firmware fix for such devices? I suspect personally if you resort to tricks to get these running at lower power levels you will end up having trouble; then you will end up locked out!
John, in this case the physical access gateway is a new enough product that our reseller has already been escalated to the firmware developers and we’re receiving new firmware daily. That doesn’t mean we’re guaranteed a straight answer on the hardware side, but I think it’s a good sign.
The two main questions that we’re directing toward Cisco in today’s conference call are how much power the gateway really draws and whether the gateway would accept the additional power from an 802.3at (or other high-powered) PoE supply.
I’m not going to hack the PowerDsine injectors at work. Whatever we do needs to be scalable and maintainable even if I’m not here, and the capacitor job is right on the cusp of that if the vendor picks it up and does it. Plus even if I wanted to, I expect the PowerDsines are much more highly integrated (and SMT) than e.g. a Soundcraft mixer power supply.
Keith, I was asking about the significance of the diode D1, not the resistor. I understand you need the resistor to limit the peak current, but I believe your circuit will work identically without the diode D1.
Tomaž, thanks for the clarification, and that’s a good observation. I’m not concerned about cutting off the forward flow if the capacitor falls below the forward drop of D2, so as far as I can tell you’re absolutely right. If we end up using this, I’ll definitely try it your way, since it looks equivalent and saves an unnecessary component.
Thanks!
I have a Sprint USB “Aircard” that has a small lithium battery in the little dongle itself. It seems to charge most of the time then draw from the battery for transmit. Newer Sprint devices dont seem to need this.
Anyway, if your duty cycle is low you could charge a battery pack for fifty minutes out of each hour then draw quite a bit of current for the strike. That would put your average power real close to the minimum draw.
Do you have two data jacks at each door? You could use one drop just for power, charge the battery and power the strike off of that one.
Of course the simplest solution is probably just to put cisco power injectors into the wiring closet on the door’s ports. A benefit here is cisco won’t be blaming you for problems when things go wrong.
I’d be interested in the end result of this, since we’re going down the door access route, and Cisco’s product has already attracted attention from higher levels.
Mike, we’re ending up using a lower-power strike, pre-market non-standards power injectors, lots of firmware updates from Cisco, and some compromises on our part to achieve a system that we think we’ll be pretty happy with. So far we’ve only accepted one working test door, but we seem to be back on track and should have a complete system by mid December.
Have you considered other options?
E.G.
http://www.hidglobal.com/prod_detail.php?prod_id=125
What you’ve ended up with is a Rube Goldberg contraption that only you can support. An external power supply with 16 individually fused channels, battery backup, fire alarm disconnect, capable of supporting maglocks or any other lock hardware is about $200. POE is fine for indoor cameras, gateways and readers but to rely on it for lock power is asking for trouble. Running the extra wire is well worth it for a reliable system. Put an 18/4 along with the UTP and you will have the option of bailing out on the POE completely if need be.
John, my experimentation with external capacitors was never intended to be the production solution, but a test to see whether I could identify a means of keeping the gateways up.
For our building, we’re ending up using Cisco-recommended non-standards-based ethernet power injector / splitter sets, which have passed all tests on the bench and on real doors with nothing but installer-provided catch diodes. We’re using ethernet power because our generator only powers the computer room and the wiring closets, and we want the IT department to have full card access and logging even if utility power is out.
For other buildings on campus, we’ve already unanimously agreed that local, external power will be our preferred method.