Coulomb

@stuvo, it looks like you're doing everything right with the software update process, at least from what we can see here. I'm concerned about the 32.40 firmware, Either that is very old (the lowest number I have seen on a 5 kVA Axpert is 52.02), or the versions don't always increase with time, or it's custom, or it's not a Voltronics Axpert. I agree it would be very good to contact your supplier to see if they can provide a known compatible software update, or at least the update files for the existing firmware in case it's special in some way (and of course that you find some way to actually perform the update). I could not find any Axpert model on the SMK website. However, the fourth scrolling picture on the main page shows what looks very much like an Axpert, but with no brand name at all. The title said "Hybrid Inverter Charger", which is strange because the Axpert isn't a hybrid. When I click on Hybrid inverters under Products, I get a completely different looking blue box with a black "slot" up the middle. When I download the catalogue PDF, the specs for the blue box do sound like that of an Axpert, except for the mains charging, which is limited to 30 A. That sounds like it might be old hardware, which is quite possibly not suitable for use with firmware version 72.XX. Perhaps not even firmware version 52.XX. Perhaps the uploading process was different back then. Perhaps you have been spared a "bricking" by this, intentionally or not. (If intentional, I would have hoped for some error message, perhaps "Your inverter is not compatible with this firmware, contact your supplier" or similar.) Do you have a manufacturing date on your machine? On later models, it's on a small (perhaps 30 mmm x 10 mm?) label put over one of the case screws, so that they have evidence if/when you open the case. The vibes I got from the SKM website are that they are an independent manufacturer, not a reseller. But perhaps they are content to resell into the Axpert market, not compete with their own product, at least for the present. Edit: one final clue: the photo on the main web page hints at a heatsink on top of the unit. The top of modern units is smooth cover metal, no visible heatsink (the SCC heatsink is now entirely internal, for better or worse). Does yours have a finned heatsink at the top?

My guess is that COM1 isn't the USB to serial adapter. Is there another option for the serial port, i..e. if you clock the arrow at the right end of the "Serial" drop-down list box, are there any other entries in the list, other than COM1? As for the the assertion failure from the SCC firmware update program, I have no idea, but it sounds like it's related to the serial port issue. You said the existing firmware version was 32.40... could that have been a typo and it was actually 72.40? If it's not a typo, perhaps it's not a real Axpert, in which case all bets are off. Edit: make triple sure that Watchpower etc are not running; you need to use the exit menu, not just close the app.

Yes, it's not that simple, and I don't get why there isn't one visible. I didn't try hard to sort it out.

I don't know much about deep cycle lead acid batteries. My understanding is that you should not charge them much faster than C/7, or discharge them faster than some other limit, which I thought was about C/2 or C/3. 4000W at 48 V with 93% efficiency is some 90 A, which is heading towards C/2. I would not expect the voltage to collapse at that load, but I would not be surprised if the battery voltage at the Axpert terminals did a bit of a dip that causes the Axpert to draw more power to maintain the load, causing more voltage drop. Enough for the Axpert to declare overload. All this could happen so quickly that the Axpert display may not show it, let alone software monitoring. This would be more plausible if your battery cables were on the thin side, say 25 mm^2 or less. As I type this however, the above scenario would probably result in a different error code, related to battery and not overload. It's still plausible, I think, but less likely than I thought. So yes, a bit mysterious.

My understanding is that when it is set up, USB comms is just the same as serial comms, including being as slow as 2400 bps serial. There is then a virtual comm port like comm12. [ Edit: this isn't quite right; see Gnome's reply. ] So then you can use any serial comms program like TeraTerm. [ Edit: and this last part is completely wrong. ] But the trick is in setting it up. I never figured it out, and I've never seen it documented anywhere.

Yeah, it's supposed to be able to run 4 kW continuously. Maybe the load has a really bad power factor, and it's exceeding 5 kVA? That also seems unlikely. Maybe the battery voltage collapses when it reaches around 48 V, but if rescued at 49 V (where the internal resistance is a little lower) it's OK? What is the capacity of your battery?

Yes, there is the CRC (two Cyclic Redundancy Check characters). That's why the NAK comes back as NAKss; the "ss" part is the two-byte (two-character) CRC. There are a very few commands that don't require a CRC, and I think that QPI must be one of them, since it doesn't send back a checksum, just the 6 characters "(QPI30" and a carriage return. Try sending the CRC with the PI command. In this case, it's 0xD752. The second character is just "R", but the first is "W" with the sign bit set. Comms programs differ in how to send such characters. Some background on using commands (for the non-V Axpert, but the principles should be the same). The end of this post has how to send 8-bit characters using the Windows program TeraTerm. C source code for generating CRCs. A Windows applet for generating the CRCs more painlessly.

Your voltage logging seems to be reporting whole volts. The inverter's DSP works on tenths of a volt. So that 48 V might really be 48.4 or even 48.9 V. So it doesn't actually cross the back to grid threshold.

