Thursday, April 26, 2012

Interrupt-Driven Alarm on Hold - Polling Instead

BUG REPORTS :

Bug # 1 - Polling instead of Interruptions

After finding a bug in the interrupt-driven alarm mechanism, that has been put on hold while the project progresses. The bug is this - with the basic circuit design, if ANY input is open, opening another one will NOT trigger the interrupt.  In lieu of the interrupt-based concepts, I implemented a simpler design that people would have used defacto - polling. In this case, the loop() function sleeps for 50ms, then manually calls the interrupt function, and continues this way indefinitely. Power savings were merely 10 milliamp (very paltry considering the overall design), and simpler is always better. As a result, it's now a polling-based alarm mechanism, and functions well. Code is available at http://svn.silverhawk.net/files/polling_alarm.ino.

Bug # 2 - DD-WRT Router, Static Lease, and Arduino Static Config

This one isn't a bug with the Arduino, but a bug with the system.  In configuring the network, I used my current Asus device with DD-WRT installed, and configured a static lease.  On the Arduino side, I set the IP address statically (no DHCP).  The problem came about after realizing the Arduino could not talk to the outside world and running some iptables routing commands on the DD-WRT :

iptables -t mangle -A POSTROUTING -d 10.1.1.20 -j ROUTE --tee --gw 10.1.1.100
iptables -t mangle -A PREROUTING -s 10.1.1.20 -j ROUTE --tee --gw 10.1.1.100
The above two lines copied all network traffic to and from 10.1.1.20 to my workstation, 10.1.1.100, and then I slapped Wireshark on there.  I saw internal communication from the Arduino to the alarm server, but as soon as it tried to talk externally, nothing got out.  In fact, the Arduino threw "Who as 10.1.1.1?" ARP messages out to the gateway in order to communicate with it, but the gateway (the DD-WRT) simply ignored the Arduino.

Hmph!  I adjusted the static lease in the DD-WRT, and the thing was instantly communicating to the outside world.  It was live (open a door and my VPS server knew what happened).  Awesome!  So, let's run it with the PoE instead of USB power.....

Bug # 3 - Insufficient Power From PoE Device

After having successful communication to the outside world with everything in place (and the sensors installed in the doors), I tried running the Arduino over the PoE with long cables - and some sensors stopped working (they just reported back as "open").  When using the USB to power the device, it worked flawlessly.  Back to the PoE, and they stopped working again.

Conclusion : put the Arduino where it can be powered using a transformer, preferrably a 12v power source.

Next, I tried installing Linux motion after ZoneMinder failed to give me decent enough performance on the frame rate,  but that had poor performance, too, so I opted to hack some security flood lights that had LED indicators - might as well get dual purpose devices.  I start picking the theories for this apart in Motion Detection via Flood Light, and interfacing that to trigger camera recording, not just events.

2 comments:

  1. Could you please post the rest of the code needed to compile this? And also possibly a schematic of your system? This looks like exactly what I was going to write, but this will save me so much time.

    ReplyDelete
  2. In the post, I had a link to the following code :

    http://www.silverhawk.net/files/polling_alarm.ino

    That will give you the arduino code of things, less of course the configuration file. That configuration is documented in :

    http://blog.silverhawk.net/2012/04/arduino-assembly-and-testing.html

    A server side of things is available at :

    http://www.silverhawk.net/files/c_code_alarm_server.tgz

    The server-side configuration examples are in there. You can make it talk to a Nagios instance (which I have done, but the nagios implementation along with selinux was a nightmare). Or, you can write a simple script from the server-side code that sends a text from a Google Voice account.

    There is no real schematic of the system - but you can find most everything (including trying an interrupt-driven method that failed) with the global post :

    http://blog.silverhawk.net/2012/04/introducing-project-homebrew-security.html

    Just make sure the keys match in the ardunio configuration and the alarm server configuration, and that a firewall doesn't prevent network traffic.

    ReplyDelete