4 hours ago, birdibird said:

Any update for us MAX 7200 users?

Dang, it has been a while, sorry. EVs and King patching have been sapping my time. It seems straightforward, I'll see what I can do after an important errand.

This is patched firmware version 245.11, based on factory firmware version 45.11 for the Axpert Max E 7.2kW '2809. It implements Georg's MPPT patches, with a minimum MPPT voltage of 120 V (since earlier Georg said that this was the best compromise for machines with no hardware modification). Factory firmware version 45.11 is said to fix some false EEPROM errors; dsp.hex is dated 22/Aug/2022. The premature float bug is fixed, but Fault Code 90 has not been defeated. These patches do not implement Georg's shadow/shading management patches; those are a separate set of patches, and as far as I can tell are fairly specific to a particular number of panels.

Only use this patched firmware on Axpert Max 7.2 kW models with the '2809 processor, i.e. those that come with factory firmware 45.xx or the following specific firmware versions (not any in between): 90.11, 90.19, 90.28.

Firmware update instructions here. Use at your own risk.

My apologies once again for those waiting so long, e.g. @birdibird.

dsp 245.11 patched Max 7.2kW '2809 120V.zip

Thanks @Coulomb
I will test it.

Look what Solar Assistant does with the Driver and Firmware version...

 

Another interesting observation with this 45.11: (I haven't had 45.11 before, only 45.07, 90.11, 90.19, 90.28)

Under setting 12, 13 and 29 when Pyl is selected there is now a SOC% written instead of V. (MCU 12.21)

Also: A setting 92 appeared. Anyone any idea what would be that?

Edited March 25, 20233 yr by birdibird

17 hours ago, birdibird said:

Look what Solar Assistant does with the Driver and Firmware version...

Ah. It might have a list of major firmware version numbers for Max Es, and if it's not on the list, it assumes it must be a Max II. That could cause problems, though I can't immediately think of what they might be, unless they are relatively trivial things like not being able to change the colour of the LEDs on the LED bar (thinking it's talking to a Max II with an LED ring).

Let me know if I have to unpatch the version number string. It would be a pity to lose the ability to be sure of that version you are running, though.

Perhaps you could ask the Solar Assistant people to ignore the hundreds digit of the major version number (e.g. the "2" of "245.11) when deciding if it's a Max E or Max II? Oh wait, maybe it's the displays that are making this distinction. I think I need to investigate.

16 hours ago, birdibird said:

Also: A setting 92 appeared. Anyone any idea what would be that?

Max IIs have this setting; it's "Brightness of RGB LED". It can be set to LO, NOr, or HI. So presumably this is a MAX E / Max II difference.

16 hours ago, birdibird said:

Under setting 12, 13 and 29 when Pyl is selected there is now a SOC% written instead of V. (MCU 12.21)

Ah. It looks like this is a difference between Es and IIs as well. The display firmware when it I have no idea why. Does it seem to work as intended?

18 hours ago, birdibird said:

Also: A setting 92 appeared. Anyone any idea what would be that?

What are the values for this menu item? Are they DCD/DCE? 12.21 seems to differ from other display firmwares in this respect.

Edit: Or at least differ from the manuals. DCD and DCE are to disable and enable the 12 V DC output, which again is a Max II only feature, I think.

Edited March 26, 20233 yr by Coulomb

On 2023/03/26 at 10:54 AM, Coulomb said:

What are the values for this menu item? Are they DCD/DCE? 12.21 seems to differ from other display firmwares in this respect.

Edit: Or at least differ from the manuals. DCD and DCE are to disable and enable the 12 V DC output, which again is a Max II only feature, I think.

Correct, is says DCD/DCE and is standard set to DCE. (setting 52 is Brightness of RGB LED)
I haven't seen it though before I flashed 45.11, but I could be mistaken of course as I don't check all settings all the time. I have been running 12.21 for quite some time now.

Strange that it is in this (display) firmware when the Axpert Max 1 doesn't have a 12V output....

I will write Solar Assistant about the faulty model name. Strange, I would expect they have a list of names against the model number (which is 44 for the MAX 1).

ps, what do you mean with the Max E? I haven't seen that name yet, I know it as MAX or MAX I or MAX 1.

pps I can't check the settings 12 or 13 SOC% functionality as I don't have grid.

On 2023/03/28 at 4:25 AM, birdibird said:

Correct, is says DCD/DCE and is standard set to DCE. (setting 52 is Brightness of RGB LED)

Ah, as per the firmware, and not the manual. [ Edit: Oops, had the wrong manual. ]

Are you checking this on Solar Assistant or on the front panel/display?

It looks to me in the 12.21 display firmware, menu 92 is always enabled. Yet only MAX IIs would have it, and the display firmware will only work with Max E (Max 1) models.

On 2023/03/28 at 4:25 AM, birdibird said:

Strange that it is in this (display) firmware when the Axpert Max 1 doesn't have a 12V output....

Yes, strange indeed. There even appears to be a bug in the 12.21 display firmware such that if it's running on a VM III, it only skips menu 92 with the UP button, not the DOWN button.

On 2023/03/28 at 4:25 AM, birdibird said:

ps, what do you mean with the Max E?

This seems to be the official Voltronic name for the Max 1, when needed to distinguish it from the Max IIs. So I'm trying to get into the habit of using it instead of Max 1.

On 2023/03/28 at 4:25 AM, birdibird said:

Strange, I would expect they have a list of names against the model number (which is 44 for the MAX 1).

Yes, one Max II main firmware I checked reports model code 49 for the Max II. But the display firmware seems to muck it up, and sometimes reports 56 instead of 44, and I don't know what they report for a Max II (I don't seem to have a Max II display firmware, but MKS IV firmware running on a Max II reports model code 49). These model codes are so confusing! And not documented. Sigh. Maybe it's confusing the developers at Solar Assistant too.

Edited March 29, 20233 yr by Coulomb

Quote

Ah, as per the firmware, and not the manual.

Are you checking this on Solar Assistant or on the front panel/display?

It looks to me in the 12.21 display firmware, menu 92 is always enabled. Yet only MAX IIs would have it, and the display firmware will only work with Max E (Max 1) models.

What do you mean per firmware and not manual? 52 is written in the manual, 92 not.

I saw the setting 92 on the panel/display

Today I was at a client who has 2 MAX's with display version 12.13 and there setting 92 was also present!

 

Quote

Yes, strange indeed. There even appears to be a bug in the 12.21 display firmware such that if it's running on a VM III, it only skips menu 92 with the UP button, not the DOWN button.

The 12.xx display versions are for the MAX as far as I know (?). The newest VM III display version I have is 02.81 and I have never seen 92 there. Or are you talking about the ones with a new chipset?

Quote

Yes, one Max II main firmware I checked reports model code 49 for the Max II. But the display firmware seems to muck it up, and sometimes reports 56 instead of 44, and I don't know what they report for a Max II (I don't seem to have a Max II display firmware, but MKS IV firmware running on a Max II reports model code 49). These model codes are so confusing! And not documented. Sigh. Maybe it's confusing the developers at Solar Assistant too.

 

Wow, a MKS IV firmware running on a MAX II?

 

 

 

Edited March 28, 20233 yr by birdibird

4 hours ago, birdibird said:

What do you mean per firmware and not manual? 52 is written in the manual, 92 not.

Oops, my bad. I was looking in the wrong manual.

4 hours ago, birdibird said:

The 12.xx display versions are for the MAX as far as I know (?).

4 hours ago, birdibird said:

Wow, a MKS IV firmware running on a MAX II?

The display firmwares all seem to try to cater for at least two different models, like the King and VM III. 12.21 seems to be Max E and VM III.

 

On 2023/03/23 at 4:28 PM, Coulomb said:

Only use this patched firmware on Axpert Max 7.2 kW models with the '2809 processor

1.) Hi @Coulomb, how do I determine if my inverter has the 2809 processor? My inverter is currently running on 90.28. Can I then assume the patched firmware will be compatible with my inverter?

