Coulomb

I'm a little surprised by that incompatibility, though it does reinforce the "same major firmware number (series) is best" adage. But VM III firmwares are so chaotic that it's often hard to follow that logic. I have version 91.19 but also a later (2021) 91.25 that has similar ratings and is also for the older VM III models. Neither of these seems to be published, so I'll add them below. Edit: Removed confusion about 91.17.

Ah. Be aware that there are subtle differences between control boards. You can't swap VM with non-VM control cards, as the VMs have only half the flash memory capacity, but the connection to the main board is totally different anyway. So hopefully you are starting with a VM control board. VM control boards often have different resistors to create different voltages at start-up on some ADC pins. The resultant voltage on these pins indicate to the firmware what the model variant of the hardware is, e.g. 24 V versus 48 V models, and various power limits. I don't know where these resistors are, or even what pins that they connect to. Logically, these resistors should be on the main board, but they may not have enough spare pins to do this. [ Edit: They DO put the resistors on the main board, as per the post below. ]

My guess is that they replaced the control board with one that has different firmware. Please report the main (U1) firmware versions for both inverters. Your monitoring software (e.g. Solar Assistant, but there are many others) may be able to provide this, or you could use the up or down buttons near the display until you get a display starting with "U1". Report the next four digits. Edit: Other possibilities include that the paralleling board was not replaced, or one of its cables. Or that you haven't connected the paralleling cables properly, or a pin became damaged with the un- or re-plugging, etc. Also check setting 16, output mode. It should be PAR for paralleling. Do you see HS and SL on the two inverters? These indicate MaSter and SLave.

This is a clone or workalike, so it may not be talking Voltronic protocol, as expected by Solar Assistant, and as provided by nearly all clones as well. If you're curious, comms is over an RS-232 serial port (usually via an RJ-45 connector, this is NOT ethernet or standard RS-232 pinout) at 2400 BPS. Download one of the Axpert communications protocol PDFs (NOTE: Infini protocol is completely different) from the File area of this forum for details.

78.10 from June 2025 is the latest available firmware in the 78.xx series that I'm aware of.

I think you mean fault code 71. If it's really warning (not fault) code 61, then that's a problem with communications with the battery's BMS. I would not think that it's corrupted firmware. The fault code is raised when a particular CAN bus message arrives with the wrong "paralleling constant" (my term). This should happen in the first minute after start-up, so I'd say that the firmwares are fine. If flash memory is not reading correctly, considering that the DSP is executing millions of instructions per second, it would probably crash anywhere, not consistently just the part that fetches the instruction with the paralleling constant. It may not be the actual data stream that is corrupted; it may be one of the several "control" lines that are wire-ORd together. If one of those is asserting when the other machines are not expecting it, it could conceivably trigger an unrelated fault code. Far more likely, something is going silly with the paralleling boards. It may be that the opto couplers are losing speed and/or current transfer ratio (CTR) as they age, or lightning (partially) damaged a transistor. I had a transistor completely fail due to nearby lightning. More distant lightning might induce a sort of "non-fatal wounding" causing an intermittent fault like you are seeing. Of course, electrolytic capacitors in the power supply are always popular candidates for weird problems. If you have spares, try swapping paralleling boards first. Or just replace the power supply capacitors as it's a good idea after 5 years of operation anyway.

The "U1 74 11" does suggest Voltronic firmware, but no Voltronic model that I'm aware of has that display. So my guess is that this is a "workalike", basically copying the Voltronic hardware, but patching or rewriting the firmware so as to drive a different display and possibly attempt to avoid copyright infringement. I'd further guess that they also modified the command that initiates firmware updates, so that Voltronic firmware update files won't work on these models. So the only way to get the firmware update files would be from this workalike manufacturer, or one of their resellers. It may be that like Voltronic in the very early days, they have not bothered to set a security password for reading the firmware. In that case, you could use a JTAG interface to read firmware from one inverter and write it to others. But that's pretty unlikely. Another possibility is that this is a new Voltronic model that I'm not aware of; I have been distracted this year with family matters.

I assume that this must be a VM III 4 kW with flag set to report 200 W of extra power and VA in the ratings. But I have no 37.xx firmware at all, and no 74.xx in the VM III new folder. The other 74.xx firmwares that I have are for totally unrelated models. If you have spare inverters to experiment on, you might try other VM III Twin firmwares that support 4 kW, e.g. 71.03 from March 2024, or 68.13 that does support 4.2 kW (Sep 2025).

