Micah; Hardware + MSXII; Joy

Owned by Joy He (Deactivated)
Jul 21, 2021
4 min read

  • Being able to see it from anywhere

  • Historical data

    • Battery, tracking cycles as you’re charging, discharging

    • Currents that we’re monitoring

    • Have everything back forever (doesn’t need to be easy)

    • Last 10 minutes to last half hour is most important

  • Debugging: where car has unexpected behaviour

    • ie large surge in current

    • Or didn’t respond to signal, or buttons

  • At MSXII, all over the place wrt role

  • Make sure battery is still safe, running properly

  • Pulling out cells and modules

  • Maintenance

  • All over the place, members be able to work with any boards

    • Ideally

  • One person did everything (all the boards), helping everyone learn about all the boards

  • Solar was frustrating, spent many hours, solar never worked

  • Swapping things out before competition

  • Solar panels didn’t work — basically an electric car

  • Three main parts

    • Solar — gets energy

    • Battery — stores energy

    • Motor — energy → movement

  • Hadn’t really adopted it as a tool

  • Guessing at what was happening (without dashboard)

    • Whenever pressed horn current would die; WHY? Identified that it was too much current, but that was mostly a guess by very experienced people



  • Had issues with motors, motor controllers overheating in the past

  • Know voltage of battery system, generally same as motor controllers

  • Wants to know which group of cells within each module is failing

  • 50 cells in each module (2 groups of 25 that are in parallel), 18 modules

  • Don’t look at data unless there are faults

  • Voltage in battery pack as a whole — need to know whether need to charge battery pack

  • Motor controller vs motor temperatures are different 

  • Relays — looked at during start up

  • aux, dcdc, external power supply

  • power distribution — first board they look at when there are faults

  • relay states (BMS...) — first thing they look at

  • power draw over interval — double check expected calculations

  • supplemental pack only powers driver ventilation, horn (if fails, it’s ok)

  • Range left — based off of voltage of battery module

  • check battery fan if battery temp getting too high

  • charger fault less critical, use charger less often

  • state transition faults — check upon start up

  • important to know that you’re looking at latest data (telemetry system connected?)

  • dcdc, main current — why grouped together? clarify with firmware

  • usually using regen brake, as opposed to regular

  • when hazard lights, lights, horn are on, mech brake engaged emphasize it more (notification)

    • history of last 10 seconds when recently used

  • ready to drive — high voltages, has a pre-charge sequence; when this completes, ready to drive

  • any spikes, transitions (if goes from low to high), state changes (ie relay)

  • identify which board is causing issues, then can get car open and mess with board

  • sharp edges

  • raw data, as opposed to smoothing lines out

  • scaling graphs for data that’s currently being displayed

    • zoom in on the data

  • absolute values, not just trends

  • everyone should know what the acceptable ranges are, and spot if the data is outside of them

  • battery fault, motor faults — car has likely already shut itself off — most severe faults

    • immediately look at the historical data relating to the faults

    • immediately open battery pack, get a fan in there to cool it down

    • look for outliers, or drove over a large hill?

  • current, voltage, relay states, look deeper into what’s connected to that fault

  • ignore less severe faults during the competition

    • look into them at the end of the day, or at checkpoint

    • look into historical data from 5 to 6 hours ago at the time of the fault

  • would like to be able to view data directly on dashboard (as opposed to downloading the data onto a text file)

  • severe ones should be really obvious, big red flashing?

    • should be obnoxious, get your attention

    • but be able to dismiss them

  • less severe, should be visible and accessible, but not obnoxious, could ignore (ie yellow)



  • historical data for booleans as well

    • look up logic analyzers (on and off, square wave type thing)



  • timelines, scroll, zoom in and zoom out



  • comparing front battery voltage to rear battery voltage could be useful to overlay

    • stuff that’s directly comparable

  • not often do overlays

  • stack data like in here

  • look at how oscilloscopes behave

  • wants to see exact value at that time (on the right, corresponds to green line)



  • selectable stacking? choose things to stack on top of each other

    • ie checkboxes to say I want this this this data

  • or follow categories he laid out

  • separate screens for each of those?



  • generate visualization of 5 or 6 signals interacting — user created graph/view

    • custom graphs

    • uses python to create quite a bit of custom graphs

    • script to gather data? gather from multiple timestamps