Problem with battery capacity measurement.

[marecek89]

Hi, I have built your project which you helped me set up and calibrate. The problem occurred when testing a 12V70Ah battery. The current drawn was set to 3.5A. During the measurement, the recorded capacity was initially displayed correctly, but then at 14 hours the value 4196981200mAh was displayed. I tried adding the value deletion on the display but with another battery I recorded 31188mAh after 8 hours of discharge, then at 17 hours 48 minutes the value was 419663027mAh which is an unrealistic value. Can you advise me what could be causing this? Even if the battery was good, the time should last 20 hours and the capacity should be around 70000mAh which should not be a problem but there is probably a mistake somewhere and I can't find it. Thank you

[Dominik-Workshop]

Hello, I'm glad you managed to replicate the project!

---

I suspect the problem may lie in the MCP79410_Timer::getTotalSeconds() method and how I'm using it to calculate elapsed time.

getTotalSeconds() seems to just convert the current time in hours, minutes, and seconds to a total number of seconds for that day. When the clock reaches midnight (23:59:59), the time resets to 00:00:00 (keep in mind, that in this case, the RTC time doesn't correspond to real time as it's just used to measure time intervals).

This causes the getTotalSeconds() output to suddenly drop from its maximum value (86,399) back to 0.

The capacity calculation subtracts the previous time from the current time. When the rollover happens, it tries to subtract a large number (e.g., 86390 from before midnight) from a very small one (e.g., 5 from after midnight). With unsigned integers, this results in an integer underflow, which "wraps around" and creates a massive, incorrect time difference, leading to the unrealistic capacity reading.

---

Hope this helps, and thank you for pointing out this problem.
I'd love to solve it, but currently I don't have much time on my hands.
Let me know if you manage to solve it.

[marecek89]

yes it looks like when changing from 9:59:59 to 10:00:00 some part of the code that sends the current time changes and the program cannot decipher it or takes it as an error. chat gpt keeps offering me the millis function as an alternative which would supposedly be good but why not use rtc when we already have it there even though I tried to edit the code I am still unsuccessful and I would like the time to be displayed until 999:59:59 due to the slow discharge of the large capacity battery. overall the load is super well thought out but I did not expect such errors to come after 10 hours but it is always about tests and communication, maybe someone who is more skilled than me will read this and write us an answer but it would be a shame not to finish it. I didn't understand it for a long time when it was explained to me that the RTC is cleared after 12 hours, why does it break after 10, but we figured out that the format is changing to a two-digit number. I was most annoyed when I tested a large battery and the result was meaningless instead of the real value.

[marecek89]

Hi, I tried using millis to track time during a capacity test but the adjustment was unsuccessful. After 7 hours of testing, the time was 4 minutes late and I didn't like that. I decided to use rtc but only a second interval and then calculate the time. I currently have a modified version that has been running for 22 hours. So far everything looks ok. I plan to let the test run for 100 hours to see if it is able to measure such a time with this adjustment. If the tests pass, I will send you the modified code so you can go through it and check it. I have a question, is rtc time only used in the battery function? I think transient uses millis. Or is rtc still used somewhere besides measuring capacity? Thank you

[Dominik-Workshop]

I'm thrilled to hear that you managed to fix the problem. I hope the long term test passes.
Thank you very much for your valuable input.

---

Yes, RTC is only used in the
batteryCapacityMode() and I'm using millis() in transient mode (which isn't a perfect solution)

[marecek89]

Hi, I'm reporting after the end of the 160-hour load test. The time delay is 30 seconds for the entire 160-hour test and when discharging at 1.004A, the deviation of the measured capacity is 667mAh, which is negligible at that time. I think it might be worth calibrating the current measurement. After the adjustments I made, the time is used from the RTC, but only the second interval 0-59s is obtained and the rest of the time is calculated later. Now the load can measure up to 999:59:59 hours if necessary :D without incorrect display of the measured capacity. I decided to use a time format that gradually adds hour digits and does not fill in 0 empty spaces but only in hours. The original function such as continuing when changing the current or during a pause is preserved. The code still needs to be cleaned of the original functions that I left there because I didn't know if something else was using them. but it's just a cosmetic defect the main thing is that it works as it should. if you tell me how I would send you or attach the modified code here I would send it to you so that you can make the modification so that others who would be interested in building your project have a flawless version. be careful I have the capacity adjusted to 999 999mAh and the fan map changed in the code. Another question should not be in the code controls.cpp line 29 in the section: fanspeed = map(measurements.temperature, lowTemperatureThreshold, 45, 20, 255); instead of the value 45, the variable is specified as highTemperatureThreshold since we have it defined in controls.h?

[Dominik-Workshop]

Hello!
That is fantastic news! Thank you very much for your efforts. It is greatly appreciated.

---

You can create a pull request with your changes. This way you will be visible as a contributor.
I'm not sure when I will be able to clean it up and merge it to master branch. I might merge it to a temporary branch with your current version of the code, so that everyone can rather easily use your fix. And after refactor it would be merged to master.

---

You are right regarding the fanspeed mapping, it should be:
fanspeed = map(measurements.temperature, lowTemperatureThreshold, highTemperatureThreshold, 60, 255);.

[marecek89]

I tried to make a pull request. I hope it worked because it was the first time I made such an edit. I hope I did everything correctly.

[Dominik-Workshop]

Yes, you managed to do it correctly. Thank you once again for your work!

---

One question: could you ensure all your comments in the code are in english?

[marecek89]

I'm glad it worked and I apologize for the comments. I'll try to fix it when I figure out how to reopen and edit the code.

[Dominik-Workshop]

Thank you.
You can just fix it on your fork and commit it to your branch as before. The Pull Request will automatically update with the new commit.

[marecek89]

I tried editing the comments in the code, I hope they are showing correctly now and that I uploaded them correctly. It should all be correct now. I'm glad I was able to contribute and add it here.

[Dominik-Workshop]

Yes, you did it correclty.
Thank you once again!

[marecek89]

Hi, I tried the new code with your application that you created. It shows everything fine on display load and the graph is drawn nicely in the application, the percentage of capacity was calculated correctly even with 70Ah batteries, but the resulting capacity displayed in the application probably has few possible places to display it, since I only saw 6000mAh, but on load it was 56000mAh. Could you edit it? Since I don't know how to edit applications and I have no experience with it. I would like some ideas for improvement, but I can't edit the application.