Hello,

I would like to ask about the possibility of modifying / patching the firmware for my Axpert MAX / MAX II 8000 inverter.

My current firmware versions are:

U1: 72.03
U2: 112.15
U3: 00.00
Model name: MKS2-8000

What I am mainly looking for is a modification of several battery-related parameter ranges, because I am using a custom battery pack with a higher voltage range than the standard 48 V settings allow.

The first parameter I would like to change is the low DC cut-off voltage range. At the moment, the inverter allows this setting only from approximately:

42.0 V to 48.0 V

For my custom battery, I would need to be able to set this value to around:

52.0 V

and ideally up to:

54.0 V

The second part is the charging voltage range. Both bulk/absorb and float charging voltages are currently limited to approximately:

48.0 V to 62.0 V

For my battery, I would need to extend this range to at least:

66.0 V

and ideally up to:

68.0 V

Of course, I understand that the related protection thresholds would also need to be reviewed and adjusted accordingly. I am not looking to simply disable protections, but rather to move the relevant voltage limits consistently, if the hardware is actually capable of operating safely in that range.

I have inspected the PCB and, from what I could identify, I did not find any obvious component in the battery voltage measurement / control path that would be clearly underrated for these voltage levels. That makes me suspect that these limits may be mostly firmware-imposed, but I would like to verify this with people who know these Voltronic/Axpert firmware branches better.

My questions are:

1. Is this type of parameter range modification feasible in the U1/DSP firmware for this generation?

2. Is U1 72.03 / U2 112.15 a known branch, and is it related to the newer MKS2-8000?

3. Are the battery voltage setting limits stored as simple constants/tables in the DSP firmware, or are they tied more deeply into the control/protection logic?

4. Would it be possible to patch only the U1/DSP firmware and leave the U2 display firmware untouched?

5. Is there any known rollback package for the original U1 72.03 / U2 112.15 firmware combination?

6. Is anyone here able to help with such a patch, or point me to the correct firmware branch / tools / person to contact?

I understand that increasing these voltage limits may have hardware and safety implications, so I would like to approach this carefully and not flash anything without first confirming compatibility and having a rollback option.

Thank you for any guidance.

Update – successful battery voltage range patches and current DC BUS investigation

Hello,

I would like to add an update to my original post, as I have since made significant progress with the U1 firmware analysis and performed several real tests on the inverter.

The inverter is:

Model name: MKS2-8000
U1: originally 72.03
U2: 112.15
U3: 00.00
Firmware branch used for testing: U1 72.07
DSP: TI C2000 / C28066

The U1 firmware is stored as Intel HEX, using C28x word-based addressing.

Battery parameter range patches

I was able to identify several battery voltage limits in the U1 firmware. The voltage values are generally stored in tenths of a volt, for example:

48.0 V = 480 = 0x01E0
54.0 V = 540 = 0x021C
62.0 V = 620 = 0x026C
65.0 V = 650 = 0x028A
68.0 V = 680 = 0x02A8

Bulk and float charging voltages

The menu/configuration limits for:

Program 26 – Bulk / C.V. charging voltage
Program 27 – Float charging voltage

were found in the area around:

0x003E38D6
0x003E38E7

The original upper limit was:

62.0 V = 0x026C

I first changed this to:

68.0 V = 0x02A8

However, changing only the menu/configuration table was not sufficient. Additional shared validation constants had to be patched in several other places.

After changing the corresponding shared validation values, higher bulk and float voltages could successfully be written through RS232 and correctly read back from the inverter.

The currently preferred test variant reduces the maximum from 68.0 V to a more conservative:

65.0 V = 0x028A

Low DC cut-off voltage

The original range for:

Program 29 – Low DC cut-off voltage

was approximately:

42.0–48.0 V

The menu/configuration candidate was found around:

0x003E38F1

Changing only this value was not sufficient.

Several additional copies of the 48.0 V validation limit were found in other branches of the firmware. After changing these together from:

48.0 V = 0x01E0

to:

54.0 V = 0x021C

the inverter accepted low DC cut-off values above 48.0 V through RS232.

Therefore, this part of the patch was successful.

U1 versus U2/display behaviour

The U1/DSP firmware accepts and stores the extended values through RS232.

However, the U2/display firmware still appears to contain its own original validation rules and display mappings.

Examples:

• Bulk and float values above the original range can be written through RS232.

• Low DC cut-off above 48 V can be written through RS232.

• The front panel still restricts the original ranges.

• Program 13 can store values above 62 V through RS232, but the display may show FUL instead of the numerical value.

• RS232 readback still returns the actual stored numerical value.

This strongly suggests that the parameter handling is split between:

1. U1/DSP validation and runtime logic,

2. U2/display validation and user-interface representation.

Battery high-voltage protection candidates

I also identified several likely high DC battery protection thresholds.

The firmware contains values matching the manual specifications:

66.0 V high DC / overcharge threshold
64.0 V high DC recovery

Likely runtime candidates include:

0x003E1DA8 – 66.0 V
0x003E1DC8 – 66.0 V
0x003E2138 – 64.0 V

There are also matching profile/default values near:

0x003EFD35
0x003EFDC9

A test variant changed:

66.0 V → 68.0 V
64.0 V → 65.0 V

The purpose was not to disable protection, but to maintain a reasonable margin above the extended charging range.

Current DC BUS investigation

The next issue is the internal high-voltage DC BUS.

From inverter telemetry, the BUS voltage rises with battery voltage and then becomes clamped at exactly:

475 V

The measured relationship is very strong. During charging, the BUS rises gradually with battery voltage, but once it reaches 475 V, it remains at exactly that value for long periods.

This is not an occasional peak. It forms a completely flat plateau in the logged data.

The BUS therefore appears to be actively limited, regulated, or at least reported with a hard upper clamp at 475 V.

Direct 475 V constants

The firmware contains two repeated groups with values:

515.0 V = 0x141E
475.0 V = 0x128E
514.0 V = 0x1414
476.0 V = 0x1298

at approximately:

0x003E71D6
0x003E7255

Because the values looked like possible BUS thresholds with hysteresis, I created a test firmware changing:

475.0 V → 485.0 V
476.0 V → 486.0 V

in both repeated blocks.

However, this test had no observable effect.

The measured BUS still stopped at exactly 475 V.

Current interpretation

At this point, the 475 V BUS limit may be implemented as:

• a raw ADC threshold,

• a PI-controller output limit,

• a maximum PWM duty-cycle value,

• a fixed-point coefficient,

• an analog hardware limit,

• or a limit stored in another representation rather than directly as 4750.

It is also possible that 475 V represents a 5% safety margin below a nominal 500 V hardware limit:

500 V × 0.95 = 475 V

but I have not yet found direct evidence of this calculation in the firmware.

Questions

I would now especially appreciate help with the following:

1. Has anyone mapped the DC BUS regulation section of the 72.xx firmware for the MKS2-8000 / original Axpert MAX 8 kW?

2. Is the 475 V limit known to be:

   • a regulation target,

   • a reporting clamp,

   • an ADC threshold,

   • or a hardware limitation?

3. Do the repeated values around 4750 / 4760 / 5140 / 5150 have a known meaning?

4. Does anyone have:

   • a commented disassembly,

   • known function addresses,

   • a partial firmware map,

   • service documentation,

   • calibration documentation,

   • or schematics for the MKS2-8000 / Model 44 / U1 72.xx platform?

5. Has anyone compared the 72.03, 72.07, 72.08 and 72.75 firmware branches specifically in the DC BUS or MPPT regulation areas?

I can provide:

• the original 72.07 firmware,

• exact Intel HEX changes,

• all patched variants,

• measured BUS, battery voltage and PV power logs,

• screenshots of the 475 V plateau,

• and the complete patch notes.

Any information about the internal DC BUS regulation, ADC scaling, PWM limits or relevant firmware sections would be very helpful.

Thank you.

Sorry for the late reply.

On 2026/07/05 at 5:31 AM, Radek99 said:

Is this type of parameter range modification feasible in the U1/DSP firmware for this generation?

As you have seen, yes. But there are limits related to hardware, obviously.

On 2026/07/05 at 5:31 AM, Radek99 said:

Is U1 72.03 / U2 112.15 a known branch, and is it related to the newer MKS2-8000?

72.xx is a known Axpert Max E '28066 non-Twin firmware series. 72.03 is quite early, from 2022, so I would say not related to newer models.

On 2026/07/05 at 5:31 AM, Radek99 said:

Are the battery voltage setting limits stored as simple constants/tables in the DSP firmware, or are they tied more deeply into the control/protection logic?

They are all over the place, unfortunately.

