Ein Mesh mit 7 Knoten läuft nun mit der RadioHead Lib. Dabei gab es ein paar interessante Stolpersteine/Erkenntnisse:
- Ein irrlichternder Kontroller mit nRF24 Modul kann das ganze Mesh zum Erliegen bringen, genauso wenn das Problem vor dem Computer zweimal die gleiche Knotennummer verteilt
- Die Stabilität der 3.3V Versorgung scheint von immenser Bedeutung, und zwar speziell beim Senden. Zurzeit hab ich einen Knoten der die restlichen fortlaufend kontaktiert und eine Antwort erwartet. Dabei zeigt sich, dass aus Sicht des zentralen Knotens die Aussenstellen relativ instabil sind (je nach Knoten 30-50% Verlust). Interessant ist das dies stark vom verwendeten Board (weniger vom Modul abhängt). Interessanterweise erhalten aber die Remote Knoten die Sendungen vom Kontroller mit einer viel höheren Zuverlässigkeit (>90%). Daraus schliesse ich mal wild spekulierend, dass eine stabile 3.3V Quelle vor allem beim Senden von entscheidender Bedeutung ist.
So will z.B. der gute alte Duemilanove gar nicht beim Mesh mitspielen - auf keine Geissart und egal mit welchem Modul. Hänge ich mein Handy an den USB Bus zum Laden, laufen zwar alle Boards weiter, aber das Mesh bricht pronto zusammen.
- Das Wechseln des Kanals kann ja nach "Vorbelastung" des 2.4GHz Bands massive Verbesserungen bringen. MIt Channel 1 lief fast gar nichts, mit Channel 50 sehr befriedigend.
- Wenn die Zuverlässigkeit nicht passt und alle Module nah beieinander liegen, hilft es die Sendeleistung zu reduzieren, mit -12db arbeiten die Module alle nebeneinander auf dem Tisch sehr ansprechend, mit 0db muss ich sie räumlich verteilen, damit ich die gleiche Stabilität hinkriege.
- Mit zunehmender Grösse des Experiments wurden aus Inventargründen ausserdem die Jumperwires immer länger, dies scheint auch deutlich mit der Zuverlässigkeit der Übertragungen zu korrelieren.
Fazit: Dafür, dass ich für den Preis der verwendeten Module noch nicht mal 2 XBees erhalte, bin ich sehr zufrieden mit den ersten Resultaten. Es zeigt sich aber, dass man mit Jumperwires und Breadboards den Modulen und hohen Frequenzen nicht ganz gerecht wird und ein dediziertes Board wie der Devduino eine gute Wahl ist. Wobei ich mir nur schwer vorstellen kann, wie der von der CR2032 Batterie gespiesen anständig senden kann.
Andererseits muss hier zur Ehrenrettung der XBees auch gesagt werden, dass der Vergleich hinkt. Das XBee entspricht eher einem nRF24 Modul mit angeschlossenem ATmega1284 und ausgereifter Mesh Firmware vorinstalliert. Dem XBee sende ich einfach Daten und es kümmert sich darum, bei der RadioHead Mesh Implementation befindet sich der Kontroller öfters in einem blockierten Zustand, der das Empfangen weiterer Daten (auch zum Weiterleiten als Mesh-Knoten) verhindert und zu Paketverlusten und Neu-Übertragungen führt. D.h. eigentlich wär es ideal wenn das nRF24 Modul gleich mit einem eigenen Mikrokontroller käme und wir diesen z.B. über I2C oder UART ansprechen könnten. An diesem Punkt verliert aber die Lösung sehr viel preisliche Attraktivität.
Was ich an diesem Punkt auch noch nicht abschätzen kann ist, wie weit es das Mesh instabil macht, wenn viele der Knoten nur kurz aufwachen, einen Messwert senden und dann wieder lange schlafen. Bei XBee löst man dies mit einer Rollenzuteilung des Modules als Router oder Endpoint (der auch schlafen darf), RadioHead kennt diese Unterscheidung nicht.
Ein dediziertes Sensor Knoten Board a la Devduino könnte in der Tat hilfreich sein, jedoch würde ich persönlich eine LiPo Lösung bevorzugen.
Grüsse - Christoph
