Unterschiede im MAC Layer

Die Protokolle sind zwar ähnlich aber im Detail doch sehr unterschiedlich, was das Reengineering nicht gerade einfach macht.

IEEE 802.15.4 MAC Layer Frame:

IEEE 802.15.4 Pakete sind im Little Endian Format. (HIGH Byte wird vor dem LOW Bate gesendet). Jedes Byte wird mit LSB zuerst gesendet.

  |  FCF  |Seq No|  Addressing |         Data          |  FCS  |
  |2 bytes|1 byte|0 to 20 bytes|Length-(Overhead) bytes|2 Bytes|
 

Hier findet man neben dem 2 Byte Frame Control Field (FCF) noch einen 1 Byte Frame Counter.

Roomba MAC Layer Frame:

  |  FCF  Seq No |  Addressing |         Data          |  FCS  |
  |2 bytes       |0 to xx bytes|Length-(Overhead) bytes|2 Bytes|
 

Beim Roomba Protokoll gibt es nur den kombinierten 2 Byte Frame Header / Frame Counter.

Wenn man nun mit Wireshark oder einem anderen Paket-Sniffer die Roomba Frames encoden möchte, erhält man lauter ‘unknown frame types’ und ‘invalid address mode’ Fehlermeldungen. Man müßte seinen eigenen Dissector für Wireshark schreiben oder das frame encoding abschalten.

Frame Checksumme FCS

Zum Glück wird bei beiden MAC layer das selbe Format für die Frame Checksumme (FCS) verwendet. In den Wireshark Quellen findet man die genauen Parameter und den Algorythmus zur Checksummen Erzeugung.

   CRC16 is calculated using the x^16 + x^12 + x^5 + 1 polynomial
   as specified by ITU-T, and is calculated over the IEEE 802.15.4
   packet (excluding the FCS) as transmitted over the air. Note,
   that because the least significan bits are transmitted first, this
   will require reversing the bit-order in each byte. Also, unlike
   most CRC algorithms, IEEE 802.15.4 uses an initial and final value
   of 0x0000, instead of 0xffff (which is used by the CCITT).

Klingt kompliziert, aber es ist lösbar. Mein C# Sniffer kann inzwischen auch die Checksumme erzeugen. Damit steht dem Erzeugen/Senden eigener Frames eigentlich nichts mehr im Wege.

Fazit

Mit den neuen Erkenntnissen und vor allem mit der Checksummen Erzeugung ist es nun möglich eigene Frames zu erzeugen und zu senden. Vorest als Notlösung auf PC Seite. Später ist es sicher besser, die ganze MAC Schicht auf dem Jackdaw Board laufen zu lassen und zum PC nur auf der Applikationsebene zu kommunizieren.

Weblinks

• IEEE 802.15.x Standards
• Wireshark
• Wireshark Sourcecode
• RoombaRFCtrl Sourcecode (GitHub)
• Pcap.Net Library

SCI / OI Schnittstelle

Wie schon die älteren Modelle, besitzen auch die aktuellen Modelle der Roomba 500 Reihe eine serielle Schnittstelle über die man den Roomba fernsteuern kann, oder seine Sensorwerte abfragen kann. Die sogenannte SCI Schnittstelle ist gut dokumentiert und erhielt mit Einführung der 500 Reihe auch ein Update mit erweiterten Befehlen, die Schnittstelle erhielt auch einen neuen Namen und heißt jetzt OI (Open Interface). Zudem besitzen die Roomba 5xx Modelle viel mehr Sensoren als die Vorgängerversionen.

Leider währte meine Freude nicht sehr lange, da mir beim Anschluss eines Controller Boards ein kleiner Fehler mit fatalen Folgen unterlief. Blind vertrauend auf den Aufdruck auf dem Controller Board vertauschte ich RX mit TX und damit war es um die Roomba Schnittstelle und den Controller geschehen. Zwar funktioniert der Roomba weiterhin problemlos, aber die SCI Schnittstelle läßt sich nun nicht mehr nutzen.

IEEE 802.11.4 2.4GHz Schnittstelle

Die Modelle ab dem Roomba 560 aufwärts besitzen neben dem seriellen Interface auch eine Drahtlos Schnittstelle im 2.4GHz Bereich. Damit kommuniziert der Roomba mit den neuen Virtual Wall/Lighthouse Modulen (kurz VWLH) und einer drahtlosen Fernbedienung, dem Wireless Control Center (kurz WCC). Über diese Schnittstelle ist leider wenig bekannt, es gibt keinerlei Doku dazu, lediglich die Eckdaten sind bekannt.

