esp_alox/readme.md

UART Protokoll

Struktur einer Nachricht

• Control Bytes:
  • 0xAA = Startbyte
  • 0xBB = EscapeByte
  • 0xCC = EndByte

checksum = XOR über alle Bytes (ohne Control Bytes und Checksum-Byte)

Command, Payload und Checksum werden Escaped sollten sie einem Control Byte ensteprechend

Startbyte	Command	Payload (variable)	Checksum	Endbyte

Felder im Detail:

• Command (uint8_t):
  Gibt an, welcher Nachrichtentyp gesendet wird.

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

• Checksum (uint8_t):
  XOR über aller Bytes von Command und Payload.

Messages

Command:

• UART_ECHO = 0x01
• UART_VERSION = 0x02
• UART_CLIENT_INFO = 0x03

Grundlegend sind alle Zahlenwerte im LittleEndian format!

UART_ECHO:

• Send Message: AA 01 01 CC
• Message Received: AA 01 01 CC

Sendet zurück was geschickt wird.

UART_VERSION:

Offset	Länge (Bytes)	Bezeichnung	Beschreibung
0	2	Version	Software Version
2	7	BuildHash	Git Hash

• Send Message: AA 02 02 CC
• Message Received: AA 02 01 00 33 62 35 36 30 37 39 6F CC

Version	Buildhash
1	3b56078

Sendet die Version und den Buildhash vom Master zurück.

UART_CLIENT_INFO:

Das erste Datenbyte nach dem Commando gibt an wie viele Client Infos in dieser Nachricht vorhanden sind.

Danach teilt sich ein Eintrag wie Folgt auf:

Offset	Länge (Bytes)	Bezeichnung	Beschreibung
0	1	Client ID	Eindeutige ID des Clients.
1	1	Ist verfügbar	Boolean-Wert (0 = nein, 1 = ja), ob der Client verfügbar ist.
2	1	Slot genutzt	Boolean-Wert (0 = nein, 1 = ja), ob der Slot belegt ist.
3	6	MAC-Adresse	Die Hardware-Adresse des Clients.
9	4	Letzter Ping	Zeit in Millisekunden seit dem letzten Ping.
13	4	Letzter erfolgreicher Ping	Zeit in Millisekunden seit dem letzten erfolgreichen Ping.
17	2	Version	Versionsnummer des Clients.

Ein Client

• Send Message: AA 03 03 CC
• Message Received: AA 03 01 00 01 01 50 78 7D 18 89 F8 34 00 00 00 61 1F 00 00 02 00 76 CC

Client ID	Verfügbar	Genutzt	MAC-Adresse	Last Ping	Last Successful Ping	Version
0	1	1	50:78:7D:18:89:F8	52	8033	2

Zwei Clients

• Send Message: AA 03 03 CC
• Message Received: AA 03 02 00 01 01 50 78 7D 18 89 F8 22 00 00 00 F4 2A 01 00 02 00 01 01 01 50 78 7D 18 0C B4 10 00 00 00 F1 2A 01 00 02 00 FE CC

Client ID	Verfügbar	Genutzt	MAC-Adresse	Last Ping	Last Successful Ping	Version
0	1	1	50:78:7D:18:89:F8	34	76532	2
1	1	1	50:78:7D:18:C:B4	16	76529	2

UART_CLIENT_INPUT:

Die Identifizierung wird hier anhand der vorher gesendeten ClientID gemacht also muss einmal vorher UART_CLIENT_INFO aufgerufen werden.

Das erste Datenbyte nach dem Commando gibt an wie viele Client Infos in dieser Nachricht vorhanden sind.

Danach teilt sich ein Eintrag wie Folgt auf:

Offset	Länge (Bytes)	Bezeichnung	Beschreibung
0	1	Client ID	Eindeutige ID des Clients.
1	4	LageX	Float Wert von der X Lage.
5	4	LageY	Float Wert von der Y Lage.
9	4	LageZ	Float Wert von der Z Lage.
13	4	InputMaske	Int32 Wert der als Bitmaske genutzt wird um bis zu 32 Boolische Werte anzugeben.

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.

OTA-Update Technische Umsetzung:

Vorrausetzung:

• Update File steht bereit und ist unter 2MB groß.
• UART Verbindung steht
• ESP Funktioniert einwandfrei
• ESP Läuft auf Partition A, Partition B soll geupdated werden

Erste Schritt:

• Update in 200Byte stücke zerhacken und stück für stück per UART an den Master schicken
• Uart Protokol hat schon eine fehlercheck für die Übertragung drinnen
• Firmware wird in Partition B geschrieben
• OTA API Validiert Firmware am ende

Hier könnte man schon einen Neustart machen und Validieren ob die Firmware für den Master läuft!

Denn angeblich kann man beim ESP die aktuell laufende Partition auslesen

Zweiter Schritt:

• Master liest in 200Byte stücken die Firmware aus seiner Partition B aus
• Und schickt per Broadcast die ersten 20 Packete an die Clients
• Die clients haben 4KB Buffer vorgesehen wo sie die 20 Packete unterbringen können
• Master Forder Ack Bitmaske an zur Validierung das alle 20 Packete da sind
• Sollten in der Bitmaske zeilen fehlen gibt der Master per unicast die fehlenden Zeilen an die Entsprechend Clients erneut
• ESP NOW kümmert sich hier um die Datenintigrität
• Wenn alle ihre ersten 20 packete haben gibt der master das go und alle schreiben die ersten 20 packete weg.
• Der master aktuallisiert den fortschritt für alle clients -> dann kann man das auch abfragen per uart und hat eine Fortschrittsanzeige
• Alle melden sich zurück wenn sie fertig sind mit dem schreiben per ota und der buffer leer ist.
• Repeat bis alle Daten da sind

Hier hab ich mal grob gerechnet: 2MB in 200Byte Schritten -> 10.000 Packete 10.000 Packete in 20er Schritten -> 500 Sequencen Retries und Acks mal aussen vor hab ich leider keinen richtigen anhaltspunkt wie lang das dauern kann. Aber 500* ca 300ms => ist schonmal 150sekunden nur für das acken das die Packete da sind. Annahme hier das die maximal latenz beim Ping mit 16 Clients ca 300ms sind. Entsprechend mit Daten und retries... ja kp, Gemini schätzt max 10min. Wird sich zeigen. Da addiert sich zu viel auf.

• Alle Clients validieren ihren firmware
• Sollte das bei einem nicht klappen muss man hier nochmal gucken ob man den ganzen process nochmal von vorne anstößt nur mit dem fehlenden client...

Dritter Schritt:

• Alle Clients rebooten
• Clients geben rückmeldung ob das Update funktioniert

Hier müssten war noch entscheiden was passiert wenn das Update bei nur ein paar funktionert hat?

Was passiert wenn das Update garnicht funktioniert hat, behält der master dann auch seinen stand?

Entsprechend hätte man ihn vorher auch nicht neustarten dürfen

• Sollten alle Clients ihr go geben startet der Master auch neu

Wenn das Master Update jetzt fehlschlägt sagt er den clients bescheid und die booten auch wieder um?

Gibt halt noch ein zwar sachen die man sich überlegen muss aber ich denke den rest hab ich soweit ausgearbeitet