2.) My display firmware is 12.13. Should I flash it with 12.21? 

 

Edited April 1, 20233 yr by Don

1 hour ago, Don said:

how do I determine if my inverter has the 2809 processor? My inverter is currently running on 90.28.

The best way is to check my What Axpert Firmware is That? page, using your present firmware version. In this case, it's '2809, same as for 90.19 which the firmware was patched from. So yes, this patched firmware is suitable for your model.

 

1 hour ago, Don said:

My display firmware is 12.13. Should I flash it with 12.21? 

12.21 seems to be the latest firmware in the 12.xx series, and should be suitable for your inverter as well. As for should you do so, if you're not noticing any issues with BMS communications with a Pylontech or other battery with BMS, then there is probably no need.

Thanks @Coulomb. I will flash my inverter with the patched software 🥶. Is the 12.21 firmware included, or should I first download it somewhere else?

@Coulomb, it went well up to about 60%, then stopped. Retry did not work. I now have 32 flashing on the display. Please help.

Note to self: In future, don't do firmware upgrade half an hour before dark and ensure laptop is fully charged. I am back on 90.28 running around with candles. All Led lamps are flat and need charging. Had to charge laptop at neighbour.

Edited April 1, 20233 yr by Don

10 hours ago, Don said:

I am back on 90.28

