Bitte warten...Progamm Sender/Empfänger
Grundsätzliche Festlegungen
Vorläufig ist nur eine (Einbahn-)Datenübertragung von den Sendern zum Empfänger geplant. Das bedeutet, dass der Empfänger weder eine Anforderung zur Datenübertragung an die Sender richtet, noch dass der Empfänger eine Bestätigung für erhaltene Daten rückmeldet.
Damit trotzdem sichergestellt ist, dass der Empfänger immer mit aktuellen Daten versorgt wird, senden die Sender ihre Daten kontinuierlich und in sehr viel kürzeren Abständen, als der Empfänger die Daten verarbeiten oder speichern soll. Ist z.B. eine Datenspeicherung alle 15 Minuten geplant und die Sender senden z.B. alle 10 oder 15 Sekunden, so können ruhig einige Datenpakete nicht richtig beim Empfänger ankommen oder verloren gehen und der Empfänger hat trotzdem immer einigermaßen aktuelle Daten zur Speicherung zur Verfügung. Das spielt vor allem dann keine Rolle, wenn es sich dabei um Daten wie Umgebungs- oder Zimmertemperaturen oder Luftdruck, Luftfeuchte oder ähnliches handelt, wo sich die Werte in kurzen Zeitabständen nicht sehr verändern. Trotzdem soll sich der Empfänger melden (akustisch oder optisch), wenn er eine gewisse Zeit keine Daten von einem Sender erhalten hat.
Gibt es mehr als eine Sendestation, kann es z.B. durch nahezu gleichzeitiges Senden dazu kommen, dass sich die Telegramme beim Empfänger überschneiden, dass es also zu Telegrammkollisionen kommt und der Empfänger dadurch keine richtigen Informationen erhält. Dieser Zustand sollte durch das Mitsenden eines Check-Bytes vom Empfänger erkannt werden.
Um die Gefahr des gleichzeitigen Sendens zu verringern (durch die Einbahn-Datenübertragung hat ja ein Sender keine Informationen, dass ein anderer Sender gerade sendet) kann man entweder z.B. die Senderate je Sender unterschiedlich festlegen, ein Sender sendet z.B. alle 5 Sekunden, der Zweite alle 7 Sekunden, oder ein Sender sendet alle 5 Sekunden, der Zweite jeweils nach einer "Zufallszeit". Trotzdem wird es dabei immer wieder zu Kollisionen kommen, aber wie gesagt, wenn man häufig sendet, spielt eine Telegrammkollision keine Rolle, weil ja das nächste Telegramm sowieso bald wieder gesendet wird. Ein Nachteil des häufigen Sendens wird aber der höhere Stromverbrauch sein, der sich bei Batteriebetrieb des Senders nachteilig auswirken kann.
Festlegung des Sendetelegramms:
Damit die von den Messstationen (Sendern) gesendeten Messdaten vom Empfänger auch richtig erkannt und interpretiert werden, ist ein Sende-Telegramm festzulegen.
Ich habe das Telegramm folgendermaßen festgelegt:
Die ersten beiden Bytes 0 und 1 beinhalten die Identität des Senders, so dass der Empfänger zuordnen kann, von welchem Sender das Telegramm stammt.
Byte 2 ist derzeit Reserve und könnte als Telegramm-ID genutzt werden, wenn z.B. ein Sender mehr als 5 Analogwerte übertragen soll und daher jeweils ein zweites Telegramm sendet.
Die Bytes 3 bis 22 sind für die Übertragung von 5 Messwerten im Datenformat "Float" reserviert. Eine Float-Zahl benötigt in Arduino 4 Byte Speicherplatz.
Die Bytes 23 bis 25 werden derzeit nicht benutzt und sind z.B. als Reserve für Checksummenerweiterung oder zur Übertragung von zusätzlichen Informationen (z.B. Binärwerte) gedacht.
Byte 26 beinhaltet eine einfach gebildete Checksumme über die Bytes 0 - 25.
Byte Nr.: Bedeutung: Inhalt: Bemerkung
0 - 1 Sender-ID #n z.B. #1 für Sender Nr. 1
2 Reserve 0 Reserve (Erweiterung für Telegramm-ID)
3 - 6 Messwert 1 float Messwert1
7 - 10 Messwert 2 float Messwert2
11 - 14 Messwert 3 float Messwert3
15 - 18 Messwert 4 float Messwert4
19 - 22 Messwert 5 float Messwert5
23 - 25 Reserve 0 Reserve
26 Checksumme byte 0-FF Berechnete Checksumme