Selbst organiserendes Funknetz auf Basis der RFM12-Module

Aus ComputerClub2 WIKI

Hardware

Folgende Verbindungen werden außer VCC und GND für den Anschluss des RFM12 benötig:

SDO<->MISO 
SDI<->MOSI
SCK<->SCK
nIRQ<->PD3 (INT1)
nSEL<->PB0 (Kann per Konfiguration geändert werden)

Software

Die Kommunikation zwischen Knoten erfolgt über ein Subset des SNAP-Protokolls. Ein Frame kann jeweils 0-8 Datenbytes übertragen. Die Übertragung wird mit CRC8 abgesichert. Die Knotenadressen sind ein Byte lang, erlaubt sind die Werte 0x01-0xFE, es gibt also maximal 254 mögliche Knotenadressen. Wie viele Knoten es wirklich sein können, hängt von den Kapazitäten (RAM) des Supervisors ab, der die Adressen verwalten muss. In der Praxis ist das aber wahrscheinlich keine Einschränkung, da die Übertragungskapazität des Netzes nicht sonderlich hoch ist. Mehr als 16 Knoten wird man da kaum betreiben wollen.

Es gibt genau einen Supervisor im Netz, der die Adresse 0x01 hat. Adresse 0x00 ist die Broadcastadresse, mit der man alle Knoten anspricht. 0xFF ist eine temporäre Adresse, die ein Knoten nach dem Einschalten hat. Er muss sich dann erst einmal eine eindeutige Adresse vom Supervisor holen. Der Supervisor speichert, welche Adressen vergeben sind und welcher Gerätetyp sich dahinter verbirgt. In vielen Fällen wird man diesen mit einem PC verbinden, so dass von dort die Clients gesteuert werden können. Denkbar ist sowohl die Verwendung eines dedizierten Knotens als Supervisor als auch die Möglichkeit eines Ad-Hoc-Netzwerkes, wo sich ein Client spontan selbst zum Supervisor erklären kann, wenn er keinen im Netz findet.

Ein Kommunikation könnte dann so aussehen:

0xFF an 0x01: Ich bin ein Gerät vom Typ 0x12 (Temperatursensor), sende mindestens alle 600 Sekunden einmal und brauche eine Adresse
0x01 an 0xFF: Willkommen im Netz. Deine Adresse ist 0x0F
0x0F an 0x01: Gibt es im Netz einen Knoten vom Typ 0x10 (Temperaturanzeige)?
0x01 an 0x0F: Knoten 0x0C ist ein Typ 0x10
0x0F an 0x0C: Ich bin ein Gerät vom Typ 0x12 und mein Messwert ist 22.4°C. Bitte Übertragung bestätigen.
0x0C an 0x0F: ACK[/quote]

Alternativ wäre auch folgendes möglich:

0xFF an 0x01: Ich bin ein Gerät vom Typ 0x12, sende mindestens alle 600 Sekunden einmal und brauche eine Adresse
0x01 an 0xFF: Willkommen im Netz. Deine Adresse ist 0x0F
0x0F an 0x00: (Nachricht an alle) Ich bin ein Gerät vom Typ 0x12 und mein Messwert ist 22.4°C

Wer im Netz auch immer etwas damit anfangen kann, darf das tun. Das ist bei manchen Anwendungen praktischer, allerdings erhöht das die Belastung aller Knoten, weil die ja immer erst überprüfen müssen, ob sie die Nachricht verstehen.

Eine Bestätigung (ACK/NAK) wird nur auf Anforderung versendet, bei Broadcast-Sendungen jedoch nie.

Was die Typen 0x12 und 0x10 genau sind, braucht der Supervisor gar nicht zu wissen. Er vermittelt ja nur die Knoten aneinander. Der Supervisor überwacht zudem den Funkverkehr. Wenn Knoten 0x0F 2*600=1200 Sekunden lang nichts gesendet hat, z.B. weil er abgeschaltet wurde, fragt der Supervisor bei ihm an, ob er noch da ist:

0x01 an 0x0F: Bist du noch da?
(Keine Antwort)