OK, so it's unbricked now? Try again in better conditions.

Flashing failed about another 5 times. At times the speed would go down to 1 block per second and would fail or just fail 3 - 5 minutes in. Restarted laptop and inverter and it finally flashed successfully. 

4 hours ago, Don said:

Flashing failed about another 5 times. At times the speed would go down to 1 block per second and would fail or just fail 3 - 5 minutes in.

Wow. It's usually nowhere near as arduous as that. It sounds like the optos in your display or inverter are very marginal.

Glad to hear that it worked in the end.

@Coulomb

A friend got a strange thing this night at 3.19 am with the patched 45.07 firmware:

There is a strange double peak of the panels visible and then at 3.50 am they got warning 71:

(If battery status is not allowed to discharge
after the communication between the inverter
and battery is successful, it will show code 71
to stop discharging battery.)

And lost their power.

They couldn't make it work anymore afterwards during the morning: every time they restarted the inverter it immediately jumped to 71.

Only after the sun came back on the panels the system works again.

Any ideas?

(batteries are 6 x Dyness B4850. Battery SoC was around 60%)

 

Edited April 28, 20233 yr by birdibird

2 hours ago, birdibird said:

There is a strange double peak of the panels visible

I don't see a scale on the graph. If it's just 50-100 W then it's likely nothing to worry about. Though as I type this, I realise it was because I used to have an external solar charger, and the monitoring software was calculating what the external charger must have been doing. That presumably doesn't apply here, and the solar charge power should come directly from a current sensor times battery voltage. So I'll admit that's weird.

2 hours ago, birdibird said:

and they got warning 71:

My guess is that the battery is out of balance, and despite the overall pack being at around 60% SoC, one or more cells was very low, so the BMS had to issue the command leading to warning 71.

Is the battery fairly new? New batteries often take a while to equalise after being in storage or shipping for a while. If so, it should settle after a week or two. Though 60% SoC is very high for that sort of problem.

Or perhaps an additional battery module was added recently? If the installer didn't take pains to get the SoC of the new and old modules to nearly the same SoC before paralleling, you can get this sort of dramatic unbalance.

Can you get information about individual cell voltages?

Finally, is it possible that the battery hasn't been at very high or very low SoC for some time? I believe that Dyness are LFP, which means that the BMS needs to see a high or low SoC reasonably frequently or its SoC estimation can drift badly. So it might not have been at 60% SoC, even though the BMS thought that it was.

Whatever it was, the inverter presumably did the right thing not allowing the battery to discharge much further. It's really annoying to be without power, but better than than ruin the battery.

It's possible that the inverter misinterpreted what the BMS was saying, I suppose. Either a hardware problem (e.g. noise getting into the RS-485 signals), or glitchy display/BMS firmware.

Is 45.07 correct? I don't seem to have a record of that being a patched firmware. 

2 hours ago, Coulomb said:

I don't see a scale on the graph. If it's just 50-100 W then it's likely nothing to worry about. Though as I type this, I realise it was because I used to have an external solar charger, and the monitoring software was calculating what the external charger must have been doing. That presumably doesn't apply here, and the solar charge power should come directly from a current sensor times battery voltage. So I'll admit that's weird.

Looking at more details at 3.19AM in Solar Assistant:

The highest PV power was 630W.

MPPT1-V 99V 1,45A 270W / MPPT2-V 129V 1,30A 300W

 

2 hours ago, Coulomb said:

My guess is that the battery is out of balance, and despite the overall pack being at around 60% SoC, one or more cells was very low, so the BMS had to issue the command leading to warning 71.

