Synapse (Voltronic/Axpert) battery voltage calibration - help?

[jbroo]

Hi all,

I tried to do some calibration to my inverter's battery voltage reading, as it was consistently higher than measured with a multimeter or reported by the battery balancer. In the process, I think I may have made things worse...

My inverter seems to use the PBATLXXXX and PBATHXXXX pair of commands (as it does not respond to the BTAX commands). I can't however see any difference when sending these, and doing a PSAVE. I've tried setting the voltage to that reported by multimeter with PBATH, with full batteries, as well as setting a PBATL voltage, admittedly not with empty batteries, but certainly a couple volts lower than the PBATH value. I can't get anything to stick - the inverter still seems to report what it wants to.

I started off with the inverter reporting about 0.10-0.20V above the actual reading. Inverter was reporting 27.20V, with batteries reading at about 27.00V. It's now even worse, with the inverter reporting 27.50-27.60, when the batteries are at 26.60 - now I have a discrepancy of about 1 Volt! I'm afraid this also means the batteries are now not going to fully charge...

I used the various commands in this post, which is how I came to find that PBATL/PBATH works for me... and also how I somehow made things worse. Some command must have changed a setting, yet retracing my steps and running various commands (including the "nudge" ones, if they worked at all) does nothing.

I've tried all commands listed in the attached document, in various orders, followed by a save, yet nothing seems to change:
SMV III 5K 232 Axpert KS&MKS&V&KING RS232 Protocol 20200102.pdf

And also this one:

The screenshot below is from during load shedding, so my batteries really are at 25.90V currently, the inverter reads them at 26.99V:

What am I doing wrong?

@Coulomb @BritishRacingGreen Maybe you have some knowledge on this? Or anyone else, please help?

Edited August 27, 2023 by jbroo

[Coulomb]

Alas, it's all theory how this works; thanks for reporting the problems.

It seems to me that since you want the readings to be lower, you need a smaller scale. So perhaps you could try lying to the inverter, telling it that the multimeter reading is even higher than it really is for PBATH, and even lower than it really is for PBATL. Use a consistent lie for both, it seems to me, though if it' calculating a new offset as well as a new scale (slope of the function), then you might be able to get tricky and try to get the offset better.

Unless these commands are completely wiping out the scale and possibly offset with random or incorrect values, it seems to me that you are affecting the result, so some combination of commands with lies should improve the situation.

Good luck, and please report the result (even if it's that you can't get the readings any better).

Edit: Oh, I didn't notice the documentation on things like the PSDF command. Perhaps I should investigate. Thanks for pointing that out.

Edited August 27, 2023 by Coulomb

[Coulomb]

Sigh. It seems I was wrong about the PBATH and PBATL commands. It seems you have to send these three in order:

PSDF

PBATLnnnn

PBATHnnnn

Internally, the PSDF sends a BTA0 command to the solar charge controller's processor, PBATL sends a BTA1, and finally PBATH sends a BTA2. I haven't checked whether the solar charge controller can cope with the commands out of order, but it seems sensible to send them in the order such that the solar charge processor gets BTA0, BTA1, and BTA2 in sequence. Probably BTA2 is the one that actually calculates the new scale and offset in the SCC, so it's important to get that right as well.

I had suggested sending the commands in the other order, and said that the order doesn't matter.

My guess is that this added enough chaos to the situation that things never made sense, and that's why the readings seem to get worse rather than better.

So (at least at this stage), it would seem that there is no need to lie about the multimeter reading.

I hope that this helps with your calibration.

It also shows the importance of reporting  when things go wrong, so that instructions like this can be corrected. So thanks for that feedback. Hopefully others can get their calibrations right now.

And sorry for the bad information, and the frustration that it caused.

[jbroo]

Thank you @Coulomb. Do you know whether there should be a vast difference between low and high voltages? For example, would 25V (12.5V per battery) and 26.5V suffice, for low and high respectively? I can't seem to get the batteries to a voltage higher than about 26.5V since I started to fiddle.

Oddly enough, my PV now reports 30V input voltage (I have nothing connected to the PV input) so something has definitely gone screwy. The heatsink temp is also now lingering around 25°C - it's never been this low. Not sure if that's because no charging is happening or some calibration got messed up there too...

