TODO :)

Firmware Qs:

• Cruise control

BMS Architecture Qs:

• How does the current sense board work?

  • Shunt resistor

  • communicates to carrier over iso-spi

• How does the AFE work?

  •  

• How many modules per AFE?

• How does the BMS carrier work? For example, the current sense board detects overcurrent during charging so it wants to open the contactor to disconnect the battery pack. What is the series of events that happens?

  • current sense sends readings over iso-spi to carrier which has stm32 and opens contactor

• How is the BMS logging information for telemetry?

BMS fault criteria:

• Over temperature (charge/discharge)

• Over-voltage

• Under-voltage

• Over-current (charge and discharge)

BPS Seminar and Testing Procedure Takeaways:

https://www.americansolarchallenge.org/ASC/wp-content/uploads/2015/02/ASC2016_Protection-System-Test-Procedure.pdf

• States

  • Safe start-up

  • Safe operation

  • Safe shutdown

  • Fail safe 

• ASC wants us to call the BMS a BPS, we need to refer to it as a BPS in PVDR and VDR

• BMS vs BPS

  • BMS is for battery optimization while BPS is for cutting off the battery when parameters are not in a operating limits

  • BMS should control the state of battery pack source and sink requirements to never reach BPS limits

  • If BPS and BMS firmware operate on common hardware, then no BMS functions should pre-empt/interfere with BPS functions

• The Ideal BPS:

  • No faults or required reset at any point along race

  • Protected from entering fault states by BMS

    • solar sense board? limits shut off before overvoltage and overcurrent

    • motor controller interface limits current and regen based on SOC

      • secondary alarming levels to prevent BPS fault

      • example: temp is nearing max, motor limits current draw to limit battery temp (this slows vehicle down but avoids fault and forced stop)

  • vehicle has proper telemetry, data logging, driver display for team to know SOC and other operating parameters

  • design is robust to electrical noise, vibration, elements, users

  • system has been tested and calibrated to have accurate measurement values over entire operating ranges as a total system

  • clear indications of fault, driver display (internal), BPS fault indicator (external)

  • fault state electrically isolates all sources and sinks

• BPS Scrutineering:

• Scrutineering will test for triggering all fault conditions

  • Over temperature (charge/discharge)

  • Over-voltage

  • Under-voltage

    • Note: high acceleration -> higher brief current draw -> higher voltage drop over internal resistance of batteries, may drop our measured voltage below the minimum voltage

      • May need to limit acceleration at low battery ?

  • Over-current (charge and discharge)

• Team is responsible for providing harness, tools, sense leads, thermistor, current sensor for test

• Fault state must be demonstrated to latch

  • fault state stays until it is cleared manually while the car is not in motion. fault clearing process is strongly recommended to include someone other than the driver who can visually inspect pack 

    • We need a written procedure to conduct everytime BPS faults before we clear the fault

• Detailed testing procedures are in battery test procedure document

• After passing scrutineering, BPS must be locked to prevent changing of fault trip points

SOC Qs:

• Would a state of charge algorithm run off the stm32 microcontroller on the MCU? Would it need to then be written in C?

  • Ideally should not have complex algorithms running on the mcu

    • Recursion not good

  • Find simpler algorithm to estimate soc on mcu to display on drivers panel, more complex algorithms can be calculated through telemetry laptop (strategy)

• Current sense to carrier through isoSPI, carrier to CAN through the CAN bus on carrier

Solar Qs:

• Do the solar cells charge like a power supply?

• How is current from solar cells limited?

• Will solar always be able to match the voltage of the pack? 

Dashboard Qs:

• Is Rasp Pi running the OS for the dashboard?

  • esp32 used for telemetry

  • esp32 is cheap, has wifi and bt, generally small power

After this meeting:

• Eventually will need to create a testing procedure for BMS and electrical system

Power Architecture

Initial Charging

• Each Module charged individually on a power supply

• Charged modules placed in car for scrutineering

Solar

• Solar cells connected to MPPTs

• Output of MPPTs goes direct to batteries

• Solar Board just used for monitoring and operation of the MPPTs

• I2C is for output of the MPPTs

• SPI is for input of MPPTs

• Relay used to disable/enable MPPT output

• Should not need to limit solar panels into batteries (This still needs to be confirmed based on understanding limit conditions of MPPTs better )

  • If we reach max battery conditions, will just trickle charge

  • Assuming that when MPPTs reach voltage limit, the current will taper even if panels get more sun

MPPTs:

• Need Configuration (via potentiometers) → Configured to certain output voltage (will only output if it can meet requested voltage)

Power States

Questions:

• Are all boards powered by aux? For the whole race?

• Does switching to main switch all power to main?

• Can we power the boards via aux initially? (only BPS)

OFF

• Relays are disconnected, batteries are not plugged

• AUX Powers Centre console and power distribution

•  

MAIN