PIC16F84 microcontrollerbased infrared surveillance system sending GSM-SMS alerts

by

Peter Sandstrom

13:th of July, 2002
(updated 26:th of March, 2008)

Summer project 2002

I try to do some kind of project every vacation just to keep myself occupied with something useful during those odd rainy days. These pages describes the "Crazy summerproject 2002": MicroGuard Mark 1, a microcontrollerbased surveillance system sending SMS alerts. The major parts of the project actually finished before vacation began this time, so things doesn't always turn out as planned... Credit goes out to the guys at work that listened to my ideas and came with suggestions, improvements, feedback and ideas to it.

Face it - your stuff matters

Guarding your stuff is important. What's maybe even more important is that it remains safe even as you're not there yourself in person to keep an eye on it (personally I don't consider hanging around and guarding stuff being of any higher quality-time factor than time spent rebooting my PC after Micro$oft Windows crashes - please forgive me all you nice people doing a great job working as guards). Anyway, I wanted to make some kind of alarm for our familys summercottage. The alarm should also be useable for e.g. guarding your precious car, garage, home, whatever.

Hardware requirements

I wanted a thingy being able to work on everything from 12VDC to 230VAC and at low current. I also wanted the thingy to be able to alert me wherever I am. As Finland has great GSM cellular phone coverage SMS (Short message service) seemed to be the ideal way to get the alarm accross. MicroGuard has mainly been designed to operate as a silent alarm, but adding hardware for generating any loud noise of your choice when it's trigged would be a piece of cake. In addition it should be cheap, versatile, easy modifiable (maybe during the next year's vacation :).

So - let's whip together a hw specification

I've coded assembler on various microprocessors in the past, e.g. Motorola 68HC11, 80C51, PC CPU:s, the C64 CPU, Microchip's 16C84, etc. From this I knew that the Microchip PIC16F84 /04 would be capable of doing the job. And it's cheap, easy to develop & test on due to it's EEPROM design. Microchip also gives away a suite of free development tools that are just great. Secondly I needed a funky sensor that could discover the potential burglar. Ok now, we've all played with tripwires of diffrerent kinds some time. But they're not especially cool, it's also easy to avoid them providing you know their whereabouts. An IR-sensor (= infrared-sensor) on the other hand would be nice. I've always wanted to test one of those in some project so I went out and bought a "pyroelectric sensor with fresnel lens and integrated logic". The type was SGM 5910 manufactured by Nippon Ceamics and it costed in the neighborhood of 25 EUR (about 25 USD). It worked on 5V just as the microcontroller so no problems there. Finally the GSM unit; I wanted to use my old Ericsson A1018S. It was old, needed a new battery to work at all. I decided to save the money for the battey and buy a cool new phone instead, then I could dedicate the old Ericsson for The Project. Guess what, even though it wasn't stated anywhere on the web I suspected I would also be able to run the GSM straight on 5 volts.

Getting the phone to obey

A little swift reverse engineering on the Ericsson and reading GSM specifications told me that I could just rip the battery away from its back and feed it from a stabilized 5V powersupply that provided a maximum of ~ 0.6 A during transmission. As it would almost never need the full 0.6 Amps I didn't need a very big heatsink on my voltage stabilizer of choice either; the 7805. There was a potential problem with my GSM-operator DNA , they don't yet provide the possibility to limit the usage of a subscription to a fixed amount of money per month. The say it's coming, but for now it would really be a problem if someone stole the whole alarm .. imagine that. Then anyone could happily dial out and cause large bills for me. That's why I wanted no battery. If the alarm unit was removed it would lose power instantly and the SIM card would lock itself giving me time to block it at the operator's. When DNA starts to provide the service mentioned above I will probably put the battery back and feed the whole system from the battery. Then the alarm can send an "power loss / tampering alert" utilizing battery power if it notices that someone has removed the power feed / charger. An alternative to the locking of the SIM card would of course be to use one of the new prepaid GSM subscriptions, ther you'd only lose what you prepaid.

