Student-Projects/2024-Rocket-Motor-Verification.md

@@ -157,7 +157,7 @@ Die Struktur des Prüfstands muss so konstruiert sein, dass sie sowohl dem Druck
 * Hinreichende Auflösung
 * Hinreichende Datenrate
 
-  Daten in OpenRocket sind ung 17Hz und aus dem Datenblatt des Herstellers
+  Daten in OpenRocket sind ung 17Hz und aus dem Datenblatt des Herstellers (siehe https://www.thrustcurve.org/motors/Klima/B4/)
 * Wichtigster Parameter: Kraft
 
   zu erwarten sind im peak 25N Schub
@@ -191,4 +191,48 @@ sonstige Elektronik:
 * **automatische elektrische Zündung** des Motors
   * extra PCB/Schaltung/Relais?
   * Verundung zweier Signale vom uC minimum
-  * Sicherheits-Pin gibt schaltung frei
\ No newline at end of file
+  * Sicherheits-Pin gibt schaltung frei
+
+## Konzepte
+
+### Mechanischer Aufbau 
+
+### Software 
+
+UI:
+
+1. Buttons und LEDs
+2. Buttons, LEDs und ein Display
+3. Buttons, LEDs, Display und Webapp
+
+**Entscheidung fällt auf 3**. Da für das UI sowohl einfache Bedienmethoden über Buttons (low level Backup oder Schnellzugriff) als auch komplexere Anforderungen erfüllt werden müssen, fiel die Wahl auf eine Kombination aus Buttons, LEDs, einem kleinen Display und einer Webapp. 
+
+Die Funktion der **Buttons** wäre, dass man zB in einem Experiment den nächsten Schritt auswählt oder ein Experiment abbricht. Diese Buttons weden direkt am Prüfstand angebracht und sind vom Versuchsleiter/Bediener gut zu erreichen. In Kombination mit den **LEDs** und einem **kleinen Display** lässt sich auf einen Blick direkt der Zustand des Prüftstands erkennen. Die **Webapp** bietet die selben  Interaktionsmöglichkeiten mit einem erweitertem Funktionsumfang zB zum Erstellen eines Experiments, Verwalten der Kalibrierdaten oder Abrufen vergangener Versuche. Die Idee ist, dass man in der Webapp aus veschiedenen vorprogrammierten Experiment-Bausteinen ein Experiment aufbaut, welches dann gefahren werden kann auf dem Prüfstand. Die Webapp interagiert mit dem microcontroller über eine API, welche wie folgt strukturiert ist:
+
+\<\< insert API \>\>
+
+Aus den definierten Anforderungen und dem angestrebten Design der Software ergab sich folgender Aufbau:
+
+\<\< insert sw architecture \>\>
+
+### Messtechnik 
+
+Kraftmessung:
+
+1. DMS und Messvertärker bei [HBK](http://www.hbm.com/de/) anfragen (Kooperation denkbar)
+2. [hx711 ](http://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf)(brückenverstärker) mit wägezelle (1kg maximale Nennlast)
+3. Kofferwaage
+
+Da die hinreichenden Anforderungen an die Messtechnik unklar sind (fehlende Referenz oder Erfahrungswerte) und die zweite Option bereits im Labor vorhanden ist, wird diese Kombination zunächst betrachtet. Weitere Untersuchungen sind nötig, die Wahl der Wägezelle und des HX711 als Meßvertsärker zu evaluieren. Untersucht werden soll die Liniariät des Messaufbaus - auch jenseits der Nennlast von 1kg - und die maximale Datenrate, die laut Datenblatt maximal 80SPS beträgt.
+
+### Elektronik
+
+Microcontroller (alle als dev-boards):
+
+1. ESP32
+2. ESP8266
+3. microcontroller board + externes WiFi Modul
+
+Die Wahl fiel auf das "[LoRa32 V2.1_1.6](http://www.lilygo.cc/products/lora3)" von LILYGO, da es zum einen alle Anforderungen erfüllt und es schon im Labor zur Verfügung stand. Im Gegensatz zu den anderen ESP32 boards im Labor, hat das von LILYGO deutlich mehr Ausgänge, einen eingebauten SD-Karten-Leser und ein kleines Display ist auch schon integriert. Die verbaute LoRa Peripherie wird in diesem Projekt wahrscheinlich keine Relevanz haben.
+
+Das Pinout findet man [hier](https://github.com/lnlp/pinout-diagrams/blob/main/LoRa%20development%20boards/TTGO%20LoRa32%20V2.1.6%20Pinout%20(LLP).pdf)
\ No newline at end of file