What is an outdoor pin pad that is compatible with the ELK M1?
- Thread starter ghurty
- Start date
Any that allows you to configure a FC independent of the credential ID and 26 bit weigand. There's plenty. What you are not going to be able to do is integrate a swipe + pin into the system easily. It's an M1 and not a robust access control system.
To make it work on the M1, you only need to send a FC and then the credential ID, which can have preceding or trailing zeros. The only item the M1 needs to know is that the user is viewed as a credential and tossed in the calculator for entry, preferably configured as separate users on the M1 (check box).
This is what I'd use: http://www.keyless.com/KTP%2012-Pad%20Specifications.htm
To make it work on the M1, you only need to send a FC and then the credential ID, which can have preceding or trailing zeros. The only item the M1 needs to know is that the user is viewed as a credential and tossed in the calculator for entry, preferably configured as separate users on the M1 (check box).
This is what I'd use: http://www.keyless.com/KTP%2012-Pad%20Specifications.htm
AutomatedOutlet
Senior Member
I agreeWork2Play said:
This is not entirely true as you need to have a fixed site code and credential sent to the M1 on a valid read. A standalone biometric or similar unit is only going to pass through the preprogrammed data that is contained within that reader itself, whereas a standalone weigand reader is going to pass the credential and site code, or in the case of a keypad, you're going to need to set up a static site code and then know how the PIN portion is passed through in relation to a credential number (0-65535).
Just because the reader states it's weigand 26 format doesn't mean the start bit, stop bit and parity are the same across all manufacturers and credentials (if used). If this were the case, system takeovers on access control and formats would be a heck of a lot easier on non-standard formats or variations. If you're unsure of the reader or if it's an "off brand" product, you would need to know the raw data in hex format then convert.
Just because the reader states it's weigand 26 format doesn't mean the start bit, stop bit and parity are the same across all manufacturers and credentials (if used). If this were the case, system takeovers on access control and formats would be a heck of a lot easier on non-standard formats or variations. If you're unsure of the reader or if it's an "off brand" product, you would need to know the raw data in hex format then convert.
Thank you.
I had this (or something like this) sitting around http://www.rosslaresecurity.com/products/ayc-g64/
And while I have the prox part working, I cant figure out how to get the kaypad to work. I tried typing in the regular code that I have working on the Elk keypad but nothing happens.
Thanks
I had this (or something like this) sitting around http://www.rosslaresecurity.com/products/ayc-g64/
And while I have the prox part working, I cant figure out how to get the kaypad to work. I tried typing in the regular code that I have working on the Elk keypad but nothing happens.
Thanks
Simple actually.
Just like I stated elsewhere. You're not going to get a prox + pin to work on the M1. It's not an access control panel and it can't handle that data. You'll be able to use the reader itself as a 26 bit weigand or pin itself as 26 bit but not both together at the same time (prox+pin).
Look at your documentation, it's either option 4 or 5 for the M1. You need to hard code the FC on the keypad, then you can add the PIN. Then you plug the FC and your PIN into the Elk calc and then change it to hex and add it as a user. Then either a credential swipe will allow access (you need to program the FC and credential # as a user) or PIN (FC is hard coded at the keypad and credential/pin is any number you want between 1 and 65,535 or 0000 and 9999.
Just like I stated elsewhere. You're not going to get a prox + pin to work on the M1. It's not an access control panel and it can't handle that data. You'll be able to use the reader itself as a 26 bit weigand or pin itself as 26 bit but not both together at the same time (prox+pin).
Look at your documentation, it's either option 4 or 5 for the M1. You need to hard code the FC on the keypad, then you can add the PIN. Then you plug the FC and your PIN into the Elk calc and then change it to hex and add it as a user. Then either a credential swipe will allow access (you need to program the FC and credential # as a user) or PIN (FC is hard coded at the keypad and credential/pin is any number you want between 1 and 65,535 or 0000 and 9999.
drvnbysound
Senior Member
Quick question... I saw this above:
I haven't used anything other than the Elk keypads so far, but showing interest in Elk's ability to do some access control as well. Am I correct to assume that said Wiegand reader needs to be connected to a M1KP or M1KPB... and installed within 10ft of the keypad? I saw this in the installation instructions for the ELK-106055.
Work2Play said:
I haven't used anything other than the Elk keypads so far, but showing interest in Elk's ability to do some access control as well. Am I correct to assume that said Wiegand reader needs to be connected to a M1KP or M1KPB... and installed within 10ft of the keypad? I saw this in the installation instructions for the ELK-106055.
Not sure of their reasoning. Most weigand devices can function up to 1K' out from the port. Might be a voltage drop item as readers do real funny things when their voltage drops below 12V and/or could be a weak input on the part of the KP.
A KAM is also the same.
If you look at a M1KP, the sink output on the unit is perfect to drive the bicolored LED on a reader for arm/disarm, or in the case of access with rules, work like a "real" reader and give you red for secure, green unlocked and (typically) a red/green flop for held or forced. Then you drive the DSM into the KP.
*edit* just looked at the KAM and it appears that a reader can be up to 50' from them, but they should also be located within 25' of the door. The one thing I don't like about the layout of the KAM is the REX is a NC circuit.....any failure or loss of power will cause the door to remain unlocked; poor design choice.
A KAM is also the same.
If you look at a M1KP, the sink output on the unit is perfect to drive the bicolored LED on a reader for arm/disarm, or in the case of access with rules, work like a "real" reader and give you red for secure, green unlocked and (typically) a red/green flop for held or forced. Then you drive the DSM into the KP.
*edit* just looked at the KAM and it appears that a reader can be up to 50' from them, but they should also be located within 25' of the door. The one thing I don't like about the layout of the KAM is the REX is a NC circuit.....any failure or loss of power will cause the door to remain unlocked; poor design choice.
tmbrown97
Senior Member
I don't have the first-hand knowledge but I read enough reports about distance from the keypad/kam making a difference so I'd locate the two as close as reasonably possible.
For DEL's comment about the facility code and all that - well, the M1 as I recall doesn't really give a crap about facility code - meaning every single access code/device can be a different facility code IIRC... It's used, but there's no expectation that you pre-program the Facility code - so as long as your device puts out a working combination code then you're fine.
That's part of what drove me away from the KAM... it has more features geared towards a purely access-control door, but you can't enroll from it - you need to enroll from an identical device connected to a keypad or know the facility/card code and use the Elk tool to convert for you. So much easier to choose "Enroll" then activate the Weigand device...
For DEL's comment about the facility code and all that - well, the M1 as I recall doesn't really give a crap about facility code - meaning every single access code/device can be a different facility code IIRC... It's used, but there's no expectation that you pre-program the Facility code - so as long as your device puts out a working combination code then you're fine.
That's part of what drove me away from the KAM... it has more features geared towards a purely access-control door, but you can't enroll from it - you need to enroll from an identical device connected to a keypad or know the facility/card code and use the Elk tool to convert for you. So much easier to choose "Enroll" then activate the Weigand device...
@ Work look at the OP's application and hardware,
Yes, while it's true that the M1 doesn't necessarily care what the FC in the field in relation to a credential as that is another data line in the user function, but it still must always be known in order for the M1 to function and action the input as a valid code. In the OP's case, using a keypad outside to send a PIN to the M1....he needs to know that FC always, because the reader is not going to allow him to dump the FC, credential and PIN into the M1 and get a valid "read" the intelligence just isn't there in the M1.
To get a reader to work on the M1, the data must present to the panel just like a standard W26 card with all the values known!
In the case of a KAM, it's not really a big deal if you stick with the same FC and credential type (and not getting into the argument that only having 255 FC's and 65,535 credentials is not secure). Personally, while the Elk (Ness) readers are nice, I've commonly stuck with HID readers and compatible credentials....far easier to get replacements and varieties out in the world.
And while off topic, 26 bit weigand is not a "type" or standard but a presentation of the data to the host system. I've had plenty of off the wall systems where the parity bits were swapped or the FC or credential was slightly tweaked from a "standard" W26 format but still passed through normal W26 readers and the decoding was done via the software and/or head end. Part of a way to lock a customer in for the "nationals"....and the reason why us integrators have systems that can drop or hold the FC and action it in many locations, in addition to CHUID's.
Yes, while it's true that the M1 doesn't necessarily care what the FC in the field in relation to a credential as that is another data line in the user function, but it still must always be known in order for the M1 to function and action the input as a valid code. In the OP's case, using a keypad outside to send a PIN to the M1....he needs to know that FC always, because the reader is not going to allow him to dump the FC, credential and PIN into the M1 and get a valid "read" the intelligence just isn't there in the M1.
To get a reader to work on the M1, the data must present to the panel just like a standard W26 card with all the values known!
In the case of a KAM, it's not really a big deal if you stick with the same FC and credential type (and not getting into the argument that only having 255 FC's and 65,535 credentials is not secure). Personally, while the Elk (Ness) readers are nice, I've commonly stuck with HID readers and compatible credentials....far easier to get replacements and varieties out in the world.
And while off topic, 26 bit weigand is not a "type" or standard but a presentation of the data to the host system. I've had plenty of off the wall systems where the parity bits were swapped or the FC or credential was slightly tweaked from a "standard" W26 format but still passed through normal W26 readers and the decoding was done via the software and/or head end. Part of a way to lock a customer in for the "nationals"....and the reason why us integrators have systems that can drop or hold the FC and action it in many locations, in addition to CHUID's.
tmbrown97
Senior Member
I have no argument or dispute... I know that the M1 uses the combination of Facility Code and User Code to make a unique ID - and for the laymen, figuring that out may be a PITA. If you're doing a campus it's worth knowing that but if you're doing a house with 3-4 fobs max, then it's really not important. All that matters is having a working combination (maybe x3/4). So - my recommendation geared towards this particular automation community is to use your reader with 26-bit weigand protocol wired to a keypad and not a KAM and just follow the instructions to Enroll - then the panel will figure out the translation for you and register an active user for you. From there you can go into RP and do rules or whatever for that "User" (all codes/cards are unique users). If you want to use a KAM you have to know exactly what's being presented by the reader and are susceptible to everything DEL mentioned about odd/jumbled readings. Doable, but more work.
Similar threads