81.xx is for some Max II 8kW models. 54.xx is for other Max II 8kW models. 281.05 is a patched version of 81.05, so it's suitable for all Max II 8kW models that are running 81.xx. The "x" here stand for any digit 0-9, e.g. 81.08 or 81.61. No, these are all "main" or "DSP" firmwares. On the front panel, the display version numbers are displayed at the bottom with U2 before the 4 digits of the display firmware, e.g. "U2 22 12“ indicates display firmware version 22.12. There are two (occasionally three) firmwares in these inverters. The "MPPT stuck at 90V" issue concerns the main firmware, which is displayed on the front display (with appropriate presses of up or down buttons) with "U1" in front of the main firmware version number, e.g. "U1 81 05" indicating either factory firmware version 81.05, OR patched firmware version 281.05. You can only see the full 281.05 version number from monitoring software, like Solar Assistant. So if you can find and report your main (U1) firmware version, I can help more.

That's unusual behaviour. My guess is a weak power supply. An OG 7.2 is probably getting old by now, so my guess is that the power supply capacitors have dried out. Replacing the usual suspects may fix it. If you are not handy with electronics and can't find someone who is, try to get a board level repair (tens of dollars plus labour), otherwise they will likely replace the main board at nearly the price of a new inverter.

My notes say that 81.xx are for the Axpert Max II, as are 54.xx, but for different DSP chips. These can't be mixed. I haven't seen where you say what your existing main (U1) firmware is. My apologies if I missed it.

Can you check if inverter 3 is missing a capacitor across the PV inputs? MKS IVs are known to be sensitive to this, usually affecting the display, but it might conceivably trigger other issues. There is a small file in the downloads section with slightly more detail. Be aware of the safety issues if you take this on yourself. Big high voltage capacitors can cause nasty shocks and/or damage underwear. Edit: Since fault code 72 is to do with current sharing, it may be to do with the length and/or resistance of the AC-out cables. If these are significantly different (you mention a 1 metre difference), it could be worth lengthening the cables from inverter 1 to the joining point, so that the lengths are more even. It's also possible that the current sense circuit for inverter 3 (or others) has a bad capacitor that would normally smooth out noise, for example from the PV input cables.

It means comms error to the BMS of the battery. Near the end of the manual, in a different section to most of the other fault and warning codes. Long ago it was the case that Axperts only connect to Pylontechs via RS-485, despite the Pylontechs being able to talk both, and the Axperts are able to talk CAN bus to other battery types. I believe that this is still the case. Do you have a cable from the inverter to the Pylontech BMS? Is the battery type set to PYL?

This page may help, though it is years old now: Use the bottom (PIP-5048MK) diagram.

Does the displayed battery voltage, when the inverter is not charging and has light loads, agree withing 0.1 or perhaps 0.2 V of a trusted multimeter's reading at the battery terminals? It may be that the inverter firmware is reading the battery voltage as higher than it actually is, and so thinks that the battery is already full when it isn't. Calibrating the battery voltage readings may help if that is the case.

Can't you send it back as unfit for purpose? Unfortunately, the problem is likely to be shorted MOSFETs and blown gate driver parts, which is a pretty significant repair effort and cost. It looks like these might be Axpert MAX 11 kW clones, though with custom firmware to drive custom displays. If so, this page might allow you to get started on the repair, or at least find out if it is basically the Axpert circuit: https://forums.aeva.asn.au/viewtopic.php?t=6007 Look in the schematic section for BritishRacingGreen's Axpert schematics. I think I need a new word for "clone", where the copy is of most of the intellectual property of the original, but the appearance and outward operation is somewhat different (to try to avoid prosecution, I would guess). So perhaps "workalike", but it doesn't seem to capture the process.

If by "cycle" you mean restart the MPPT logic, the standard MPPT patches achieve roughly that. Have you tried patched firmware version 281.05? It depends on so many factors. But from various posts with many MPPT performance graphs, it seems that on the worst days, you can lose something like 80% of available power for something like half the day. That's rare of course. Most days you probably lose 5-10%, and on the best days basically nothing at all.

There is Patched firmware version 281.05 but it's a bit old. I should update it for 81.08 and several minimum MPPT voltages. Life has been busy this year. But indeed there are no 54.xx for the '2809 DSP. I do have 54.06 now, so I could patch that if there is interest.

Those capacitors seem to work hard, and often seem to fail with weird effects. I don't believe that they are 100 nF as shown on the schematic, I think that they are closer to 10μF (at least for 5kVA 48V models). So it might be worth replacing those with decent quality 50V parts, if you can find them in a suitable size. The other possibility is more gate driver parts, like the bipolar transistors.

