161 lines
5.1 KiB
Markdown
161 lines
5.1 KiB
Markdown
---
|
||
aliases:
|
||
Tags:
|
||
- daily
|
||
day_grade:
|
||
Dehnen:
|
||
Sport:
|
||
Ernährung:
|
||
---
|
||
# 2026-01-07
|
||
|
||
[[2026-01-06]] <--> [[2026-01-08]]
|
||
|
||
|
||
Error generating daily quote
|
||
|
||
---
|
||
## Planning
|
||
- [ ] Write Email to F&D to quit.
|
||
- [ ] finalize battery bms driver
|
||
|
||
|
||
___
|
||
## Reflection
|
||
|
||
|
||
___
|
||
## Notes
|
||
### Email Draft
|
||
Hey
|
||
I've been thinking about my situation at OneSec and I want to fix an end date this week. I think the best solution is to leave as soon as possible. The reason for this being: I don't feel the same drive as before after what happened in December and you can hire 2 extra Valentins for my salary. I'm open to discuss the exact date, but I'd suggest end of January, this leaves a bit more than 3 weeks to do the following:
|
||
- finalize the battery driver code and have it reviewed by Hasan
|
||
- Review both PDBs --> this concludes a full iteration of pcbs.
|
||
- With the new wiring and propulsion harnesses arriving next week: test thoroughly then bring up propulsion system
|
||
- Handover
|
||
- document everything I can think of with loom videos and articles
|
||
|
||
Are there any other subjects you want me to tackle?
|
||
|
||
|
||
Hey, regarding my notice I suggest fixing the 31st of January as an end date. This leaves just enough time to finalize ongoing activities and organize a clean handover. Additionally it leaves space to hire two more interns with the same financial investment if needed. Please let me know if that is fine for you.
|
||
|
||
Hey
|
||
Regarding my situation at OneSec:
|
||
- has there been any progress on the contracts that we wanted to sign? Can I assist in any way?
|
||
- I want to fix an end date and my suggestion is the 31st of January. This leaves just enough time to finalize ongoing activities and organize a clean handover and frees up resources for OneSec to hire 2 interns just like Valentin. I'm aware that this is very short notice, so I'm open to discuss this if you are against it, but I think this is the best solution.
|
||
|
||
Rough list of things to finish:
|
||
- finalize the battery driver code and have it reviewed by Hasan
|
||
- Review both PDBs --> this concludes a full iteration of pcbs.
|
||
- With the new wiring and propulsion harnesses arriving next week: test thoroughly then bring up propulsion system with healthy pcbs. Include Valentin in the process
|
||
- Handover
|
||
- document everything I can think of with loom videos and articles
|
||
|
||
Please let me know your thoughts and if anything is missing on the list.
|
||
|
||
|
||
|
||
---
|
||
## Upper PDB Driver Requirements
|
||
|
||
Structure:
|
||
- each driver standalone and not dependent on osd-autopilot-2
|
||
- the upper pdb manager module is responsible of using the three drivers (bq76942, bq34z100, hdc2010) to get the right registers at the right frequencies and publish them to where its needed (chirp, zmq, mqtt)
|
||
- the upper pdb message structures are the following:
|
||
|
||
1. HDC2010 Data
|
||
1. temperature in deg C
|
||
2. humidity in RH%
|
||
3. is heater on in bool
|
||
2. HDC2010 Config (includes calibration values)
|
||
1. manufacturer ID
|
||
2. device ID
|
||
3. Measurement config
|
||
4. temperature offset
|
||
5. temperature resolution
|
||
6. humidity offset
|
||
7. humidity resolution
|
||
8. dataready and interrupt configuration
|
||
9. soft reset and interrupt cofniguration
|
||
10. etc (look at datasheet)
|
||
3. BMS Data Fast
|
||
1. pack voltage in V
|
||
2. pack current in A (use CC2)
|
||
3. min cell voltage in V
|
||
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)
|
||
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
|
||
4. BMS Data Detailed
|
||
1. soc_percent
|
||
2. remaining_capacity_mah
|
||
3. pack_voltage_mv
|
||
4. instantaneous_current_ma
|
||
5. average_current_2s_ma
|
||
6. discharged_mah
|
||
7. fault_bitmask
|
||
8. cell_voltages_mv
|
||
9. cell_min_index
|
||
10. cell_max_index
|
||
11. balancing_cells_bitmask --> indicates which cells are being balanced right now
|
||
12. num_cells_balancing
|
||
13. balancing_enabled
|
||
14. balance_threshold_mv
|
||
15. fault_flags
|
||
16. full_charge_capacity_mah
|
||
17. design_capacity_mah
|
||
18. time_to_empty_min --> based on what consumption?
|
||
19. time_to_full_min --> based on what charging?
|
||
20. state_of_health_percent
|
||
21. max_error_percent
|
||
22. cycle_count
|
||
23. total_cycle_count
|
||
24. average_power_mw
|
||
25. remaining_energy_kwh
|
||
26. design_energy_kwh
|
||
27. status_flags
|
||
5. BMS Data Temperatures
|
||
1. bq76942_internal
|
||
2. bq76942_cell
|
||
3. bq76942_mosfet
|
||
4. bq34z100_internal
|
||
5. bq34z100_cell
|
||
6. BMS Config
|
||
1. bq76942_fw_version
|
||
2. bq34z100_fw_version
|
||
3. all AFE safety settings (alerts and thresholds)
|
||
|
||
|
||
### MQTT topic structure
|
||
- /fleet/
|
||
- configurations/{ID}/
|
||
- hdc2010_updb/
|
||
- bq34z100_updb/
|
||
- hdc2010_updb/
|
||
- temperatures/{ID}/
|
||
- hdc2010_updb/
|
||
- bms_updb/
|
||
- bms/{ID}/
|
||
- data_fast
|
||
- data_detailed
|
||
|
||
### HDC2010 barebones Driver Requirements
|
||
- Needs to be configurable
|
||
- change resolution of measurements
|
||
- change measurement mode
|
||
- 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 |