Ryan Dancy; Firmware; Catherine

What is the purpose of the telemetry dash for firmware

Way to easily get info to figure out what’s going on inside the system
Sort through CAN information easier
The dash makes it easier to read the data, sort through the CAN messages (will be updating one particular value multiple times and while we can read the raw data, its easier to read it off a graph or table)
Sometimes all we need is just a signal (smth good or bad is happening) and the telemetry dash can help to make it more noticeable

Card sorting notes

B - boolean, S - string(enum), V - value
Babydriver is not being used at all
Solar 5 and solar 6 are the same thing
All of the ‘faults’ are VERY important - need to know what’s going wrong
State transition fault is important - transitioning between parking and driving etc.
Information on currents (mostly useful to hardware)
E-brake engaged → mech brake engaged (it’s now mechanical)
Ready to drive signal is similar to power-on thing
Major state changes (powered on, battery plugged in) are not too critical but good to know that they happened
Drive output from the centre console? MCI has to know states from the centre console so the message is sent from the centre console to MCI to update the MCI drive state.

Meaning of the information on the cards

In the driver display documentation there’s a list of faults
Solar 5 and solar 6 are identical
- 5 or 6 refers to the number of mppts
- measure stuff from the solar panels
Power select status
- Selects between power (power on or off)
State transition
- Driver, neutral, reverse, park - drive states
Battery fan state
- Not bool - status codes 0-10 with each number having a specific meaning
- 0 is success, anything else is failure

Dealing with real time data? Or historical?

Will probably need both of them (hardware will likely require historical graphs)
- Eg. racing and smth weird happens but they continue driving, they will want to find the logs from that time and see what it was that happened
- Want to be able to locate data by time to allow them to refer back to it later

Walk through a scenario where they would use telemetry

Someone in the chase car / backseat, constantly monitoring feed from the car on laptop, monitoring that everything that should be happening is happening, and looking for anything outstanding that may be concerning
Making sure that all of the state changes messages are happening when they’re supposed to (status from the motor controllers)
Get alerted FAST if any of the faults are happening
More important for debugging than alerting
Biggest rule for the telemetry dash → something weird happened… why?

Who will be using the dash on firmware?

Will they get any prep for usage of the dash?

Should be intuitive enough that they can be thrown in and understand what information is
They will be familiar with logging to CAN but not necessarily experience in digging through logs
Maybe have some sort of information feature which gives some details on what each thing is (one of those information icons)

Are there any current tasks / projects in firmware that involve reading through telemetry?

CAN explorer project - GUI for sending messages
Probably don't need to decode the bootloader messages which differ - but be aware of them
When reading through telemetry, CANDump which displays all the data in hex for each CAN message lmao, another program which, when runs, takes over the terminal window and based on the id, updates a spot on the screen
Has nothing to do with priority - harder to find relevant data

What makes things easier?

Sort logs by message and sort logs by the time they came in
Filter out value messages in sequencing things? Sort by type of CAN message?
Specific data is better shown as graphs (sequencing - show trends) or values (traditional logs), so differentiate those!