I will try the following, in order, and report results:

1. Run inverter on batteries for 1 hour to deplete them a bit
2. PSDF
3. PBATLXXXX where XXXX is current "low" voltage
4. Let batteries charge
5. PBATHXXXX where XXXX is current "high" voltage
6. CF11 to turn on both fans
7. PBFXXXX where XXXX is current voltage with fans on. I gather from documentation this might mean the fans run off battery and have some draw
8. CF00 to turn off the fans
9. PSAVE

EDIT: The above doesn't work.

Edited August 28, 2023 by jbroo

[jbroo]

The above appears not to have worked. Inverter still reports 27.50-27.60V, and my batteries are sitting at 26.60V.

Worse, my suspicions are confirmed - they are not being properly charged. I ran a 500W load off the inverter on battery, and it shut down the AC output after about 15min - I have 2 x 200Ah in series. The mutimeter on my batteries reported 26.00V at the time. Not sure if the shutdown was due to the low battery cutoff setting on the inverter, or the batteries' BMS kicking in. Either way, at 13v per battery, its still too high... The inverter registered a fault when this happened, but in panic I didn't see the code and cleared it.

After returning main supply to the inverter, it had a few attempts to enable AC output, which failed, before it finally managed to power a load again. The multimeter reported 26.30V within a minute, and the inverter was reporting 27.30... No real bulk charge seemed to happen either.

I'm starting to think the PBATL/H commands only affect the SCC controller's battery reading, and not the main battery voltage measurement, since after a few attempts I noticed that "SCC battery" value was in line with my actual battery voltage, but the other "main" value reported was still wrong. @Coulomb do these commands in fact only calibrate the SCC battery voltage? I do not have solar.

Edited August 28, 2023 by jbroo

[Coulomb]

4 hours ago, jbroo said:

@Coulomb do these commands in fact only calibrate the SCC battery voltage?

It may depend on what firmware you are running. What is your main (U1) firmware?

[jbroo]

5 hours ago, Coulomb said:

It may depend on what firmware you are running. What is your main (U1) firmware?

QVFW: VERFW:00009.56
QVFW2: VERFW2:00003.39

[jbroo]

Alright, I think I've figured it out, and it's a lot simpler and quicker than assumed:

1. Connect a reliable multimeter across your battery bank. It might be a good idea to cross-reference with another meter.
2. PF - This one is optional but will reset all settings to default. Set your preferred settings again via WatchPower or whatever you use. Skip this to just do calibration.
3. PSDF - Enter calibration mode
4. PBATHnnnn - Set the "high" voltage. In my case this was PBATH2665, as my meter reported 26.65V.
5. Turn off mains supply to inverter so it's running off battery only. Let it run for 10-15 min to get a sufficient voltage drop (make sure you have a decent load).
6. PBATLnnnn - Set the "low" voltage. In my case this was PBATL2630, as my meter now reported 26.30V.
7. PMID - No idea what this does actually, but did it since it was included in the steps in the protocol doc.
8. PSAVE - Save calibration.
9. Turn the mains supply back on and let the batteries charge for 10-15 min.
10. CF11 - Turn on both fans.
11. PBFnnnn - Set the battery voltage with both fans running. Consult your meter again here.
12. PSAVE - Save calibration again. This will turn off any running fans that are not needed.
13. QPIGS - Run this one a few times in a loop, and compare the reported battery voltage with the reading from your multimeter.

If all went well, your inverter's reading should now match the reading of your multimeter.

After the above process, my batteries began to charge properly and topped out at a perfect 13.60V per battery (27.20V total). Once they reached 100%, the inverter entered float mode and they settled at 13.50V each (27.00V total). The inverter was reporting correct battery voltage throughout the charging process. For reference, I'm using 28.20V for bulk, and 27.00V for float.

I will check the readings again this evening for any drift.

Edited August 28, 2023 by jbroo

[jbroo]

Update: Readings remained accurate, but because of my OCD I had to fiddle again, and buggered them up  The good news is the above process repeated gets me back to an accurate reading and good charge. It looks like including the PF command helps - attempts to calibrate without doing a PF first resulted in the same overly high readings as before.

