Should i contact SergioF or will you provide that fw version…?
Do you mean the reduction of delay between the packages based on the current q_length that I have done for my system recently (we have discussed it in the main [DIYBMS v4]topic)?
Yes, for me it works great since the change. @vas I believe has also tested this change on his system - no failures reported so far, as far as I know.
true, but I have a simple 8S system and no issues before the edit either. Just confirming it had no ill effects so to speak.
V.
1 Like
q_length… I think sometimes I see a small q_length frame with info on the bottom of gui… but it disappears after 1-2sec…
Curious what you guys come up with… is there a fw which I can test?
best
Karl
To be fair, the change @Yar_Leo made increases the delay based on queue length, which I didn’t expect to work as normally you would want the queue to be processed quickly to reduce the queue length.
Perhaps just reducing the overall delay helped.
Don’t get too hung up on the queue length, its just a debug value, when the BMS is first powered up it will be high (probably 30) but should drop after a few minutes and settle on single digit numbers.
Hi @stuart,
If you remember, I have done first the tests with fixed values. If the delay is <=7s - the system works stable.
However, you have told me, that reducing the delay between new requests to update the modules data can result in overflowing the queue, for example when additional requests would be generated during balancing, etc.) and that you wish to have the queue as empty as possible. So, with the help from advices from other members of community, I have made this delay adjustable. So that when there are no additional requests and the queue is empty the requests are generated very often for more frequent data update from the modules, and when queue is already filled with other requests and to prevent the overflow (keeping the queue as empty as possible), the delay for generating new request increases, so that the queue is emptied fast (make no sense to generate new requests, if previous ones are not yet processed), and when it is again empty - the delay is again reduced to have the faster periods of data update from modules. I hope I have explained it good enough and from the beginning understood you right about the ideas, implemented / planned for the data exchange sequence.
Generally, based on my tests, the communication works also fine with a fixed value, like 5-7 seconds.
The last code update I released, makes it impossible to over flow the queue, new requests pause until there is a space in the queue to add the new request.
I think its probably easier to add a simple user configurable delay/interval setting to the interface, or do some math based on the number of cells in the system.
Either way, it looks like the delay is the root cause of the issue in larger deployments, and we have both solved it but approached in different directions.
Supper, in this case
would be, from my point of view, a perfect solution. Calculation, based on cell numbers, was implemented partly at the very beginning and was not working properly, and it that case also a communication speed would probably must be taken into account. So - simple setting in the interface would make it much easier and flexible.
Hi,
any ideas how i should deal with the problem…
thx
karl
If you are ok with compiling the source code yourself, you can try to change the 10000 in line 45 to 6000 or 7000. And check if it helped or not.
thx. will do so!
1 Like
Leo,
Your solution from a month or so ago - did it prove to be unstable ?
see DIYBMS v4 - #4500 by Yar_Leo
Yes, it works fine for me since than: stable and without any issues. However, as you can see in our discussion with Stuart above, another solution would be implemented in future updates to deal with this issue.
If you experience similar problems, you can use it till a new update is released. Alternatively you can just reduce the delay from 10s to 6 or 7, as recommended to @Emir0815. It als works and helps with communication issues
Hi All, I’ve added in a variable delay, which can be selected from the user interface. I’ve called this “Inter-packet gap (ms)”
If you take a look at this GITHUB action, you can see the new firmware files in the link named DIYBMS-Compiled
[https://github.com/stuartpittaway/diyBMSv4ESP32/actions/runs/1893981502]
Let me know how you get on.
Try to pick a delay which works for you, but isn’t too low. The idea is that you give the modules some time to “sleep” to preserve energy and ensure they don’t drain the cells they are connected to.
Thanks.
dumb question, how can I download compiled fw?
aaaah, was just a question of logging in…
thx
I’ve released this code as part of an update over the weekend, so its now in the master branch as well.
many thanks, stuart!
Sorry for responding so late. I only could manage to care about my diybms setup just in last few days.
It didn’t work with the new firmware either. I tried every possible setting between 6000 and 9500 but no success. As it cost me soooo much time (and you guys as well) and sun is coming out now I wanted a running system now, I’ve decided to reconfigure my whole setup.
Now I have 2 strings 14S160P and 1 string 14S80P. By doing so I have 42 modules only and I hope this will work out. I’ve reflashed modules with standard V4.4.
What I can see is, that, when modules balance, they receive very few packets.
Any idea what the reason for that issue?
Pls. see attached screenshot
Regards
karl
PacketsReceivedTopic.pdf (117.6 KB)