Raspberry PI meets Nano Alarm Panel

The last 3 weeks have been spent getting up to speed with the Raspi and determining the quickest way of interfacing it with the Nano Alarm Panel (based on the Ciseco XRF board).The end goal was two fold, firstly to read the alarm sensor triggers which later could form the basis of a Raspi Alarm and secondly to be able to arm/disarm my existing SL5 control via the Raspi. I guess another goal was the see if the XRF board could be powered from the Raspi therefore reducing the dependency on an external power source.
As the Nano Alarm Panel already exposes a serial interface the logical choice was to connect the Raspi using the GPIO serial port. However its being widely discussed that the GPIO 3.3v can't supply much current therefore powering the XRF board from the PI may not be possible. Instead I opted to use one of the usb ports because these should be capable of supplying up to 100mA. I used a cheap FDTI serial to usb adaptor which fortunately also had 3.3v output pins to the supply the XRF board.

The XRF powered up with any problems and there have been no stability issues with it powered from the Raspi USB port. This is probably mitigated by the fact the XRF uses a relativity low power RF MCU in the form of the CC1110, looking at the datasheet peak current consumption is less than 40mA.

The next step was to soak test the Nano Alarm Panel code which currently was just dumping the alarm sensor triggers to the serial port. I wrote some C code on the Raspi which read the serial port and dumped the sensor trigger data to a MySQL database. This was complemented with some php scripts running under to lighthttpd to view the data in a browser. The Raspi proved valuable because it allowed me to run numerous long running tests (12 to 24 hours) replacing a PC consuming 200-300 watts of power. These tests resulted in me finding a number a bugs in the Nano Alarm Panel code. Below is the sample output collected while running my tests showing the sensors triggered through a short period in the day. Collecting the sensor triggers can be useful for example I can roughly determine how long my morning runs are by the front door contact trigger.

Having read that the CC1110 also has a built in ambient temperature sensor, I updated the Nano Alarm Panel code to periodically (every 5 minutes) output the temperature, this was done without 1 or 2 point calibration which would have giving better results and as per the TI design note. This change was also made as a result of me wanting to soak test the Debian build as more data would be written to the MySQL database in a 24 hour period, around 300+ per day.

So .... the end results are the Raspi ran 24x7 for over 8 days, collecting around 2700 data readings. Best of all this is running using a £1 ipod power adapter and min usb cable. I stopped the tests after this period so that I could continue developing as I wanted to create additional code to arm/disarm from my phone which should be covered in my next blog. Here's the uptime for the Raspi and the number of data points.

Raspberry PI first impressions

I received my PI on the Friday although not desperately seeking one I was fortunate to be in the second batch. The packing was simple, consisting of a padded envelope containing in small cardboard box. The PI is smaller than I expected and its actually the same size as credit card which I over laid to prove. The dual USB connectors result in an overall height of around 15mm.

The PI is powered through a micro usb socket and there's no on/off switch which long term makes me dubious of the longevity of the socket. I'm surprised no has produced a usb cable with an in-line switch or may be a case with this feature. If the PI is aimed at the younger generation that I'd expect this to be an very useful feature.

My initial setup consisted of a cheap 1A PSU along with a usb keyboard/mouse and the HDMI output fed to DVI monitor. Deploying the debian build is relatively painless as long as you are PC literature to do so. I found the PI to be slow at booting and Debian although workable slightly basic. If  you are looking to use the PI as cheap 'Browsing' solution then its not for you! The default Midori just about manages to display pages and a little patience is required. This does bring me onto another point, if we expect kids to use these for projects then I suppose you would expect to 'google' while developing. Not sure how practical it is to do both on the PI.

Next I moved onto the Arch Linux image, having being introduced to Arch while working on my O2 Joggler and I had higher hopes of its usability although potentially it require more effort to deploy a usable build. Furthermore the ARM port is not as mature as the x86 builds. Arch Linux definitely runs faster although again the booting is slow. I got LXDE up and running although Midori and NetSurf browser failed to start when launched and I didn't have time to debug the issue.

I also tried to use the PI which a powered laptop usb hub (Targus), I plugged an old PS/2 keyboard and mouse into the hub. These wouldn't work with the PI again something that may need to be addressed if we want to these to be deployed in schools where older PC equipment may be prevalent.

I purchased the PI for 2 reasons, firstly as a 'cheap' development board for my own hobby use and secondly as an introduction for my young children to software development.

On the first point I have a number of uses of the PI  for my hobby projects. Even then I think theres probably a fair  percentage of potential purchasers who may be disappointed as the PI is relatively low spec ARM board.

On the second point the juries out. I'd say there's a fair bit of knowledge required to configure the PI as the kid friendly device, as of now I'd say the software isn't there. However I guess this is where innovation and creativity comes into the picture, so I'll have to find a way to make it kid friendly!

Friedland Alarm Serial Ouput

So I've managed to create code to output sensors information to the XRF serial port. The plan is provide a simple interface allowing the XRF to be switched to different alarm modes:

