vault backup: 2025-09-19 13:15:55

Affected files:
.obsidian/workspace.json
0 Journal/0 Daily/2025-09-19.md
Temporary/Webapp - Chirp Log Review.md

0 Journal/0 Daily/2025-09-19.md

@@ -22,11 +22,59 @@ Error generating daily quote
 - [ ] do flight with valentin
 
 Saturday
-- [ ] Hackathon: MVP for logserver --> publish it and host it.
+- [ ] Hackathon: MVP for logserver --> publish it and host it. Core functionality: Parse chirp file, add it to the database as timeseries (use time series parsing and chirp parsing). New project with direct dependency on chirp (include as a submodule). 
+Database structure
+- Logs
+	- id
+	- date_added
+	- file_path
+	- file_size
+	- status: ChirpFile::Status
+	- chirp_binary_size
+	- chirp_log_size
+	- chirp_version
+	- chirp_file_type: should always be chripCombined
+	- chirp_participant_id
+	- text_content
+	- LogMetrics
+		- log_start_date_time
+		- log_end_date_time
+		- log_duration
+		- flightcontroller
+- TimeSeries
+	- either we have a table per Opcode, meaning we need to update the schema whenever we change the chirp version
+	- or we have a table for TimeSeries and one for TimePoint:
+		-  Series
+			- id
+			- log_id
+			- opcode
+			- source_id
+			- component_id
+			- device_id
+			- message_name
+			- field_list
+			- count
+			- t_start_us
+			- t_end_us
+- Special Cases: 
+	- SoftwareVersion Message --> parse to metrics
+	- Parameter update Message --> own table
+	- ConsoleEntry Message --> own Table
+	- DebugMessages (create one time series per key --> create DebugTimeSeries?)
+	- extract perf_counters and put them into a table
+	- we should never have file transfer pacets
 ___
 ## Reflection
 
 
 ___
 ## Notes
-- 
+
+### Parameter System
+The parameters of every subsystem (autopilot, flightcontroller) are independent from each other and they live in the respective components. What this parameter system is is nothing else than parameter protocol, which allows to read and set parameters through chirp. The only coupling there is is that we will be able to do that from our development computer and the autopilot forwards the requests which are meant to be for the flight controller. Like this the parameters of both the flightcontroller and the autopilot can be configured over the network without having to open up the drone and get a usb cable into the teensy every time and change a small setting. 
+
+What it specifically means for the flightcontroller code:
+- currently the parameters are stored in like 10 different files as constants (or sometimes just as magic numbers without any name). this means that every time we want to modify a parameter (e.g. control gains or physics model variables like the mass) we need to open that specific file in the source code, change it and reflash the teensy (this also changes the software version, because you're essentially flashing a different firmware file.)
+- Therefore, the plan is to implement a parameter registry (or we could also name it parameter Manager class), where all the changeable parameters of the flightcontroller are stored. The different modules that require the parameter values then ask the registry for the parameter.
+- This parameter registry also has API functions which lets the outside (e.g dev computer or cm4) get and set parameters through a small chirp message we send to the flightcontroller. 
+- the exact architecture of this is not yet determined.