FlexiBMS Lite - New approach to get past Vaporware stage

Got the charging algorithm adapted, so it’s working again, mostly. Need to fine-tune things alongside testing. Found for example weird stability issue with the LTC6803 that manifests as incorrect cell voltage measurements when an USB-cable wasn’t connected, but was fixed by connecting an USB-cable. Not yet sure if it’s grounding or power supply issue, but I have ideas where to start testing for a fix.

I have also fixed the 5 boards, but have not yet power-tested them. Need to get the firmware sorted into a basic stable functioning state first.

I have also opened communications with an US based start-up company for designing a high voltage, cascadable car/energy storage scale BMS. We’re still in the process of doing the HW block diagram for the Proof-of-Concept prototype.

6 Likes

When the time is right it communication with Davega could be implemented (like the smart BMS), no? :star_struck:

I think so, provided there’s CAN and communication can be relayed by VESC the same way as with DieBieMS.

Did a hotfix for the LTC6803 measurement error. Looks like it’s 5V VREG output really doesn’t tolerate any extra load on it (and I’m powering the MCU currently from it…), so I’m gonna have to do another HW iteration for the board. I have shown below the current power supply scheme and then what I propose for the 0.3 HW revision. I found a nice linear regulator for the MCU. image

2 Likes

I ordered 0.3 HW boards today.

Changelog 0.2 -> 0.3:

  • Added a small pull-down resistor to INA180 shunt op-amp output to pull it to ground, if IC un-powered
  • Added a protection/fuse resistor to CAN ground, in case battery negative lead gets cut, then all current would try to return through CAN ground, but will blow resistor now, instead of burning CAN GND wire
  • Moved traces from between LTC6803 pins
  • Switched MCU supply to dedicated 3V3 linear regulator (RT9068), removing it from loading LTC6803’s 5V VREG output, which caused measurement inaccuracies
  • Improved LTC6803 power decoupling
  • Changed couple diodes related to MCU power supply to work with new regulator
6 Likes

Update

Got the 0.3 HW boards (last week) and components (this week) and assembled one this weekend. Did some analysis on the quiescent current consumption and after couple of code tweaks, got it to ~80 µA in the low-power run state (not stopped state). There is the possibility of optimizing into a Stop 2 mode for the power-saving, which could (according to datasheet) lower the quiescent current another ~30-50 µA, but this is a sleep state, so can’t run any code during this.

I still need to test that the power supply scheme change fixed the cell voltage measurement error, but this setup should actually improve the measurement accuracy performance in all states compared to before, but need to verify this.

16 Likes

Update

Have been using the 0.3 board to charge my pack on the start of the week and I’ve been testing it’s performance.

I started with just comparing the cell measurement results between the 0.2 and 0.3 boards. Both showed steady numbers for all the cell measurements, but the 0.2 board showed slightly lower voltages for all cells, namely about 2-3 mV lower compared to the 0.3 board. So I used my multimeter to manually check the cell voltages to compare against the boards measurements. The DMM showed identical numbers to the 0.3 board, but a doubt started to rise within in about one thing. How accurate are my DMM’s voltage measurements? I need to calibrate/verify it’s readings before I can say whether the results are good or not.

Brought the DMM to office to compare against better and more expensive equipment. So I hooked up my chinese Aneng AN8008, a Fluke 179 and a Keysight 34461A benchtop DMM to a low noise voltage source and tested couple different voltage measurements on different ranges to see how accurate the indicated measurements were. The Keysight is probably the most accurate DMM, so it’s an accurate enough reference to compare the AN8008 results against.

The measurements seemed to be within 1 least significant indicated number. All the DMMs had some noise on their indicated least significant numbers, but that’s normal as the voltage source was not a voltage reference, but just quite clean DC output. So with that test I could trust the steady DC voltage measurement were pretty spot on in the 3.000 - 4.200 V range, which was the range I was interested in due to wanting to verify the Li-Ion cell voltages.

So what is the result?

Well my DMM is showing identical numbers to one measured by the LTC6803 on the 0.3 board and I have verified that the DMM is accurate withing ±1 mV in the used voltage range, so all I can say is that I’m pretty darn happy about it’s performance! Also not bad for a 22€ DMM.

I suspect on the 0.2 board that the MCU is loading down the LTC6803’s VREG enough that it disturbs the measurement results, even though they are steady, they show consistently 2-3 mV less then the 0.3 board results. But that is really what I wanted to fix for the 0.3 iteration, by completely supplying the MCU through a separate regulation, removing it’s influence on the LTC6803’s VREG output.


Future moves and HW RC (Release Candidate)

I’m moving to a ramp-up stage on the development. I did very slight changes to the HW and with that I’m moving onto 0.4/RC1 HW (Release Candidate). I feel like the HW is now mature enough and the SW is usable enough (still under development) to start considering doing a development batch of 10 boards meant for distributing to HW testers and SW developers. I will be opening a sign-up form for testers and developers in the coming days. Link to it will be posted on this thread along with more info.

