Tags: #<Tag:0x00007f6e03592360> #<Tag:0x00007f6e03592298> #<Tag:0x00007f6e035921a8>

Nice work - you hand soldered 0603 parts ?!? Crazy :slight_smile:

I also use the pogopins for programming - saves soldering a connector on the boards - its a shame it takes about a minute to program each board though as my hand hurts holding that long!

Yes thats correct - short it (keep it shorted) and reboot - the access point should then re-appear.

Just reporting in after being silent for a long time. Rain here and cloudy for ever it seems, so my batteries have been just sitting on top balancing. They are at 4mv difference.

So, I can program both controller and boards to get the new software going? I’m quite happy with my current setup though.

Thanks again @stuart for your design and work on a great project!

Hand assembled to be more precise, although I did have to do some rework by hand for a few LEDs and optos that moved during baking. I had to order a stencil too as placing little balls of solder paste did not work very well.

What I found was,
With the controller OFF, I put on the jumper, and then turn it back on, the status LED on the board would stay on, and no access point was created, and no debug data was seen, it was like it had locked up,

but playing around with it, I found with it running, I would put the jumper on, go to the web interface, and use the ‘Restart Controller’ under the Settings option, it would reboot and go into AP mode (and it was also showing the debug info), I would then remove the jumper (with it still running), and connect to the AP (wireless access point it had created ), web into it (, then configure it to my WiFi, when it rebooted , it connected to my WiFi fine

Is this how it is suppose to work ?

All, its just be reported that on the v4.2 branch and boards the R19 (thermistor) and R20 (47k resistor) are in the wrong location - this doesn’t affect v4.0 boards.

They should be reversed as the R19 part is near the ATTINY instead of in the shunt resistors.

I’ll update the design today to fix this.

Does this mean that when my v4.2 boards arrive from jclpcb that as well as soldering on the ATTINY chips, I’ll also have to unsolder and swap over these two parts?

Yes, unfortunately it does.


Really, what a nightmare. I currently have boards in SMT production. The I went SMT assembly as I didn’t want to do it myself!

I can’t get the modules to appear on the computer, which I do wrong

Really sorry about this, the two parts are very small, but that also means they are easy to undersolder and swap over.

The boards work as they are, but the thermistor is far away from the balance resistors - as a work around you could lower the balance temperature to a much lower value - like 45 degrees C instead of moving the parts

The fixed boards are now in GITHUB in the v4.2 branch. The new boards have a V4.21 silkscreen version.

R19 and R20 have been swapped and the tracks updated to reflect this. The Gerber and CPL files have been updated and checked by uploading to JLCPCB.

Thank you I appreciate the prompt response. It’s reassuring to know that things will still work and there is a workaround :sweat_smile:

If you’ve had to update tracks as well, will just swapping the R19 and R20 on my v4.20 boards work?

The tracks were moved to keep the circuit the same however, if R19 and R20 are swapped over on the existing v4.2 boards the components are still connected correctly (just upside down) if that makes any sense - its a simple resistor divider circuit.


1 Like

Yep, understood. Thanks.

Thanks so much for this DiyBMSv4 project. I have been a long time follower and have benefited greatly from comments/questions of others and your answers. So I thought I would try to contribute a little by explaining my variations on your excellent work.

I’ve assembled the version 4.0 modules and controller for a new 300Ah LiFePO4 house battery for my sailboat. The picture shows my test setup. The battery uses 100Ah cells in a 3P4S configuration. I have top balanced the cells and plan to use them in the “linear” range away from the voltage “knees”. I’m using the DiyBMS4 for monitoring with Influxdb/Grafana and cell/pack protection control. Therefore I have not included the cell balancing features on the cell modules. To allow temperature monitoring of all 3 parallel cells in a group I have added a second external temperature probe to each module replacing the internal board thermistor. This second external probe is connected between pin 2 of the sensor header and pin 3 of the program header. I have also modified the controller code rules to test both temperatures to trigger relays.

The plan is to use the controller to drive protection relays for both high and low voltage/temperature events. However for low and high voltage events the relays will likely “chatter” because the disconnect will likely resolve the trigger voltage causing the rule to activate. To resolve this issue I have modified the controller code to incorporate a user defined cell and pack voltage hysteresis. So for example if a low cell voltage triggered a low voltage disconnect relay the rule would not reset until the cell voltage increases to the trigger + hysteresis voltage. This way the relay will not reset immediately on disconnecting the load. I use the same hysteresis voltage for the high and low condition. I do use a different pack voltage hysteresis value.

Thanks again for the great work and for sharing with the community.


Nice work @Jay_cd33, are you using the latest controller code? I switched that to using JSON payload for the MQTT data - or are you using the native Influx API?

1 Like

Stuart, I am using almost the latest controller code. I used the code from just prior to the changes you made to fix the compiler warnings. I did get those compiler warnings about “reply”. I am not using MQTT. I am feeding the data into Influx API running on a RPi.