UART Protokoll

Struktur einer Nachricht

0xAA = Startbyte  
checksum = XOR über alle Bytes (ohne Startbyte und Checksum-Byte)

Nachrichtenaufbau (Message Frame)

+-------------+----------+---------------+----------------------+-----------+ | Startbyte | Length | CommandPage | Payload (variabel) | Checksum | +-------------+----------+---------------+----------------------+-----------+ | 0xAA | 1 Byte | 1 Byte | n Bytes | 1 Byte | +-------------+----------+---------------+----------------------+-----------+

Felder im Detail:

• Length (uint8_t):
  Gibt die Gesamtlänge der Nachricht ab CommandPage bis einschließlich Payload an.

• CommandPage (uint8_t):
  Gibt an, welcher Nachrichtentyp oder Befehl gesendet wird.

• Payload (variabel):
  Datenfeld mit variabler Länge, abhängig vom CommandPage.

• Checksum (uint8_t):
  XOR über alle Bytes ab Length bis einschließlich Payload.

---

Roadmap

• SEND STATUS OF DEVICE OVER UART
• CONFIGURE PEERS OVER MASTER
• SAVE PIN CONFIG ON PEERS

Machbarkeits-Studie

1.0 Hardware-Features

1.1 Hardware-Aufbau

Anforderung Es soll eine Hardware von 20 Modulen bereitgestellt werden, welche als Basis der grundlegenden Software-Features dient. Dabei liegt der Fokus auf der Verarbeitung von Wifi-Nachrichten und weniger auf deren Hardware-technischen Umsetzung. Lösungsansatz Die Hardware besteht aus 20 ESP32-Modulen (1x Koordinator und 19 Peers) und der entsprechenden Energieversorgung: 20x Stecker-Netzteil + USB-Leitungen Abnahme-Kriterium Alle Peers sind so mit Energie zu versorgen, dass sie sich in einem Radius von ca. 15m um den versorgten Koordinator befinden. Dokumentation Es wird per Liste festgehalten, welches ESP32-Board benutzt wird und ob Modifikationen bei der Spannungsversorgung (bspw. Elko an 3.3V) vorgenommen wurden.

2.0 Software-Features

2.1 Netzwerk-Aufbau

Anforderung Das Netzwerk soll sich nach einem Power-On selbständig aufbauen und eine Teilnehmer- Liste nach abgeschlossener Initialisierung bereitstellen. Lösungsansatz Der Koordinator erstellt ein MAC-Netzwerk und fügt die Peers in das Netzwerk hinzu. Zusätzlich erstellt der Koordinator eine Liste von MAC-Adressen der Peers. Abnahme-Kriterium Dieses Feature wird per Systemtest verifiziert. Der Test startet den Netzwerk-Aufbau auf dem Koordinator per Terminal-Kommando und gibt nach 5 Minuten die MAC-Adressen- Liste zurück. Dokumentation Der Netzwerk-Aufbau wird per Ablauf-Diagramm dokumentiert.

2.2 PingPong-Feature

Anforderung Nach dem Netzwerk-Aufbau soll jeder Peer durch den Koordinator ein Ping erhalten, welchen dieser umgehend mit einem Pong (bzw. mit seiner Firmware-Version) beantwortet. Sollte ein Teilnehmer auf die Anfrage nicht reagieren, soll die Anfrage sofort wiederholt werden. Die benötigte Zeit und die Anzahl der Wiederholungen soll erfasst werden. ALOX Labs UG Lastenheft Pflichtenheft PowerPods 4 Lösungsansatz Der Koordinator sendet an die hinterlegten MAC-Adressen jeweils den Ping-Befehl und erwartet die Pong-Antwort (Firmware-Version) des jeweiligen Peers. Sollte ein Teilnehmer nicht antworten wird die Nachricht nach 10ms wiederholt – maximale Wiederholung: 5x. Die Zeit (Start: vor der Sendung – Stopp: nach dem Empfang) wird im Koordinator erfasst. Abnahme-Kriterium Dieses Feature wird per Systemtest verifiziert. Der Test startet das PingPong-Feature mit einer erwarteten Firmware-Version und bekommt als Resultat eine Liste mit dem Status der Firmware, der Dauer und den benötigten Versuchen pro Peer zurück. Dokumentation Das PingPong-Feature wird per Ablauf-Diagramm dokumentiert.

2.3 PingPong-Feature im definierten Raster