It can't be that; as far as I know iGrid implies Infini (on-grid) and iSolar implies Axpert (off-grid). So all Infini firmwares would be G not S, but that doesn't seem to be the case.

Just use your computer's file explorer. On Windows, you single click on the file name below a file's icon and the name will highlight, and you can edit it. Just click away from the name to confirm the change. As to what name to change it to, use the same file extension (part after the final period/dot) as the infini file names have. Actually, I have both of these in my collection, and they are both called "dsp.hex" (without the quotes). So there is actually no need to rename. However, that means that the old reflash tool will be looking for dsp.hex in the same folder (directory) as the reflash tool itself (the .exe file). So make a copy of an Axpert reflash folder, rename the dsp.hex to something like dsp_axpert.hex (or simply delete it), and copy the dsp.hex from a Infini reflash folder to that new folder. Go to that new folder, and run the reflash tool from there. That should cause the Axpert reflash tool to read the infini dsp.hex file. Assuming that works, the control board is now running Infini firmware, so any later firmware updates should be done with an Infini reflash tool. Yes, use monitoring software to perform a "factory reset" of most of the parameters. Do let us know how it goes. I suspect that you may run into problems with calibration of measurements, and possibly with serial numbers, and other things related to the EEPROM contents.

Are you saying that each inverter's grid input has a residual current breaker in series with a classic breaker? Or is the classic breaker on the inverters' outputs (heading to the loads)? 16A seems marginal for an 8kW inverter, especially on the AC input, where you might have 8kW of loads plus several kilowatts of AC charging. That could explain the 16A RCDs breaking, and that might somehow cause the 63A breaker to trip. I'll grant you that this is a long shot. It might be worth replacing the bypass relays (contactors?) in one of the inverters to see if that helps. Perhaps just the neutral changeover relay, as that switches earth to the inverter's neutral output. If that is slow or arcing or stuck, it might cause current imbalances that trip the RCDs. Also check the earth and neutral wiring of the premesis carefully. Just a little neutral current carried by an earth wire somewhere will unbalance active and neutral currents and cause RCDs to trip. Edit: Also check for screws missing on the main boards near these bypass relays. The earth connection to the changeover neutral relay usually goes through a hex screw and its threaded standoff, via the metalwork to the inverter's earth terminal.

It's not "normal", but it is common on many Voltronic Axpert inverters with the high PV voltage rating, which is almost all of them these days. I have a big post about patched firnware, see the section on MPPT stuck at 90V. It tells you what patched firmwares are available for particular models. Voltronic do have several firmwares that do OK with this issue, but none of them seem to be "mainline" firmwares with version numbers like xx.yy where yy < 60. But it seems that Georg's original patches work best. I merely adapt his patches to many Axpert firmwares for many models. There does seem to be a way that the bug manifests towards the end of the day, though it often seems to be less noticeable there compared to mornings. As to why the bug is there at all, my guess is that these MPPT chargers run off PV power, so in the morning, it's important not to demand too much PV power, as you may "strangle" the weak PV power needed to run the charger's electronics. Power electronics running on marginal power supplies is not a good thing, so they have special code to prevent this. As the AI suggests, it seems over cautious the way it does this. I have to say it's somewhat flattering to have AI mentioning my forum name directly 😊. Now if we could somehow train it to point to my patched firmware post directly, that would be wonderful.

That's up to you. The fully patched firmware has a number of features. But if you happen not to use any of those, you could go to factory firmware, which is now much more recent. Without release notes, we don't know how significant the factory firmware changes are. Main firmware is usually called DSP. I can't recall if this is important or not, but doing it in that order probably doesn't hurt. Edit: Sorry for the late reply.

It looks identical perhaps. But is the transformer turns ratio the same? Do the various sensors use the exact same scale? Does the EEPROM layout match enough to be useful? Is the DSP chip the same? I suspect that the Infinis might use floating point instructions, meaning that a '2809 DSP would just crash. It's possible that it might work, but I think it would be very risky, and I don't recommend it. Certainly it would require using an Axpert reflash tool with an Infini hex file, and you may need to rename the hex file. To go back again, assuming that it doesn't immediately brick the inverter, you'd have to di the opposite; use an Infini reflash tool with a suitable Axpert hex file again renaming as needed. Immediately after each reflash, you would need to run a command to reset the settings to factory. Even then, most if not all of the calibrations could be wrong, so many of the measurements could be inaccurate. Finally, in most jurustrictions, running the inverter would be illegal, as the inverter would be capable of exporting non-trivial power to the grid, and the model would not be type approved and registered (I think). There are just so many ways that this could go wrong.