• 2.4GHz IEEE 802.15.4 Transceiver
• nicht ZigBee kompatibles, proprietäres Protokoll
• Freescale MC13202 2.4GHz RF transceiver

Nach dem Lesen dieses robotreviews Threads, kam ich dann auf die Idee mich näher mit dem RF Protokoll des Roomba zu befassen und die in dem Thread begonnene Arbeit fortzusetzen.

verwendete Hard- und Software

Da ich auch ein bisher ungenutztes RZRAVEN Bord herumliegen hatte, war auch die nötige Hardware vorhanden, um das Roomba RF Protokoll zu erforschen.
Die Software-Tools des RZRAVEN Boards funktionierten leider nicht so wie ich das gerne mochte, deshalb wurde die Firmware des RZRAVEN Board mit der Jackdaw Firmware aus dem Contiki Projekt ersetzt. Man benötigt nicht das komplette Contiki Paket, es genügt das Contiki Raven Paket. Somit wurde aus dem Raben (Raven) eine Dohle (Jackdaw) und damit funktioniert bisher alles wunderbar. Man kann damit sogar Wireshark für das Packet Capturing verwenden.
Der Trick dabei ist, das die Jackdaw Firmware die 802.15.4 Pakete in einem Ethernet-Frame einbindet. Mit den Jackdaw Treiber erscheint das Board unter Windows zum einen als Netzwerk-Gerät und als USB-Gerät für die serielle Konfiguration (zum auswählen des Kanals, dem Sniffer Mode, etc.).

Leider wird zum Umprogrammieren des RZRAVEN boards ein JTAG Programmer benötigt, d.h. man benötigt einen JTAG ICE Mk II, einen AVR ONE! oder ein Dragon Board.

Diese derzeitige Lösung ist sicher nicht für jedermann geeignet. Das RZRAVEN Kit ist nicht gerade billig (105€ bei Watterott) und zudem ist ein JTAG Programmer erforderlich. Vielleicht ergibt sich ein Weg, das Transceiver Modul aus der WCC oder einem VWLH auszulöten und über einen anderen Controller (z.B. einem Arduino) anzusteuern. Die Schnittstelle ist ein einfaches SPI Interface. Eine Firmware gibt es im Transceiver auch nicht, der ist relativ dumm. Eine andere Möglichkeit wären vielleicht die XBee Module von Digi. Diese verwenden wohl den gleichen Freescale Transceiver. Allerdings arbeiten die XBees im ZigBee Mode.

Erste Untersuchungen

Hier ist mein derzeitiger Stand der Forschung über das Roomba RF-Protokoll:

Begonnen wurde damit, bei jedem Gerät einzeln die Batterien einzulegen und die rohen IEEE 802.15.4 Pakete mit Wireshark aufzuzeichnen.

Roomba auf Kanal 15:

   No.     Time      Data
      1 0.000000   17 00 ff ff 00 05 00 01 10 f7 02
      2 0.420558   17 10 ff ff 00 05 00 01 10 8f 59
      3 1.488229   17 00 ff ff fc 00 01 16 76 43
      4 2.188864   17 10 ff ff fc 00 01 16 bf f6
      5 2.971726   17 20 ff ff fc 00 01 16 f5 20
      6 3.754072   17 30 ff ff fc 00 01 16 3c 95
      7 4.537940   17 40 ff ff fc 00 01 16 70 84
      8 5.320669   17 50 ff ff fc 00 01 16 b9 31
      9 6.103414   17 60 ff ff fc 00 01 16 f3 e7
     10 6.885647   17 70 ff ff fc 00 01 16 3a 52
     11 7.669509   17 80 ff ff fc 00 01 16 6b c5
     12 8.451608   17 90 ff ff fc 00 01 16 a2 70
     13 9.235353   17 a0 ff ff fc 00 01 16 e8 a6
     14 10.017840  17 b0 ff ff fc 00 01 16 21 13
     15 10.801700  17 c0 ff ff fc 00 01 16 6d 02
     16 11.584420  17 d0 ff ff fc 00 01 16 a4 b7
     17 12.366922  17 e0 ff ff fc 00 01 16 ee 61
     18 13.149155  17 f0 ff ff fc 00 01 16 27 d4

Die ersten beiden Frames werden nur nach Einlegen des Batteriepacks eingelegt, ansonsten werden immer nur die folgenden 16 Frames stetig wiederholt.