[Coulomb]

14 hours ago, jbroo said:

I think I've figured it out, and it's a lot simpler and quicker than assumed:

Just a quick 13-step process! Wow, thanks for sorting that out.

It looks like PBATH and PBATL might be able to be done in either order again, but the results DO NOT TAKE EFFECT IMMEDIATELY. They seem to take effect on the next power-up. Does this affect your process at all? I don't see turning off the inverter completely as part of your step by step process. I can't immediately think why PF (resetting user settings) would affect this process, so I suspect that there is a confounding factor. Not totally resetting might be that factor.

Whatever PMID does, it seems to also only actually take effect on power-up. It's all quite complex; dozens of memory locations are involved, there are undocumented commands (like the D command; looks like it might be a Debug command that returns a 70 character result), and everything seems to depend on everything else. I still haven't checked against the only 09.xx firmware that I have; this is still all 02.43.

[jbroo]

5 hours ago, Coulomb said:

Just a quick 13-step process! Wow, thanks for sorting that out.

Sigh, I wish it were this simple. Of the two times this worked, there are 10 where it didn't. I don't quite have the formula yet.

5 hours ago, Coulomb said:

They seem to take effect on the next power-up. Does this affect your process at all? I don't see turning off the inverter completely as part of your step by step process.

Turning off completely is/was not part of my process. I did try my process twice now with the last step being a power off and on, and it's still not working. Inverter is over-reading by 1.2-1.4V  I will keep trying until I stumble on a repeatable process...

Edited August 29, 2023 by jbroo

[Scorp007]

1 hour ago, jbroo said:

Sigh, I wish it were this simple. Of the two times this worked, there are 10 where it didn't. I don't quite have the formula yet.

Turning off completely is/was not part of my process. I did try my process twice now with the last step being a power off and on, and it's still not working. Inverter is over-reading by 1.2-1.4V  I will keep trying until I stumble on a repeatable process...

Sorry to read the long road to get a more accurate reading. 

It reminds me of if not broken don't fix it

[Coulomb]

1 hour ago, jbroo said:

I did try my process twice now with the last step being a power off and on, and it's still not working.

Actually, I've just realised that the new values are saved in RAM. Unless those values are saved and restored from EEPROM, it can't work the way I was expecting.

And it looks like they are; the new battery offset and scale are the first two words (pairs of bytes) written to the EEPROM. So make sure that PSAVE is sent between the second PBATH/L and the powering down. But I'm pretty sure that would always be the case.

[jbroo]

1 hour ago, Scorp007 said:

Sorry to read the long road to get a more accurate reading. 

It just part and parcel of trying to do something with little to no documentation on the topic. I have hope that with enough trial and error I'll find a working method that is repeatable.

1 hour ago, Scorp007 said:

It reminds me of if not broken don't fix it

Well, in my case it was broken - the reading was not accurate. It might be frustrating but it's worth it to me.

[jbroo]

9 hours ago, Coulomb said:

Actually, I've just realised that the new values are saved in RAM. Unless those values are saved and restored from EEPROM, it can't work the way I was expecting.

And it looks like they are; the new battery offset and scale are the first two words (pairs of bytes) written to the EEPROM. So make sure that PSAVE is sent between the second PBATH/L and the powering down. But I'm pretty sure that would always be the case.

@Coulomb I wonder if a PSAVE is not required at every step? I assumed logically that PSDF would begin calibration, and the PSAVE would only be needed at the end. Before I left home this morning, after many fruitless attempts, load shedding had kicked so out of frustration I just did the PBATL and PSAVE commands (no PSDF, no PBATH, no PMID). It seemed to then report a reading in line with what my meter was reporting. It could also just be more accurate when the batteries are discharging.

I really hope I can find the correct pattern or sequence of events... It's frustrating that I don't know what I did right on the two times that it did work...

EDIT: this is what I last sent, I threw caution to the wind and went 0.30V lower than my meter reading, because I was over it...

Edited August 29, 2023 by jbroo

[jbroo]

Well, somehow that last PBATL command got me where I want to be. Still not sure of the correct sequence or magic combination, but I'm quite happy with these results:

