UBC-Rocket / Whistler-Blackcomb-v2

Flight computer firmware for Whistler Blackcomb rocket.
http://www.ubcrocket.com/
MIT License
18 stars 4 forks source link

BMS Protocol #29

Open misprit7 opened 3 years ago

misprit7 commented 3 years ago

Implement reading from BMS battery voltages and add load balancing and logging with these values. Will have to talk to Pablo to get more specific specs on what exactly is required.

misprit7 commented 3 years ago

To follow up on this, the protocol in question is ISO SPI. The specific chip that has to be communicated with is the LTC6812ILWE-1.

Esouder commented 2 years ago
kxing28 commented 2 years ago

I'm leaving this issue. Here are my (unsorted) notes on this whole thing.

BMS Communication Diagram: Flight Computer --- SPI --- isoSPI LTC-6820 --- D-SUB --- D-SUB --- LTC-6812

Fundamental Goal: Report voltage of our batteries

Problems in the way

  1. Verify the flight computer's communication is correct We are SO close. There is code in the bms_spi branch. If you probe across the differential output of isoSPI, you can get spikes that match isoSPI signals. However, the Flight Computer is loose near the SPI pins (CS, MOSI, MISO, CLK), so bumping the board or tapping on the board will cause weak connections. BUT it is confirmed to work, when that mechanical connection isn't bad.

  2. Verify the BMS chip can respond to differential signals We did this before but it would be good to try again, to make sure the chip is responding properly:

    • Send in any differential information to the BMS input (ex. a 3.3V 0.25Hz clock on IA_P, GND on IA_N using the AD2)
    • Probe DRIVE (Pin 49) -- it goes to high when the chip receives differential data. It goes to low if it doesn't receive a valid command after 2 seconds. If we can see the battery chip is responding in this way, we can be relatively confident that entire chip is working correctly.
  3. Find the correct command for the flight computer to send DISCLAIMER my understanding of this is not very solid. But don't attempt this until you've verified electrical signals are working correctly!! Else the debugging will be hell. The flight computer code in SpiTask has a way to send commands over SPI. pg. 59-60 of the datasheet has every LTC6812 command. They're 13-bits, which is sent in 2 bytes. A lot of the bits are dependent on what 'mode' the chip is in. MD should be in 7kHZ mode. Every command needs an error-correction code (PEC) after it. The BMS rejects it if the code isn't correct. It's calculated off a terrible algorithm, but there is C code (with some syntax errors) on page 77!! Get this code onto the flight computer so we can use it to calculate codes.

There are 2 steps to actually get data off the board: We might need a config step here, I haven't figured that out.

  1. Run a "write" command (ex ADCV) to store data into registers on the chip. With 7kHz, measuring all the cells, the command is 011 01100000 = 0x03, 0x60 Error Code (PEC): (from the code) 0xF4, 0x6C

  2. Run a "read" command (ex RDCVA) to get the data out of the BMS. Command: 000 00000100 = 0x00, 0x04 PEC: 0x07, 0xC2 I believe the BMS spits out bytes stored in the registers. Every 2 bytes is the voltage of 1 cell. You'll need to convert that into a double somehow, I don't know how it's represented.