Hi all.
Has anyone come across an issue where the CCL updates just fine from BMS but DCL is stuck at a constant value all the time?
EDIT:
At the first day of install it seems it was a higher value, but since it is enforcing 646A:
It depends on what your battery sends to the system.
And yes, many batteries vary the CCL based on what they want, but not the DCL.
The ones that vary the DCL do it based on the load currently being pulled from it. So basically it could be what is left that you are allowed to draw from it in discharge amps. Eg. 100A DCL (total bank) but you are currently pulling 20A means it will send 80A not the original 100A
The other possibility is that a battery in your stack is loosing communication.
The battery we know is sending updated values as we monoitor it directly on console. Problem is Cerbo doesn’t seem to update its own value:
Sute its updating its own, but does it send it on the can bus?
Am i blind where does it show the DCL in your battery stats screenshot?
{Edit} never mind i see the recommendation discharge current.
It expect because what we see in console for CCL is being updated almost realtime.
Yes, so your battery doesn’t update the DCL.
Pylontec are the same (their DCL remains constant) unless there are batteries that stop communicating in the stack.
That’s not good because here for example I notice than instead of using the battery bank to service the load when it gets near this 640A DCL it starts to use the grid.
And you have set up according to the guide?
Pylontechs can reduce DCL when below ~15 degC. Are they cold?
Yes, we are in direct contact with Pytes also. Wanted to reach out here also because they do not have an answer yet why this happens. Maybe someone ran into this issue before. Note we are using a Pytes Hub because there are 96 V5 Pytes batteries here in question.
No, it is at 17C all the time inside here.
The answer is simple.
The charge and discharge currents are communicated on 16 bit variables (2 bytes) with a resolution of 0.1A.
That’s the Pylontech protocol which many are copying.
For example, a value of 200A will be represented as a value of 2000.
Your 7200A, will, ideally, be represented as a value of 72000.
But on 16 bits, only values from 0 to up to 65535 can be represented.
Therefore, the value will be truncated to the lowest 16 bit part, which is 72000 - 65536 = 6464.
So it will show as 646.4A.
As a side note, as the storage systems capacity grow bigger and bigger, maybe a revision of the protocol, at the international standard level, may be expected in the future…
2 Likes
Ok, i’ll test your theory now by disconnecting some of the batteries to fall under that value.
The max number is 87 in order to show correctly… 
So you’ll disconnect at least 9.
Or 10 to be a round number… 
So you have 8 banks of 12 batteries each… 
Well Pytes has nothing to do to solve the problem, unfortunately… The protocol has become obsolete and insufficient.
And even if they modify the representation to be at 1A resolution, Victron will need to adapt its software to proper represent the values and for sure it wont.
Solution would be if value exceeds the maximum, to report just the maximum.
That could be a crude and temporary solution that’ll work. 
Probably they need to give you (or to all) a new firmware…
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.