That all sounds very familiar to how I often find the web interface. I have it running on an access point also (a router in ap mode) running into main router in the house via ethernet. The Mini D1 is almost on top of the AP just like yours. I get big lags and unresponsiveness for periods of time, then eventually it will work for a while, then at some point I loose connection again. If I look at the controller I can see LED’s going off, then on as it resets itself. I seem to get the same behaviour even if the D1 is not connected to anything too.
Issues with WIFI often relate to the power supply - should be 5V 2Amp at least. Random reboots caused by brownouts.
I have prepared the third group of modules (16) to have two installed in the system and a spare third programmed and operational to change quickly. As I am going to reprogram all the modules and the controller again to the latest version, I have a question Stuart. Now there are three firmware versions for the classic modules say, 5K and 9K6. I am reasonably satisfied with the refresh time as with 32 cells it is 6000ms. Is there any other good reason besides the faster refresh rate to opt for faster communications? On the other hand, I have the DIYBMS monitored to an Influx database, so I don’t want to accumulate many more unnecessary records.
What do you think?
1 Like
The key point is to ensure the round trip is below 8 seconds, which is the auto-wake up of the modules.
There are 3 different speed settings depending on if the user finds an issue when running at a higher speed. I would recommend using the 9k6 for all v4.4 installations unless you run into a problem.
just a note: influx data are sent in standard format every 8sec. That’s not related to the polling on the modules done by the controller and the comms speed. It’s two different things.
I also recommend the 9k6 speed, I reflashed all of my modules to use this roughly a month ago and saw the roundtrip time for 2x 7s strings (14 modules) drop to ~750ms.
Hi everyone,
Since JLCPCB is no longer satisfied with the external temperature sensor and wish an additional fee for the 2nd design (right on the picture), I have tried to figure out what would be suitable for them.
For me that version (left on the picture) worked fine without any extra fees and the sensor is still easy to separate from the main PCB:
I ordered 30 modules a couple weeks back and did not pay any extra fees for the break-away portion. It sounds likely that some reviewers are stricter than others.
I’ve had good success with them accepting my design with the external temperature sensor, protruding extensively out of the board.
Trick was to add the tracks going all the way to somewhere (in my case to the normal take off points on the connector) so to their system it looks like a fancy isolated piece on the board connected properly to the board. My first attempt with the ext. temp sensor not connected anywhere failed.
V.
From my experience it is a matter of how lucky you are with the analysts, for some the original design is a problem and for others it is not, recommendation, if they object, you cancel the order and order them the next day.
thanks
Hi Stuart, that’s starting to make sense as I temporarily fixed the controller up to a very low powered 5v usb and it significantly struggled. I’ve always had them plugged into the USB port of a router or similar. I’ll try with a higher current dedicated 5v supply and see if it’s more reliable.
Hi @stuart ,
I have updated to a 9k6 version of the code, since my in my setup 56 cell modules are planed, from which 28 are already in operation. The system works, however I have more than a 100 OOS errors per hour + a couple of CRC errors and sometimes Ignored request. The strange thing here, is that I do not think that there is a problem with cell modules (or am I missing something?) because:
- I have changed all the communication cables from my previous setup with 4.21 boards. They are now only 12 cm long and good twisted. No improvement.
- I have used a spare controller board, which I normally use only for programming and tests of cell monitoring boards after assembly. The same behavior
- I have moved the cell boards around the battery bank. No change - there are still oos errors and the errors does not “move” with boards. For example, there is a packets receive difference between cell 0 and cell 1, so I have exchanged them with cells 14 and 15, where previously there was the same number of received packages. The screenshot below was done after cell were exchanged, and as you can see, there is still difference between 0 and 1 and no difference between 14 and 15… I have also made similar tests on other places with the same result.
- I have resoldered attinys on a couple of boards, where the packets received difference was the biggest, but it looks like the were before the procedure also fine.
I have run out of ideas of what else can I do with cell modules to eliminate those errors… May someone can advice me.
The one thing that additionally looks strange for me, is that communication “running lights” a not flashing with some fixed period. The goes usually in pairs or 3 at a time with small delay in-between (like 0.5s) and then there is a long pause up to 10-12 seconds, then goes another pair. So it looks like controller board sends 2-3 requests and than wait for something to happen. During this pause some sell modules goes to “stand alone” mode by flashing the blue light rapidly. Is it planed so or there is something wrong with my setup? Can it be that I have this huge amount of errors because of that?
Sometimes I also see “Send Q length” field with values from 1 to 3.
The screen shoot is done after 1 Hour 45 minutes of Uptime and counters reset.
Otherwise it works, also the rules including the internal bms error.
I would appreciate any help/advice
Thanks
Update: I am using the latest version
Ok i see, thanks. Though i wanted to use the module to monitor my 105ah lifepo4 battery but with out the current wire, making it a cleaner battery pack
you have not mentioned how you power the controller.
Most of my problems disappeared once I got a 2.5A 5V power supply straight onto the terminals at the top of the board
So, try not to power it from the ESP32 usb cable!
V.
yes, that I have forgotten to mention, however here have also experimented:
- normally, control board is powered through dc-dc converter directly from the battery and connected to the 5V input on the top of the board.
- for the experiment on the main controller board I have tried a standard usb charger/power supply 3A connected to the esp. No improvement
- during the experiment with a spare controller I have placed it directly in the battery compartment so that communication cables were also as short as possible (15cm instead of 40-50 cm to the main controller board) and powered it from a powerful powerbank. No improvement.
So different power sources in my case giving exactly the same result.
Nevertheless, thank you for the suggestion
then I’d expect to be an issue with one of the cables/modules.
Easy test would be to stop charging discharging for a few hours and reconfigure the controller for say 1/2 of the modules and change the cables from the controller to the right number of cells and move along the full number of cells. Could do half and half to test this hypothesis. Obvs if you have the same number of OOS in the same period on both halves of the bank my theory is rubbish 
1 Like
Since I have a spare controller I have made a little bit extended experiment: 14 cells connected to 1 controller and the other 14 to another. After more than 4 hours no errors neither on controller 1 nor on 2.
Additional observation: the running light now coming not only in series of 1 to 3 sets, but also sometimes in series up 6 sets. And also the pause between such series is only 4-5 seconds maximum, so the cell modules are not switching to independent mode and believe because of that there no errors.
“Send Q length” still up to 3
The good news here is that we know now that cables and cell modules are completely fine, but the question is what is wrong…
Now I am doing the next experiment: 16 cells on controller 1 and 12 on controller 2 and then one more with 18 and 10.
good debugging, now you have to wait for ideas from the masters 
I’m out of my depth now.
1 Like
So, the experiment is finished. Up to 16 modules everything is fine, if more - begins chaos with communication.
Here are results from a couple of hours in configuration 12 modules on main controller, 16 modules on reserve controller.
And overnight in configuration 10 modules on the main controller and 18 on reserve one:
Main controller configuration: powered from dc-dc directly from the battery bank (14s), communication cables from battery compartment to controller board around 50 cm and are not yet optimally placed since are going in some places along power cables, which can explain small amount of errors in the night time, because at night time my inverters charge the battery with small currents (2 A each) and from what I measured - it is done in pulses, which can cause some interference. However, based on the packages count on the modules - there are no errors between cell modules.
Reserve controller configuration: to eliminate possible issues with power supply, it is powered from a powerful power bank with usb cable directly to esp. The controller is placed directly in the battery compartment, so the communication cables are short (15 cm on TX and 25 cm on RX). Nevertheless, if modules count is more than 16 - a huge amount of errors appears.
Previous tests in configuration 1p14s on main controller and 1p14s on reserve control, and 2p14s on main controller are above.
@stuart it looks like we would not be able to solve it without your help, since we run out of ideas. =)) Please help