WCC auf Kanal 15:

   No.     Time      Data
      1 0.000000   17 00 14 c4 00 11 00 01 10 55 0d
      2 0.357063   17 10 14 c4 00 11 00 01 10 2d 56
      3 2.254351   17 00 14 c4 00 11 00 01 10 55 0d
      4 2.610909   17 10 14 c4 00 11 00 01 10 2d 56
      5 4.509101   17 00 14 c4 00 11 00 01 10 55 0d
      6 4.866875   17 10 14 c4 00 11 00 01 10 2d 56
      7 6.764044   17 00 14 c4 00 11 00 01 10 55 0d
      8 7.121856   17 10 14 c4 00 11 00 01 10 2d 56

Im Unterschied zu Roomba und VWLH ändert sich der Frame counter nur zwischen 0 und 1. Alle 2 Sekunden werden die beiden Pakete wiederholt.

VWLH auf Kanal 15:

   No.     Time      Data
      1 0.000000   17 00 ff ff 00 07 b8 01 10 01 77
      2 0.359804   17 10 ff ff 00 07 b8 01 10 79 2c
      3 4.113874   17 20 ff ff 00 07 b8 01 10 f1 c1
      4 4.478571   17 30 ff ff 00 07 b8 01 10 89 9a
      5 8.233644   17 40 ff ff 00 07 b8 01 10 f0 12
      6 8.599708   17 50 ff ff 00 07 b8 01 10 88 49
      7 12.355781  17 60 ff ff 00 07 b8 01 10 00 a4
      8 12.722344  17 70 ff ff 00 07 b8 01 10 78 ff
      9 16.478553  17 80 ff ff 00 07 b8 01 10 e3 bc
     10 16.844117  17 90 ff ff 00 07 b8 01 10 9b e7
     11 20.597685  17 a0 ff ff 00 07 b8 01 10 13 0a
     12 20.963336  17 b0 ff ff 00 07 b8 01 10 6b 51
     13 24.719456  17 c0 ff ff 00 07 b8 01 10 12 d9
     14 25.086514  17 d0 ff ff 00 07 b8 01 10 6a 82
     15 28.842096  17 e0 ff ff 00 07 b8 01 10 e2 6f
     16 29.207154  17 f0 ff ff 00 07 b8 01 10 9a 34

Beim VWLH werden jeweils 2 Pakete alle 4 Sekunden gesendet. Der Frame counter zählt wie beim Roomba von 0 bis F.

Alle Messages sehen ziemlich ähnlich aus, beginnend mit 0×17 (wie fast jedes Paket). Das HIGH Nibble des folgenden Bytes wird mit jedem Paket inkrementiert, ich denke es ist ein Frame counter. Das LOW Nibble ist wohl der Message Typ, in diesem Fall 0. Die nächsten 2 Bytes könnte ein 16-Bit-Adresse. Roomba und VWLH verwendet 0xFFFF als Adresse, das ist demnach eine Broadcast-Adresse. Nur das WCC liefert eine andere Adresse, 0x14C4 in diesem Fall. Der Rest der Nachricht ist so weit unbekannt, mit Ausnahme der letzten 2 Bytes, der CRC-Prüfsumme für das Paket.

Pairing Roomba mit WCC auf Kanal 15:

   No.     Time      Data
      1 0.000000   17 00 ff ff 00 05 00 01 10 f7 02
      2 0.420800   17 10 ff ff 00 05 00 01 10 8f 59
      3 1.487354   17 00 ff ff fc 00 01 16 76 43
      4 2.188480   17 10 ff ff fc 00 01 16 bf f6
      5 2.970842   17 20 ff ff fc 00 01 16 f5 20
      6 3.753079   17 30 ff ff fc 00 01 16 3c 95
      7 4.536435   17 40 ff ff fc 00 01 16 70 84
      8 5.320184   17 50 ff ff fc 00 01 16 b9 31
      9 5.333627   17 00 14 c4 00 11 00 01 17 ea 79
     10 6.171521   17 10 14 c4 00 11 00 01 10 2d 56
     11 6.528450   17 20 14 c4 00 11 00 01 10 a5 bb
     12 6.544792   17 00 ff ff fc 00 01 11 14 c4 0f 01 e6 82

