Coulomb

All I can think of is some problem with the buck converter circuit, since this is involved with all battery charging on these models. Though I can't see how this would affect the AC output, if all the relays are working correctly. Maybe disconnect the board with the SCRs on it, if these models have that. It should work without it, just switch slower.

Oh. I don’t recommend spraying the back of the panels. Ah. This could be the power supply capacitors on their way out. This sometimes results in the power supply collapsing, recovering, restarting the DSP, and repeating, sometimes a few tines per second, iften with the LEDs flashing. This is a moderately easy task to fix if you are good with electronics. See this post (page down a bit): This possibly explains why it happens at night, when the battery voltage is lower.

Sorry, I don't have either. I have a partial schematic trace here: https://forums.aeva.asn.au/viewtopic.php?f=64&t=6007&p=90479#p90479 They are simple enough boards, but they would still be a lot of work to "copy".

You might be able to use a low tech diagnostic tool: the garden hose. Possibly with rubber gloves and rubber bands to keep water from getting inside them. Hose the panels (from the ground if that is possible) during the day and see if you can cause it to trip. If so, reset, and see if there is a consistent location where the trip occurs. That might let you home in on where the leakage to earth is. I assume that the fact that it happens mostly at night means that it's condensation related. It might be that you can bypass or replace one or two panels and have lasting relief (an actual cure / permanent fix). Or maybe apply neutral cure silicone (NOT the acid cure variety) to try to keep the moisture out. But obviously you'll need to be very careful with that; stay safe. From the above, I'm only about 80% sure that it's a leakage to earth. If not, it could be something to do with the solar charger inside the inverter.

Almost all Voltronic firmwares, with the exception of the VM firmwares, support paralleling. However, PowMr inverters are work-alikes (perhaps manufactured by Must), and often don't run Voltronic firmware from the factory. I don't know whether Voltronic firmware would work with these.

In retrospect, I think that Gemini's response is convincingly worded nonsense. Thanks anyway. It's good to see that Gemini checks the responses of experts, though. Who was it that it checked, oh yes, Coulomb 😎😉

Wow, it's as if Gemini has access to the source code, or at least to a change log that I don't know about. Was there a reference link with this? There is no reason why you can't take advantage of later firmware, as long as the firmware assumes the same hardware and doesn't change the EEPROM layout. If by "equipped" you mean "comes from the factory programmed with", then sure, I agree.

No. 46.xx is '2809, 72.xx is '28066. You check my Axpert firmware page here: https://forums.aeva.asn.au/viewtopic.php?p=95278#main

The latest 60.xx firmware for VM III and VM IV is 60.14, about 2 years later than 60.76. I have no idea what limiting it does, and sadly I have no time to check just now.

I would think you would be able to restore the correct firmware variant without significant issue. The EEPROM would not be able to be read, so the firmware would immediately throw up a warning, I think, but the serial code should still work. Best not to have anything connected other than the battery. Firmware versions 12.21 and later are "universal", i.e. they work on either chipset.

It's the structure (order, layout) of the EEPROM contents that is the problem. If I understand you correctly, you have two inverters; one came with 78.09 and correctly reads the SOC, and the other came with 78.11, and reads the SOC as zero always. I've just verified that 78.10 has the same layout as 78.11, so it should be safe to flash to 78.10 to see if that fixes the problem. It's available here, as a set of patched firmwares, including the original unpatched firmware. Should that not work, you can go back to 78.11 here, along with several patched versions if you wish, and again including the unpatched original.

I highly don't recommend flashing an inverter that came with 78.11 with 78.07, as these use quite different EEPROM layouts. 78.11 even has two more regions than 78.07 has. I don't have a 78.xx that is later than 78.11, but I have 78.10. I'm checking that now. But SOC tracking is largely a display/comms firmware business. What are the display/comms (U2) firmware versions that work and which don't?

That can't be a main firmware version. There should be a page displaying something like U1 43 90 meaning that the U1 firmware version is 43.90. But maybe this clone doesn't have standard Voltronic firmware. 3500W is not a common Voltronic power rating. If it's non-standard, then the change of finding a firmware update for it reduce to nearly zero, unfortunately.

I assume that this is an older 145V max PV model, hence the lowish PV voltage. With these, the PV power is confusing. The column that shows 0.0 all the way down is titled "Charging current"; that's the current into the battery that's left over after the loads are supplied. With these models, when in battery mode, the AC-in power is never blended. So the problem could be that your ≈2¼ kW of panels, likely producing about 1.5 kW max at that time of day, doesn't have any left over after powering the loads to charge the battery. Though at the bottom (earliest time) when the load is only about 726 W, losses would be about 70 W plus 50 W constant, so ~850 W total to be provided by the battery and/or PV. Your panels are about half the power of mine, and I had over 2.5 kW at 9:35 this morning (clear sky). So yes, if you had clear skies that morning, I would expect a little charge current into the battery. About 400W, so some 8 amps. Is this system charging the battery?

You might try display/comms (U2) firmware version 39.36, which is more recent. The display/comms firmware is what talks to the battery BMS.

Yes, it could be firmware, especially display/comms (U2) firmware. Press up or down buttons on your display until you see a page with U1 or U2 followed by 4 digits. Note both of those and post them in a reply. If you are using monitoring software, it will have the firmware versions in there somewhere. Details vary with the monitoring software.

That's the main (U1) firmware version. Communication with a battery's BMS is handled by the display/comms (U2) firmware. Please tell us what your display (U2) firmware version is. The latest U1 firmware for your model is 72.10. Beware of the many 72.xx firmwares for other models.

Sometimes they just don't populate a part if they figure out that they can get away without it. To check, you'd have to find out what it connects to, e.g. that nearby transistor (perhaps across emitter and base), or a pin number on the power supply IC, etc.

These files are now quite old, so I wonder what you need these for. This is display/comms (U2) factory firmware version 12.06 for the Axpert Max non-Twin models with a removable display. Do not use with any other model or version. This version cannot replace 112.xx firmware. Use at your own risk. The hex file is dated 04/12/2020. Firmware upload instructions for models with a removable display. This firmware does not process the QDOP command, so even with suitably recent main firmware, it will not support SoC% for settings 12,13, and 29, when connected to a suitable battery's BMS. MAX3k6-7k2-Remote Panel_Reflash_MCU(12.06).rar

Unfortunately, the closest available main (U1) firmware is 46.07. For a long time, no 46.xx firmwares were available at all. Could you update all your inverters to 46.07? I'm presuming that you need them all the same for paralleling. This is main (U1) factory firmware version 46.07 for the Axpert Max 8kW '2809 non-Twin. Do not use with any other model or version. Use at your own risk. The hex file is dated 28/07/2022. Firmware upload instructions for models with a removable display. This firmware does NOT process the QDOP command, so even with suitably recent display firmware, it will not support SoC% for settings 12,13, and 29, when connected to a suitable battery's BMS. MAX 8K_Ver46.07.7z

Alas, I don't think that there is a 475V target voltage (see below). 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 212 = 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.

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. 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.

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. 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.

Sorry for the late reply. As you have seen, yes. But there are limits related to hardware, obviously. 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. They are all over the place, unfortunately. 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. 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).

It's probably an IRF640, but any TO-220 MOSFET with similar specifications should work. Here is a 24V clone's power supply schematic in case it helps: