stakoz

Okay, so due to high demand 😀 I'm posting it here. Hopefully it doesn't cause more harm than good. As always, make sure your battery (BMS) doesn't disconnect while charging - that seems to be the main risk here. Also I'd recommend to use at least two or three battery packs in parallel. Charging current over 100A would be a lot for a single 280Ah battery.
dsp_278.07_patched_200V_derate_460V.zip

I usually fix the premature float problem, as it's a single byte fix (after you've found the right place to patch). But when I patch a firmware that has the "presumed good" MPPT logic, it's a combination of not having recognised the presumed good logic as such, and also reducing a current threshold that seems to make patched firmware perform a bit better than the presumed good logic. This threshold is the PV current beyond which the firmware no longer tries to drive the PV voltage ever lower, which is presumably needed to get things started, especially considering the presence of a fixed power drain needed to power the control logic from available PV power.
Other patches in the past have been to add features like KettleKomp™ (load/charge compensation), Dynamic Charge Control so users can send commands to alter the maximum charge rate on the fly, enhance data displays, even "font" improvements, but these are a lot of work, and I don't have access to the more recent models to test them out. So the MPPT patches that I do are all "blind", in the sense that I mimic what user Georg594 did (he did own an Axpert Max0 and adapted those changes to other models.
Heh. A handful of people have expressed this wish to learn patching, but few have been able. It seems to take a certain kind of personality (madness?) to pore over countless pages of assembly language instructions, figuring out the meaning of thousands of variables (global and stack temporaries), and learning the peculiarities of a Digital Signals Processor whose instruction set was never designed for humans to understand (save a very few engineers that write the very low level code).
To patch a firmware, first you have to understand the part of the firmware that is relevant, at least to a reasonable degree. I can't pretend to understand all the ins and outs of even the MPPT logic, for example. But you need to know it pretty well, and for that you need a good reverse engineering tool, and have the required mindset to be able to use it effectively. I use the Ida Pro disassembler, which is expensive, but few other tools come close to it. I started poking at early firmwares, and am able to transfer the ideas more or less well to later firmwares.
Then there is the process of patching itself. A colleague of mine (Weber on the forums) and I started by painfully editing the hex files by hand, and maintaining a text file recording what we'd done, with before and after lines of hex, so we could debug it if necessary and perhaps adapt one patch to another firmware or another patch requirement. We performed our first few "fully patched" firmwares that way, with dozens of individual patches and occasional new pieces of assembly language code, and occasionally used a JTAG interface to single step through modified code when a particular condition was detected. This has to be done carefully, as single stepping a DSP can lead to inductors saturating and other unpleasant outcomes. The only "automation" we had then was a spreadsheet that would calculate the checksum for a line of hex code. Every hex file has a checksum at the end of every line to make sure that communication errors don't end up corrupting a flash image during the reflash process. Oh, and a set of macros to allow for more or less structured programming when using assembly language.
Towards the end of that collaboration, we ended up developing a set of Python scripts to make life much easier. These take care of many of the details, like automatically calculating checksums, merging hex files, and the like. So now for most patches, I just modify an assembly language source file that is typically one or two pages in length, including about 50% comments, and "compile" (it's only assembling) them with a product from Texas Instruments called Code Composer Studio. This latter is free under certain conditions like assembly language only projects, and has the ability to add "steps" to the "compile" which call the python scripts. The result is a new hex file, which I can disassemble with Ida Pro to ensure that the changes are made as intended. This last step is made easier by Ida's ability to save most of the annotations made when reverse engineering to a large script file, which can then be loaded into the disassembly of the new hex file, so it's possible to quickly jump to the parts of the code where the changes should be. After that, it's a matter of zipping up the appropriate files and uploading them, usually to this forum but sometimes to the Australian Electric Vehicle Association where I'm also active.
If I haven't turned you off the idea already, and you know what the result of xoring (performing an exclusive OR function) on the same value is, know what the stack is an how it's used, and have at least a passing knowledge of things like timers and Pulse Width Modulation modules are, then PM me and we can chat further. I don't make all my secrets available to all so as not to enable clone makers to profit from Voltronic's intellectual property.

I second the above issue, I have a Tommatech 11kw non-twin (clone of Axpert Max with removable display) and whatever I do I cannot make my batteries charge above 100amps. I have 6x Dyness A48100 (approx 28.8 kwh) and a Braun battery (modified from 16s to 15s with JK BMS, approx 13.4 kwh) in parallel, both MultiSibControl with the Dyness batteries input and Solar Assistat with a Victron Shunt (for all Dynesss and Braun batteries) talking to the inverter. I have tried switching off one or the other in various combinations and sequence but the batteries do not charge above 100amps, though their BMS settings are for 150A. I have also tried changing in MultiSibControl the "PV power balance strategy" settings between "Charge only" and "Loads + Charge" which sends a PSB0 or PSB1 command to the inverter (and this changes the setting in Solar Assistant for "PV power Balance" between "Limit PV input to max charge current" and "Allow higher PV than max charge current" but no change, batteries still charge with max 100amps, even if I disconnect some of them and try using only MultiSibControl or Solar Assistant.
Actually for Robert1968 above, the max charge setting of 150A includes BOTH from PV and from Utility, however even if my Utility charges is set to 2A or 10A, the Batteries are charged with max 100A from Solar
@Coloumb will appreciate any insight you might provide on the above inverter behaviour/logic, I am using your 273.63 firmware.
Thank you in advance

I've been investigating this issue. It seems that there are several versions of "data layout" for  the various firmwares. I've been concentrating on Max firmwares for now, as these seem to have more issues with EEPROM layout (e.g. losing serial number, bad battery voltage calibration, etc).
It looks like the thing that varies the most, yet is fairly easy to find in a new firmware, is the size of the configuration partition. Here are some numbers, in firmware version, partition size pairs:
90.06, 148
72.72, 152
72.74, 148
73.76, 148  Extended partitions
73.78, 148
11.05, 154
11.06, 154
As you can see, 72.72 and  72.74 have different sizes! It looks like the odd one out is 72.74. I somehow got the impression that  73.76 was different to other 73.xx, but the partition sizes and starting addresses are the same. 73.76 does have extra checking, as well as several new areas not used by other firmwares. Maybe it means that updating from 73.76 to 73.78 is OK, but not the other way (as the extended data will not be present).
So at this stage, don't attempt to update from 72.72 to other 72.xx, or other 72.xx to 72.72.
I guess the next step is to figure out what 73.76 is doing with the extra partitions.
 

There is a huge thread on it.
Summary: Most Axpert Max firmwares (except for a few "experimental" ones), and all VM III and VM IV firmwares, have a bug where the PV voltage can get stuck at a low value, usually close to the bottom of the MPPT range (90 V or 60 V), particularly in low light conditions (early morning, late afternoon, cloud, and rain). In the morning, the voltage will eventually shoot up from say 92 V to say 276 V, tripling the PV power. All that time from dawn through to this voltage rise, you've been missing out on up to 2/3 of available PV power. In some cases, on cloudy days, you can miss out on 75% of available PV power. But on a sunny day, the loss might be negligible, depending on many factors.
Georg594 pioneered a patched firmware that largely fixed this issue, with the downside that you end up with a fixed minimum PV voltage. So someone with 4S panels needed a different patched firmware than someone with 8S or 10S panels. I extended the patched firmware to other models. It looks like Voltronic have fixed the problem in a way that works for all panel configurations. But for whatever reason, they don't port the good code to "mainstream" firmwares. I'm able to recognise the presumed good firmwares, and list them here.

This is patched firmware versions 273.78, 573.78, and 173.78, based on factory firmware version 73.78 for the Axpert Max E 11 kW non-twin running the TMS320F28066 DSP chip. Use only if you know that your processor is a '28066, e.g. if your main firmware from the factory was version 73.xx. If you get this wrong, the upload will refuse to work, but it should not brick your inverter (just restart). The factory hex file is dated 2024-Jan-09.
The patches implement Georg's patches for the 90.06 firmware: current threshold is reduced from 0.50 A to 0.05 A, the minimum MPPT voltage is changed as below, a pair of control constants is changed, and the boost functions are modified. In addition, the premature float bug is fixed, and the version number reported by monitoring software should be the full 5 digits. The LC Display will continue to show 73.78 (U1 73 78). See the post above for how I chose one of the control constants; I can't exactly copy Georg's patches.
Version 273.78 implements a minimum MPPT voltage of 200 V.
Version 573.78 implements a minimum MPPT voltage of 150 V.
Version 173.78 implements a minimum MPPT voltage of 120 V. (100 V is too close to the default 90 V).
As always, the original factory firmware is provided, as dsp_73.78_original.inv. When you run the Arena reflash tool, navigate to the folder with the unzipped files, and choose one of the four .inv files (these are hex files). Choose a voltage such that your panels will almost never be below that voltage, even in rainy weather.
Use at your own risk. Firmware update instructions are here.
dsp x73.78_patched.zip

So I've decided to use 73.78, even though it seems to have some debugging code left in, and the new commands actually won't be useful, except for those trying out the factory firmware. If I make it so that the patched firmware listens to the new command, then users will have to use the command to get a new value for the minimum MPPT  value. I'd rather not mandate that, and I suspect that later versions of the firmware won't have these new commands (i.e. my suspicion is that the new commands are for debugging only).
Having started patching that version, I realise I have to decide what current forward constant to use for the various measured PV currents. It turns out that 73.63 and 73.78 both use a forward current constant, when the measured PV current is under 2.00A, of 30, which is quite high: 73.06 uses 13, and @Georg594's patch uses a value of 4 up to 0.35A, and 21 for 0.36 to 2.99 A. I have the option of using a different value for between 0.35 A and 2.99 A. I've settled on 13, the same value as 73.06 would use for < 2.00A, and it's about the middle between 4 and 21. The forward current constant seems to control how fast the MPPT ramps towards higher current, although the way that panels work, this is also the way towards low panel voltage! It seems to me that smooth increases of this constant would be better, and the very low value of 4 that Georg settled on is likely a major factor in his patch's success. In the region from 2.00 to 2.99 A, my proposed value (13) is lower than Georg's (it would be 21 in this region). It will be interesting to see if it works better than other patches.
Rain if forecast for tomorrow,  so I'll hopefully finish the patch then, if air conditioning concerns don't override.

This turns out to be quite tricky, as 73.78 seems to be compiled with a different compiler, or at least with different optimisation settings. 73.78 seems to have faster, more compact code, except for 16-bit compares that are often extended to 32 bit registers and a 32-bit comparison is made. As a result, most 73.78 functions are a little shorter, but some are a bit longer. This makes finding subtle differences nearly impossible.
On top of that, most command handlers have an extra variable set to 20, and this doesn't happen in any of the other firmwares. Weirdly, this change appears to delay updating of the big array of data about all paralleled machines if you are continually sending commands.
However, 73.78 has two additional commands, that query and set the MPPT minimum voltage! It would  therefore be possible to have one firmware image, and users could experiment with various minimum MPPT minimum voltages by sending a command, and not having  to reflash another firmware version!
Hence, thus far, 73.78 appears to be the best firmware to patch for the Axpert Max E 11 kW non-twin models for '28066 processor.
For the curious, the command to change the MPPT minimum voltage is PMPL (Put Maximum Power Low panel voltage), followed by a 3 digit whole number of volts. For example, to set it it 95V, send PMPL095 (leading zero required); for 150 V, PMPL150. The usual two CRC characters and the carriage return should follow. Values below 90 and above 250 will be rejected with a NAK response. QMPL should return for example (095 if the limit is set to 95 V. I have no idea whether this command will be continued, or if it will appear in all new firmwares. It may be just a temporary change to facilitate their testing in the lab.

Neither did I. In fact, I could not find an original zip/7z/rar file for this firmware. I may have obtained it via some back channel, so I created a zip file with just three files in it below.
This is factory firmware version 73.06 for the Axpert Max E 11 kW non-twin with '28066 processor. Do not use for any other model; use at your own risk. The hex (.inv) file is dated 2023/02/17, so this is slighty more recent than version 73.63 (2023/01/11).
MAX11K_DSP_73.06_28066 Non-twin.zip
Let me know if there are any problems. Upload instructions.
 

Ok, so here is a patched firmware that adds the missing pair of compares.
@Solar shed
This is patched firmware version 391.70 for the Axpert Max E 11 kW non-twin with the '28066 DSP. It is based on factory firmware version 91.70. It should be the same as 291.70 except that it has the missing pair of compares, as mentioned in the preceding few posts. Do not use with any other model of inverter.
Use at your own risk. Please report results, good or bad, and even if you could not get it work etc.
Firmware upload instructions for models with the removable display.
Edit 15/Jan/2024: I have detected an error in this patch, so it is deleted.
There have been 20 downloads of this file. If you are one of them, please delete it! If you are running it on an inverter, please revert to factory firmware version 91.70, or patched firmware version 291.70. One user has had an inverter with 391.70 blow up; it's not clear if it was caused by this firmware, but it might be.
I have a fixed version of 391.70: patched firmware version 491.70. My humblest apologies for the hassle. I generate so many patches that a problem like this is unfortunately likely to happen sooner or later.
 

Yes.
This is patched firmware version 373.63, based on factory firmware version 73.63 for the Axpert Max E 11 kW non-twin and the '28066 DSP. Do not use with any other model of inverter, or if you have the '2809 DSP chip; see Chipset Chatter. This is the same as patched firmware version 273.63, except that the minimum MPPT voltage is pegged at 200 V. Note that some users might find that 273.63 works better for them, especially if they have the bare minimum of panels.
Use at your own risk.
Firmware upload instructions.
 
dsp_373.63_patched_05_200V.zip

Thank you @Coulomb in case i upgrade to the new 73.63 "as is" above but it does not work for the mppt sticking at 90v in gloomy days and/or the battery premature float bugs - would it be possible to downgrade then back to the patched (2)91.70, or should you then need to patch again the new 73.63 to be re-applied in the inverter?
Many thanks again .

There are scattered changes. it was a bit of a pain to compare them. 73.63 does seem to be an evolution from 91.70.
The major change seems to be with the MPPT control code. 73.63 has some logic I don't recall seeing before, so it's possible that they've finally nailed the stuck at 90V issue. Though it seems to be to be a mishmash of ideas that they have already tried, so I'm not super confident.
As for whether it's worth patching, I think it's worth trying as is first. If it still doesn't solve the stuck at 90 V problem, I can reduce the current threshold as I have for earlier patches.
Huh. One of the changes is to avoid emitting a warning for EEPROM errors in 91.70, in the case of another warning to do with the I²C hardware. That avoidance code is missing in 73.63. But there are also initialisations of the I²C hardware missing; perhaps 73.63 uses software emulation of I²C (something that they seem to have to do with the GigaDevice display chips), and maybe this actually works more reliably than the hardware in the DSP. Hard to imagine, but possible I suppose. At least, there IS a difference with respect to EEPROM warnings, so that alone may make it worth using 73.63, patched or not.

@aamilev,
You've been more than generous and more than patient, sorry for the wait. Things are still frantic here, but I made time today for this patch. It should also be useful for @stakoz and presumably others. I wondered what patches to implement, perhaps even the changes found in 72.66. I decided the latter was too new and untested (by forum readers at least), so I decide to keep it simple and start with Georg's original 200 V patches. So this patched firmware has no resets or any attempt at shade management. Shade management is a great idea if you need it, but the present implementation seems to be very panel configuration specific.
This is patched firmware version 269.61, based on factory firmware version 69.61 for the Axpert Max 1 7.2 kW non-twin with the '28066 DSP chip. It fixes the premature float bug, hopefully there isn't a "never float" bug lurking. If there is, it's easily reversed. It also implements all @Georg594's original 200 V minimum MPPT patches (first applied to factory firmware 90.06). On the display, the main U1 firmware version should show as 69.61, but monitoring software and apps should show it as 269.61. Do not use with other models, even other Axpert Maxs, or even an Axpert Max II 7.2 kW. Do not use with a '2809 DSP chip; see the first post of this thread for details.
Use at your own risk.
dsp 269.61 Axpert Max 1 7.2kW '28066 patched.zip

Thank you @Coulomb glad to have been of help. 
I know this thread is not on this but any chance you could please patch the Max1 7.2kW with the new processor for the float and mppt voltage freeze? 
Your work and support is greatly appreciated and I will repeat my previous donation and sure there will be others who will benefit from this.
Many thanks in advance for your kind consideration.

I knew that in the past, i could charge from solar with 120A