On 2026/07/05 at 5:31 AM, Radek99 said:

Would it be possible to patch only the U1/DSP firmware and leave the U2 display firmware untouched?

A quick look at x12.15 indicates that it does not check the parameters to PBFT (Put Battery FloaT voltage) and PBCV (Put battery CV voltage) commands. So it may be possible to leave the U2 firmware untouched, though I suspect that you'll run into trouble somewhere.

On 2026/07/05 at 5:31 AM, Radek99 said:

Is there any known rollback package for the original U1 72.03 / U2 112.15 firmware combination?

Yes, I have 72.03, but you may as well go directly to 73.08, which is a more recent version of the same firmware.

I don't have 112.15 (I do have 12.15, which is functionally the same, but it won't work for technical reasons). The closest I have is 112.19, but you may as well go to a more recent version like 12.28. (12.xx with xx > about 20 will safely replace 112.xx; they dropped the leading 1 at that point).

On 2026/07/22 at 11:38 PM, Radek99 said:

Battery parameter range patches

I was able to identify several battery voltage limits in the U1 firmware. The voltage values are generally stored in tenths of a volt, for example:

48.0 V = 480 = 0x01E0
54.0 V = 540 = 0x021C
62.0 V = 620 = 0x026C
65.0 V = 650 = 0x028A
68.0 V = 680 = 0x02A8

Bulk and float charging voltages

The menu/configuration limits for:

Program 26 – Bulk / C.V. charging voltage
Program 27 – Float charging voltage

were found in the area around:

0x003E38D6
0x003E38E7

These constants are in a function that ensures that the values in EEPROM are within expected limits. If outside these limits, values are set to defaults. So this will have no effect most of the time, yet you will need to change these to expand the limits.

On 2026/07/22 at 11:38 PM, Radek99 said:

U1 versus U2/display behaviour

The U1/DSP firmware accepts and stores the extended values through RS232.

However, the U2/display firmware still appears to contain its own original validation rules and display mappings.

Examples:

• Bulk and float values above the original range can be written through RS232.

• Low DC cut-off above 48 V can be written through RS232.

• The front panel still restricts the original ranges.

• Program 13 can store values above 62 V through RS232, but the display may show FUL instead of the numerical value.

• RS232 readback still returns the actual stored numerical value.

This strongly suggests that the parameter handling is split between:

1. U1/DSP validation and runtime logic,

2. U2/display validation and user-interface representation.

Yes. The display firmware won't let you enter settings values that it considers to be beyond limits.

Displaying the values for setting 13 properly will require an out-of-flow patch, i.e. a jump to new code to process the extra values. I have done such things, but it's a lot easier with some Python code that a colleague and I developed some years ago.

It might be easier for you to use monitoring software to alter the settings; do you use such now? Will it allow other values?

It might be that you need to change the response to certain commands; from memory, that's how WatchPower works. A command like QMCHGCR returns the valid range of values for the maximum charge current setting, and WatchPower makes sure that the parameter to a command to set the present maximum charge current is one of the allowed values. See a protocol manual for details.

Getting late here; more later.

On 2026/07/25 at 3:08 PM, Coulomb said:

It might be easier for you to use monitoring software to alter the settings; do you use such now? Will it allow other values?

Regarding your question: I don't use WatchPower. My inverter is integrated into Home Assistant using a heavily modified version of the ESPHome/Pipsolar component. I kept only the basic communication framework and rewrote a large part of it to support additional protocol commands and to remove the original software limits so I can freely send the values required for my experiments.

At the moment, the battery voltage range itself is no longer my primary goal. The patches already allow me to configure the values I need via RS232, and the inverter stores and uses them correctly.

I also fully understand that there are hardware limitations. If I eventually decide to operate at higher voltages, I expect that some hardware modifications may also be required (for example higher voltage capacitors or other components if necessary). I definitely do not intend to simply remove protection limits without understanding why they are there.

My main objective now is the internal DC BUS.

From long-term measurements, it consistently saturates at exactly 475 V and limits further battery voltage increase arround 64,2V. I tried patching the obvious 4750/4760 constants, but there was absolutely no change, so they clearly are not the actual regulation target.

What I would really like to understand is how the DC BUS regulation is implemented in this firmware and where the real limiting mechanism is located. Even increasing the BUS limit modestly, for example from 475 V to around 490 V, would already be sufficient for my application.