You can use both [ Edit: monitoring software and remote display ] I believe. Just use a USB to serial adapter, and connect the computer to the serial input of the remote unit. You might find extra delays that way, so it might not be ideal. I've never tried it, this is all theoretical.

My slightly educated guess is that running queries on multiple machines should be fine; the Axperts run a multitasking operating system and there are interlocks to prevent problems. However on a single machine, there is a lack of serial ports. There are two, but one is dedicated to talking to the SCC. It's possible that the USB port talks via some other port, but then I'd expect to see an extra cable from the serial port board to the processor board.

@Don, I think that today's chart was a textbook perfect case. The SCC has to get consistent readings of 9 A or less for 30 seconds, and it looks very close to that when it transitioned. There may be slightly different readings between the SCC, the DSP, and your BMV (a nice alphabet soup there), and I can readily excuse that difference today. Hopefully today was a best case, and yesterday near worst case, and you won't have to worry about it any more. Thanks for the additional data.

The current criterion is that the charge current has to be *strictly* less than (as in integer < as opposed to integer ≤) the threshold, i.e. strictly less than 10 amps, and because the current is measured in whole amps, this actually means 9 amps or less. Given that the time units in your grid charging chart are about 11 minutes, that seems to agree reasonably well (it's hard to tell the way the current is tapering off so gently). For completeness, the voltage criterion is not strict, and there are two measurements. In order to pass the criterion, you need either battery voltage as measured by the DSP to be greater *or equal* to the threshold, *or* the battery voltage as measured by the SCC to be greater *or equal* to the threshold. The SCC voltage is usually a little higher while charging, so it's usually the SCC voltage that makes or breaks the criterion. Put another way, to fail the voltage test, you need the battery voltage as measured by the DSP and the SCC to both be less than the criterion. Looking at your solar charging charts, it looks like the battery voltage is pretty steady, and is not a factor from about 10:35 on. The average current seems to drop to 9 amps at about 9:35, and seems to be smooth for the next 40 minutes or so. So ideally, it should have transitioned to float by about 9:36, give or take 10 minutes. But solar charging is rarely smooth, and there could well have been voltage or current glitches that don't show up on the chart. From about 10:15 to 11:00, the clouds seem to have made the voltage and current curves quite choppy, so it's not surprising that float wasn't achieved there. It eventually went to float at about 11:18, about 1:42 later than it ideally could have. Ironically, this was a couple of minutes after a moderate glitch in the voltage and current. There is even a pair of glitches right before it went to float. I think up to two hours of extra absorb time is not too bad, but it would sure be nice to minimise the over- and under-shoots of voltage (and hence of current), so that this figure could be improved. After all, some days might have choppy cloud all day. Hopefully, there will usually be a 30-second period where the chop is slight enough to allow transition to float. The chances of 30 seconds of smooth sun or cloud are a lot higher than the chances of 10 minutes (20x as long!) of relatively constant solar output. If today's conditions (sun with scattered clouds) are about the worst case, then I think that this is Ok, and is as good as can be had for a while. If not, it would be possible to change the current criterion to be say divide by 4 (50 / 4 = 12.5 A, so 12 A would be used, really 11 A or less) so that it would be easier still to make it to float. But then on days where you needed to grid charge, you'd be getting a little less than a full charge. Maybe we'd make it /5 for single machines, and /4 for any number of paralleled machines ≥ 2. But let's see how 72.70b performs over time. Thanks once again @Don for your prompt testing.

The Axperts, also made by Voltronic, had this issue and it was fixed by a firmware update. @superdiy, maybe you're thinking of them, but maybe all their products from that period (2015?) had this issue. It may have been a desperation fix for some issue, and I'm blanking on what that was. Overcharging batteries comes to mind, but I can't see how the two are related. Edit: maybe it was overheating due to fan failures, that they fixed with coating some fan connectors. Still makes little sense.

Patched firmware version 72.70b is now available; see this AEVA post and the posts it links to. @Don, it would be great if you could test this for us all. Sun here has been poor, and rain is forecast for the next few days.

Sigh. It's been pointed out to me that actually, changing the PWM is exactly changing the effective voltage that the panel sees. The panel sees in effect a boosted battery voltage, even though we call it a buck converter (because the power flow is in the buck direction). When the sun comes out, you just end up on a scaled-up version of the present IV curve, where the current is too high, so you just need to roll down the new IV curve to the desired current. In short, the "other effect" (other than integral wind-up, I mean) doesn't exist. Sorry for the misinformation.

Duh, of course. Those IV curves always seem backwards to me. [ Edit: the convention is to put the independent variable, the one you can control, on the X axis, and the dependent variable, that one that arises from your choice of X axis value, on the Y axis. But they always seem to show it the other way around. Maybe it started that way because people put panels directly across batteries, so that the battery voltage really was the independent variable. But no-one does that any more. ] And of course you are right, you can't go to zero in the other direction. So yes, a small PWM (current) error will produce a large voltage error in that part of the curve. Interesting. All the more reason that you need good R&D to make a good charge controller.

My thoughts are that you would usually back off the current, i.e. move back away from the cliff, rather than over it. A lot of the MOSFET losses are proportional to I²R, so you'd be nuts to go for the high current option. Especially since as you say it's like "a little guy balancing on a surf board at the bottom of the hill there". I think it's also more intuitive; to back off the current, you just back off the PWM, and if the shape of the curve is such that this is now more power, just keep backing off. So that makes for a simpler algorithm, perhaps. Now that I type this, perhaps that's the main problem, not integral wind-up. In Don's wonderful example, the PWM is set for maximum power, which with cloud is only 335 W. When the sun comes out, this PWM value may be past the MP point, so backing off the PWM actually increases the power for a while. If you aren't compensating for that somehow, you will get quite an overshoot. I'm no SCC expert, so I could be way off base there. It's possibly also a combination of the two, if the above effect is real. Thanks for your thoughts, @plonkster.

Alas, Helios was not cooperative today. We were forecast a week of rain two days ago, now it's finally here.

Yay! I don't suppose you remember if the sunshine or clouds were particularly steady towards the end there, say after 3pm? I suppose other graphs could tell you that. Yeah. That's a doozy. Notice that there was a small voltage dip (undershoot) just before the overshoot. So for maybe a minute before the sun burst out around 2pm, the SCC was working at maximum output, and even that wasn't quite enough to maintain 57.6 V. So there was a small error in the output voltage, that over the minute would have integrated to a moderate "I" (integral term) value. My theory is that they have no protection against integral wind-up, so once the sun came out and there was plenty of available solar power, the I term of the PI loop kept the power pouring in too long, until that integrated error was reduced to zero by a negative error (the overshoot).

@Mark, as far as I know the Axperts have a "Non-Return" valve. With firmware you can only go forward, not backwards. I'm pretty sure you can go backwards. I'd say that 72.60A would actually work better for you than 72.70A at present. I have 72.70b (LFP version) ready for alpha testing today. Would it be possible to post your battery amps graph? Just to get a feel for whether 72.70b is on the right track. From the battery voltage graph, it sure looks like there would be several stretches of 10 minutes where the solar input is even enough to allow the transition from absorb to float. The other thing to try would be to turn off some of your PV breakers when the SOC is near 100%, so that it has less power to overshoot and undershoot with. Obviously, this is not a permanent solution, but would be a helpful diagnostic. It's a little ironic that your very capable PV array is contributing to the problem here.

@Don, thanks for the clarification. Are you in a position to watch the charge currents on the LCD display? You may find that when the sun comes out, there is a rush of charge current due to the SCC overshooting the voltage set point, that the software doesn't catch (or only catches every fourth time perhaps). Similarly, you may find the battery voltage dipping more than half a volt below setting 26 for a second or two. It could happen even faster than that; the software works on 20 ms time slices, whereas the display seems to update about once or twice per second. But your software may be monitoring battery voltage and current much less than once per second. My theory is that at least one of these must be happening to reset the counter, so it never makes it to ten minutes. Sounds like cutting down the 10 minute qualification time is the way to go.

@Don, also what's your setting 32 ("Bulk charging time")? Automatic or a time?

Don, you say that your Axperts are stuck in bulk stage, and are not getting to absorb and hence not to float. How do you know it's in bulk? Hanging around the CV voltage (I assume your setting 26 is about 57.6 V) sounds like it's in absorb. What the Axpert actually believes it's in is only revealed by a field in the non officially documented Q1 command response. Does your software show the charge stage? I don't see it on the screen dump you showed earlier, but it may be on other screens. The thing is, the qualification time for bulk to absorb is only 10 seconds, already quite short, and changing the qualification time for absorb to float won't affect anything if it really is stuck in bulk.

I'm starting to think that the problem is the much longer qualifying time for reaching float (10 minutes in 72.70, 30 seconds in 72.60, 72.40, and 52.30, though in the latter we seem to have attempted to patch to 2 minutes (actually achieving 72 seconds). So the qualifying time is much longer. Maybe this was their lame attempt at fixing the main charge bug (too *easy* to go to float). Watching mine just now, with the solar power bouncing up and down, it's really hard to make both criteria (high enough voltage, low enough charge current). When the sun comes out, the temporary overshoot on battery voltage disqualifies the low current criterion. When a cloud comes over, the temporary undershoot makes it fail the battery voltage criterion. The chances of making both criteria without exception for 10 minutes become very low if you have changing solar conditions and/or loads. I'll ask Weber whether he agrees, and perhaps we could bring out 72.70b with that change (30 seconds qualify for float, instead of 10 minutes).

Sorry, it's me that is confused. I shouldn't be posting after midnight on my phone. Yes, those settings are fine. I'll have another think about what your problem might be.