Balancer:

Inverter:

I can now confidently set all my various charging and discharging settings, knowing that the voltages set will be realistically tied to the actual battery voltage.

Moral of the story?

[Coulomb]

Perhaps the PMID command is another confounding factor.

It seems to take the average of 64 readings from channel 10 of the ADC (Analog to Digital Converter) that was saved before the last power-on, if I got that right.

I think perhaps power on when everything is quiet (no loads, no utility or solar connected), run the PMID command, then PSAVE and power off. Then unless you have very good reason, don't use the PMID command again.

Then start your calibration checklist again, minus the PMID step.

That's if you're willing to play with it any more.

[jbroo]

4 hours ago, Coulomb said:

That's if you're willing to play with it any more.

I'd be very reluctant to open this can of worms again. As much as I would love to know the exact correct procedure, I've got the voltage readings so close now, that unless I run into other calibration issues in future (adding PV, charging issues), I'm going to let sleeping dogs lie.

If anyone else on the forum is willing to experiment, maybe they can add some clarity to the process further.

Thanks for all your helpful responses @Coulomb.

[Coulomb]

6 hours ago, jbroo said:

I'd be very reluctant to open this can of worms again.

Ok, totally understandable. I just wondered if your OCD might have overcome your caution .

[jbroo]

Hello all. At some point my inverter decided to de-calibrate itself, so now it is wildly over-reading the voltage, and consequently not charging the batteries.

I've played ad nauseum with the PBATH and PBATL command pair, and have established I can pretty reliably set the battery voltage on the SCC, however this doesn't come into play - I don't have solar and this reading does not seem to influence the inverter's actual perception of the battery SOC. Instead, it uses the "battery voltage" reading, which I cannot for the life of me seem to set in any way.

