Car security. 2019-03-21

New cars are often delivered without any alarm installed. And the user does not really want to install an aftermarket because it's expensive and you probably will need to cut wires etc. 

Therefore, I wanted to design a simple alarm that is very easy to install. Of course, easy to install is hard to combine with bulletproof design but with some well thought through compromises I designed an alarm that is.

-Easy to install. Connected to OBD connector, no additional connections

-Detects shock/impact to any part of the car

-Measures battery voltage to control the alarm, neg voltage transients when unlocking doors and higher voltage levels when engine started.

-GSM enabled

There are to ways to detect the battery voltage. One is by reading ADC channel 1, this is used to detect if the engine is started Vbat>14V. The alarm module is not active if engine is on. Also, low battery voltage is detected by the ADC. 

I did a lot of measurements of the battery voltage when unlocking the car and the pic above shows that the voltage level drops with 800mV when doors are unlocked. Great but this is under a very short period, 10us. 

I tried to catch this with the ADC, but the ADC need around 4ms to complete a reading. The built- in comparator module was fast enough to handle this fast transient.

Every time this pulse is detected the software goes into a delay loop for 10min so driver can enter the car without triggering the alarm.

Detecting impact to the car is done by ADXL345 accelerometer. It communicates with the MCU through I2C which is used for setting up the chip but also for resetting it after it has been trigged. The ADXL345 is configured to detect a single tap, when this occurs a logic output pin goes high which is sensed by the MCU. Then a I2C reset command is sent to the ADXL345 chip.

I did a lot of sniffing the I2C bus to the accellerometer chip both to control what I'm sending to the ADXL345 chip, and what the chip responds. I also did a lot of trouble shooting when trying to identify the I2C restart issue

Without having a proper logic analyzer it's impossible to sort out any issues in this kind of signals. I bought a cheap eBay analazyer which did not work well at all. I decided then after Googling to try the Logic 8 analyzer from https://www.saleae.com .

It's their smallest model but it worked great instantly without any time lost trying the get it work. The biggest benefit is that it just works without any issues and on everything. The days and hours one save on using Saleae instead of some weird clone is worth every cent of their "high" purchase price.

Below is the communication between the MCU and the ADXL345 sniffed and decoded by the Logic 8. The analyzer shows also a real good picture of the signals but for this purpose the actual writings are more of interest.

Pic 16LF1937 has all modules and can be clocked up to 32MHz, which is well suited for this project. Although the code runs on 16MHz. It's required to be fast enough to catch the unlock pulse. I put a lot of effort by solving this by a interrupt trigged by the comparator but it was triggering in a way that was unpredictable, and I didn't find any solution. I dropped the interrupt idea and wrote the code to be fast enough instead. It uses a counter 0-10000, the voltage transient is checked every cycle while the ADC readings are done 1/10000. Basically, it could miss one unlock transient but it's really low risk.

During development I had one big issue with the pic reset/restarted randomly. That was what I believed initially at least. After a lot of testing I found out that sometimes when the output from accelerometer was trigged and detected by the MCU, it should send the reset command through I2C, but it did sometimes reset. Originally, I used 18F4685 but due to not finding any solution to the restart problem I decided to go with 16f1937. Changing the MCU solved the problem I thought.

Built one more fully assembled unit with the 16F MCU and the restart problem was back. So, I had one unit fully working with the new MCU and unit with restart issue and new MCU. I put a lot of work into solving the issue but could not find the root cause unfortunately. First, I had enabled the i2c module in the chip and thought it woul be a good idea to try the software I2C routines instead and see if that would make any difference, but it didn't.

I got a lot of help from forums on what I could test, but nothing pointed to any root cause and no solution was found. At the end my conclusion was that it might be some timing error that occurs sometimes when the I2C reset command is sent and that will hang the entire routine which will result in main program not executing.

Finally, I wrote some additional code that kept track if reset had occurred or not and then force the whole program into "normal" behavior. Sad to not find the real cause but I felt that I had tried everything. The alarm works well but the code fix is not the best solution!

Since then I have used I2C in several much more demanding projects without any issues more that writing correct commands to correct registers.

Two working units are mounted in a Mercedes C class and one in an old Opel Vectra. The alarm module works perfect in the Opel but in the Mercedes, it is very hard to trigger the alarm. The Mercedes is a much more stable car and trying to shake it will not trigger the accelerometer, maybe if something crashes into it or somebody takes a big rock and throws at the car it will trigger but that's kind of hard to test :)

In future I might make a new version of the alarm equipped with a mechanical shock sensor such as the 801S instead of the ADXL345 and that way make it more sensitive (and cheaper).