Mode 0 - IDLE      (Radio is off, waiting commands from the serial port)
Mode 1-  LEARN  (Registers a new alarm peripheral, registration is needed so that a peripheral can be easily identified and you don't get messages for peripheral you are interested in)
Mode 2-  LISTEN (Radio is listening for a registered sensors to be tigger)
Mode 3 - SEND (Commands can be sent to an existing Control Panel or Bell).

Currently the code supports Mode 0 and Mode 2, as shown in the output below where we switch to Mode 2 and listen for peripheral events. For now I've hardcode the list of registered peripherals because I still need to write the code to save these to the XRF flash memory.

Once a peripheral event is received we dump the ouput which is an 9 character string (this isn't the raw output) but a simplified representation:

AAABBCCCC
 
AAA - A 3 digit code representing the alarm perhiperal 

PIR - PIR,

PAN - Control Panel, 

DOR - Door Switch

REM - Remote Fob

KEY - Keypad

BB - runing number indicated the id of the peripheral (I'll probably allow 32 peripheral to be registered).

CCCC - 4 digit number indicator depending on the perhiperal event. For example in the above output 0004 represents a trigger for a PIR or Door Switch. For a Remote Fob or Keypad 0008 represents a disarm. In the output the Remote Fob disarm is always followed by the Control Panel sending a command to the Bell to stop if activated.

I think we can also decode the Freidland Libra+ Door bell and Spectra Outdoor PIR but I don't have these to prove it.

Next steps are to code up the peripheral registration and write a bootloader so that firmware updates can be applied through the serial port. Then I could release the a cut of the firmware.

Nano SL5 Alarm Panel

This project came about because my existing alarm system an SL5 Friedland Response Alarm (Honeywell) system had no easy means to interface with it so that I could control it through sms or through the web. It then took off in a direction I wasn't expecting. My initial plan of attack was to interface through the phone port on the SL5 Control panel using an Linksys PAP2. Although I was successful in doing this the interface turned out to be rather clunky as it required a PAP2 plugged to the control panel along with an linux box (O2 Joggler) running asterisk.

So my next (crazy) idea was to see if  I could somehow decode the RF protocol as this would allow me to possible talk to the Control panel or listen to the sensors. Having no experience of alarm systems technology didn't deter me nor the slim chances of dechipering the protocol.

After many months of hardware tracing, constantly staring at bit streams and analysing hex data the dectective work finally paid off. So here is the Nano SL5 alarm panel, possible the smallest alarm panel out there (although not as useful in its current state)! It actually consists of an XRF module reprogrammed with my custom software. This prototype consists of 2 LEDs, the Orange LED indicates the alarm is armed and the Red an alarm is trigged.

As you can see in my test setup I used a Friedland Wireless Keypad to arm/disarm the alarm and a PIR to trigger the alarm. First I have to Arm the alarm using the the Keypad which results in the Orange LED lit.

Next I triggered the PIR, this took some time as the PIR sleeps for 2 minutes between triggers caused by camera movement. This results in the Red LED lighting up to indicate alarm condition.

Finally we can disarm through the Keypad.

Hopefully this now opens up a number of opportunites as the alarm sensors can now be used for other applications. My initial idea is to develop the software so that all sensor information is provide through a serial port. It is also possible to mimic a sensor in order to talk to a real Control Panel. The only downside is that the type of sensors are limited to a PIRs, Door Contacts, Remote Key Fobs, Keypads and an Outside Bell.

Budget CC1110/2430/2510 programmer/debugger

Although the TI CC debugger is a relative inexpensive debugging tool, I did stumble across a cheaper option that is compatible with the TI software suite (SmartRF Studio & IAR) and could be used for development or re-flashing a dead CC debugger/SmartRF04EB.

An alternative to the CC debugger is to use the more expensive SmartRF04EB development board. The SmartRF04 essentially contains a C8051F320 and along with additional circuitry for level shifting and on board peripherals. The chipcon debug/programming interface for these TI chips is  just 3 wires Debug Data, Debug Clock and RESET. Therefore the interface required from the board is minimal if we disregard the level shifting feature and assume 3 volts.

So I started searching for a C8051F320 board that could possible could do the trick, in the end I found the understated EX-F320 development board by WaveShare. Initially I wasn't sure whether it would possible to use this board or not but ordered one considering its low cost (approx £12+£4p&p). Luckily I already had a Silabs programmer to flash the EX-F320, in fact the Silabs programmer also uses a C8051F320! Its possible to build a cheap Silabs parallel port programmer or buy a cheap clone from Aliexpress.

Just over a week later I received the EX-F320, it came with 2 different USB cables for powering the board, 2 sets of 2 pin jump leads and 2 sets of 4 pin jump leads (I can't see the point of the 4 pin leads, it would have been better to supply individual jump leads!).

A powering up the EX-F320 and verifying it was recognised by the Silabls programmer I downloaded and installed SmartRF Studio (SRFS). Next I flashed the bootloader (srf04eb_bootloader.hex) and the firmware (fw0400.hex) to the EX-F320. These files are located in \Program Files\Texas Instruments\SmartRF Tools\Firmware\SmartRF04EB. A quick restart of the EX-F320 would determined if the SmartRF04 firmware would run or not. Fortunately after power up the EX-F320 was recognised by SRFS as a SmartRF04 board.

The next step was to locate the SmartRF04 debug pins on the EX-F320, these turn out to be the following pins:

 P0.6 - DD (DEBUG_DATA)

P0.7 - DC (DEBUG_CLK)

P2.3 (RESET)

     

Ideally the 3 pins should be protected with a buffer circuit (74HC245/74HC244) possible with the inclusion of pin P2.2 to enable ouput (have to verify with the SmartRF04 schematic).  The EX-F320 also produces a regulated +3.3v supply which can be used to power the board to flash/debug. 

Final stage was to test (I tested without a buffer circuit) chip detection. I used Ciseco XRF CC1110 module in combination with their Xino basic board.

The CC1110 was also detected by IAR (kickstart) and could be programmed/debugged without any problems.

Another plus point is that the EX-F320 can be used for 8051 development once it is no longer required for CC development.