BMS Carrier Validation - Rev 1.1 Walkthrough

Owned by Micah Black
Last updated: Jun 09, 2020
9 min read

I decided to make a confluence page as I validated the BMS carrier rev 1.1, so here it is. I’ll be following the validation guide (Validation - BMS Carrier ).

 

Before Starting

  1. Inspected the board thoroughly for solder bridges and bad solder joints, and fixed up a few.

  2. Gave the board a good clean with a toothbrush, ethanol (rubbing alcohol) since I didn’t have any isopropyl alcohol, water, and a cloth.

  3. Made sure the controller board that I was going to use works by running the booard validation scripts (Board Validation ).

  4. LEDs were checked for the correct polarity.

    1. LED5 (which is actually a duplicate of LED4), the fan indication LED was installed backwards.

At this point, the isoSPI ICs are not populated, nor are the micro fit connectors for the HV relays, killswitch, or fans. We will add them as necessary as we go through the test. This board has already been powered up and some testing done - 12V was initially connected backwards, so there could be more issues on this board.

Power Validation (May 5, 2020)

  1. GND, 3V3, 5V, and 12V test points are all isolated from each other, tested with the multimeter continuity test.

  2. Removed R23. This is a 0 ohm resistor between the Current Sense output of the load switch and the input of the MCU for measurement. Why do we need to remove this (@Liam Hawkins)?

  3. Without the controller board connected, 12V tested good. Installing the controller board, both 3V3 and 12V are good!

  4. 5V does not seem to be powering on. It slowly rises to 1.8V, and then stays there. I was artificially turning on EN with another power supply connected to wires I had soldered to R3. I realized that the wire also touched R2, and caused this behaviour. Fixing this, the 5V converter works and we get 4.935V.

  5. 86mV Vpp on no load, 20mV Vpp for both 1A and 2A loads. Oscilloscope was set to AC coupled, triggering on rising edge, with a 1X probe connected to the GND with the probe’s alligator clip.

    1. Note - Good page on measuring power supply noise: https://www.edn.com/testing-a-power-supply-noise-part-2/

^ No load

^ 1A Load

^ 2A Load

Power Validation Part 2

I replaced the LTC6820 ICs and am now getting a 0.22V on the 3V3 rail. They seem to be drawing too much current or causing a short. When not powered, the 3V3 line does not show any signs of a short, has about 170k of resistance to GND, whether or not the controller board is in place - this test was done measuring between the 3V3 and GND connections on P7, which it turns out is not correct. The GND that is labelled on this connector on the rear (which I assumed was the board GND) goes through the HV relay activation FET before going to board GND. So I was never measuring the real GND point when measuring this resistance. A careful look through the schematics would have revealed that, but fixing the silkscreen to not show GND might also be a good idea. Measuring between the GND test point on the right side of the board and 3V3 indicates about 1Ohm of resistance → so we found an issue - likely from the isoSPI ICs.

I double checked the pin assignment and layout for the LTC6820 ICs and it all seems good.

So my conclusion is busted ICs, likely due to the original plugging the board in backwards. We will order some extras and test it out.

Removing the isoSPI ICs, the board fine again, no more shorts on 3V3. At this point, I plugged in the controller board that I now had programming properly, and was able to activate the 5V converter by using the PB0 pin set in firmware. And it still works!

HSD Current Sense Output (May 7, 2020)

  1. R23 has been removed

  2. HSD output connected to E-Load

  3. Board supplied with 12V

    1. With no code on the board, the e-load is measuring 0.005V, so it is correctly stopping the current from being drawn.

  4. (Steps 4 and onwards) Enabling the pin, the e-load measures 11.988V on the output at no load.

    1. Setting E-load to 100mA and turning it on, it only draws 48mA and the measured voltage on the e-load is practically 0 (0.0022V). It seems like something is faulting.

    2. Thinking this could be due to the slew rate and control loop of the DC load, I tried raising it slowly 10mA at a time. At 70mA, it seems to fault again and goes back to about 48mA.

    3. Turns out the HSD is faulting. Measuring the N_FAULT pin of the HSD, it stays high (3V3) until the current raises above 70mA, then goes low - signalling a fault.

    4. Also - @Liam Hawkins on measuring the voltage across D2 - its underneath the controller board. Might be good to update the instructions to measure the voltage across C21 instead.

    5. Playing around with it a little more, the exact current that it faults at it is 64mA and does not recover until the current goes below 47mA. When it faults, the HSD_CS pin (measuring across C21) reads 2.65V. Just before it faults (around 62mA) the pin reads 2.25V.

    6. Time to read the Datasheet for the HSD.

    7. The current limit should be 51mA according to Eq. 4 in the datasheet (0.8 * 300 / 4700 = 0.051mA). With the margin of error at the low range of +- 25% (Table 7.5 in the datasheet), we are within the range given. This lines up with what we have been testing here. Under normal operation, only 18.3mA current should be drawing, according to the nominal coil current for the G6RN-1A DC12 relay datasheet.

    8. @Liam Hawkins mentioned that this test should trip the current limit, so we are all good - the voltage across D2 was always lower than 2.7V which is a safe level for our controller board.

