Task Structure
SD Card Logging Task - 500ms (Maybe more, depending on how much data we are logging) with priority 3
Considerations: We CURRENTLY (September 8, 2024) have 17 messages on CAN. For an overestimate and to include undeveloped systems like MPPTs and IMUs, let’s assume we have 30 messages in total. Assuming each message is the full 64 bits, we will have 1920 bits in total. This gives us 3840 bits/sec. This is a relatively slow data rate.
Needs more research but good resources:
https://www.eevblog.com/forum/microcontrollers/sd-card-writing-speed/
http://elm-chan.org/docs/mmc/mmc_e.html
XBee UART Task
Explore CAN RX configurations. We have a few options, I will list the ones that I am thinking of currently:
Runs in fast cycle of Master Task
Stay with current CAN architecture and RX all values at a set frequency. Maybe every 50ms? This will ensure timing consistency for all data being received but I do not think that is needed.
PROS: Already exists and is very easy to implement
CONS: We will not support data logging for mono-repo devices like IMU and MPPTs, assuming they transmit at faster intervals. Even if we have them transmit every 50ms per second (Like the rest of our car), that could significantly reduce how much data we have.Runs continuously with priority 2
Write a custom CAN ISR for telemetry so every time we receive a message we will increment some counter/index, and the XBee UART Task will trigger a UART transmission if the counter/index has been updated.
CIRCULAR BUFFER: Read and write index. When the ISR is triggered and a message is received, increment the write index. Check if read index == write index. If not, we will UART transmit the data to the XBee for logging, and increment the read index.
PROS: Will support data logging for all devices, regardless of the rate of transmission.
CONS: Requires us to rewrite a CAN HAL for a single project. Considering that the code already exists and we are only updating the implementation, it is not too difficult.Runs in fast cycle of Master Task
Increase entire vehicle fast cycle to 25ms.
PROS: Easy to do, change one variable and use our existing CAN infrastructure. Will also support faster data transmission in the case our MPPTs and IMU transmit at a faster data rate
CONS: May cause system failure if some of our boards for some reason cannot operate at a faster rate
How to use XBEE
https://www.printed-droid.com/kb/programming-the-xbee/
https://maker.pro/arduino/tutorial/interfacing-xbee-module-with-arduino
TX: Send UART to the XBee. It will handle the RF communication for us.
RX: Receive UART from the XBee.
Things Other Teams Do
UBC: Runs a bare-metal application that runs off ISRs. Warned us about packet linkage occurring, where adjacent packets have no distinction on the receiver's side. Seems to be a transceiver issue and is likely not a FW issue. However, we can include software checks to prevent this.