****'* * ****** ******* ***** ***, if ****, ***** ** *** **** access ******* **** *******.
** **** ****, ** *************** ******* '*******', ******** **** ****'* **** *** not ** ****.
The ****** **********
*** **** ** ********'* ****** ** * device *** ******* ***** * "******" [link ** ****** *********]. ******* ******** the ****** "***** *** **** ****** into ** ** ******" ******* *** need ** * **********, *** "******" is ****** * ********** [**** ** longer *********]. *** **** ********** **** locks, *******, *** **** ******** *** wired **** *** ******, *** *** board ****** ** ********* **** ** ethernet ******* - *** **** ********** of * ******** **********.
*** **** ********** ** **** *** Bridge ***** ** ******* *********, *** acts ** ** ********* ***** *** ****** ********. Bridge ****** ***** **** ** **** and *** ********* ** ******* ******* board ********** *** ******** ************. *** different ***** *** ****** ** *** stock ********** ****** * '**** **' changeover **** *** ******** **********, ****** wiring, *** *********** ******. *******, ** order ** ******* '*******' ~*"**" *** Bridges, *** ******** ********** *** ** additional **** *** ******** ******** *** most *********. ******** ****** '************', *** ************ *** ******** ************* **** ~$**-$**.
*** ****** *** ****** ********* *** different **** *********** ******* ******* **** eliminate '******* ******' *** '********** ***** function' ** ********. *** *** ******* Viscount ****** ****** *** ** ***** are:
**** ************: ***** *** **** *** ************ use **** ****, **** ****** ********* how * ****** ***** ********. *** Bridge ********** *** ********* ******** ** the **** *** **** ****** ********* to * **** ********. ******* *** available ** ******, ******, *** **** reader ********, *** *** ****** ********* boards ** ***** ******* **** ********* and *********. ** ************ ** **** control ****** *** ****, **** * network ** ************** *******.
****** *********:****** **** ********** ********, ******* **** remain ********* ** * ****** ** be ***********. ***** ******* *** ** connected ** ****** ******* ** '********', *** ******* ******** ****** ***** failover ******* ** ****. ***** '********' instances *** ******** ** ***** '****-*******' or ******** ******* ********* ** ******* workstations *** *** ** ********** *********. Failover ** ******** ************* ** *** Bridge, *** ******* ******** ******* *** be ********** **** **** ******.
**** ****** ** **** *******:* ******** ******** ** ***'* ********* is * **** ***** ** **************** with ********** ******* **** ** ****** make ** '********* *********'. *** ******* ****** * **** swath ** ********** ******* ********* **** Wiegand, ***, ***, ******, *** ********* types, ** ** ***** ***** **** bits. **** ** * ********** **** is *******, ** ****** ** ****** through *** ****** ** * ****** and ******* *****. ** ******** ** a *** ********** **** **** ***** with *** ***********, ***'* ******* ******** has ** *********** ** ******* *******.
*******
********'* ********* *** ************* ****** ******** to ************, *** ********* *** ***** to ********** **** *********. *** * standard ****, ***'* ******** ********:
- * ****** **** [**** ** ****** *********]: ($250)
- * ****-****** [**** ** ****** *********] ** Software: ($***)
*** ****** ***** ******** ~$***. VSI's *****/****** ********* *** ******* ** national ************ *** *** ** ********* without ******* ********. [**** ** ****** available]
*** **********, ******** ******* ********* **** Infinias, ***** * ****** ****'***** *****' ************* ******** ***** ~$***.
*** *** ******, ********* ***** **** door *****, *******, ***********, *** ******** networking *** *** ******** *** *** result ** ****** ****** '*** ****' costs.
*********
***** **** ** ***********, ***'* ******** does *** **** ******* ******* **********:
****** *********: ** ******* *****, *** ******* cannot ******* **** *** ** ****** connection ** * ******** ******.
*** **** ************:***** ***, ******* ********, ** ****' controllers *** '****', ***'* ******** ** proprietary. **** *** ******** ** *********, it *** **** ** **** **** VSI ********** ********. **** ***** ********* into *** ** * ******** ***** is * **** **** ***** ******** avoid.
******* ***********:******* ****** ******* **** ***** ************ is *** ** *** **** ****** integrations ** ******** ********, *** ***** no *********** **** *** ***** ***.
Ideal ***********
***'* ****** ********* **** ******** ******** to ********** *** '**** ********' ***********. For *******, *** ******** ** *******-* compliant, ***** **** ***-****** ***/*** ***********, and ******** '**** **/**** ***' ************ as *******. *** ******** ** ****** on ******* *** *********, *** ****************** ******** ************, ******* ** ***********.
*******, *********** *** ******** ** ***********, integrations *** *******, *** ** ************ feature ***, **** **** ****** ** open ****** ****** **** *** ** used **** ***** ****** ** ***** access ******* ******** *********.
Comments (10)
John Grocke
Good to see you back writing articles Brian!
Create New Topic
Luis Carmona
IPVMU Certified | 12/05/13 07:17pm
I don't think I would be comfortable having door controllers dependent on network connections, and I'm a network guy. It's one thing if a network connection to a camera gets interrupted- so you lose some video.... If these "bridges" loose network connection, you have access issues that prevent you from getting in or maybe getting out, or permitting unrestricted access, I guess whichever way the devices default too or are configured. This possibility increases exponentially if are using wireless access points.
I wish there was more mention or a development in terminology when reviewing access or other devices like this to distinguish systems that use a "sync'd data architecture", where the controllers or bridges are actually syncing and caching data, either with a master controller or PC based server, thus allowing them to operate independently when communication issues occur, versus systems that do not, where the controller or bridge cannot function on its own.
See John, free lunches don't affect my objectivity. =)
Create New Topic
Vasiles Kiosses
I approached VSI many times at their booths. I was impressed with the technology however they explained the system as using IT infrastucture and Active Directory to do the management. What I quickly found was that there must be an active directory domain controller on the site that has the devices since as you say, the credentials have to be passed to a system with a database to provide a response. So if you are network dependant, intersite for example, I would not be putting this in. It is a greate idea and can work on a local area network with a domain controller available. And that is where I left the product. The cost of deploying domain controllres everywhere and supporting them far exceeds the cost of a control panel at the site. Maybe what people may want to design is AD Domain Controllers that can fit in the palm of your hand and can hold 100s of thousands or millions of records. It would make the whole system plug and play for everyone.
Create New Topic
Daniel S-T
Viscount has had a system like this for awhile. I've always called it Mesh, though they now have a different product called Mesh.
The Mesh system I worked with was server dependent, but without a "Bridge". The reader was semi-intelligent in that it handled all the connections, including lock relay, RTE, door position switch. But it needed the server for cards. If the server went down you were screwed. A single cat5e ran back to a hub/switch which could also server as a junction point for all the additional hardware if you didn't want to go right at the reader. The switch/hub had an in from previous reader/server, in from the reader, and then out to the next one. As well as a screw terminal set for the door hardware.
We've only ever had one customer on the system (and recently upgraded to a Keyscan system) and it did work surprisingly well for 6-8 years.
I like the idea of the bridge, as it would leave me able to use any reader, where as the older Mesh style we were stuck with Viscounts readers and cards.
Create New Topic
Kok Long Pang
My R&D developed a simillr system few years back, where we use fingerprint devices to read fingerprint images from users, and send back to server for verification. Result of verification return from server to the fingerprint devices to response to the users. The idea is similar, where server stores all credentials, verification algorithm, access rules and database. This is ideal because you will only need a server and multiple slave fingerprint readers.
When comes to real operation, we noticed the software can only handle single thread of data transfer. It only receive and proceed verification for the "first reach" fingerprint images. While it ignores the rest of the fingerprint images sent from other fingerprint devices. The result, only 1 fingerprint device can verify 1 user at the same time, while the rest fail.
By the end, we pull back the development and change to develop bigger fingerprint storage in our products. We know no matter how big the storage of the device can achieve, it cannot compare with server-client based system.
When comes to a server-client based verification system, how many threads can the server handle? Will it accept all "input" in queue? Or it ignore the rest? I am not familiar with the VSI, but I like the idea of server-client verification. However the delay time between every read/verification is my concern.
Create New Topic
Luis Carmona
IPVMU Certified | 12/09/13 05:09pm
"When comes to real operation, we noticed the software can only handle single thread of data transfer. It only receive and proceed verification for the "first reach" fingerprint images. While it ignores the rest of the fingerprint images sent from other fingerprint devices. "
Kok, I would think that should have been a simple software fix- one system process that receives data and qeues them up for processing and another process that processes the images. If you send the fingerprint straight to the imaging process without any queing then I can see how you'd miss processing requests from other devices.
"This is ideal because you will only need a server and multiple slave fingerprint readers. "
What about that would be the ideal? Is it a possibly cheaper cost of the edge devices, since they don't have to perform any or a limited amount of intelligenece and storage? That would be the only benefit I could think of.
Create New Topic
Undisclosed Manufacturer #1
VSI's software technology seems admittedly cool. However, I've noticed over the years that cool software technology doesn't always succeed in access control because:
VSI will certainly find some success with this in the higher-end market wtih established IT environments. Time will tell if this can become mainstream.
Create New Topic
Joe Cunetta
Any thoughts on using the Nano Cube Server or have any experience with it? I find it interesting and am wondering when these are generally installed. I would be worried to have my access database on something that someone could potentially plug into a wall socket not in a secured room.
Create New Topic