Der Supervisor trägt dann in seiner Tabelle ein, dass die Adresse 0x0F wieder frei ist.

Kann ein Knoten mit einer Nachricht nichts anfangen, verwirft er sie, beziehungsweise sendet ein NAK, wenn für diesen Fall eine Antwort angefordert wurde.

Jeder Knoten versteht die Nachricht "NETWORK RESET", nach der er alle Informationen über seine P2P-Partner verwirft, selbst kein Supervisor mehr ist und sich nach einer zufällig gewählten Zeit eine neue Adresse holt. Damit kann man ein Netzwerk neu aufbauen, wenn es durcheinander geraten sein sollte.

Realisierung

Die Kommunikation selbst soll per Interrupt im Hintergrund ablaufen. Dazu müssen VCC, GND, SDO, SDI, SCK, nSEL und nIRQ des RFM-Moduls verdrahtet werden. Bei meinem Hardwaredesign habe ich dafür schon einen erweiterten, 10-poligen ISP-Anschluss integriert. Die Kommunikation übernimmt die Hardware-SPI-Schnittstelle, die ebenfalls Interrupt-gesteuert abläuft. Zumindest dieses Modul ist schon fertig. Im Mainloop müsste zusätzlich regelmäßig eine Funktion aufgerufen werden, die die Kommunikation auswertet. Das wäre für eine ISR zu aufwändig. Eine Funktion wird die Standardnachrichten bearbeiten (Vergabe von Netzadressen etc), so dass man nur noch Nachrichten bearbeiten muss, mit denen diese nichts anfangen kann. Es wird Funktionen geben, mit denen man auf den Inhalt des Frames zugreifen kann (Zielknoten, Sendeknoten, Prüfsumme in Ordnung, Zugriff auf Daten) sowie Standardaufgaben (Sendeframe erstellen, ACK/NAK-Senden). Innerhalb des Main-Loops muss regelmäßig eine Funktion aufgerufen werden, damit eventuell empfangene Daten ausgewertet werden können. ("Kooperatives Multitasking") Grob könnte das dann so aussehen:

while(1)
 {
    // Tue irgendetwas

    if(0xFF == snap_my_id) net_request_id();      // Noch keine Adresse erhalten?
          
    if(snap_frame_complete())                     // Gibt es einen neuen Frame?
     {
       if(net_eval_frame() == NET_FRAME_UNDONE)  // Keine Standardnachricht
         {
           if(snap_get_dest_id() == snap_my_id)     // Bin ich gemeint?
             {
                // Nachricht irgendwie auswerten
             }
         }
        snap_drop_frame();                     // Frame aus dem Speicher entfernen
     }

    // Tue was irgendetwas anderes
 }

Der Protokoll-Stack hat insgesamt vier Ebenen, die aufeinander aufbauen.

• SPI ist die Hardware-Anbindung des RFM-Moduls. Sie verwendet die Hardware-SPI-Schnittstelle des Mikrocontrollers und arbeitet interrupt-gesteuert im Hintergrund.
• RFM steuert die RFM-Hardware. Damit kann man das Modul initialisieren, von Empfangs- auf Sendebetrieb umstellen und mehrere Bytes versenden und empfangen. Senden und Empfang erfolgt ebenfalls interruptgesteuert im Hintergrund.
• SNAP ist ein Subset des "Scaleable Node Address Protocol" (SNAP). Dieses definiert Daten-Frames, Knotenadressen und die Absicherung der Übertragung mittels CRC.
• NET definiert die Verteilung der Knotenadressen durch einen Supervisor (so etwas ähnliches wie ein DHCP-Server im IP-Netz). Der Supervisor stellt zudem eine Yellow-Page-Funktion bereit, mit der einzelne Knoten die Adresse des Zielpartners erfahren können (z.B. ein Temeperatursensor die Adresse einer Temperaturanzeige). Ein Knoten kann sich dabei selbst zum Supervisor erklären, wenn er keinen findet, so dass sich ein Netz ad Hoc aufbauen könnte.

--DetlevT 19:52, 17. Jan. 2009 (CET)