Hacking the protocol

Now the next problem was how to interface the PIC16F84 with the GSM. I began with building my own datacable using the connector from an old handsfree and some components for about 8 EUR (about 8 USD). The datacable is basically a MAX232-based RS232-TTL converter. Looking at the protocol, the only thing I knew for sure was that the comm.params were 9600,n,8,1 and that some kind of AT-commands could be used to send an SMS. Here everything begins to become really shady. No documentation on the web, ericsson won't bother to tell me how one of their stoneage-model phones work. I happened to come over the AT-spec:s for some of their newer models, but those commands weren't supported on my phone. I knew I had to do some handshaking and then get a PDU (protocol description unit) over to the phone to send. (A PDU contains phone numbers, message, and lots of other important info encoded in a special way) After I've been to the other side of the internet and back I finally found a piece of software that could from my PC send a SMS to the GSM. It was a badly written piece of software by the way, unstable and it also didn't calculate the PDU:s correcty so the text came out garbled on the receiving phone. Anyway, I borrowed the trusted old HP 4951 protocol analyzer from my job. This nifty gadget has provided me with many hours of pleasure while debugging protocols. I sampled a couple of transmissions on it and spent a couple of evenings analyzing it and finally got it cracked. You can find the protocol here. (If you're able to verify the operation of the protocol described on any other of the Ericsson models please e-mail me about it and you'll get credit for it). I could now get the pone to obey! I quickly wrote a Visual Basic program to verify that I did all the calculations and timing correctly and that my hack worked, and it did. The phone obeyed. It had better.

The datacable	Datacable circuit diagram	GSM Connector
	The HP 4951B Protocol analyzer

PDU:s in VB

I didn't want to calculate the PDU:s within the PIC16F84, as that would be too much work for both me and the processor and really unneccessary as PDU:s seldom change. On the other hand, calculating the PDU:s manually was also one notch more boring than I could stand. So I wrote a second VB application that allowed me to feed all the parameters in and it returned a ROM table for the PIC. This could later be pasted into the source code of the PIC. You can download it from here - but beware it's extremely beta:ish ! The table I created for mapping between GSM 03.38 and ISO-8859-1 DEC alphabets is here.

Operation of the alarm

The alarm has a "cold" and a "hot" mode. Cold mode means that the alarm is in test mode / disabled. In cold mode the alarm LED will light for two seconds if the sensor is trigged and that's it. In hot mode it will send a SMS and wait for a predetermined interval until sending the next SMS (normally 60 minutes). There's a reset switch which resets the alarm LED:s. Reset can also be performed by switching mode switch from hot->cold or cold->hot. This was implemented quite late and actually rendered the reset switch unnecessary.

The PIC16F84 program

The program was written and debugged using the free tool MPLAB, version 5.31. With MPLAB I could easily verify timings, simulate events on inputs and see results on the outputs. I used assembler as the language of choice becuse it's a nice change to the high level programming languages that I use at my job. Furthermore assembler gives me full control over the code which is important when you do e.g. critical timing. The source files complete with comments are about 1000 lines long and the compiled code is 504 bytes. So I've used up roughly 50% of the PIC16F84:s program memory, but the program could be optimized to use less memory, maybe only in the neighborhood of only 30% of today's version. But I won't go there until more free memory is needed in an upcoming version. Se example code of the SEND_SMS routine below:

Operation is as follows: after the 30 second startup (needed by the IR sensor to stabilize after power-on) the program begins checking the sensors and user input, If it's in hot mode and an alarm is trigged, a SMS is sent out and the alarm-LED lights up (this version has 4 alarm LED:s, but the software only supports one alarm sensor for now). When SMS is sent the program will go to sleep for one hour before starting to check sensors again and sending more alarms. This is because I don't want to be flooded with 15-20 SMS:s per minute. One is enough. In cold mode an alarm simply means that the alarm-LED will be lit for two seconds and then things return to normal again, and there will not be any SMS sent out whatsoever. Using this mode one can 1) test the operation of the system 2) disable the alarm while in the building. When flipping the switch between hot/cold mode a reset of the alarm will always occur. When the alarm is resetted the alarm-LED:s goes off and a sleep will be aborted. Pressing the reset button will also have this effect.

