Well I did get IC soldered on, by bending the legs under it. The pads were far enough under it that you can’t just trim the legs and try to solder it (pads are actually completely hidden beneath the IC, unlike shown in the illustrative picture). You need to have them go inwards for them to be able to reach the pads.
Other than that, the layout was fine and it will in any case get largely redone, because I need to change the MCU for one with a CAN support that people requested.
It’s alive!
I’ll now start to configure the peripherals and start connecting to the other ICs on the board.
EDIT: I have now tested and succesfully flashed the MCU via the USB bootloader, so the end-user, if they want/need to re-flash the firmware, they can do it with just a USB cable, no external programmer needed.
So, I was thinking today what my action plan will be for the next couple of weeks and what I need to achieve before I can progress to the next hardware iteration and have the next boards sent for fabrication with the goal to reach the beta test phase, hopefully by this summer.
I looked at the new MCU with the CAN support today and ended up with STM32F072C8T6 to replace the currently soldered STM32F070CBT6. Good thing is, as it’s nearly identical model with the earlier one, the firmware should be pretty easy to port over, with basically just pin remaps, so I can already start developing the firmware features further than the basic functions with this board, but before I can work on the next hardware iteration with the new features, I need to code test functions for this board and test the performance of all the blocks, so I know they are functionally ok and don’t need changing.
So here’s a priority list on how to progress for now:
I have been doing a long time test on how the pre-alpha prototype BMS has been draining the battery over the last 20+ days and have been logging the battery pack voltage. The test was started with a fully charged battery and has then just been left sitting with the BMS hooked up and I take voltage measurements roughly every 12 hours and enter them into a google sheet to generate the graph. I also measured the standby current with a multimeter and it seems to stay at pretty stable ~9 mA over the whole pack voltage (42-33 V). This test will continue on after this post and the google sheet updated.
The aim will be to lower this drain by at least a factor of 2 in standby mode and by a factor of 10 for the deep sleep mode for long time storage.
Ok, the LTC6803 is not properly soldered on and it has intermittent connection problems, but I managed to test that the deep sleep wake-up via the external pushbutton works and that the MCU is able to turn itself off into the deep sleep mode.
I measured the following input currents @ 40V simulated battery voltage: Deep sleep mode: 500µA Standby mode: 7,3 mA (Can probably be reduced to < 7 mA, by powering all the ICs down and putting MCU into sleep mode)
So compared to the 9 mA standby current on the pre-alpha prototype.
Current reduction factor of 10 for the deep sleep mode is easily achievable, but after looking at the relevant IC datasheets for the standby mode current. I don’t think it’s possible to realistically go lower than 6 mA, because the buck regulator alone with no load consumes about 4.8 mA, as shown in it’s datasheet caption below. And also at very light loads (<20 mA), the buck converter has pretty bad efficiency. So, a factor of 2 reduction in current in standby use is simply impossible, but we can reduce it somewhat from the measured 7.3 mA still.
I have also confirmed with my earlier test board for the LTC6803-3 that the charge FET safety cut-off will work with a properly soldered IC. I was having weird behavior on the test module (Watchdog’s open-drain couldn’t pull itself completely down, but floated around 2,2V), but I’m very sure it’s caused by the bad soldering job (due to wrong footprint), as it worked as intended with the standalone test module pictured below.
I have little doubt that there is anything wrong with the balance circuitry, due to it being pretty much identical to the ones used in earlier working prototypes, so I’m not sweating over that.
Now I need to test the current measurement, the boost charger circuit and some other small things and then I can start to work on the next hardware iteration.
The charging part is purely hardware to prevent this issue? I haven’t looked at the schematics
My module has complete hardware side protection against microcontroller hanging during charging.
If the microcontroller hangs while charging, even if it’s enable_charging pin is left high, it also stops the communication with the LTC6803-3 battery stack monitor, which then causes it’s watchdog to activate and the watchdog’s open-drain output will pull the charging FET’s gate low, cutting off the charging current.
When the MCU is operating normally it’s keeping the LTC6803-3 in an active state during which it’s watchdog output pin is floating and the MCU can pull-up or pull-down the charging FETs gate.
Along with this, I’m planning on also running the MCU’s internal watchdog, so it can recover from hang states, by resetting itself.
IMHO a good BMS should be below 20 microamps in deep-sleep/shutdown.
I think you replied to the wrong thread 
No no, that’s on purpose since we were talking about @SimosMCmuffin Bms on batman thread
Edit: now I see, thanks, too many tabs open
I think 100uA is a bit much for deep sleep drain. It will kill the battery if someone parks their board after driving and leaves it for a month or so.
There are microcontrollers that can do 1uA with RTC and SRAM powered. The LTC6801 quiecient current is about 10uA.
It that a 20uA or so design is possible. that’s with RAM powered and waking up every hour or so to take a measurment.
Look at the STM32L4. Low enough power you wont even need another DCDC and can power it directly from the LTC6803.
You can also consider a regular linear regulator or LDO for ultra low quiescent current. With something like STM32L4 at low frequency and all your components optimized… (low leakage caps) The poor efficiency wont matter.
Im doing a long time discharge test on my 10S5P (600 Wh) battery pack with my old BMS proto, which has standby current of ~9 mA from the battery, here’s the current graph of it’s effect
It has almost been 30 days in standby mode. Then consider slowing this drain over 10 times for the deep sleep mode for 300+ days for the equivalent capacity. I think it’s good enough. Could the deep sleep mode discharge be smaller? Yes, but this is already looking good enough approach.
After looking closer at the Battman’s RTC wake-up implementation and figuring out the logic behind it, it’s pretty smart and I hadn’t before realized how it exactly worked. But yes, it’s a very good design that allows for very low quiescent current. Essentially only the LTC6803.
the MCU in sleep mode is not enough to reduce the input current a lot, because the buck regulator has such a high no-load current. Battman’s implementation gets around this by completely cutting off the regulators from the battery via Q7, which causes the MCU to also shut off, but the RTC is using the Cell1 from the battery pack to power itself and periodically then enables the regulators back up.
I feel like I was beaten in 4D chess game I didn’t realize I was even playing 
At least I learned something new.
I’m gonna look at the possibilities on how to possibly implement something similar considering that there is hardware difference between the boards.
EDIT: Note, that the Battman’s implementation does depend on having the balance connector on, so that the Cell1 is actually available. Mine implementation works with just the battery pack connected.
This is my new favourite quote.
I’m considering this. There is the LTC6803 5V output, which could be used to power just the MCU via a small LDO, the MCU (STM32L433CCT6) supply pins didn’t seem to accept 5V directly after looking the datasheet. Then the MCU could power up the buck regulator directly if it needed to enable other circuits needing higher power.
I personally like this approach more then an external RTC IC. I’m gonna check the datasheet to see if the MCU has internal RTC capability, or if it needs an external 32kHz rock + does it need a high speed crystal for USB, or does it have an internal oscillator for that.
Direct quotes from the STM32L433 reference manual. RCC chapter
HSI48 clock The HSI48 clock signal is generated from an internal 48 MHz RC oscillator and can be used directly for USB and for random number generator (RNG) as well as SDMMC. LSI clock The LSI RC acts as a low-power clock source that can be kept running in Stop and Standby mode for the independent watchdog (IWDG), RTC and LCD. The clock frequency is 32 kHz.
It seems that it wouldn’t actually need any external crystals or oscillators to run USB and the RTC in low power mode.
@okashira I’ve been doing some measurements and comparisons between the Battman and Flexi 0.1 design and based on my tests I would say that the Battman has at least about 200 µA input current at 40 V battery voltage even at deep sleep mode.
Here’s my evidence based on purely schematic design.
The boost charger resistive divider will have with 40 V battery voltage: 40V - 0.7V (FET body diode) = 39.3V 39.3V / 207kOhm = 190 µA
There is also going to be some leakage through the FSV10120V schottky in the boost charger block to the LTC3873 boost controller. So I would say from design viewpoint, that there is no way for the Battman to have sleep drain of only 10 µAmps. Period.
Most of my quiescent currents also comes from voltage dividers, eliminating those somehow would have a decent effect on the deep sleep quiescent current.
I am posting this for the sake of transparency.
I have had multiple people contact(PM) me about the interest towards the FlexiBMS project, so I am compiling this message as a general reply in relation to the current project status at this point of time (22.3.2018).
Thank you for showing interest towards my project, I’m honored and also appreciate the outreach from the community in both user and vendor side. At this moment in time I’m planning on continuing the development of the project under my own control, but I welcome all feedback and discussion towards and about the project, preferably in the FlexiBMS forum thread itself (FlexiBMS - First prototype board assembled and firmware development started! - Flexible configuration and charging BMS). I’m neither accepting or refusing any possible collaborations or other offers at this time or for the perceivable future. For now the project is so WIP that I don’t want to tie myself down yet. I’ll continue working on it and updating the thread as things progress.
I am in thinking on changing the license of the project to something that would allow:
Personal message: I want to do this for a living and make a living with it. I find this to be enjoyable and rewarding. I want to give people good products. I want to allow people to make their own derivatives based off of my work and be able to sell those. I want to protect myself from somebody flooding the market using 1:1 clone of my product without receiving compensation. In the case that I can’t supply the demand, I will allow for other vendors to produce their own batches under a reasonable license fee to help ease the possible supply problems (what good is a product you can’t get?).
Nothing has been set in stone yet, but these are my current thoughts, so I’m posting this here if people want to have a discussion.
In case you’re wondering about how the license fee would work. I mean it as a small compensation per board (5-15 €). Maybe I see there is a supply problem and I can’t meet the demand so I decide to allow the production of 200 boards with the aforementioned fee. Vendor X takes up the offer and we make a contract, they pay me license fee and then they are free to produce those 200 boards directly with the files available on github, they are also free to sell those boards at the price they see fit. I personally see this being the fairest to all sides on this issue: Me, Vendor and the end-user.
Thoughts, opinions?
Require certain levels of QC to be met in order to use the license. Some of the east Asian factories just pump stuff out without even testing to see if it works, hence the super low prices. A bunch of junk on the market just looks bad on your design, even if it was the manufacturer being negligent. Shipping defective units revokes licenses.
.
Good idea and point altogether. This can be bundled into the contract for the license fees.
I plan on doing my own visual check on the soldering job and then make an automated function/sanity check for the electronics that can quickly be run to test the circuitry.
How do i get my hands on one/buy one!!!???
