Goals / Background / Strategic Fit / Requirements

Detail the behaviour of the BMS carrier board and how firmware should enable/control it. 

Monitors voltages, currents, temperatures, fan status and a whole bunch of other things relevant to the the battery and other battery related boards.

Board Overview (Firmware)

I/O 

• CAN 

• Kill Switch 

• AFEs (isoSPI) 

• Fan Control 

• Current Sense Board (isoSPI)

• Relays

Stuff that happens that board needs to deal with

• CAN Message recieved

• Monitor Temparature (AFE)

  • Too High→ increase fan speed

  • Too low → who cares (?)

• Car powered on

  • validate battery health / status

  • turn on relays

  • turn on current sense board

• Monitors state of charge

  • Voltage

  • Current

• Kill Switch flipped (?)

• AFE Under/Over volt

  • Disconnect relay

Overview of firmware responsibilities for BMS Carrier

1. Relay control: to close relays, pull the pin high and verify successful. There are two relays to control.

2. Killswitch: monitors killswitch status, if pressed, fault BPS

3. Current sense: talk to the ADS1259 through SPI, periodically read current, and fault BPS if overcurrent

4. Voltage sense: talk to daisy chained LTC6811s through SPI, trigger ADC conversions, read back the results, fault BPS if overvoltage or undervoltage

5. Temperature sense: cycle through 20 thermistors through the ADG731 MUX, trigger conversions, read back the results, fault BPS if overtemp

6. BPS heartbeat: periodically send a heartbeat to rest of car, ensure it’s acknowledged

7. Fan control: control 4 fans, notify if they’re stuck

8. Logging: log all temperature, voltage, current, fan state, and relay state data over CAN. Eventually over UART to a raspi for SOC, but not for MVP.

9. Passive balancing: tell the AFEs to bleed the highest charge cell until all cells are within 25mV.

Revised Block Diagram

Open

Design Notes

• Main initializes killswitch, current_sense, battery_heartbeat, cell_sense, and fan_control. 

• Killswitch, current_sense, and cell_sense need direct access to battery_heartbeat in order to quickly raise or clear faults.

Detailed Design / Modules

Main

• Initializes other modules, initializes CAN and other modules

• Stores the most updated measurements

  • Current

  • Cell voltages

  • Cell temps

  • Relay state

  • Fan speed

Data_tx

• periodically transmits over CAN the current, cell voltages, cell temps, and relay states

• only need to transmit fan states if it’s bad, we don’t need to log all the time

• Note: may be switched to an alternate form of communication, pending raspberry pi integration

Killswitch

• Initializes a debounced GPIO pin to handle killswitch presses

• Exposes init

Battery_heartbeat

• Periodically transmits battery status and receives acks

• Exposes ability to raise and clear faults based on a bitset, and init

• Opens relays in case of fault and updates relay state

Relay_control

• Statically sets relay state, updates stored state, and returns whether the relay state set was successful.

• Exposes set_relay_state

• Note: may need to have a delay when setting relay states to avoid drawing too much current at once

• Read the relay state through GPIO expander upon receiving interrupt

Current_sense

• Registers an interrupt to update the stored current value based on ADC reading

  • If the updated current value is above a threshold, raise overcurrent fault

  • If the overcurrent fault bit is set and the updated current value is below the threshold, drop the fault bit

• Should read at ideally 100hz

• Exposes init

Ads_1259

• Driver for the ADS1259 24 bit ADC

• Exposes ltc_adc_register_callback and init

Cell_sense

• To be ported from MSXII firmware.

• measures voltages through the AFEs

• measures temperatures through the auxiliary GPIO pins on the AFEs through the ADG731 multiplexer

• Raises / lowers faults similar to current_sense, including overcharge, over temperature, under charge

• General structure is an FSM that usually remains in idle state, but moves to a “voltage reading” state or “temp reading” state whenever reading.

  • will likely use this approach for passive balancing as well

Fan_control

• Periodically updates the fan speed based on the temperature

• Uses an offset linear fan control curve based on the desired operating temperature of the battery (refer to datasheet)

• Exposes init

• will need a driver for the ADT7470 fan controller

Passive_balancing

• determines which cell voltage is the highest

• balancing is not required if cells are within 25 mV of each other

• periodically raises an event to the AFE FSM to send a broadcast command to set the balance_control pin for whichever cell needs balancing

Can_handler

• has access to main storage

• handles relay can messages

• handles center console can messages

Raspi

• toggle the 5V_EN pin when we want to turn the raspi on

• send data to the raspi through UART

• Receive data from raspi through UART

Other questions:

• What’s passive balancing?

  • Balancing is making sure cells are all at the same voltage so one module doesn’t limit the charging current

  • Passive balancing is using up charge from high voltage packs through a resistor

  • Toggle balance control on the highest voltage cell

  • Look at AFE data sheet for how this works

  • “We tried” in MSXII, probably not implemented

  • The difference between the highest and lowest voltage cell should be < 25 mV