I'm also trying to understand the firmware itself rather than just changing constants by trial and error. Your explanation about the EEPROM validation already helped me significantly, and I'm hoping to gradually understand the purpose of the other areas we have identified as well.

On 2026/07/25 at 2:25 PM, Coulomb said:

Yes, I have 72.03, but you may as well go directly to 73.08, which is a more recent version of the same firmware.

I don't have 112.15 (I do have 12.15, which is functionally the same, but it won't work for technical reasons). The closest I have is 112.19, but you may as well go to a more recent version like 12.28. (12.xx with xx > about 20 will safely replace 112.xx; they dropped the leading 1 at that point).

Would you be willing to share the changelog for recomanded firmware version 73.08 and 12.28 (u1 and u2)?

Thanks again for taking the time to help.

23 hours ago, Radek99 said:

Would you be willing to share the changelog for recomanded firmware version 73.08 and 12.28 (u1 and u2)?

There is no changelog that I'm aware of.

Diffing (finding the differences between) firmware versions is very time consuming, and often all I can tell is that 12 extra instructions were inserted at this point, involving these memory locations. But what are those memory locations used for? I can use cross referencing to find where they are used, but unless I happen to understand those locations well, I usually don't know what the practical effect, much less intention, of any particular change is.

I suggest 73.08 and 12.28 as they are available, reasonably recent, and I'm not aware of any particular problems with them.

23 hours ago, Radek99 said:

What I would really like to understand is how the DC BUS regulation is implemented in this firmware and where the real limiting mechanism is located.

This is unfortunately one of the more complex aspects of the inverter firmware. The bus voltage is at the mercy of the PV voltage, in the sense that the solar charging stage, being a boost converter, cannot allow the bus voltage to be lower than the PV voltage. Similarly, the turns ratio of the transformer imposes another minimum on the bus voltage. As an example, if the battery voltage is 64.0V and the turns ratio is 7.3:1, then the bus voltage can't be lower than 64.0 x 7.3 = 467 V. Firmware version 73.07 uses a turns ratio of 7.3:1. There is a buck stage between the bus and the transformed battery voltage, but when power flow is away from the battery (discharging the battery), the buck stage can't overcome that limit. Beyond these two limits, the bus voltage is pushed around by PV, which is intermittent in nature, and the DC <-> AC converter, which is affected by the loads (which can suddenly change), and even the utility voltage, which can change, hopefully not as wildly. So the firmware has to balance all these needs.

I spent some time years ago trying to understand the King's firmware and how it controls PV power, bus voltage, etc. The Kings are slightly more complex in that they have an extra AC->DC converter (rectifier) that the DSP controls as well. I was not able to make much sense of it. Of course, I don't have the luxury of source code with comments. So MAX firmware would be easier than that, but still is extremely complex.

I have a suspicion that the firmware aims for a more modest voltage target of 475 V rather than e.g. the 490 V figure that you mention, in part because their control algorithms are not great. In particular, I see clues that they are not addressing integral windup, which means that when a control loop is saturated at a limit for some time, the integral term increases without limit, meaning that overshoots and undershoots are unnecessarily common. So far I haven't found one to prove this suspicion. But by allowing a high upper battery voltage and therefore a high bus voltage, you may find that the poor control leads to excessive bus voltage, leading to premature capacitor failure and possibly early switching device failure.

Is the 475 V limit known to be:

• a regulation target,

• a reporting clamp,

• an ADC threshold,

• or a hardware limitation?

Alas, I don't think that there is a 475V target voltage (see below).

On 2026/07/22 at 11:38 PM, Radek99 said:

Do the repeated values around 4750 / 4760 / 5140 / 5150 have a known meaning?

Yes. But these are frequency limits, for determining when the utility frequency is out of spec, or coming back into spec (47.50 Hz, 47.60 Hz, 51.40 Hz, 51.50 Hz). This is one of the problems with searching for constants that appear to be significant. Be aware that the DSP occasionally loads constants with a binary shift, e.g. sub ACC,#563 << #12 (subtracting the constant 563 x 2¹² = 2,306,048).

So the plateau at 475 V may be due to the battery or PV voltage at the time. I suspect that the firmware targets the lowest DC bus voltage that fulfils various requirements, such as generating an unclipped sine wave (not always possible), charging the battery at a certain voltage, and so on. It could be that these are the only two constraints.