FlexiBMS - 0.2 HW under work - Flexible configuration and charging BMS

It’s a voltage divider so you need the current flow? no current flow no divider :smiley:

What do you mean? If you talking about LTC voltage divider then it’s for its output voltage or I am wrong?

Oh i assumed it was a voltage divider. No time to look closer at the moment.

If I understand correctly its feedback loop for LTC to keep voltage right, so if you add diode next to CHR FET it will only allow charging via CHR terminal or you can use another FET back in back so that way if the switch is off nothing happens.

Another suggestion is to drop LTC and use your MCU to boost :slight_smile: http://www.st.com/content/ccc/resource/technical/document/application_note/ec/9c/b0/81/b5/12/4e/21/DM00108726.pdf/files/DM00108726.pdf/jcr:content/translations/en.DM00108726.pdf

I have considered both options earlier already. a Diode would block most of the “back-flow” current, but it would also introduce more heating when charging with either charger input and as can be seen, the board is already running hot enough. Drain-to-drain FETs are tricky due to the space problem + driving them both + doubling resistive losses in conducting mode. But as I said earlier I’m gonna look into the options and then gauge the feasibility of the implementations.

2 Likes

Thank you very much for keeping us updated ! That’s a real and freaky R&D job !

1 Like

Here’s the current 0.1 -> 0.2 HW changelog, this also works as a reminder for myself and I can update and change this post to show how things are progressing. These changes haven’t necessarily been done yet, but are in the works or waiting.

  • External Led & switch + Comms connectors changed from THT JST-XH to SMT JST-PH (done)
  • MCU changed from STM32F070CBT6 to STM32L433CCT6 (done)
  • External oscillators removed due to being unnecessary with the new MCU (done)
  • CAN support added to Comms connector, USART can be connected using solder bridges (done)
  • Power delivery done via LTC6803-3’s 5V linear output and 5V from the buck converter, which are then fed to a 3V3 LDO. Buck converter can be disabled when going into low-power state and keep MCU powered via the LTC6803-3 5V going to the LDO (done)
  • LTC6803-3 footprint changed to the correct one (done)
  • Balance circuit resistors changed from 0603 to 0402 package to save some space and give a bit more tolerance with the soldering (done)
  • Buck regulator TVS protection diode switched from SMC to SMA to save space (done)
  • Boost converter electrolytic caps upgraded to more fitting ones for the application (done)
  • Ceramic capacitors added to the boost converter’s input and output
  • Ground plane partitioning to isolate the noisy, higher current areas from the analog and logic side
  • Buzzer control pin moved to a DAC enabled pin
  • ADC sense voltage dividers changed to higher resistance connections to decrease quiescent currents (done)

I decided against moving to the synchronous boost circuit for now, because it proved to be a real headache with the layout. It doesn’t want to easily fit in to the board, so I’ll probably do a standalone test board for it to test it out.

5 Likes

Did you mean imperial code right? Because metric 0603 is already small and if you go smaller it would be even bigger pain to solder :smiley:

Is it enough for MCU 4mA?

The balance circuitry is so dense that the smaller footprint would actually give a bit more breathing room around the components themselves, so they don’t as easily jump to the neighboring pad during soldering. It’s already hard to place the components, because the tweezers ends feel so big :wink: . by having the smaller resistor package it would give a bit more breathing room around them, making placing them and the leds a bit easier.

The resistors are already in each others keep out areas with the 0603 package in KiCad, so they are really packed tight.

It’s enough to keep MCU powered in it’s ultra low power state. When going into standby mode, shutdown all other ICs and then disable the buck converter and it’s LDO and switch to the LTC6803 LDO regulator to keep the MCU still powered. Going into the active state, activate buck converter and switch it’s LDO on and then the LTC6803’s one off.

This way I can keep the MCU powered up always when the battery is connected, so I can keep the RAM intact. Then check every now and then if the external button/switch is pressed or if a charger is connected and then switch to a active state.

1 Like

and your bleed resistor size is? If they are this small it would take forever to balance for e.g. 10Ah pack…