• How do you tell if the battery is charging? Re: directional temperature faults

  • Current sense gives positive vs negative current

  • Ask Liam if positive is in or out / if negative or in and out

• What timing is needed for the relays?

  • Part number EV200HAANA, datasheet has specs of current in it

    • 100 ms 4A, afterwards 130mA

  • We don’t want to draw 4A from more than one relay at once, so wait at least 200 ms

  • Relays have a sanity check in an aux coil: aux coil will mimic the main coil.

  • Relay control: always check after toggling state, if it didn’t toggle, either retry or fault. Waiting 100 ms between closing it and checking the state is good.

• Does order matter for relays / what order?

  • Always close HV_GND first.

  • Note: there’s a relay for MCI and for Charger interface

• What’s considered fast for current sense measurements? 

  • Theoretically should do 14 khz

  • 100 hz is good, below 20 is bad

    • Based on coulomb counting, current always has sinusoidal components (from motor controllers, since we drive motors with sinusoidal phases), so higher frequency means better SOC accuracy, also MPPTs don’t have perfect DC output

• What’s / Why UART?

  • We have a library so we’re good

• Do we have to receive anything from the pi?

  • Right now no. Eventually, yes. No sending over UART either for MVP elec.

• What’s needed for the RPI software?

  • Nothing right now.

Meeting Notes

• logs all 

  • Voltage, 

  • Temp, 

  • Current

  • Relay States

• Controls

  • Relays

• used for state of the charge model: 

  • state of the charge status of battery how much energy

  • we need fast logging for a good soc model

  • overcharge

  • over temperature

  • over current

  • undercharge

  • power distribution tells u something’s wrong
    
    

    • dc dc failed

  • precharge board: 

    • precharge failed 

  • controls the relays

  • if AFE undervoltage, we disconnect the relays

  • you can also disconnect from car power button so that comes from can

  • other conditions: 

  • controls fans based on the temp

  • car turn on: checks battery pack status, then connects relays

  • turns on the current sense board: firmware doesn't need to care it's literally a line that goes to it.

  • RPI will be SOC algorithm
    
    

    • connetion between pi's haven't made decision

How it works: 

• Three AFEs 

• Temperatures measured via thermistors (AFEs)

• gpio's control the mux (for AFEs)

• adc: for reading measurements

• we talk to the AFEs and Current Sense using iso-spi

• LTC6811 is the chip (AFE/Battery Monitor) (6811-1)

  • According to the datasheet, the 6811 is pin and software compatible with the 6804 used in MSXII. The changes seem to entirely affect electrical characteristics.

  • So we should be able to reuse the majority of AFE driver code

Killswitch:

• The killswitch MCU has an Enable Line (PB9) and Monitor Line (PB5) 

  • The Enable Line is an output from the MCU that causes the relays to close if the killswitches are closed 

  • The Monitor Line is an input to the MCU that measures the state of the killswitches 

• Enable activates high side driver which sends a 12V signal to the killswitches 

  • If both killswitches are closed, the signal returns to the BMS carrier and powers the main relay coils 

  • If a killswitch is pressed (Open), the relay coils do not receive the 12V and they open, shutting off the car 

• A monitor line is required because the regulations require the car to enter into a BPS fault when a killswitch is pressed 

  • We need a way of measuring if the signal has come back to the BMS carrier from the killswitches 

  • Lower-left corner of schematic page 5 shows a voltage divider that sends a 3.3V monitor signal if killswitches are closed and 0V if killswitches are open

Changes that probably need to be made to MS12 plutus to work with MS14 bms carrier board (if that firmware is reused, not comprehensive)

• change heartbeat behaviour (heartbeat functionality needs to be figured out first)

• add/remove CAN events that can happen

• change/verify Killswitch behaviour

• LTC6811 should be pin/software compatible with one from MSXII, pin mapping/drivers should be updated to reflect new pinout scheme

• everything else mentioned above/below

Questions

Misc Links

Some Guys Masters Thesis on EV BMS - https://pdfs.semanticscholar.org/7b9d/934eaf10114c091e1229ed4d65de3a1002a0.pdf

LTC6811 (Battery Monitor) Datasheet - https://www.analog.com/media/en/technical-documentation/data-sheets/68111fb.pdf

Car's Power States

Old Block Diagram 

Open

This block diagram is highly inspired by MSXII's Plutus. Some minor adjustments were made to make it slightly more easy to understand.

Reasons to revise:

• Relay_control doesn’t need to be under fault_handler since it’ll also receive messages from center console

• Event driven architecture

• System_init is not necessary since startup logic is handled by center console

• Fault handling is also moved to center console

Open