Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BMS Protocol #29

Open
misprit7 opened this issue Mar 14, 2021 · 3 comments
Open

BMS Protocol #29

misprit7 opened this issue Mar 14, 2021 · 3 comments
Labels
enhancement New feature or request High Priority

Comments

@misprit7
Copy link
Contributor

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 misprit7 added the enhancement New feature or request label Mar 14, 2021
@misprit7
Copy link
Contributor Author

misprit7 commented Jul 4, 2021

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
Copy link
Member

Esouder commented May 13, 2022

  • check this box when we verify that isoSPI is working on the new FC board.

@Esouder Esouder added this to the RCS Test Stand milestone Jun 19, 2022
@kxing28
Copy link
Contributor

kxing28 commented Sep 18, 2022

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.
  1. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request High Priority
Projects
None yet
Development

No branches or pull requests

5 participants