Datenfunk mit dem AVR: Unterschied zwischen den Versionen

Aus LaborWiki
Wechseln zu: Navigation, Suche
Keine Bearbeitungszusammenfassung
 
(34 dazwischenliegende Versionen von 17 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{ProjektInfoBox
|name=Datenfunk mit dem AVR
|status=unknown
|tags=Microcontroller & FPGAs,
|update=
}}
= Hardware =
= 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.
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://roulette.das-labor.org/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.


= Datenblätter =
== Beispielcode ==
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!
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();
  }


Ein etwas brauchbareres, aber dennoch nicht ganz vollständiges Datenblatt findet sich auf der Herstellerseite: [http://www.hoperf.com/pdf/RF12.pdf|Herstellerseite].
= 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.


= Protokoll =
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.
Damit die verschiedenen Devices auch vernünftig miteinander plaudern können, muss ein Protokoll her.


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).
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.  


== Pakettypen ==
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.
Es gibt verschiedene Pakettypen, einige davon sind ganze Unterprotokolle, andere sind einfach nur Daten. Folgende Pakettypen sind festgeschrieben:


=== 0x00 - Daten ===
[[Rfm12usb|RFM12USB Projektseite]]
Ein einfaches Datenbyte ohne Checksumme oder sonstigen Schnickschnack.


=== 0x01 - Daten + XOR Checksumme ===
= Datenblätter =
Ein Datenpaket, dessen letztes Byte eine XOR Checksumme der anderen Payload Bytes ist.
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!


=== 0x1* - Adressbasierte Protokolle (8bit) ===
Ein etwas brauchbareres, aber dennoch nicht ganz vollständiges [http://www.hoperf.com/upfile/RFM12.pdf Datenblatt] findet sich auf der Herstellerseite.
Die ersten 2 Byte des Payloads sind Quell- und Zieladressen.


  +----+----+----+----+----- ...
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.
  |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.
= Protokoll =
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.


==== Management ====
= Probleme =
===== 0x10, 0x11 Ping & Pong =====
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.
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 =====
Ferner können die Module offenbar nicht die '''Empfangsstärke''' messen oder bzw. ausgeben.
Empfangsbestätigung für ein Paket. Der übrige Payload ist die Sequenznummer.


===== 0x13 Retransmission request =====
Anfrage, ein korruptes Paket nochmals zu senden.


===== 0x14 Nameservice: Who has ...? =====
'''''Fehler im Beispielcode des Herstellers'''''
Dieses Paket dient zur Namensauflösung vollständiger ASCII Namen. Das erste Byte des Payloads gibt an, ob es sich um ein Antwort- oder Request Paket handelt: 0x00 == Request, 0x01 == Reply.


Der folgende Payload ist dann die Anfage, bzw. Antwort.
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...


==== 0x18 - Checksumme + Daten ====
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.
Datenpaket mit Quell- und Zieladresse. Das letzte Byte des Payloads ist die XOR-Checksumme des gesamten Paketes (inkl. type- und len field.)


==== 0x19 - Checksumme + Daten + Seqnum ====
= Verschlüsselung und Authenzität =
Wie 0x18, jedoch mit zusätzlicher 8-Byte 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.


==== 0x1A - Checksumme + Daten + Seqnum - must-ACK ====
= Praxiserfahrung =
Wie 0x19, jedoch muss jedes Paket bestätigt werden.
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]]

Aktuelle Version vom 8. April 2017, 00: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.