Hey,
da jetzt mit dem ganzen Projekt einiges weitergegangen ist, möchte ich hier mal ein Dankeschön für die nette und kompetente Unterstützung bedanken. Ich neige dazu, ein Thema zuerst geistig ziemlich eng abzustecken bevor ich ans experimentieren gehe. Über die freien Weihnachtstage möchte ich aber auf jeden Fall versuchen eine Platine zu ätzen und mit 2 RFM12s auf den Pollin Boards herumzuspielen.
Hier gefällt nach reichlicher Überlegung der Ansatz mit dem Signieren der Daten eigentlich am besten, v.a. weil sich das Erkennen von Übertragungsfehlern und die sichere Herkunft der Daten in einem Rutsch prüfen lässt. Da ich mit "Daemon" auch gewisse Standards für die Units festlegen will (zu dem eine ISP Buchse gehört) werde ich das gemeinsame Geheimnis einfach als Konstante im Code führen und beim Flashen mitübertragen.Hast du schon über das Thema Nachrichtensicherung vs -verschlüsselung nachgedacht?
Mit dieser Aussage konnte ich zum Zeitpunkt an dem sie geschrieben wurde absolut nichts anfangen. Ich bin es nicht gewohnt, dass ein Programm/Skript quasi in einer Endlosschleife läuft und ich keine nativen Funktionen hab um mir die Zeit einzuteilen. Wird aber sicher noch hochinteressant und lehrreich.Ich glaube du möchtest dich Mal ein wenig in Richtung Multitasking auf µCs informieren. Solche einfachen zeitgesteuerten Aufgaben kann man relativ einfach über eine Warteschlange lösen, die in regelmäßigen Abständen (Timer!) gepollt wird. (Stichwort: Delta-Queue). Im Wesentlichen musst du dich einfach darauf einstellen, dass deine Funktionen nicht mehr blockierend warten, sondern sich ihren Zustand merken und dann andere Funktionen weiterrechnen lassen. Das nennt man kooperatives Multitasking.
Die Wolken um diese Thematik haben sich auch noch nicht ganz gelichtet, denn die Frage der Frequenz, mit der die einzelnen Units gepollt werden ist noch immer offen. Auf der einen Seite steht hier die kurze Latenzzeit dem Strom-Spar-Faktor und den gesetzlichen Gegebenheiten gegebüber. Um schnellstmöglich ein Datenpaket zu übertragen ist der Tower/Master ständig mit dem Routen der Pakete beschäftigt, empfängt oder sendet Frames, immer. Ich schätze, dass die Polling-Frequenz relativ hoch sein wird, weshalb so bremsen möchte, dass jede Unit ca. 5x pro Sekunde das Token erhält. Auch zu den rechtlichen Auflagen in Österreich finde ich kaum brauchbare Informationen, habe aber was von DutyCycle max. 10% oder so gelesen.Du meinst also, dass ich ähnlich wie bei einer fehlerhaften Datenübertragung auch auf fehlerhafte Tokenübertragung mit direkter Sendewiederholung reagieren soll?Schon klar, aber: Du unternimmst damit noch nicht einmal den Versuch, eine stabile Kommunikation zu schaffen, weil du im Zweifelsfalle schon vor Kommunikationsbeginn aufgibst. Bei einer guten Funkverbindung sollte das eber weniger problematisch sein ...
Was bringt mir das für Vorteile wenn die Unit direkt nochmal das Token bekommt anstatt erst in der nächsten Runde?
Ich bedanke mich schon im Voraus für die Mühe.
Die Projektübersicht gibts auch auf: http://neox.ws/clouds/daemonbio.html
Lesezeichen