Software upgrades

With new version of hardware in fabrication, I have turned back to software side of gateway. I have made significant improvements in zone thread and also improved the alarm event thread (AET). It stays, that it can handle 3 simultaneous alarm events at once. That is the software is able to wait for authentication when you enter one zone, while setting alarm for any other two, or any combination.  Additional  AET can be added, but 3 should be enough for any normal household or property. Overflowing event will not be lost, but logged, and if reoccurring it will trigger AET again. In real scenario your inner house zones will have authentication time set to 0 seconds, and they will be properly handled by AET in no-time. Only time the AET will overflow is when your local SWAT team enter your house by every window at once. Still it will set alarm On and notify you and you neighbours :).

I have reworked time keeping mechanism. Mainly inspired by simple idea that the NilRTOS, that is used for gateway, can trigger thread periodically at any given millisecond interval. I have tossed away routine, that was asking RTC chip connected by TWI/I2S every time software was needing exact time. And instead created a new timer thread with 1 second wakeup interval. There the thread increase internal second counter, keeping the time available to other threads. Also there is 2 byte counter that will sync with RTC chip when it overflow, that is every 2^16 seconds, at least once a day. It nicely give back some processing power to all threads as TWI/I2S transfers are only 400kbs.

With all that I was able to get back to original idea of having not only a security system, but also a sensor gateway. All started with unifying authentication nodes and sensors. Now they are put together simply as nodes in web interface, and they can also have name assigned along with address and local number. This further improves registration and handling of sensors. I added new feature, or better new type of node. An input node that represents a remote relay, switch or any other output resource that can be addressed by float point value. It works astonishingly well and it does not matter if the node sits on wired or wireless network.

Another news are new feature sets called triggers and timers. As name imply it will do just that :), but I will leave it for new blog post. I think it is worth it.

Also PCB's are fabricated and waiting for shippment.

New design

It has been a while when I started real world testing of the whole system.  I have polished the code, fixed few bugs. Now I'm deciding that do next. I have few things on mind:

1. Design new PCB, bigger with all things on it. I have moved from Eagle to KiCad, and curently designing something like this:

It has WizNet W5500 Ethernet chip, SIM900 for GSM, and also some other improvements like better analogue protection. Size would be 10x15cm and it will be drop in replacement for any old wired burglar alarm.

2. Move the software to Arduino 1.6 to resolve the last bug with SPI transactions. Ethernet library disables interrupts and very seldom some interrupts are missed, causing a radio or RS485 packet to be not seen.  That would mean to rewrite libraries too, namely W5500 and RFM12B.

3. Port the RTOS from Nil to newer version called ChibiOS RT that allows dynamic threads and dynamic allocation of memory. This would eliminate the static allocation of memory for sensors and keys taking up RAM even if not needed.

For me all that work for many months is just fine, but I would like this to maybe become some kind of community project, so I'm not alone in this. I would gladly accept any hints, help in coding or design, or give some help to anyone.

Let me know...

RS485 protocol

Last post reminded me to write about library I have created for the wired network. It is called simply LibRS485, or NilRS485 adopted to work in NilRTOS. The library defines packet protocols on RS485 drivers. I use ST3485EB a 3.3 V powered, 15 kV ESD protected and up to 12 Mbps RS-485 half duplex transceiver. Inexpensive SO8 chip that has all that is needed already inside. As it is half duplex we need one extra pin to tell the transceiver if we are receiving or transmitting. The transmission itself require one twisted pair of wire and is able to push the data to distances over 1km with reasonable speed. The nice thing about RS485 it uses a differential balanced line and resists electromagnetic interference from motors and other equipment, more can be found on wiki.

LibRS485 uses a 9bit protocol and Multi-processor Communication mode defined in ATmega. This allows the MCU to do other thing without looking on communication unless there is a address frame. Basically i work like this:

1. All nodes are in Multi-processor Communication mode (MPCM)
2. One of the node sends an address frame, and all receive and read this frame.
3. All nodes reads the address frame and determine if it has been selected. If so, it clears the MPCM, otherwise it waits for the next address frame and
   keeps the MPCM setting.
4. The addressed node will receive all data frames until a new address frame is received.
5. The other nodes which still have the MPCM bit set, will ignore the data frames.
6. When the last data frame is received by the addressed node, the addressed MCU sets the MPCM and waits for a new address frame. The process then
   repeats from 2.

Library also defines a packet structure like this:

 -------------~~~~~~~~~~~~~~~~~~~~~~
 - A - P - X -  D0 - D63 ~ S0 ~ S1 ~
 -------------~~~~~~~~~~~~~~~~~~~~~~
  
  - Required fields
  ~ Data and signature fields
  A Address - 4 bits form and 4 bits to address.
    0  is master, but not really as any node can drive communication
    15 is broadcast to all
    14 addresses left for other devices
  
  P Packet definition - 2 bits type and 6 bits length.
    Flag bit configuration:
    FLAG_ACK 3
    FLAG_NAK 2
    FLAG_CMD 1
    FLAG_DTA 0
     
    Types: CMD - Command - user defined general commands value 0 - 63
           DTA - Data - user data length D0 - D63 and CRC S0, S1
           ACK, NAK - flags for data, using signature of data packet
           
  X XOR of A and P, for basic transfer safety.
  
  D0 - D63 user data.     
                       
  S0 ~ S0  CRC for user data or signature for ACK, NAK.   

So basically there are two types of packets. Command packet that has only 3 bytes (APX) and deliver a command(number 0-63) to node(s). It is used for example to issue a call for registration. Or data packet  that has 6-69 bytes (APX D0~D63 S0S1). This deliver any data to node(s). The nodes are addressed by its address 0-14, which select any individual node. Or address 15 that is broadcast to all nodes.