Die Frames 1 bis 8 kennt man bereits vom ‘Roomba auf Kanal 15′ capture. Die nächsten 3 Frames stammen vom WCC. Ein kleiner Unterschied ist die letzte Date im Frame 9 (0×17 anstelle de 0×10). Dann folgt als letzter Frame wieder eine Antwort vom Roomba, länger als die bisherigen Pakete. Zudem erscheint die WCC Adresse 0x14c4 in diesem Antwort Paket. Das ist wohl die eigentliche Pairing complete Message. Danach ist auf Kanal 15 Sendepause. Der weitere Datenverkehr findet nun auf Kanal 26 statt.

Datenverkehr Roomba / WCC auf Kanal 26:

   No.     Time      Data
      1 0.000000   17 02 14 c4 fc 00 48 15 23 eb
      2 0.720154   17 12 14 c4 fc 00 48 15 ea 5e
      3 24.349287  17 12 14 c4 fc 00 48 15 ea 5e
      5 25.789405  17 22 14 c4 fc 00 48 15 a0 88
      6 25.804986  17 01 14 c4 10 11 00 01 20 29 09
      7 25.810707  17 01 14 c4 10 11 00 01 20 29 09
      8 25.817085  17 01 14 c4 10 11 00 01 20 29 09
      9 25.822579  17 01 14 c4 10 11 00 01 20 29 09
     10 25.828787  17 01 14 c4 10 11 00 01 20 29 09
     11 25.843207  17 11 14 c4 10 11 00 01 20 51 52
     12 25.849459  17 11 14 c4 10 11 00 01 20 51 52
     13 25.854948  17 11 14 c4 10 11 00 01 20 51 52
     14 25.861073  17 11 14 c4 10 11 00 01 20 51 52
     15 25.868092  17 11 14 c4 10 11 00 01 20 51 52
     16 25.880333  17 21 14 c4 00 11 00 01 30 0a 88 33
     17 25.881948  17 24 bf bf
     18 25.892321  17 31 14 c4 00 11 00 14 02 00 00 b1 b9
     19 25.894274  17 34 3e af
     20 25.903341  17 41 14 c4 00 11 00 14 02 00 00 2d 96
     21 25.905069  17 44 b9 dc
     22 25.915725  17 51 14 c4 00 11 00 14 02 00 00 7f 44
     23 25.917568  17 54 38 cc
     24 25.924315  17 21 14 c4 10 00 17 41 0a 0a 8a 0a 00 00 53 ad
     25 25.925691  17 24 bf bf
     26 25.928831  17 61 14 c4 00 11 00 14 02 00 00 98 3a
     27 25.930092  17 64 bb fd
     28 25.941191  17 71 14 c4 00 11 00 14 02 00 00 ca e8
     29 25.942873  17 74 3a ed
     30 25.953745  17 81 14 c4 00 11 00 14 02 00 00 a0 65
     31 25.955264  17 84 b5 1a
     32 25.965316  17 91 14 c4 00 11 00 14 02 00 00 f2 b7
     33 25.966801  17 94 34 0a
     34 26.509151  17 32 14 c4 fc 00 14 14 b7 56
     35 26.512332  17 a1 14 c4 00 11 00 14 02 00 00 15 c9
     36 26.513828  17 a4 b7 3b
     37 26.520839  17 b1 14 c4 00 11 00 14 02 00 00 47 1b
     38 26.522708  17 b4 36 2b
     39 26.532451  17 c1 14 c4 00 11 00 14 02 00 00 db 34
     40 26.534199  17 c4 b1 58
     41 26.545332  17 d1 14 c4 00 11 00 14 02 00 00 89 e6
     42 26.547079  17 d4 30 48
     43 26.556988  17 e1 14 c4 00 11 00 14 02 00 00 6e 98
     44 26.558448  17 e4 b3 79
     45 26.569661  17 f1 14 c4 00 11 00 14 02 00 00 3c 4a
     46 26.571201  17 f4 32 69

Es gibt wesentlich mehr Traffic auf diesem Kanal nach erfolreichem Pairing. Im Gegensatz zu den Nachrichten auf Kanal 15 gibt es hier andere Message Typen (Low Nibble des 2. Byte, 0 bei Kanal 15, hier 1,2 und 4).
Der Frame counter wird in Abhängigkeit des Message Typs inkrementiert (siehe Frame 34).
Ebenso enthalten die meisten Pakete die WCC-Adresse 0x14C4, stammen also vom WCC. Dazwischen gibt es einige kurze Mitteilungen zu 4 Bytes (ohne Adresse). Sieht nach einer Acknowlegde Nachricht vom Roomba zur vorherigen Nachricht aus. Z.B. sendet die WCC 0×17 0xD1 … Dann lautet die Antwort des Roombas dazu: 0×17 0xD4. Man erkennt zudem die gleiche Frame-Nummer im Acknowledge Paket.

