xAP Hardware
The distributed nature of xAP means that it goes hand-in-hand with small, low cost, embedded devices, that are dedicated to a specific control task. Currently I am working on two classes of embedded device - ultra-low cost, low-capability controllers using the PIC microcontroller - the most sophisticated of which costs around £2 - with a serial xAP interface, and slightly more costly Rabbit based microcontrollers which are correspondingly more capable, featuring an ethernet as well as serial interfaces.
PIC Controller
The PIC is a low power device, with little RAM, slightly more EPROM, a single serial port and a number of digital inputs and outputs. Given the limited capabilities of the device, there as some scepticism that even a protocol as light as xAP could be squeezed into the device. Happily it can, and the software, which is table driven and therefore easy to reuse, is available here. Typical PIC applications are: relay control (switching both high and low voltage loads), basic telemetry (sensing temperature, light levels and so on), and simple user input output (driving LCD displays and keypads).
Rabbit Node Controller
 The Rabbit provides a cost effective bridge between a cat 5 TCP/IP network and local, low cost PIC based units which use a simple serial interface - such as a telemetry unit, simple displays, relay boards and so on. Each node controller can support two RS232 devices or multiple RS485 multi-drop serial devices. In addition, the node controller has infra-red send and receive hardware, and should be able to act as a multi-zone infra-red controller. An on-board real time clock allows the controller to perform scheduled actions independently of a central controller if required.
The xAP bridging software, together with a simple web interface, is already in place. The picture shows the first prototype PCB run - which were manufactured by PCB-pool and are finished to a very high standard.
PC Controller
The ultimate goal is to deploy a fully distributed control system, where no single node is responsible for much more than its' own actions, and which supports intelligent fall back when the loss of an associated node is detected. For example, if the loss of a dusk/dawn sensor was detected, a device on the network with real time clock capabilities would detect this, and assume the responsibilities of dusk/dawn notification based on calculation rather than ambient light level. The xAP library software isn't yet capable of this level of sophistication (a decision engine is in the works), and in its absence, some taks require a degree of centralised control. In any case, there is also a requirement for some heavyweight processing in order to provide web-enabled services, and an economy of scale associated with interfacing many devices to a single controller, which justify a dedicated PC class controller. This function is performed by xAP-in-a-box, a controller and scripting engine that runs a custom Linux build. You can read more about xAP-in-a-box here.
|
|
|