Building the different blocks of the prototype

All electronic components was purchased form Vaasan Elektroniikkakeskus and an additional second-hand Ericsson A1018S as backup was bought from Päämies. The costs for the complete system landed on about 110 EUR (about 110 USD) and you should be able to get off cheaper by using lower quality components. Below are pictures showing the assembly of the different parts of the system. Everything was developed in a small improvised laboratory in the corner of my kitchen which also is the "server room" for the Spaceorbit.Net domain. You can notice the servers and firewalls under the table, and the console in the corner.

A bag of goodies was acquired	Prototype:ish voltage stabilizer	Panel soldered on prototyping-laminate
GSM battery is replaced with soldered-on power conductors	Welcome to the Spaceorbit.Net Lab	First test of the whole chain: from sensor to SMS
	The protoboard

Assembling the prototype

I wanted to put everything together in somekind of box to be able to move it into different test locations. Below are pictures of the metal-framed "box" I used for this purpose. Note that a PC power supply is used to simulate the 12V car battery that is eventually going to power the system when it's installed at the summer cottage. I kept the prototype running for a couple of days and it operated nicely. However I found a two minor glitches which were traced back to being bugs in the software. One was incorrect operation of the modeswitch during certain circumstances and the other one was that alarm LED:s were cleared without reset being pressed. During the test period around 50 SMS-messages were sent out and not one of them failed, so I was fairly confident that the system was stable and robust enough to be deployed into its final environment.

Designing the PCB & panels

Someone might at this point wonder why the panel circuit board wasn't made as an "real" PCB. Well the answer is easy; I designed the panel so early in the project that I hadn't decided on what software to use for the PCB design. Furthermore it was such a simple part of the project that it could well be built on one of those prototyping laminates available. The piece of sofware I ended up using for designing the circuit board was the free version of Eagle Layout Editor 4.09r2 from CadSoft. A really great tool providing schematic capture, board layout and autorouting. Component list is here. I'm afraid I haven't yet had time to "clean up" the design to look really good, but by comparing the schematic with PCB pictures you should be able to get the information you need out. Anyway, by using the good old UV-lamp, a bottle of NaOH and another bottle of the nasty FeCl the PCB was finished. Panels were designed using Corel Draw 10 and made to stickers in a do-it-yourself-way by printing with a laser printer on that kind of paper which has a sticky side. After that it was laminated with transparent glue-on plastic used for protecting book covers... yeah, that's right - book covers.

Designing the PCB in Eagle Layout Editor	Component side	Copper side
Schematic	Control panel	Connection panel

Fitting everything in the box

A couple of hours of measuring and drilling later the aluminium box was ready for painting. I found a funky red car-color that had been used for covering damages from flying stones on one of my father's earlier Nissan Primeras (he's now moved on to silvermetallic Nissans' claiming that dirt is almost insvisible on that surface). Anyway, I began painting by using a black color as a base and then applied the red Nissan paint on top of that, but I ran out of the red so the finished box got a brownish color and looked just like it was rusty. I left it looking like that as it gave the box a certain amount of personality and even a bit of soul :) After the painting, the connectors was bolted on, phone and PCB mounted, and the wiring was put into place and soldered in.

Cramming everything in	The control panel. Antenna poking out on top.	The connection panel for power, fuses and sensors at the bottom of the box.
	The Box, in a cheerful and relaxed pose for the camera.

Installation time!