R23 has been added back (I just put a blob of solder since I could not find the original 0 ohm resistor).

 

Capacitor Inrush Current

I used the clamp meter in peak mode to get an estimate of the inrush current since I don’t have an appropriate shunt resistor here.
Peak current observed was 2.2A (with a 13.5V supply and a current limit on the power supply of 5A).
This seemed like it was high than Liam’s specs, so I tested with the oscilloscope, using the power supply cable as the shunt resistor (measuring the voltage at both ends of it). The cable has a voltage drop of 28mV on a 2A current draw, and the peak current measured was about 8A. Note that this only lasted about 3uS. I am not confident in the oscilloscope measurements since we are dealing with inrush currents and thus EMC - and my test setup included long leads for the oscilloscope cables which increases the error. I propose that we find a better way to measure inrush current - we need a board or adapter that we can attach to any power supply (or ultra-fit/micro-fit connector) and oscilloscope to measure the inrush current easily, without much setup.

The kill switch operation was also checked at the point, and it works as expected. The relay opens when the kill switch is pressed. The circuit is so simple, so I didn’t expect any issues here.

Inrush Current Revisited on May 14, 2020

Funny how implementing some of the industry ‘best practices' tend to give you more accurate results - they’re not just best practices for a reason - most of them are based on fundamental laws and relationships in electronics. In this case, we were dealing with the rate of current rise, controlled directly by inductance. So the goal with the measurement is to minimize the inductance of your measurement setup. In this case, minimize the loop area of the GND return path to the oscilloscope. To achieve this I did 2 things:

  1. Created a short GND return path for the oscilloscope probe (as opposed to the alligator clips) by using a piece of 22AWG solid core wire and twisting it around the barrel of the scope probe:

     

  2. In order to make use of this, I had to provide a resistive element which also had a low inductance - which a current sense resistor is great for! In this case, I used one from a cheap 4S BMS that I got off Aliexpress a long time ago (the BMS itself is terrible). I would expect probably a 5% tolerance or so on the resistor given how cheap the module was.

     

     

And we got some much better results:

Below we see the inrush current across the 5mOhm shunt resistor. Ignoring the super high frequency transient at the 0us mark (which is likely cause due to wire inductance, and is just a measurement artifact) we see at voltage at cursor A of 4.6mV. Using Ohm’s law, I = V/R = 4.6mV / 5mOhm = 0.92A. Notice that we also see the current dropping in somewhat of an exponential manner, as we would expect for an RC circuit. I am much more confident in this result than with the earlier testing. The second peak, at cursor B, is just over 2mV (the actual peak is hidden behind the cursor line) which gives us 0.4A. This could be where the precharge circuit activates the bypass FET, but it does seem a bit early for it to kick in given the 10mS designed target. This testing was done activating the relay on a 10s period with 5s off time, so the capacitor on the gate of the FET might not have fully discharged before activating again. Either way, the current is within an acceptable range.

How is this ‘acceptable range’ determined?
The purpose of limiting inrush current is to limit the supply voltage droop at the input to the board during these high current moments. Too high of a voltage droop, and you could risk resetting sensitive measurements or the MCU, which we certainly don’t want to happen on the car. We have had issues in the past relating to inrush current with the Power Distribution Board Rev 1.0 in the power selection section (later moved to its own board) which caused reset loops.
The operating range of our AUX battery is anywhere from 9-15V or at least around there (its 10S 1P NiMH cells). As long as our supply voltage does not dip below 9V, we should be fine. We will later implement a limit in firmware to determine if the AUX has enough charge left to provide the inrush current and not droop below 9V, causing the car to reset (we had issues with this in MSXII as well). Let’s take a look at the graphs.

Powered from a Power Supply, with V = 13V

Powered from the AUX battery, V = 13.2

With either supply, the voltage droop measured at the input connector of the BMS Carrier is below 2V. This voltage droop test should be re-run with the contactor connected and measure the voltage droop when switching the contactor (almost a 4A load) as that load is larger than the inrush current observed. So this is all good from the perspective of the capacitor inrush current.

Enable Relays

Pins set according to instructions (PB9, PB3, and PB4 all HIGH)

Audible click heard and all GNDs are connected!
The red LED on the controller board is very bright here. Might want to consider changing resistor values?

For added validation, I connected an actual EV200HAANA relay to the board. It switches on properly! Kill switch operation was verified to be working again (because I like hearing relays click on my command).

Note: The HV relay connectors near the relay were hard to remove as the relay blocked being able to grip the back of the connector to pull on it. Might want to consider repositioning for future revisions.

 

isoSPI

Now to reconnect the isoSPI ICs and test them.

The 5V converter seems to be turning ON by default… Turns out that in the code I’m using the default state for initialized pins is high, so no issue here.

My firmware knowledge if very limited at the moment, so I will wait until I learn to generate a clock pulse or just jump straight to the AFE validation and hope it works.

Testing out the AFEs - we got them working, so isoSPI seems to work well!