openinverter forum

johu wrote: ↑Tue Jul 23, 2024 9:48 pm It seems the esp32 firmware isn't up to date. Is it the latest github source?

So I got a little further last night. Turns out the bootloader I was trying to flash was the wrong one, this was the one linked from the GitHub so that may need correcting or I just have completely misunderstood what was written there.
Anyway, once the correct bootloader was flashed and firmware I get a constant flashing LED.

But still firmware :null.
I also cannot change the Node ID or Speed as it appears to be constantly refreshing, so as soon as I select the drop down box it refreshes and deselects.

It's progress but not as much as I'd hoped....

Oh, indeed the wrong boot loader is linked in the README, will correct.

But again, have you flashed the latest https://github.com/jsphuebner/esp32-web-interface to the ESP module?

johu wrote: ↑Wed Jul 24, 2024 9:44 am But again, have you flashed the latest https://github.com/jsphuebner/esp32-web-interface to the ESP module?

I have now flashed the CAN Backend version, but it was still not working. unfortunately now I seem to have broken my ESP32 Lilygo TCAN485 board. I performed a "full clean" in PlatformIO in order to reflash and see if the issue would be fixed but since this, I no longer get a wifi network when powering the board. The upload claims to be successful.

Ok I finally got mine BMS boards working yesterday, possibly due to some cheap breadboards/dupont connectors...
I've updated the wiki with the process I used to flash the boards here... https://openinverter.org/wiki/16-cell_B ... g_firmware
Maybe have a read and correct any obvious wrongs if necessary. Thanks for the help!

I finally implemented support for both temperature sensor inputs and also high/low temperature derating. Check wiki for more info.
https://openinverter.org/wiki/16-cell_B ... ure_limits

As opposed to the inverter temperature sensors are now configured via their nominal resistance and beta factor. This should do away with maintaining lookup tables.

I've updated first board with 0.20.B firmware and have there one temperature sensor for testing...
Reported value looks good with default settings.

Next version is going to have pull-down resistors on the control gates

If I have the Tesla motor connected to the ESP32 CAN Web Interface, do I connect the can wires from the BMS in parallel with the CAN wires coming from the motor?

yes, if running version 0.16 on the bms i think its nodeID 10 on the web interface

Finally getting around to setting this up on the bench with some modules and I'm wondering about how best to integrate it with my system running an OI V3 board in the leaf and a Zombieverter (soon to be wqith a FOCCI). Would adding it to the zombieverter be difficult? And what would the advantages be? presumable providing zombie with charge/discharge limits which then controls the charger/FOCCI