In den Wireshark PCAP Files standen auch einige Einträge mit Nachrichten, die kein Acknowledge bekamen. Die WCC wiederholt dann solange die Nachricht, bis ein Acknowledge kommt.

Fazit

Message Format

So sieht nach derzeitigem Kenntnisstand der allgemeinen Nachrichten Aufbau aus:

    <hh> <ft> <aa <aa> <dd>.....<dd> 

    hh    8bit Frame Header constant 0x17
    ft    4Bit Frame counter / 4bit Message Typ
    aa    optionale 16bit Adresse
    dd    optionale Daten variabler Länge
    cc    16bit CRC Checksumme CCITT

Message Typ

     0    Pairing, Connection
     1    Command, ACK expected
     2    ???, no ACK expected
     4    Acknowledge

WCC Bedien Message

Die Kodierung der gedrückten Tasten beim WCC waren sehr leicht anhand der aufgezeichneten Protokolle zu erkennen. Jedes Paket wird zudem vom Roomba mit einer Acknowledge Message quittiert. So sieht die Befehlsfolge dazu aus:

    17 f1 14 C4 00 11 00 14 02 kk kk cc cc   (13 Bytes) command from WCC
    17 f4 cc cc                              (4 Bytes) ack from roomba

    f 4Bit Frame counter 0..f
    k 16Bit Key number bit oriented
    c 16Bit CRC checksum

Tasten Bits

    00 00   no key
    00 01   hour
    00 02   minute
    00 04   clock
    00 08   ???
    00 10   ???
    00 20   ???
    00 40   ???
    00 80   ???
    01 00   clean
    02 00   spot
    04 00   max
    08 00   schedule
    10 00   forward
    20 00   right
    40 00   left
    80 00   day

Taste geddrückt, das entsprechende Bit ist 1, Taste losgelassen, das entsprechend Bit ist 0. 11 Tasten befinden sich auf der Remote, 5 Bits bleiben unbenutzt.

Was kann man damit anfangen

Nach derzeitigem Stand kann man zumindest die Funktionen der WCC mit einem PC Programm und dem RZRAVEN USB Dongle nachbilden und den Roomba damit rudimentär ansteueren. Für die Einbindung in eine bestehende Hausautomation oder einen PC gesteuerte Scheduler ist das sicher ausreichend.
Die kompletten Features zur Steuerung, wie sie die SCI/OI Schnittstelle bietet, wird man damit wohl leider nicht erreichen. Hier sollte vielleicht der Hersteller iRobot darüber mal nachdenken, diese Schnittstelle freizugeben bzw. besser zu unterstützen. Technisch wäre es sicher kein Problem, die bestehende SCI/OI Schnittstelle auch über das RF Modul zu rooten. Bedarf dafür gibt es auf alle Fälle. Der Vorteil liegt einfach darin, dass man ohne Umbau und Aufbauten auf dem Roomba diesen über eine drahtlose Schnittstelle steuern könnte.

Wie geht es weiter

Viele Fragen bleiben noch offen:

• Wie werden die Uhrzeit und die Scheduler Zeiten übertragen?
• Liefert der Roomba seinen Akku Ladezustand?
• Was hat es mit den ominösen Messages auf sich, die nicht in das derzeitige Protokoll passen?
• Gibt es vielleicht ein Hintertürchen um an die Blackbox Daten oder an das SCI/OI Interface heranzukommen?

Ich habe begonnen, ein Tool mit der Pcap.Net Bibliothek in C# zu programmieren. Damit soll der Empfang und das Versenden von Paketen sowie das Pairing mit dem Roomba ermöglicht werden. Im Moment ist das Tools aber noch ein reiner Paket-Sniffer.

Was derzeit noch fehlt:

• Generieren / Check der Check. Dieses sollte eine normale CCITT CRC Checksumme sein.
• Senden von Paketen
• Interpreter für die empfangenen Pakete
• Automatischer Kanalwechsel, nach dem Pairing

Weblinks

• iRobot
• Roomba 500 Open Interface
• Roomba SCI Interface
• Freescale MC13202 2.4GHz RF Transceiver
• Jackdaw Firmware
• Contiki Raven Paket
• Wireshark