Freitag, 19. Juli 2013

ePIR Bewegungsmelder

Der erste Sensor, den ich euch hier genauer vorstelle, ist folgender Bewegungsensor:
Zilog ePIR™  Motion Detection Zdots® SBC

Der Sensor wirbt mit einem integrierten Chip, welcher euch die Daten vorfiltert und so die Fehlalarmrate reduzieren soll. Außerdem könnt ihr den Sensor damit sehr individuell auf eure Bedürfnisse zuschneiden.

Es gibt zwei Möglichkeiten den Sensor mit seinen 8 Pins (davon 1x VCC, 2x GND) anzusteuern:
  • Hardware-Interface: Hier steuert ihr den direkt über Spannungen, die ihr an die GPIO Pins per Spannungsteiler anlegen müsst. Ein weiterer Pin dient als active-LOW Pin, welcher bei erkannter Bewegung auf HIGH wechselt.
  • Serial-Interface: Hier wird der Chip über eine serielle Verbindung angesprochen (UART (*)). Nur in diesem Modus können sämtliche Features des Sensors genutzt werden.
    Besonders erwähnenswert ist hierbei der Extended-Range-Modus, bei welchem der Empfindlichkeitsbereich auf einen 5m x 5m großen Bereich erweitert wird. Da dieser Modus über Hardware-Interface nicht konfigurierbar ist, spricht allein schon diese Reichweitensteigerung gegenüber dem normalen 3m x 3m Bereich für die Nutzung des seriellen Zugangs.
    In diesem Modus wird der aktuelle Status gepollt, d.h. ihr sendet ein Steuerzeichen, woraufhin der Sensor euch antwortet, ob er eine Bewegung registriert hat. Praktisch ist hierbei die Möglichkeit, eine Hold Duration zu setzen. Diese gibt dann an, wie lange der Sensor bei erkannter Bewegung den Alarmstatus aufrecht erhalten soll. Eine Möglichkeit wäre beispielsweise eine Hold Duration von 35s. Hier würde es dann ausreichen, den Sensorstatus nur alle 30s abzufragen.

    Weitere Features sind:
    • Frequency Response Setting, eine Art Unterscheidung zwischen vertikal-orientierten Objekten (Menschen) und horizontal-orientieren Objekten (Haustiere). Aktiviert man diese Option, werden horizontal-orientierte Objekte weniger stark beachtet um Fehlalarm zu vermeiden. Wie gut dieses Feature funktioniert kann ich nicht sagen, sicher ist dass man es für höchste Empfindlichkeit deaktiviert lassen sollte.
    • Pulse Count, kann auf 1 oder 2 gesetzt werden. Gibt die Anzahl der Ereignisse an, welche der Sensor erkennen muss, damit eine Bewegung gemeldet wird. Auch hier gilt, ein Wert von 1 führt zu einer höheren Empfindlichkeit, aber wohl auch zu einer höheren Wahrscheinlichkeit für einen Fehlalarm.
    • Motion Direction, hierbei soll der Sensor die Richtung der Bewegung erkennen (von links nach rechts oder umgekehrt) und eine Sorte von Bewegungen ignorieren können. Auch dieses Feature ist recht nett aber doch sehr speziell, sodass ich es nicht weiter getestet habe.
    • Sensitivity, die wohl wichtigste Einstellung ist die Empfindlichkeit selbst. Diese kann in einem Bereich von 0 (maximale Empfindlichkeit) bis 255 (minimale Empfindlichkeit) geregelt werden. Eine geringere Empfindlichkeit verringert laut Datenblatt auch den räumlichen Empfindlichkeitsbereich. 

Ich selbst teste den Sensor aktuell im Serial-Interface Modus mit einem Raspberry Pi unter Python als Alarmanlage. 


Weiterhin hat sich bereits jemand die Mühe gemacht, den Sensor intensiv zu testen und mit einem weiteren bekannten PIR-Sensor zu vergleichen. Auf jeden Fall einen Blick wert:
http://www.youtube.com/watch?v=xZGYn-oipQc

(*)Damit eure UART-Schnittstelle auch funktioniert, rate ich euch zu folgender Anleitung:
http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port

Mittwoch, 3. Juli 2013

Arduino Micro und der ISP Sketch

Ich persönlich verwende ja den Arduino Micro, allein schon wegen seinem praktischen Breadboard-Format.
Die meisten Beispiele und Howto's werden für den Arduino Uno konzipiert, in 99% der Fälle lassen sich diese aber auch 1:1 auf dem Micro ausführen.

Der ISP Sketch (ArduinoISP), welcher den Arduino in einen ISP verwandelt, zählt leider zu dem einen Prozent, bei welchem eine Anpassung notwendig ist.

Folgende Änderungen sind nötig, um den Sketch auf einem Micro so zum laufen zu bringen, um damit dann auch tatsächlich andere µC's flashen zu können:

  1. Setzen eines Parameters in der Preferences (ggf. neu anlegen):
    build.verbose=true
    upload.verbose=true

    Damit aktiviert ihr ein detailiertes Log!
    Edit: Diese Optionen bekommt ihr auch weniger umständlich über die IDE: Datei -> Einstellungen -> Ausführliche Ausgaben anzeigen während -> Beide Häkchen setzen.
  2. Beim Starten des Upload-Vorgangs wird der Sketch für den eingstellten µC kompiliert, danach per avrdude geflasht. Dank verbose=true wird der avrdude-Befehl in der Konsole geloggt, bei mir sieht das in etwa so aus:
    avrdude -CC:avrdude.conf -v -v -v -v -pattiny84 -carduino -P\\.\COM20 -b19200 -Uflash:w:[...].hex:i
    Hier muss der Programmer (Parameter c bei avrdude) auf arduino gestellt sein:
    -carduino
    Häufige Fehlerquelle ist ein -cstk500v1 o.Ä. an dieser Stelle. Diesen Fehler kann man abstellen, indem man in der boards.txt der Core-Dateien den Paramter upload.using des entsprechenden µC's ändert.
  3. ICSP nutzen! Die ersten paar Kommentarzeilen des ArduinoISP Sketch geben eine Anleitung, in welche man die Pins 10-13 nutzen sollt, um eine Verbindung mit dem µC herzustellen. Dies gilt nicht im Falle des Micro, hier habt ihr eigene Pins für MISO, MOSI und SCK. Diese verbindet man alle mit den entsprechenden Pins des µC. Den RESET-Pin des µC verbindet man mit Pin 10 des Micro und ändert den Sketch, indem man die Zeile
    #define RESET     SS
    ändert in
    #define RESET     10

Genaueres findet man in einem Thread des Arduino Forums: