vault backup: 2026-01-13 14:58:51
Affected files: .obsidian/workspace.json 0 Journal/0 Daily/2026-01-07.md
This commit is contained in:
7
.obsidian/workspace.json
vendored
7
.obsidian/workspace.json
vendored
@@ -92,7 +92,7 @@
|
||||
}
|
||||
}
|
||||
],
|
||||
"currentTab": 5
|
||||
"currentTab": 3
|
||||
}
|
||||
],
|
||||
"direction": "vertical"
|
||||
@@ -317,7 +317,8 @@
|
||||
"vantage-obsidian:Vantage - Advanced search builder": false,
|
||||
"templater-obsidian:Templater": false,
|
||||
"obsidian-git:Open Git source control": false,
|
||||
"markdown-importer:Open format converter": false
|
||||
"markdown-importer:Open format converter": false,
|
||||
"periodic-notes:Open today": false
|
||||
}
|
||||
},
|
||||
"floating": {
|
||||
@@ -353,7 +354,7 @@
|
||||
"x": 0,
|
||||
"y": 44,
|
||||
"width": 900,
|
||||
"height": 944,
|
||||
"height": 777,
|
||||
"maximize": false,
|
||||
"zoom": 0
|
||||
}
|
||||
|
||||
@@ -102,7 +102,7 @@ Structure:
|
||||
4. max cell voltage in V
|
||||
5. max temperature in BMS in °C
|
||||
6. min temperature in BMS in °C
|
||||
7. state of charge in % (from 34z100)
|
||||
7. state of charge in % (from 34z100 coulomb counter)
|
||||
8. charge fet enabled
|
||||
9. discharge fet enabled
|
||||
10. has fault? --> protection/alarm active? --> if yes trigger a search for what is wrong and escalate
|
||||
@@ -144,6 +144,7 @@ Structure:
|
||||
1. bq76942_fw_version
|
||||
2. bq34z100_fw_version
|
||||
3. all AFE safety settings (alerts and thresholds)
|
||||
4. etc
|
||||
|
||||
|
||||
### MQTT topic structure
|
||||
@@ -158,6 +159,7 @@ Structure:
|
||||
- bms/{ID}/
|
||||
- data_fast
|
||||
- data_detailed
|
||||
-
|
||||
|
||||
### HDC2010 barebones Driver Requirements
|
||||
- Needs to be configurable
|
||||
@@ -166,12 +168,44 @@ Structure:
|
||||
- needs to support a self test to ensure proper health status
|
||||
- needs to answer in polling mode
|
||||
- needs to support a calibration routine
|
||||
-
|
||||
|
||||
### BQ76942 barebones Driver Requirements
|
||||
|
||||
-
|
||||
|
||||
### BQ34Z100 barebones Driver Requirements
|
||||
|
||||
### UPDB Manager Module
|
||||
- needs to configure the 3 drivers according to the .conf file
|
||||
- shall be configured with the conf file
|
||||
- needs to pass the configuration to the 3 drivers according to the .conf file
|
||||
- shall run the driver data polling at the right intervals for the different chips and different messages
|
||||
- shall publish mqtt / zmq and or chirp messages depending on the configuration
|
||||
- needs to make sure the i2c handler works and can be shared without concurrency issues with the 3 drivers
|
||||
- shall poll the configuration of each sensor once after initialization and after configuration and publish the config messages
|
||||
- if there is any fault triggered by the bq chips it shall poll the necessary information and escalate it by sending error and warning messages
|
||||
- all measurements shall be treated as invalid after a timeout (e.g 2s, configuratble): meaning we need timestamps
|
||||
- The Battery Manager module shall validate incoming measurements against configurable physical bounds (e.g., voltage/current/temperature limits) and mark invalid samples.
|
||||
- The Battery Manager module shall maintain a health state per battery instance (e.g., OK / degraded / failed) derived from data validity and driver communication status.
|
||||
- The Battery Manager module shall continue operating with reduced functionality when optional measurements (e.g., temperature, cell voltages) are unavailable.
|
||||
- The Battery Manager module shall behave deterministically for identical input streams and parameter sets.
|
||||
- When a battery data source becomes available (driver starts successfully or communication is established), the Battery Manager module shall transition that battery instance to “connected” and begin publishing valid status.
|
||||
- When communication with a battery data source is lost for longer than the stale timeout, the Battery Manager module shall mark the instance as failed and publish status indicating loss of battery data.
|
||||
- When an incoming measurement violates configured bounds, the Battery Manager module shall reject the sample and increment an error counter for that instance.
|
||||
- When valid measurements resume after a communication fault, the Battery Manager module shall clear the failed state after a configurable number of consecutive valid updates.
|
||||
- When remaining capacity or voltage crosses configured low thresholds, the Battery Manager module shall set the corresponding warning level for that instance.
|
||||
- When remaining capacity or voltage crosses configured critical thresholds, the Battery Manager module shall set the corresponding warning level for that instance.
|
||||
- When remaining capacity or voltage crosses configured emergency thresholds, the Battery Manager module shall set the corresponding warning level for that instance.
|
||||
- When current exceeds a configured maximum for longer than a configured duration, the Battery Manager module shall set an over-current warning/fault for that instance.
|
||||
- When temperature exceeds configured limits (or drops below configured limits), the Battery Manager module shall set the corresponding temperature warning/fault for that instance.
|
||||
- When any cell voltage exceeds configured per-cell limits (min/max), the Battery Manager module shall set a cell warning/fault and identify the affected cell index where supported.
|
||||
- If the BMS provides state-of-health and cycle count, the Battery Manager module shall publish them
|
||||
- If the BMS provides manufacturer name, serial number, pack name, or chemistry, the Battery Manager module shall publish and log these identifiers.
|
||||
- The Battery Manager module shall not mark a battery instance as valid when the underlying measurement stream is stale, uninitialized, or failing validation.
|
||||
- The Battery Manager module shall not publish values with inconsistent units or scaling relative to the configured source.
|
||||
- The Battery Manager module shall not oscillate warning states due to noise; it shall apply hysteresis and/or time filtering.
|
||||
- The Battery Manager module shall not fail silently; it shall surface persistent faults through status flags and logs/events.
|
||||
- The Battery Manager module shall log battery status, warnings, and faults at rates compatible with flight log analysis.
|
||||
- The Battery Manager module shall provide battery data needed for telemetry reporting to a ground station (voltage, current, remaining, warnings) where telemetry is enabled.
|
||||
- The Battery Manager module shall initialize into a safe state where missing/invalid data results in conservative warnings rather than optimistic “OK”.
|
||||
- The Battery Manager module shall rate-limit error reporting to avoid log flooding during repeated comms failures.
|
||||
- The Battery Manager module shall bound its CPU usage and bus transaction rate to avoid starving higher priority real-time control tasks.
|
||||
- The Battery Manager module shall ensure thread-safe access to shared state if multiple drivers/sources update concurrently.
|
||||
Reference in New Issue
Block a user