(I'm not asking anyone to do this for me BTW, but wondering about doing it myself whilst learning how the backend of this stuff works)
I've got very basic coding knowledge.

You can always just have it spit out the "SimpBMS" CAN message structure. This should be programmable as it uses the openinvlib so freely configurable CAN.

tom91 wrote: ↑Tue Jan 28, 2025 10:50 am You can always just have it spit out the "SimpBMS" CAN message structure. This should be programmable as it uses the openinvlib so freely configurable CAN.

Thanks that definitely seems like the path of least resistance and keeps zombie in line with official releases if I'm understanding correctly.
I'll take a look into configuring the CAN messages cheers.

I finally got around to testing my BMS boards today. After updating them all one by one to the latest firmware 0.20B (when I tried doing multiple over CAN it bricked a board and or stopped communicating with others and required the bootloader and firmware flashing using an STLink again).

So, things I've noticed on my 9S bench setup. Whatever the last module is, has a negative reading of around -2.7V, show below (cell 8 or U7 in this example but occured whichever cell was last) 2nd the spot values shows total cells as 16 regardless of the number of channels selected in params. This also is the same for opmode which shows RunBalance despite balancing being switched off. fixed by deleting JSONs and Bins in files.
Lastly, I tried to connect one of the temp sensors but the sensors on my modules have 2 wires each. I tried one to gnd and one to the tempS1+ input and also both to twmpS1+ and TempS1- but neither option resulted in a change in the temp values in spot values, this may be related to not being able to select a temp sensor from the drop down (see below)
Oh and lastly, the dashboard never updates.
Also the description for J2 on the wiki is outdated, but I'll update that now. incorrect just is not every pin is silkscreened.
Oh and another one, the dropdown to select temp sensors doesn't work, (see image below) nor does saving parameters for me. I've deleted all the JSON files. fixed by deleting the binary which now also fixed the total totalcells issue in spot values and doesn't seem to want to force balance all the time. Other issues remain

Any help on the above would be great.

If you only connect 9 cells you have to set numcells to 9, save and power cycle
tempsns loaded the previously saved value of -1. Go to dashboard and write "set tempsns 0". Then you get the dropdown back. But this only lets you select if 0, 1 or 2 sensors are connected. The sensor itself must be NTC and must be parametrized with tempres (resistance at 25°C) and tempbeta (coefficient from data sheet).

By default balancing starts 60s after power up or in fact 60s after idcavg settled below 1A. You will see opmode changing to RunBalance

Thanks Johu,
I've sorted and tried to calibrate the temp sensors I have on my modules and they seem to be accurate to a few degrees.
Any idea on why the last cell is showing as a negative?
Re: balancing, I have balancing turned off on parameters, should this stop RunBlanace showing at all? it's a little confusing if not.
Thanks

Jacobsmess wrote: ↑Thu Jan 30, 2025 12:38 pm Any idea on why the last cell is showing as a negative?

Is there anything connected to that input? The first unconnected input always shows a negative number, the subsequent ones show 0.

Jacobsmess wrote: ↑Thu Jan 30, 2025 12:38 pm I have balancing turned off on parameters, should this stop RunBlanace showing at all? it's a little confusing if not.
Thanks

Good point, might change that

I have added some startup self tests now: https://github.com/jsphuebner/FlyingAdc ... 31107e477d

It checks if the ADC sees 0V when the mux if off, checks for ADC saturation when turning the active balancer on and finally checks all enabled channels for over voltage and inverse polarity.

The latter one does misfire though as explained in the post above. If you do not populate all channels and forget to set numchan accordingly it will be reported as reversed polarity. Will work on that.

If you have any more usage questions please open a new thread so that this one can be reserved for development progress.

I worked a bit more on the self tests and added a possibility to enable the BMS despite a failed test. "enable" is set off "Off" on a failed test. For resuming simply set it to "On" again. Of course you should first determine the cause for an error message
- CELL_OVERVOLTAGE - definitely check what is not right before enabling!
- CELL_POLARITY - can be serious or can be caused by not having "numchan" at the correct value if not using all channels
- MUXSHORT - probably one or more failed transistors
- BALANCER - General communication problem with ADC or balancer circuit

I also improved the SoH and SoC calculation. Whenever there is not current flowing for longer than "idlewait" seconds SoC is updated from the lowest of all cell voltages. This process continues until current returns. If there are 20% SoC between the last estimation and the current one, the measurement is considered relevant for an SoH update.
SoH is simply calculated by comparing the charge taken from or put into the battery with the charge we would expect from the SoC difference (scaled with nomcap).

SoH is heavily filtered, so every estimate is transferred to the non-volatile SoH value via a very slow IIR filter. That way bad estimations don't skew the SoH too badly in a direction. It is absolutely crucial to setup valid voltage-to-soc points in the parameters for this to work as accurately as possible.

Speaking of non-volatile memory - the NVRAM is preserved via the VBAT pin. That is always supplied via an LDO on the permanent 12V line. The intended mode of operation is like that
- 12V is fed by uninterrupted 12V supply
- ENABLE is fed by an ignition or charge signal
- When ENABLE drops out the BMS will remain active for 2 more hours (will make this configurable also)
- It then does balancing and SoH estimation
- After 2 hours it shuts itself down, drawing only a few µA from the 12V line
- When powered up again it can restore SoH and SoC from NVRAM

The current SoH is also written to "sohpreset". Before disconnecting permanent 12V you should go into the web interface and save parameters to flash. Then it will resume with the correct long-term SoH estimate.

And worked on the documentation also: https://openinverter.org/wiki/16-cell_BMS

And now started working on unit tests to keep software quality high and make it easier to spot when something gets broken: https://github.com/jsphuebner/FlyingAdc ... b81d05d30e

I added a simple bar graph to the web interface. https://github.com/jsphuebner/esp32-web ... f67db59e21

Can be found under "Plot & Gauge" by pressing "Toggle BMS bargraph". Thanks to Patron Phil for the symbol Would be cool to extend it to sweep across all sub modules

May I ask regarding the production files - any other bodges I may need to do apart from the gate pulldowns between V 2.0 and 2.2?

Just that.
The change from 2.0 to 2.1 was reverse polarity protection of the 12V supply and a constant 3.3V supply for Vbat. You can't bodge that one in I'm afraid.
From 2.1 to 2.2 the pull-downs were added and R9 lowered to 100 Ohms

Without seeing the schematic it is hard to visualize what constant 3v3 for Vbat means in this context, my guess is if I supply constant 12V - 2.0 with bodged pulldowns and R9 would still be useable?

I hope to order my "BMS manager" tonight on JLC, so just wondering if I have some chance of not having to excessively worry about the usage of 2.0 apart from my own assembly mistakes.

I have published the latest manufacturing files on Patreon now.