Is the battery fairly new? New batteries often take a while to equalise after being in storage or shipping for a while. If so, it should settle after a week or two. Though 60% SoC is very high for that sort of problem.

Or perhaps an additional battery module was added recently? If the installer didn't take pains to get the SoC of the new and old modules to nearly the same SoC before paralleling, you can get this sort of dramatic unbalance.

Can you get information about individual cell voltages?

Finally, is it possible that the battery hasn't been at very high or very low SoC for some time? I believe that Dyness are LFP, which means that the BMS needs to see a high or low SoC reasonably frequently or its SoC estimation can drift badly. So it might not have been at 60% SoC, even though the BMS thought that it was.

Whatever it was, the inverter presumably did the right thing not allowing the battery to discharge much further. It's really annoying to be without power, but better than than ruin the battery.

It's possible that the inverter misinterpreted what the BMS was saying, I suppose. Either a hardware problem (e.g. noise getting into the RS-485 signals), or glitchy display/BMS firmware.

Sorry, I was mistaken: I meant 45.11 (your 245.11) together with Display 12.21
The batteries were new and were installed together almost 2 years ago.
Dyness is indeed LFP, like Pylontech, and they use the same RS485 comm to the Axpert Max.
What I do notice, looking in the history of Solar Assistant, that the batteries are not being charged full all the time.
The last time that they hit 100% was on 14/4. Then you see in the 2 weeks after they are being charged up to almost every 2 days 1V less, resulting in the max SoC yesterday on 91%. The previous date they hit 100% was March 27, which was the day I installed the patched 45.11 and display 12.21.

Before that they were running on unpatched 45.07 and display 12.13 and the last date before March 27 that they had 100% charge was January 17.

Is this something Dyness is doing in their BMS?

And why then fault 71 now, while they have been charge 'full' the day before.


Update:
They say now that the 3rd battery is charging less. That this morning it was almost empty while the others were on 50%+ or 75%.
They also said that has been going on for months now, but only this is the first time #71 is given.
Also there appears in the night regularly (sometimes every 10 min) a peak of 1 or 1,5 kW. A fridge? A leaking tap -> pump starts automatically? They are looking into the cause of that.
So, there is an unbalance between the batteries. And the 3rd battery must have given the #71 signal as protection.

I see that at this moment the batteries are not charging further than 91% again. (If I set the Axpert to user, it does continue to charge.)

Do you think going back to patched Georgs patched firmware (without your patches) or even the normal 45.07 would make a difference?

And this might be a case to notify Dyness to ask them about the imbalance?

Edited April 28, 20233 yr by birdibird

On 2023/04/28 at 11:48 PM, birdibird said:

I see that at this moment the batteries are not charging further than 91% again.

On 2023/04/28 at 11:48 PM, birdibird said:

Is this something Dyness is doing in their BMS?

It may be that there is a fault with the third battery module, either a cell fault or BMS fault, and this may be causing the third module's BMS to report (truthfully or not yet to be determined) that one or more cells would be going over-voltage if the charge continued beyond ≈90% SoC. This would exacerbate the imbalance. They might find that the battery actually works better without that third module; it might be worth testing that idea. If I'm right, that module might be effectively dragging down the performance of the other modules.

There might be a fault in the external wiring that is causing the third module to be such low SoC. But I don't see how that would explain the ≈90% SoC charge limit.

On 2023/04/28 at 11:48 PM, birdibird said:

If I set the Axpert to user, it does continue to charge.

That's good to know, but be careful doing this for any length of time, as a cell or cells may be over-voltaging.

On 2023/04/28 at 11:48 PM, birdibird said:

Do you think going back to patched Georgs patched firmware (without your patches) or even the normal 45.07 would make a difference?

Not so far; it seems more likely to me that this is a battery module health or possibly a wiring issue.

2 hours ago, Coulomb said:

Not so far; it seems more likely to me that this is a battery module health or possibly a wiring issue.

A wiring issue in what way?

5 hours ago, birdibird said:

A wiring issue in what way?

Daisy chaining instead of diagonal take-off, high resistance crimp, high resistance lug contact, corroded connector on the battery, that sort of thing.

As I mentioned, this is the less likely scenario in my opinion, as it doesn't explain the low final SoC.

Edit: But worth e.g. checking voltage drops across cables, especially to the problematic third module.

Edited April 30, 20233 yr by Coulomb