Bei der Suche nach dem richtigen Funkstandard zur Kommunikation zwischen Arduinos, Raspberrys oder auch "nackten" Mikrocontrollern wie einem ATtiny trifft man auf viele Möglichkeiten. Vom mittlerweile überladenen 433 MHz-Band über das per Gesetz weniger vermüllte 868 MHz-Band bis hin zum etablierten, aber wegen Bluetooth und W-Lan auch schon stark belegten 2,4 GHz-Band ist alles möglich.
Ohne genauer auf die Vor- und Nachteile der einzelnen Standards einzugehen fasse ich hier meine Erfahrungen mit einem Modul für den 2,4 GHz-Funk zusammen: Dem Nordic nRF24L01+ Funkmodul.
Das in der Szene recht weit verbreitete Modul ist über diverse Auktionshäuser sehr kostengünstig zu erwerben (~1,50 € pro Stück). Wem das zu heikel ist, der findet es zu einem höheren Preis auch in deutschen Shops. Die genauen Einzelheiten dieses Moduls findet man zu genüge auf anderen Websiten gelistet, ich beschränke mich hier auf eine kurze Liste:
- 2,4 GHz Basisfrequenz, 125 Kanäle zur "Feinjustierung" zur Auswahl
- 3,3 V Betriebsspannung (hat allerdings scheinbar einen Spannungsregler, 5 V sollten also ebenfalls funktionieren)
- Datenraten von 2 MBPS bis runter auf 250 KBPS. Dabei gilt: Geringere Datenrate bringt größere Reichweite.
- Ansteuerung über SPI
- Transceiver, d.h. ein Gerät für Senden und Empfangen
- AutoAck-Funktion, Ack steht für Acknowledge, d.h. jede gesendete Nachricht wird auf Empfang geprüft. Somit kann sichergestellt werden, dass/ob der Empfänger die Nachricht wirklich empfangen hat. Sehr hilfreiche Funktion!
- Nutzbar mit Arduino, Raspberry Pi und ATtiny
Vor allem die letzte Aussage ist interessant: Ich benutze zum testen und entwickeln von Projekten immer Arduinos, welche ich dann soweit möglich auf ATtinys, am liebsten den ATtiny 84A, runterschraube. Allgemein würde ich die RF24-Library empfehlen. Sie läuft mit Arduino, dem Raspberry unter Verwendung von C/C++ und vor allem auch in Verwendung mit Python. Weiterhin ist es möglich, sie mit dem ATtiny 84A zu nutzen. Bei diesem muss jedoch getrickst werden, um die SPI-Schnittstelle nutzen zu können.
1. RF24 über die Arduino IDE auf einem ATtiny 84A nutzen
Die RF24-Lib lässt sich eigentlich ohne Probleme mit einem ATtiny nutzen (natürlich in Verbindung mit der Arduino IDE und cores für die tinys), das einzige Problem stellt die original SPI-Library dar. Diese SPI-Library kommt nicht mit dem ATtiny-Core klar. Wer
hätte das gedacht. Hier muss etwas korrigiert werden. Dazu sollte man die gesamte IDE schließen.
Nun holt man
sich aus dem Archiv https://github.com/jscrane/SPI die korrigierten Codes und ersetzt damit
die originale SPI-Library. Dann sollte das Kompilieren ohne weiteres funktionieren.
2. RF24 auf dem Raspberry Pi mit C/C++
Hier nutze ich folgendes Archiv: https://github.com/ahuillet/RF24
Auffällig ist, dass in dem entscheidenden Ordner librf24-rpi zwei weitere Ordner lauern. Einer davon ist mit dem Zusatz -bcm benannt, was für den Baustein des Raspberry Pi steht, welcher unter anderem für die GPIO-Pins und damit für SPI verantworlich ist (Broadcom bcm2835). Darin steckt eine Lib, die eigentlich identisch ist zu der ohne bcm. Lediglich die Art und Weise wie die SPI-Schnittstelle angesprochen wird ist anders, genauer unterscheiden sich die libs nur im verwendeten Treiber. Man nennt die bcm-Variante auch Hardware-SPI. Ich empfehle hier für C/C++ erstmal die bcm-Variante zu testen, die hat bei mir super funktioniert.
Gleichzeitig kann man sich auch noch ans Software-SPI heran wagen (also die lib ohne bcm), insbesondere, wenn man später Python statt C/C++ nutzen möchte. Zuvor ist zur Einrichtung des Software-SPI's folgendes Tutorial hilfreich:
http://www.brianhensley.net/2012/07/getting-spi-working-on-raspberry-pi.html
3. RF24 auf dem Raspberry Pi mit Python
Hier empfehle ich folgendes Archiv:
https://github.com/jonathongrigg/RF24/tree/master/raspberrypi/pyRF24
Hat man im vorherigen Schritt die Software-SPI-Variante von RF24 auf dem Pi zum laufen gebracht, lässt sich diese Python-lib direkt installieren. Sie wrappt dabei quasi "nur" die C++ Library. Wichtig ist dabei, dass es sich um eine Lib für Python-Versionen >= 3 handelt!
Ist alles richtig installiert (gemäß der Anleitung auf der Website), lässt sich die lib direkt in Python einbinden und nutzen wie bereits mit dem Arduino.
Ich bin mit dem Autor in Kontakt, unter anderem um die lib auch für den bcm-Treiber fit zu machen und um kleinere Bugs zu fixen. So wird beispielsweise ein 0x00 beim python-seitigen Empfang durch den C-Wrapper fälschlicherweise als das C-typische Abbruchzeichen eines Strings interpretiert und der Rest der Nachricht verschwindet im Äther...Dumm nur, wenn man eigentlich keinen String sondern ein byte-array verschickt hatte und nach der 0x00 noch was kommen sollte...
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