Anforderung Es soll sichergestellt werden, dass die Dauer der Peer-Abfrage immer im gleichen zeitlichen Raster stattfindet. Dies soll unabhängig von den Teilnehmern des Netzwerks sein und sich an der Maximalen Anzahl der Teilnehmer richten. Dadurch soll sichergestellt werden, dass die Performance bei 5 Teilnehmern sich genauso verhält wie bei 19 Teilnehmern. Lösungsansatz Der Koordinator sendet an die hinterlegten MAC-Adressen jeweils den Ping-Befehl in einem vor-definierten zeitlichen Raster. Das Raster richtet sich an die in Pos. 2.2 gemachten Ergebnisse, wo die maximale Dauer einen PingPongs bestimmt wird. Die menschl. Reaktionszeit beträgt ca. 250ms. Die maximale Abfrage-Zeit sollte unterhalb von 200ms (bestenfalls bei 125ms) liegen um ein flüssigen Spielablauf zu gewährleisten.

• 19 Teilnehmer mit 125ms: 5ms Raster + 3 Wiederholungen (5ms + 5ms)
• 19 Teilnehmer mit 200ms: 8ms Raster + 3 Wiederholungen (8ms + 8ms) Abnahme-Kriterium Dieses Feature wird per Systemtest verifiziert. Der Test startet das PingPong-Feature im vor-definierten Raster und bekommt als Resultat eine Liste mit der jeweiligen Dauer, den benötigten Versuchen und einer Rückmeldung, ob das Raster eingehalten wurde zurück. Dokumentation Das PingPong-Feature im definierten Raster wird per Ablauf-Diagramm dokumentiert

2.4 Broadcast-Message

Anforderung Der Koordinator soll nicht nur die Peers einzeln per MAC-Adresse, sondern auch per globaler Nachricht direkt an alle Peers eine Nachricht versenden können. Lösungsansatz Durch eine spezielle Nachricht, die an alle Peers gerichtet ist, können Nachrichten per Broadcast vom Koordinator an alle Peers versendet werden. Eine Rückmeldung der Peers wird nicht erwartet. ALOX Labs UG Lastenheft Pflichtenheft PowerPods 5 Hinweis Der erfolgreiche Abschluss der Machbarkeitsstudie soll mit den aufgeführten Punkten erreicht werden. Nach dem Abschluss soll der Status soweit sein, um mit der Produkt-Entwicklung starten zu können. Im Rahmen der Entwicklung wird (wenn nicht anders im Unterpunkt beschrieben) immer davon ausgegangen, dass Funktionen und Übertragungen korrekt funktionieren – sprich, es wird der Gut-Fall abgedeckt. Sollten trotz dieser Erwartung Fehler während oder nach der Inbetriebnahme stattfinden, werden diese nachträglich behoben. Abnahme-Kriterium Die Broadcast-Message wird über einen Systemtest verifiziert. Dabei wird der Test per Terminal-Kommando gestartet und an alle Peers eine globale Nachricht mit einem Wert gesendet. Diesen Wert fragt der Koordinator per modifiziertem PingPong (Wert statt Firmware-Version) im zweiten Schritt ab. Dokumentation Der Systemtest zur Broadcast-Nachricht wird per Ablauf-Diagramm dokumentiert.

2.5 OTA-Update

Anforderung Die Peers sollen vom Koordinator eine neue Firmware per Funk übertragen bekommen, so dass eine händische Programmierung der Module nicht notwendig ist. Lösungsansatz Der Koordinator prüft nach jedem Neustart des Netzwerks, ob die Teilnehmer die korrekte Firmware besitzen. Wenn dies nicht der Fall ist, wird die aktuelle Firmware übertragen. Abnahme-Kriterium Das OTA-Update wird über einen Systemtest verifiziert. Dabei wird der Test per Terminal- Kommando gestartet und an alle Peers die neue Firmware übertragen. Mit einem nachträglichen PingPong wird im zweiten Schritt die neue Version der Peers abgefragt. Dokumentation Der Integrationstest zum OTA-Update wird per Ablauf-Diagramm dokumentiert.

3.0 Abschlussbericht

3.1 Nach erfolgreicher Implementierung der beschriebenen Features soll ein

aussagekräftiger Abschlussbericht erstellt werden. Darin sollen die gemachten Ergebnisse und Erkenntnisse kurz dargestellt werden. Dieser Bericht dient dann als Grundlage für das Lasten- und Pflichtenheft der Produktentwicklung und gibt einen Ausblick, ob sich die techn. Anforderungen hinreichend gut umsetzen lassen.

3.2 Eine tabellarische Auflistung, welche der aufgeführten Features wie umgesetzt wurden

und ob diese den ursprünglichen Anforderungen entsprechen.