Hallo,
... hier eine Antwort zu diesem
Posting, passt aber hier besser rein.
Außerdem habe ich nach der Lekture der Dokus und Freds zu diesem Thema erst einmal darüber schlafen müssen, man liest und staunt...
Die obigen Fragen sind von euch auch gut beantwortet worden. Der Rest nun so geschrieben, dass andere noch mitlesen können.
===
Es gibt 16 Kanäle die sich alle Teilnehmer teilen, jeder sendet wenn "frei" ist. Das Maxstream-Modul bzw. Zigbee-Verfahren kennt dazu aber kein aktives Frequency hopping (wie Futaba) - eigentlich ein Hammer für einen sog. Standard. Aber man hat immerhin als Programmierer alternative Möglichkeiten den boardeigenen Befehlssatz des Moduls zu nutzen und diesen (man beachte natürlich auch die vielen Notes wie zB ...programmieren sie bitte ein Flow-Control...) ein Hopping zu implementieren. Das hat XPS wohl gemacht.
Damit ein Hopping also nun funktioniert gibt es beispielsweise Befehle für ein Scan-Verfahren zu Frequenzen (JD spielt als Parameter wohl mit dem "noise-Level", aktuell -45dB) und eine programmierbare Wiederholrate (default 3x). Ebenso kann man "virtual wires" nutzen oder die Übertragungsverfahren (Modes) des Moduls zB mit oder ohne Acknowledge-Bit (Broadcast-Mode) umschalten. Eine Kommunikation zwischen den beiden Partner (Sender/Empfänger) ist normalerweise gleichberechtigt, laut gefundener Aussagen scannt aber scheinbar nur der Empfänger und transferiert das Ergebnis (Tabelle) an den Sender (=> gemeinsames Sprungziel).
Programmiert wird das ganze über Open-Source Libraries in einem vorgeschlagenen Editor und einem Entwicklerboard.
Nun gibt es es aber typische Situationen in die eine solche Systemarchitektur fallen kann (Stichwort Zustandslosigkeit). Nach einem eigenem Scan und vor dem eigenen Hopping werden Frequenzen durch einen anderen Teilnehmer blockiert (=> Scan-Tabelle mit freien Frequenzen nicht mehr aktuell).
Oder der Noise-Level als Parameter für das Scan-Ergebnis passt nicht zur aktuellen Situation im Äther (=> dynamische Parameter).
Von größter Wichtigkeit ist bei Kommunikationssystemen daher eine Sequenz- und Zustands-Analyse. Nur damit weiß ich, ob nicht nach 2 oder 3 oder 35 Schritten nicht doch ein Problem und damit ein Verbindungsabriss auftritt. Das Zeitproblem im Ablauf ist kritisch, da zwischen Scan, Datenaustausch, Sprung und ggf. Wiederholung Zeit vergeht, in der andere Teilnehmer aktiv werden können. Eine Kommunikation funktioniert aber nur dann sicher, wenn ich die möglichen Zustände sauber ansprechen kann. Auch das Testen (Ozilloskop) usw. bring mich nicht weiter, denn es gleicht einer Lotterie welche aktuelle Situation zum Problem wird, da der Faktor Zeit die grösste Rolle spielt.
Es gibt diverse weitere Punkte, die ein Implementierung eines nachträglichen Frequenz-Hoppings aus meiner Sicht schwierig machen. Eine solche Architektur (Scan => Speichern => später nutzen) kann insbesondere zu typischen Einzelfall-Problemen führen. Man testet sich zu Tode und kann dennoch ein auftretendes Problem nicht sauber reproduzieren (höchstens über ein Parameter-/Funktionslogging, davon lese ich aber bisher nichts).
Zum Thema IFS: Ich denke Graupner hat aber seine Sache gut gemacht und diese ganzen Faktoren im Griff.
By the way...
Assan?
Viele Grüße
Ulrich
