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.