After a number of trials at quiescent ( 0 and 2A charging), charging (80-90A)
and discharging (100-120A) states, a pattern of Daly BMS to PC comms begins
to form.
These are illustrated in the two attached charts. Both show the time-stamped
'BMS Life' reporting intervals reported in the logs of the trial periods before
reporting either ceased entirely and/or the DalyBMSMonitor program crashed.
The reporting interval generally increases with time. In the 211125 plot, this
interval actually went off the scale of the graph (>200 BMS Life cycles),
reaching the 500-600 count.
As previously stated, the DalyBMSMonitor program uses a lot of this PC's
microprocessor's capacity. It starts at 20% and rises pretty quickly (<1hr)
to ~80%. If other programs running simultaneously are terminated, it can
rise further.
Another interesting point to note:
The log files carry a date-stamp that identifies the last recording time or log
entry.
Of the five logs present at the end of testing, 2 crashed within minutes of 3PM
and 3 crashed within minutes of 9PM.
This may reflect or amplify the relevance of reports of BMS units repeatedly
ceasing to function normally at a specific time of day.
This system install is located at GMT-5. and no equipment in the test bed has an
internet connection, or wireless comm. Clock times reported are those of the PC.
Reports of other users experiencing anomalies at certain times of day are
present on at least one other thread (8S, PV and bluetooth comms).
Good day. I have a Daly BMS on a 24V 202Ah LiFePo4 battery system. I am using a Victron 100/20 MPPT Solar Charger. Currently, the equipment and Charge Controller's Negative wires are connected straight to the Daly's "P-" Black cable and the Equipment and Charge Controller's Positive (Red) wires...
diysolarforum.com
[Beside the point; the logs developed by the DalyBMS-v1.1.6, in .xlsx have the SOC and
current column headers swapped over. I don't know if this reflects possible problems
in actual comm/BMS processing activity.]