Bleed resistors are still on the other side of the board and it’s a 0805 package with a decent power rating. Bleed current should be a little less than100 mA, with ~80 mA through the 51 Ohm bleed resistor and ~16 mA through the LED.

1 Like

Here’s the plan on how to support both USART and CAN on the same connector pins: image

By default CAN is used and the communication line should be fault tolerant, but the CAN transceiver can be disabled with software, so the pins can be switched to USART use, with the solder bridges bridged.

The +3V3 line is also software controlled, so the external device can be powered off, when going to standby state from active state for example. The +3V3 line isn’t fault tolerant, so don’t go connecting that to +5V power anywhere.

2 Likes

Regarding the balacing LEDs, are they really needed ? Battman has also those leds but thie device (BMS)is meant to be embedded and enclosed, so no vision on any LEDs.

(That’s basically why I wanted to externalize the main RGB led and use an Adafruit RGB led switch instead).

Anyway, thanks for the changelog, that sounds really amazing !

1 Like

Technically, no. Development wise, they are a nice thing to have.

In testing phase especially they are a good visual feedback on the behavior of the balance circuitry. I can just with a glance see if something should be balancing, but isn’t or if something shouldn’t be balancing, but is. If I can’t visually inspect the state of the balance circuit I’ll have to get in there with a probe head to measure voltages and that can be challenging, so you don’t accidentally short something while you’re poking in there. Then consider that it’s another user that is having a problem and they can’t just tell me if the Leds are on or off, which makes possible troubleshooting harder.

For everyone’s information, I managed to break the microcontroller and the USB 3V3 regulator on the 0.1 test board, by accidentally connecting the oscilloscope probe head and ground the wrong way around on the battery lead terminals. Seems like the components didn’t appreciate the -+40V Volts on them… USB port on the PC was ok. So let’s just say that 0.2 HW priority has been elevated.

a Normal RGB led with discrete diodes is gonna be a challenge to figure out how the connectors should be done, because you need 3 signals wires and there isn’t really room for bigger connectors. It would be much easier if there was a pushbutton with something like a WS281x RGB led integrated, as you would only need 1 data signal to that.

EDIT:

  • we can only use the +3V3 line to power any external Leds, so the voltage is also limiting.
1 Like

Can’t you just look at at serial monitor (even better a simple program) to have all the balancing info ? I’m agree that LEDs are very convenient for troubleshooting, but as you’re looking for room, removing them help you this way.

That was the first device I looked for. But no luck to find it. Maybe by tweaking an RGB one by adding a ws2812 chip can be the solution.

1 Like

The problem is that the software might say the something is balancing for example, but it actually isn’t. I can’t verify the actual behavior from just the serial terminal. What if there is a bad solder joint in the balance circuitry and it can’t actually balance, but the firmware might be physically unable to verify that.

But, yes for the fact that removing the Leds and their front resistors, would free up space from the board and the balancing circuitry could be packed in even tighter.

Oh yes, hardware wise, this is the only way to go. Sure. Are you planning to remove them once your design will be validated ?

It depends on a couple factors.

Do we need more space on board for something else and the balance circuitry has been tested and proven to work? Then it’s a possibility.

We don’t need more space on the board and the balance circuitry has been tested and proven to work? Maybe just leave the Leds and their resistors un-populated in this case.

Balance circuitry non-proven or tested to work? I’d like to keep the Leds populated.

I think that you need to consider a few factors in regards to the LED’s.

How good are they (so what do they provide). How expensive are they (not just price but board space and such) who do they target (n00bs, veterans or everyone)

Pimousse said that this meant to be embedded and enclosed, but is it? I’d personally cut a hole in my enclosure and put some perspex over to keep a seal and be able to see it, either that or have the lights travel up some fiber to the side of the enclosure. The muffin could also use the design for more than just Esk8, what if someone bought it to charge LiPo/LiIon packs outside the case for testing. (i’m not great at circuitry so i don’t know if this is a good idea).

Best validation i can think for the LED’s is the fact the raspberry Pi has them. So many forum posts where the 1st thing someone asks is what LED’s are lit, they’re just so helpfull. It seems you don’t personally want them pimousse, but i’m guessing you’re in the minority (just a guess though)