For example, these commands reliably set the SCC voltage (even when using the same voltage reading):
PBATH2458
(ACK
PBATL2458
(ACK
PSAVE
(ACK

This results in the following:
Battery voltage    28,71V
Battery voltage SCC    24,58V

QPIGS result:
(228.0 50.0 228.0 50.0 0374 0338 014 418 28.71 000 100 0027 0000 000.0 24.56 00000 10010000 00 03 00000 000

Note the correct SCC voltage set above, and the wildly incorrect "battery voltage". I've done this over and over in various permutations, with/without PMID, with/without a power off and on, with/without CF11/PBFnnnn, and so on.

I've figured out how to set the SCC voltage accurately repeatedly, but the other voltage just does not correlate, ever. It's gone as high as 30+V, and as low as 24, with no relation to the actual battery voltage as measured by a multimeter, nor any relation to the value displayed for SCC voltage.

Any ideas here would be greatly appreciated. I'm sitting with flat batteries that won't charge until this stupid thing actually knows they are flat.

@Coulomb maybe you have some suggestions?

Edited April 11 by jbroo

[Coulomb]

On 2024/04/12 at 5:36 AM, jbroo said:

PBATH2458
(ACK
PBATL2458

I believe that you have to send the H and L commands at significantly different SoCs, otherwise it can't calculate the offset, only the slope, of the curve.

So when it's nearly full, send a PBATH,  then hours later when it's much lower, send the PBATL.

These are designed for use on the test bench at the factory, where you can adjust a power supply to look like a high or low voltage battery. If you have a suitable adjustable power supply, you could do the same.

I'm surprised it ACKd the second command when the parameter to the first was the same.

Edit: It's also possible that the resistors are now intermittent, in which case this won't help much, and you'll have to eventually repair the resistors.

Edited April 17 by Coulomb

[jbroo]

Thanks @Coulomb

I think the resistors you speak of must be intermittent or toast. Pity, the machine is less than a year old.
I tried last night/this morning, leaving the batteries to drain:

PSDF
(ACK
PBATH2648
(ACK
PBATL2256
(ACK
CF11
(ACK
PBF2244
(ACK
PSAVE

Sadly, the result is still way out:

QPIGS
(225.0 49.9 225.0 49.9 2460 2459 102 423 26.86 000 100 0031 0000 000.0 24.75 00000 10010101 00 03 00000 100

Edited April 24 by jbroo

[Coulomb]

On 2024/04/24 at 2:31 AM, jbroo said:

I think the resistors you speak of must be intermittent or toast. Pity, the machine is less than a year old.

The resistors themselves cost less than about US$1; you'll pay 20x that for shipping.

On 2024/04/24 at 2:31 AM, jbroo said:

PSDF
(ACK
PBATH2648
(ACK
PBATL2256
(ACK...

So the voltages you entered in the PBATH and PBATL commands are from a trusted multimeter, with the  battery not charging or discharging very much,  and were hours apart?

On 2024/04/24 at 2:31 AM, jbroo said:

CF11
(ACK
PBF2244
(ACK

I'm not  familiar with those. Perhaps the  magic formula that you found by trial and error isn't right in all circumstances?

Maybe I'll get a change to chase up those commands one day, and see if I can sort out what they really do, and possibly, if and when to apply them.

[Coulomb]

44 minutes ago, Coulomb said:

Maybe I'll get a change to chase up those commands one day,

I got this far: in Axpert firmware version 02.43, the CF command takes more digits:

C F n n n m m m

n n is 00, 01, 10, or 11 as per the protocol manual

m m m seems to be a fan percentage, 000  to 100. It doesn't seem to be error checking the mmm parameter.

But I can't see how this would affect battery calibration.

[jbroo]

On 2024/04/25 at 5:39 AM, Coulomb said:

The resistors themselves cost less than about US$1; you'll pay 20x that for shipping.

I figured as much. I'm fairly handy with a soldering iron and a resistor chart so if I can figure out where these are, I will change them, provided they are indeed the culprits.

On 2024/04/25 at 5:39 AM, Coulomb said:

So the voltages you entered in the PBATH and PBATL commands are from a trusted multimeter, with the  battery not charging or discharging very much,  and were hours apart?

Yes, trusted multimeter (and cross referenced on the balancer's reading). They were about 12 hours apart - left the system running on battery overnight to discharge.

On 2024/04/25 at 5:39 AM, Coulomb said:

I'm not  familiar with those.

They're in the same calibration section in the manual. It seems to be an additional optional calibration step, perhaps for accuracy. CF11 turns on both fans (to full, since they're either on or off), then you tell the inverter what voltage you get with these turned on, by using the PBFnnnn command.

Presumably this is because they would draw a little more, but realistically I've never seen the voltage drop when the fans are turned on. Interesting however that you've found the additional "percentage" option on the CF command. This is not described in literature, and presumably without any components to control speed, this would actually do nothing. I suspect the inverter may parse the "nnnn" values and ignore "mmm". In any case, the CF and PBF command pair were always a last step I took and never seemed to have much effect on the reading.

Edit: As expected, CFnnmmm does nothing extra. CF11 = both fans on, CF00 = both fans off. No fan speed control. Sending CF11050, for example, still turns them both on to full.

This whole saga has really drawn out for me and I'm no closer to finding any particular pattern. For instance, yesterday when I woke up the inverter was severely under-reading the voltage (reporting 27 or so), while the batteries were being pushed to a dangerously high 31.10...

Once again, I started with PSDF, used 31.10 as the PBATH reference, then left them until about 26.50 for the PBATH reference. PSAVE, CF11, BPF, and so on... It got rid of the overcharging, but still remained inaccurate.

Throughout all this, the SCC voltage has been easily and reliably set to an accurate reading. It's the "battery" voltage that always drifts, and it is this voltage that the inverter uses as a reference for the battery SoC, charge voltages, etc. Hence, when it is wrong, everything is wrong.

I've just done yet another PSDF followed by the usual steps. This time, however, I issued a PMID directly after PSDF. So far, I'm closer than I've been in a while:

I measure single battery voltage for better accuracy on the meter.

Fingers crossed this does not drift again in a few hours or days...

I suspect PMID is a black magic command that does a lot more than we know. Perhaps it must be issued after all? I know @Coulomb you suggested not to issue it, and I have avoided using it, just sticking to PSDF and the PBATH/PBATL pair, until now again. There is probably also a correct time in the sequence to use it - be this directly after PSDF or after the voltage pair.

The hunt for accuracy continues...

Edited April 28 by jbroo