Datenfunk mit dem AVR
| Datenfunk mit dem AVR Release status: unknown [box doku] | |
|---|---|
| Description | {{{description}}} |
Hardware[Bearbeiten | Quelltext bearbeiten]
Die benutzten Transceiver gibt es bei verschiedenen Herstellern unter dem Namen RFM12 oder RF12. Sie können im 433 Mhz ISM Band und zusätzlich auf Frequenzen in der Umgebung von 315, 868 und 915 MHz funken.
In Deutschland sind die Module bei Pollin zum Preis von 8 Eur erhältlich, allerdings lohnt sich ab einer Menge von 10 oder mehr Modulen eine direkte Bestellung beim Hersteller (Produktseite).
Library für den Atmel[Bearbeiten | Quelltext bearbeiten]
Wir haben eine library für die RFM12 Module gebastelt. Mit ihr lassen sich die Module auf einfache Weise mit dem Microcontroller steuern.
Beispielcode[Bearbeiten | Quelltext bearbeiten]
Im SVN ist Beispielcode (veraltet) hinterlegt, der die Module in Empfangsbereitschaft versetzt und ein empfangenes Byte mit den LEDs des Laborboards anzeigt. Wenn man Button 0 drückt, sendet das Modul.
Zum Betrieb der Module sind im Grunde nur wenige Befehle nötig - hier ein Beispiel:
uint8_t teststring[] = "teststring\r\n";
rfm12_init();
sei();
for(;;)
{
/* ... */
rfm12_tx (sizeof(teststring), 0, teststring);
rfm12_tick();
}
USB Packetsniffer & Debugtool[Bearbeiten | Quelltext bearbeiten]
Derzeit entsteht ein USB Datenlogger- und Sender für die Funkmodule. Vorab gibt es schon einmal den Code im SVN. Das Gerät soll ein Werkzeug werden, um damit leichter die Funkschnittstelle zu debuggen und um ein Interface zwischen Datenfunk und PCs zu bieten.
Wir bedienten uns dabei der selbst geschriebenen RFM Library, sowie der USB library von objective development, die einen Software USB Stack implementiert und so ein USB Lowspeed Device aus gewöhnlichen Microcontrollern macht.
Das Projekt ist noch in der Entwicklungsphase und entsteht zunächst hauptsächlich im SVN. Derzeit entsteht zusätzlich eine GUI für die Hostseite in QT.
Es existiert ein kleiner Treiber für den Host zum Empfangen und Versenden von Paketen. Der Treiber benötigt libusb und sollte unter Windows sowie Linux kompilieren. Das Programm rfmusbcmd ist eine kleine Konsolenanwendung, die die Treiber-API verwendet um empfangene Pakete zu dumpen und um Pakete zu versenden.
Datenblätter[Bearbeiten | Quelltext bearbeiten]
Auf der Pollin Homepage sind unvollständige Datenblätter und nicht funktionierender Beispielcode verzeichnet. Die beigelegte Papierdokumentation ist ebenso unbrauchbar. Von diesen ist ausdrücklich abzuraten!
Ein etwas brauchbareres, aber dennoch nicht ganz vollständiges Datenblatt findet sich auf der Herstellerseite.
Die URL hat sich geändert (wurde in ein Unterverzeichnis verschoben), das Datenblatt RFM12.pdf ist nun HIER zu bekommen.
Protokoll[Bearbeiten | Quelltext bearbeiten]
Die erste Version des Datenaustauschprotokolls hat den Namen AirLAB v0. Es ist ein erste Entwicklung, die zunächst einmal in der Praxis erprobt werden muss.
Probleme[Bearbeiten | Quelltext bearbeiten]
Die Module können scheinbar keine Kollisionen erkennen. Die erste Version des Protokolls arbeitet mit relativ kleinen Paketen (<= 260 Bytes), damit der Ether zum Einen möglichst schnell wieder frei wird und zum Anderen ganz einfach weil die partizipierenden Devices groessere Pakete zumeist garnicht handlen koennten.
Ferner können die Module offenbar nicht die Empfangsstärke messen oder bzw. ausgeben.
Fehler im Beispielcode des Herstellers
Die Zeile "RFXX_WRT_CMD(0xC400);//1.66MHz, 2.2V" (Low Battery Detector and Clock Divider) spricht den falschen Adressbereich an und ueberschreibt die Einstellungen des AFC Command. Richtig ist (0xC000). Trotzdem funktioniert der Beispielcode - so lange man nicht den externen Takt nutzen moechte...
Ueberhaupt sollte man bei den Commands nicht alles glauben, was die Kommentare als Setup vorgaukeln. Es gibt deutliche Abweichungen, unter anderem auch bei besagtem Clock Divider.
Verschlüsselung und Authenzität[Bearbeiten | Quelltext bearbeiten]
Parallel zum Netzwerkstack für die Funkmodule wird auch die AVR-Crypto-Lib entwickelt, welche hash- und verschlüsselungsfunktionen bietet, um den Datenverkehr der Geräte untereinander zu sichern.
Praxiserfahrung[Bearbeiten | Quelltext bearbeiten]
Erste Tests mit zwei mit dem Beispielcode aus dem SVN geflashten Microcontrollern haben gezeigt, das die Module wirklich zuverlässig arbeiten und offenbar relativ unanfällig für Störungen sind. So war es z.B. möglich, mit der Funkfernbedienung für die billigen Baumarktsteckdosen zu senden, während das Empfängermodul Pakete empfing.
Bei einigen hundert gesendeten Paketen gingen natürlich welche verloren (gerade während des Fernbedienungs-Tests), aber offenbar kam nicht eins mit falschen Daten am Empfänger an.