I launched this project 28:th of May 2002, and now it was 12:th of July 2002 and time to install the MicroGuard at our family's summer cottage: My father and I packed our electrical installation gear down the boat and went there. Since it was my father who originally had made all the installation of the 12V power system in and between the buildings at our summer place he came along to make the neccessary modifications around the power source. The IR sensor is active low, and that means that anyone trying to cut the wires to the sensor only trigs the alarm, so no need to hide the cabling, but I didn't put a flashing led on the IR-sensor's box as I rather wanted a slient alam. Five hours later the IR sensor was mounted inside the cottage and the MicroGuard was mounted in an undisclosed location nearby. Ok, now we we're getting ready for first run! The mode switch was set to "Off/Test". The sensor was connected, then the power cable. The system started doing the 30-second bootup. The PIN code was meanwhile keyed into the GSM. The GSM associated itself with the network and signal level was ok in the GSM cell. Everything came online ok! Hooray! When doing the system tests everything also worked as planned, GSM transmitted fine, the system was very sensitive to motion inside the cottage and alarms flew without any problems. Now it was finally time to flip the switch to "Guard" and go on back home. MicroGuard Mark One was operational and the summer cottage was finally secured, phew.

The Sandstrom Family summer cottage. Guarded.

The sensor in its housing, unobtrusively keeping an watchful eye inside the summer cottage.

Received a test alert !

MicroGuard Mark Two - the Future ?

The upcoming version of the MicroGuard - the Mark 2 version - will probably have one or more of the features below added to it. These had to be discarded in Mark 1 in order to get it finished within reasonable time. Also Mark 1 will provide necessary experiences so that Mark 2 can be designed in the best possible way. The PCB was designed with everything necessary already onboard, and that means that almost all new features below can be added just by updating the software (or rather firmware) in the microcontroller.

Possible new features in Mark 2:

• Ability to interact with my planned SQAN protocol
• Ability to handle up to four different sensors
• Ability to respond to remote queries for system status from the user with a SMS
• Will have a built in powersupply in case of power failure / tampering
• Will use prepaid SIM card. Using a normal one feels unsecure.
• Will be able to switch the phone on / off itself to save power
• Reset button no longer needed - make it into a "test alarm" button?
• Ability to read temperature from sensor and send alarms if thresholds reached
• Ability to ask the system for temperature by sending a remote query
• PC interface for setting parameters and downloading status information (maybe using my old trusted Atari Portfolio palmtop which is highly portable)
• Numeric keypad for keying in code to activate/deactivate alarm instead of switch.
• 30 sec delay before alarm goes out, this would allow the alarm to be IN the actual guarded area and it could be disabled with the keypad.
  

Wrapping everything up

The project was quite interesting as I was able to gain some basic knowledge in intefacing a CPU with a GSM device and learning about how SMS PDU:s are composed. That I found it interesting is also reflected by the fact that I managed to build it from idea to finished design in (for me) record time, I used only evenings. If you have any comments, questions or even would like to play around with something similar and make use of the hacked protocol, please let me know as I'd be very interested to hear about your experiences. Also if you're able to get the protocol working on any other ericsson model, please tell me as I would like to make a list of supported models.

• Ericsson A1018S
• Ericsson T28 (Thanks to Sunish Issac)
• Ericsson GH688 (Thanks to Per Jönsson)
• Ericsson GA628 (Thanks to Valery Elkin)

Thanks for reading !

Peter Sandstrom

All content on this website is copyrighted (c) 2002,2003,2004 by Peter Sandstrom / Spaceorbit.Net. All rights reserved. Users may download pages or other content for their own personal use on a single computer, but no part of such content may be otherwise or subsequently reproduced, downloaded, disseminated, or transferred, in any form or by any means, except with the prior written agreement of, and with express attribution to Peter Sandstrom / Spaceorbit.Net. Usage of content on this website for commercial puposes strictly forbidden. Peter Sandstrom / Spaceorbit.Net will not be liable for any damages of any kind arising from the use of this site or the information provided on this site, including, but not limited to direct, indirect, incidental, punitive, and consequential damages.