Aktuelle Version vom 8. April 2017, 01:23 Uhr

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]

USB Datenlogger Prototyp

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.

RFM12USB Projektseite

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.

@@ Zeile 1: / Zeile 1: @@
+{{ProjektInfoBox
+|name=Datenfunk mit dem AVR
+|status=unknown
+|tags=Microcontroller & FPGAs,
+|update=
+}}
 = Hardware =
 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 ([http://www.hoperf.com/doce/pro/RF12.html|Produktseite]).
+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 ([http://www.hoperf.com/pro/RF12.html Produktseite]).
-= Beispielcode =
+= Library für den Atmel =
-Im [[Subversion|SVN]] ist Beispielcode [https://10.0.5.2/trac/browser/microcontroller/src-atmel/lib/rfmxx|Beispielcode] hinterlegt, der die Module in Empfangsbereitschaft versetzt und ein empfangenes Byte mit den LEDs des [[Laborboard]]s anzeigt. Wenn man Button 0 drückt, sendet das Modul.
+Wir haben eine [[RFM12_Library|library]] für die RFM12 Module gebastelt. Mit ihr lassen sich die Module auf einfache Weise mit dem Microcontroller steuern.
+== Beispielcode ==
+Im [[Subversion|SVN]] ist [http://www.das-labor.org/LaborLibTrac/browser/rfm12/oldstable/test Beispielcode] (veraltet) hinterlegt, der die Module in Empfangsbereitschaft versetzt und ein empfangenes Byte mit den LEDs des [[Laborboard]]s 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 =
+[[Bild:USB to RFM12.jpg|thumb|300px|right|USB Datenlogger Prototyp]]
+Derzeit entsteht ein USB Datenlogger- und Sender für die Funkmodule. Vorab gibt es schon einmal den Code im [http://www.das-labor.org/trac/browser/microcontroller/src-atmel/rfm12/rfm12usb 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 [http://www.obdev.at/products/vusb/ 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 [http://www.das-labor.org/trac/browser/microcontroller/src-atmel/rfm12/rfm12usb/host/CDriver 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 [http://www.das-labor.org/trac/browser/microcontroller/src-atmel/rfm12/rfm12usb/trunk/host/rfmusbcmd rfmusbcmd] ist eine kleine Konsolenanwendung, die die Treiber-API verwendet um empfangene Pakete zu dumpen und um Pakete zu versenden.
+[[Rfm12usb|RFM12USB Projektseite]]
 = Datenblätter =
 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: [http://www.hoperf.com/pdf/RF12.pdf|Herstellerseite].
+Ein etwas brauchbareres, aber dennoch nicht ganz vollständiges [http://www.hoperf.com/upfile/RFM12.pdf Datenblatt] findet sich auf der Herstellerseite.
+Die URL hat sich geändert (wurde in ein Unterverzeichnis verschoben), das Datenblatt RFM12.pdf ist nun [http://www.hoperf.com/upload/rf/RFM12.pdf HIER] zu bekommen.
 = Protokoll =
-Damit die verschiedenen Devices auch vernünftig miteinander plaudern können, muss ein Protokoll her.
+Die erste Version des Datenaustauschprotokolls hat den Namen [[AirLAB_Protokoll_Version_0|AirLAB v0]]. Es ist ein erste Entwicklung, die zunächst einmal in der Praxis erprobt werden muss.
-Das Protokoll ist so simpel wie möglich: Zwei Bytes am Anfang eines jeden Datenpaketes stehen für Typ und Länge des Paketes. Der Pakettyp gibt (wer hätte das gedacht?) an, um welche Art von Paket es sich handelt. Das zweite byte gibt die Länge des Payloads an (in Bytes).
-== Pakettypen ==
-Es gibt verschiedene Pakettypen, einige davon sind ganze Unterprotokolle, andere sind einfach nur Daten. Folgende Pakettypen sind festgeschrieben:
-=== 0x00 - Daten ===
+= Probleme =
-Ein einfaches Datenbyte ohne Checksumme oder sonstigen Schnickschnack.
+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.
-=== 0x01 - Daten + XOR Checksumme ===
+Ferner können die Module offenbar nicht die '''Empfangsstärke''' messen oder bzw. ausgeben.
-Ein Datenpaket, dessen letztes Byte eine XOR Checksumme der anderen Payload Bytes ist.
-=== 0x1* - Adressbasierte Protokolle (8bit) ===
-Die ersten 2 Byte des Payloads sind Quell- und Zieladressen.
-  +----+----+----+----+----- ...
+'''''Fehler im Beispielcode des Herstellers'''''
-  |0x0*|len |src |tgt | payload
-  +----+----+----+----+----- ...
-Die Adressaushandlung erfolgt via Ping. Ein neu gebooteter client gibt sich zunächst die Adresse 0x00 und sendet min. 10 Pakete an die Wunschadresse. Wenn keine Antwort kommt, nimmt sich der client die Adresse.
+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...
-==== Management ====
+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.
-===== 0x10, 0x11 Ping & Pong =====
-Das erste Byte des Payloads gibt an, ob es sich um ein Ping oder Pong Paket handelt. 0x00 ist ein Ping, 0x01 ist ein Pong. Der Rest des Payloads wird einfach in das Antwortpaket kopiert.
-===== 0x12 Ack =====
+= Verschlüsselung und Authenzität =
-Empfangsbestätigung für ein Paket. Der übrige Payload ist die Sequenznummer.
+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.
-==== 0x11 - Checksumme + Daten ====
+= Praxiserfahrung =
-Datenpaket mit Quell- und Zieladresse. Das letzte Byte des Payloads ist die XOR-Checksumme des gesamten Paketes (inkl. type- und len field.)
+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.
-=== 0xE* - Experimentierecke ===
+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.
-Diese Protokolltypen sind zum experimentieren gedacht.
-=== 0xF* - Reserviert ===
+[[Kategorie:Microcontroller]]
-Reserviert für Erweiterungen oder für den Tag, an dem uns die Protokolltypen ausgehen.
+[[Kategorie:Datenfunk mit dem Microcontroller]]

Datenfunk mit dem AVR: Unterschied zwischen den Versionen