Open Source Access Control Messaging Standard: Difference between revisions

From ACCX Products Wiki
Jump to navigation Jump to search
 
Line 26: Line 26:


=====Existing Protocols=====
=====Existing Protocols=====
* [http://www.accxproducts.com/wiki/images/2/27/YLMF507A_protocol.pdf Commercial Mifare reader protocol]
* [http://www.accxproducts.com/wiki/images/f/ff/EM_Communication_protocol.pdf Another Commercial Reader Protocol]
* [https://github.com/roycepipkins/MakerAccessControl- Royce Pipkins Access Control Project]
<code>
<code>
* [https://github.com/roycepipkins/MakerAccessControl- Royce Pipkins Access Control Project]
//Copyright Royce Pipkins 2010
//May be used under the terms of the GPL V3 or higher. http://www.gnu.org/licenses/gpl.html
/*
* ASCIIProtocol.h
*
* Created on: Mar 28, 2010
* Author: Royce Pipkins
*
* ASCII protocol driver
* ASCII protocol driver
* Address and Type will be encoded as ascii-hex in the
* Address and Type will be encoded as ascii-hex in the
Line 49: Line 42:
* will reject the packet.
* will reject the packet.
*/
*/
</code>
</code>

Latest revision as of 10:59, 28 June 2012

Draft Messaging Standard for Open Source Access Control

Low-level Signaling

Message format should be adaptable to the following mediums

  • Serial
    • RS-485
      • Up to 32 devices per chain
      • 9600-57600BPS
      • Half-Duplex
    • RS-232
  • Ethernet
  • REST style API(http POST/GET API)
  • SMS/Cellular
    • <140 characters or less per message

Desired Features

  • Polling, and unique identification of nodes in the system
  • Collision-handling and/or retry protocol
  • CRC protocol for message integrity
  • Encrypted/authenticated and cleartext messagig support
  • Ability to interoperate if other protocols are on the same bus
    • Can ignore messages in wrong format
    • Graceful recovery/retry of messages
    • Ethernet-style back-off in case of collisions?
  • Need s rich library of polling, sending and control messages
Existing Protocols

  • ASCII protocol driver
  • Address and Type will be encoded as ascii-hex in the
  • first four bytes after STX. The body string will follow
  • as-is and will include the zero terminator. The next
  • four bytes will be the 16 bit check sum of the everything
  • past the STX up to the checksum expressed as ascii-hex
  • [STX][ADDRESS][TYPE][BODYSTR][\0][CHECKSUM][ETX]
  • The body string mustn't contain an STX or ETX or the receiver
  • will reject the packet.
  • /