I have ordered components for a couple hundred euros for the upcoming developer build, which I I’m going to hand assemble, so I have the best/personal control over quality. I can also test the hand assembly time for larger batches, so I can compare the time/cost ratio for future production batches. The 0.4/RC1 gerbers are ready and I’m planning on ordering the boards next week. I want to test couple extra connector options for the XH and PH connectors on the board before ordering the 0.4 boards.


Other BMS news, FlexiBMS HV

I’ve been doing HW design with an American start-up company for a high voltage variant of the FlexiBMS for a bit over a month now. They contacted me through PMs on this forum, commenting about this Lite thread and expressing interested for the Lite and a HV version. I’m not on a payroll, I’m working rather for the possible future sales, we have been discussing and planning for me to give them a license allowing them to use the HW design (single-time payment) and then a small commission fee for every unit sold.

So what’s this HV version about then?

  • LTC6804 battery stack monitor (newer gen. to the LTC6803)
  • Master/Slave topology
  • Cascadable design for chaining multiple packs together in series (they are going for 8 units -> 96S)
  • True isolated connections between LTC6804’s
  • Isolated external charging contactor control on Master module
  • CAN-bus on Master module

What application is the HV meant for?

Higher voltage use, EVs, power storage. The real point is that you can connect multiple packs together in series for larger S-configurations and be able to measure all series cell voltages and balance them if necessary. They for now have been talking about using them in recycled Tesla model S packs for re-use and want a BMS for that.

It’s not meant for the small scale as the Lite is (3S-12S) and is not an All-In-One, but for bigger pack configurations (12S+) where you need to start designing your system as a distributed one.

10 Likes

Great progress! I’d be happy to do some testing. I can also do a code review for you and/or help build the integration with VESC and other devices like Metr or my DAVEGA. This would be best done by implementing the same communication protocol as DieBieMS uses since that one is already supported by Metr and is going to be supported by DAVEGA soon as well.

6 Likes

It’s awesome watching the progress of this BMS. I’ll be sending money your way when they are available. Awesome work!!!

Nice to hear that, so in the future we will be able to read all BMS data on DAVEGA? And maybe the other way around? configure DAVEGA through Metr

This is looking awesome. This is mostly the only thread i come back here for these days. cant wait till you have RC1 builds to send out. Id be happy to help do some testing when the time comes.

2 Likes

Not sure about the “all” part but you’ll definitely be able to read the most important DieBieMS data (e.g. individual cell voltages) on DAVEGA X pretty soon. It’s high on the TODO list now.

This is less likely though not completely out of question. It would definitely be possible technically once DAVEGA X has CANBUS. We would need to coordinate with @rpasichnyk. We have already been working together a little bit – me testing his Metr Unity module and him and @hexakopter testing the DAVEGA X – so we’ll see what happens.

If you have any more questions please ask in https://forum./t/davega-x-gauging-interest/5203 so that we don’t hijack this thread.

2 Likes

Did a final check on the CAN bus functionality today. Implemented an echo function that waits for the CAN to receive any message on the bus and then sends it back to the bus with the same info. Worked without problem.

The upper received messages were test messages for testing RX at first and checking that the filtering settings were working. Then I changed to actually using the echo function and sent the message shown on the bottom half and it was then received back to the CAN analyzer.


I also updated the programming jig a little bit. Testers will be sent one, so if we have SW updates, we can flash them before the bootloader and “live flashing” are implemented. You are gonna have to supply your own programmer though.


I also tested how JST’s XA and PA series fit onto the board. They are essentially almost identical to the XH and PH series, but instead of the detent lock they actually have a locking ramp, so they can’t be disconnected unless you press on the tab and pull, or the wires break.

8 Likes

Is the software foss? Or is it secret?

Hoping so to this will then start to be a standard for eSk8 in my eyes.

1 Like

I’ll throw it up on github at some point soonish. Need to clean up the commented code lines and comments.

All these improvements are awesome ! Congrats @SimosMCmuffin !

We should definitely work on a PR for integrating a standard BMS communication into VESC FW for a better interaction between both. :slight_smile:

Has there been development for a generic/standard BMS CAN communication for VESC with DieBieMS’s or has it just been DieBie’s side implementation?

No, at least I’m not aware of this. That was my top priority when I jumped into the DieBieMS adventure but I couldn’t find details to successfully compile the code (I tried tho but I bricked my DBMS, rescued by a ST-Link :neutral_face: ).

If you’re interested, I can work on a draft of features that may be interesting to develop for such VESC-BMS wedding. :slight_smile:

1 Like

Maybe just a more general look at what possible messages could be used in a generalized BMS CAN communication. Then maybe add to that more VESC specific messages.

Here’s little sneak-peek picture of the FlexiBMS HV:

6 Likes