Roomba RF Protokoll (Teil 2)

admin — Fri, 14 May 2010 13:03:32 +0000

Im zweiten Teil der Roomba RF Protokoll Reihe geht es um die Unterschiede im MAC Layer Protokoll. Unverständlicherweise wird beim Roomba nicht der IEEE 802.15.4 MAC Layer verwendet, sondern ein eigenes Protokoll, obwohl IEEE 802.15.4 ein Standard ist und lizens- und kostenfrei verwendet werden kann, im Gegensatz zum lizens- und kostenpflichtigen Zigbee Protokoll.
Das unterschiedliche MAC Layer Protokoll ist wahrscheinlich auch die Ursache dafür, das ich mit der Standard RZRAVEN Software keinen Erfolg beim Sniffen der Pakete hatte.

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.

Robotfreak Blog » Wireshark