[TASK] Telemetry Unit

[forrisdahl]

Description of Task

Develop firmware for the Telemetry Unit MCU, responsible for reading data from sensors, monitoring system health, and communicating with the main control system over CAN bus. The firmware should respond in real-time to incoming command messages and provide system status feedback.

---

Suggested Workflow

• Research all necessary peripherals and sensors
• Write drivers for all peripherals (CAN, sensors, comms)
• Integrate all peripherals into a single firmware project
• Test functionality on development board
• Validate on final PCB hardware

---

Specifications

1. CAN Communication

   • Receive control commands over CAN (e.g., thrust setpoints, PWM duty cycles)
   • Parse incoming frames according to the thruster CAN specification
   • Transmit periodic status frames (e.g., current draw, temperature, fault status)

2. Sensor Interfaces (Serial Communication)

   • Use UART, I²C, and/or SPI to communicate with sensors
   • Ensure correct initialization and error handling for all sensors

3. Safety and Fault Handling

   • Implement watchdog/timeout: stop thrusters if no valid CAN command is received within a set time window
   • Detect and report faults (overcurrent, undervoltage, communication loss, sensor errors)
   • Detect water leakage and shutdown system

4. Modular Code Structure

   • Separate CAN, sensor drivers, and main control logic into their own .c/.h modules
   • Define clear interfaces to maximize code reusability across other MCU projects

---

To-Do Checklist

• Research peripherals and sensors (e.g., ADCs, shunt resistors, current sensors, CAN transceivers)
• Select components and confirm availability for PCB integration
• Implement drivers for each peripheral (ADC, current sensor, CAN)
• Integrate all peripherals into MCU firmware
• Verify functionality on development board (bench testing)
• Validate on final PCB hardware
• Document configuration parameters (thresholds, scaling, CAN message format)

Contacts

• @forrisdahl
• @IbixD97

---

[chrstrom]

Something to consider (started on manta/beluga but never finished): Since you're pulling a vacuum in the el-house, you can use an internal pressure reading to fairly quickly detect leaks. A good alternative / addition to dedicated leakage sensors (which you will need many of to ensure good coverage). 😼

Do note that temperature changes will also lead to fluctuations in pressure, so not quite a trivial addition

[IbixD97]

When considering the communication protocol choice for sensors, UART is only a one-to-one interface since you can not connect more than one sensor for each UART channel. So if we are talking about, and hopefully are, many sensors, then it is not ideal, or even doable to use UART as you would soon run out of channels and it would be mess with wires (electrical would hate you).

I2C has less wires (only 2 wires) but has a higher risk of going down since if one node is down then the entire bus is down as well, but SPI can very easily persist over that (though except when the sensors are daisy chained but I think that is not needed for us).

SPI has some more granular control as you, from the master that is, always have control over clock and rate of data transfer. Plus devices with SPI interface, allow very easy access to specific registers to have extra control over how the sensor data is read and all that.

I2C can connect up to 127 devices over one line, SPI has, in theory, no inherent limit though the number of available chip select can force you to daisy chain if you have more sensors and the bus capacitance can be annoying for electrical peeps to handle or even detect if any issue occurs, though I think we have too few sensors for either of these two to be an issue.

Finally, SPI is faster than I2C, but SPI becomes quite more susceptible to electrical noise and timing issues if the distance between the MCU and the sensor is long. So if any of the sensors are going to sit relatively far, then I2C might be the safest choice.

Good devving.