Design Recommendations - Revision history

Arclight: /* Bi-Directional Protocol Standards */

2011-10-21T18:36:41Z

Bi-Directional Protocol Standards

← Older revision		Revision as of 11:36, 21 October 2011
Line 8:		Line 8:
	====Bi-Directional Protocol Standards====		====Bi-Directional Protocol Standards====

	1. Peripheral nodes such as door readers, sensor boards and keypads should support RS-485 or CAN bus. The advantages of CAN bus include support for message prioritization, a larger address space and support for more nodes, while RS-485 is simpler and many commercial devices already support it.		*Peripheral nodes such as door readers, sensor boards and keypads should support RS-485 or CAN bus. The advantages of CAN bus include support for message prioritization, a larger address space and support for more nodes, while RS-485 is simpler and many commercial devices already support it.

	2. Point-to-point serial over USB or RS-232 is acceptable for interface to a monitoring/control computer. Modern PCs have limited options for I/O, so any device that does not support Ethernet will most likely communicate with the PC either through an intermediate node or a serial USB/RS-232 connection.		*Point-to-point serial over USB or RS-232 is acceptable for interface to a monitoring/control computer. Modern PCs have limited options for I/O, so any device that does not support Ethernet will most likely communicate with the PC either through an intermediate node or a serial USB/RS-232 connection.

	3. Controller nodes that have sufficient resources to run an IP stack should be connected via Ethernet, especially if a client/server authentication model is planned.		*Controller nodes that have sufficient resources to run an IP stack should be connected via Ethernet, especially if a client/server authentication model is planned.

	4. For alerting and monitoring connections to the outside world, IP connectivity is going to have the fastest data rate and message delivery time of the above methods. A data-capable cellular device (GSM card or smartphone SDK interface) is an option for areas that lack connectivity or as a backup. POTS service via a serial modem is simple and robust, but lacking in functionality.		*For alerting and monitoring connections to the outside world, IP connectivity is going to have the fastest data rate and message delivery time of the above methods. A data-capable cellular device (GSM card or smartphone SDK interface) is an option for areas that lack connectivity or as a backup. POTS service via a serial modem is simple and robust, but lacking in functionality.

	===Physical Standards===		===Physical Standards===

Arclight at 20:15, 19 October 2011

2011-10-19T20:15:52Z

← Older revision		Revision as of 13:15, 19 October 2011
Line 1:		Line 1:
	~~'''Design Recommendations'''~~
	== ~~Protocol Recommendations~~==		== Protocols==
	This page outlines our recommendations for open-source access control product standards. Specifically, we address physical and electrical interfaces.		This page outlines our recommendations for open-source access control product standards. Specifically, we address physical and electrical interfaces.

Arclight at 20:14, 19 October 2011

2011-10-19T20:14:53Z

← Older revision		Revision as of 13:14, 19 October 2011
Line 1:		Line 1:
			'''Design Recommendations'''
	== Protocol Recommendations==		== Protocol Recommendations==
	This page outlines our recommendations for open-source access control product standards. Specifically, we address physical and electrical interfaces.		This page outlines our recommendations for open-source access control product standards. Specifically, we address physical and electrical interfaces.

Arclight: /* =Signalling Standards */

2011-10-19T20:13:01Z

=Signalling Standards

← Older revision		Revision as of 13:13, 19 October 2011
Line 2:		Line 2:
	This page outlines our recommendations for open-source access control product standards. Specifically, we address physical and electrical interfaces.		This page outlines our recommendations for open-source access control product standards. Specifically, we address physical and electrical interfaces.

	===Signalling Standards==		==Signalling Standards==
	*All new open-source access and security hardware should support legacy protocols such as Wiegand or clock-and-data as needed, due to the variety of devices available on the market.		*All new open-source access and security hardware should support legacy protocols such as Wiegand or clock-and-data as needed, due to the variety of devices available on the market.
	*All newly developed panels or peripherals should support a bi-directional protocol.		*All newly developed panels or peripherals should support a bi-directional protocol.

Arclight: Created page with "== Protocol Recommendations== This page outlines our recommendations for open-source access control product standards. Specifically, we address physical and electrical interfaces..."

2011-10-19T20:12:44Z

Created page with "== Protocol Recommendations== This page outlines our recommendations for open-source access control product standards. Specifically, we address physical and electrical interfaces..."

New page

== Protocol Recommendations==
This page outlines our recommendations for open-source access control product standards. Specifically, we address physical and electrical interfaces.

===Signalling Standards==
*All new open-source access and security hardware should support legacy protocols such as Wiegand or clock-and-data as needed, due to the variety of devices available on the market.
*All newly developed panels or peripherals should support a bi-directional protocol.
====Bi-Directional Protocol Standards====

1. Peripheral nodes such as door readers, sensor boards and keypads should support RS-485 or CAN bus. The advantages of CAN bus include support for message prioritization, a larger address space and support for more nodes, while RS-485 is simpler and many commercial devices already support it.

2. Point-to-point serial over USB or RS-232 is acceptable for interface to a monitoring/control computer. Modern PCs have limited options for I/O, so any device that does not support Ethernet will most likely communicate with the PC either through an intermediate node or a serial USB/RS-232 connection.

3. Controller nodes that have sufficient resources to run an IP stack should be connected via Ethernet, especially if a client/server authentication model is planned.

4. For alerting and monitoring connections to the outside world, IP connectivity is going to have the fastest data rate and message delivery time of the above methods. A data-capable cellular device (GSM card or smartphone SDK interface) is an option for areas that lack connectivity or as a backup. POTS service via a serial modem is simple and robust, but lacking in functionality.

===Physical Standards===
*Standard RJ-45 connectors for all wired Ethernet applications
*Removable 3.5mm screw terminals for other hard-wired connections up to 5A
*Fixed or removable 5mm screw terminals for higher current power connections
*Anderson Power Pole connectors for battery and high-current DC power supply connections