Coulomb

Sorry for the late reply, but I thought I'd answer this question since I have a bit of a unique insight into the firmware, and others may want to know the same thing. It's not terribly clear in the manual. Parameter setting number 13 ("back to battery mode") seems to be about terminating the bulk/absorb stage of a utility charge early when the battery reaches a certain voltage. This might be because you are using the utility as a "last resort" or "most expensive, use last" option for charging the battery. You would prefer to use solar, but sometimes there just isn't enough. When there isn't enough solar energy available, parameter 12 will have initiated a utility charge to prevent the battery voltage (and hence rough SOC) from falling below a certain level. Parameter 13 is about when to stop doing that utility charging. When the utility charge gets the battery to the voltage in setting 13, the utility charger goes to the float stage, meaning it will not cost you much money now, you're just maintaining the float voltage. So the "FUL" setting in parameter 13 means don't terminate the charge early; continue in bulk and absorb until the charge would normally terminate, i.e. when the battery is full. So effectively, this is like choosing your CV setting; that's the voltage where the absorb stage would stop and float would start. But with a normal charge (setting 13 = FUL), the utility charge won't stop as soon as it hits the CV voltage; it will start an absorb stage where the CV voltage is maintained until the charge current falls to a low value. So in that sense, FUL doesn't correspond exactly to a fixed voltage setting. Internally, the effect of the FUL setting is to make the "back from weak battery" voltage equal to 100.0 V; the battery will never reach 100 V. In other words, if the battery is declared weak (that means that utility charging is turned on where possible), it is never declared non-weak. So that means that the utility charge is never forced from bulk/absorb to float before the normal charge has completed. So in that sense, FUL is equivalent to 100 V. I believe that this has no relevance when using Uti as the Output Source Priority (parameter setting 1). You would use Uti output source priority for an off-grid installation. They (settings 12 and 13) make most sense to me when using SbU as the output source priority (i.e. Solar first, battery next and Utility as a last resort).

At low power levels is when you tend to measure the highest temperatures. I think it's because they slightly over-compensate for loads. But my friend and I joked that at low power levels, the low fan velocity was just enough to counteract the natural convection .

Yes, I do :-) Oh - it takes the highest. Seems sensible.

There are at least four, as shown in this AEVA post. Note that after turning the fans around, there is a chance your inverter's high frequency transformer may get 5-6

I didn't think there was any protocol difference between 52.30 and 72.40, which came with my October 2015 manufactured inverter.

Alas, no. None of the commands sends an event to the ModeSwitchTask. In fact, such events are quite rare. I haven't commented every call to OSEventSend() yet, but none of the ones I've done so far pass 0 as the task parameter (i.e. reference the ModeSwitchTask). But I've only done about half of these (but all the command processing functions).

That seems to be setting output source priority, as Oomd mentioned. Does this effectively change modes immediately, assuming that the conditions are right? I think that this may be the problem, that it doesn't effect a mode change immediately. Looking at the firmware, it merely changes the eeprom parameter OutputPriority, and sends an event. But the event is to the SciTask, which handles the serial ports (SCI stands for Serial Control Interface or similar). I wonder if it should wake up some other task to make the change happen sooner. I can poke around to see what task reads the output priority setting; it's probably task 0, the ModeSwitchTask. Maybe you can send some other command after the POP command to wake up the ModeSwitchTask; it will take me a while to sort this one out.

This issue could be related to the bug I've found (and fixed!) in the firmware. What seems to happen is this: * The charger exits absorb mode when the current falls below a particular current threshold for a partucular time threshold. The current threshold depends in a few things, but it's a minimum of 5 A; for now let's call it 8 A. The time threshold is fixed at 50 seconds. * Bulk and absorb are actually combined into a single stage when the SCC (Solar Charge Controller) is connected to the DSP (Digital Signals Processor) inside an Axpert. * Bulk mode starts slowly. Sometimes this is because of the strength of the available solar energy. * Bulk/absorb mode would exit to float while the current is still less than 8 A for 50 seconds. In other words, it exits *on the way up* (PV current is still buiding) using criteria it's supposed to be using *on the way down* (battery has absorbed enough charge, and is full). This could be causing the excess switching that you have been observing. I have developed a patch to firmware 72.40 that makes these changes: * The time threshold is increased from 50 to 120 seconds. * The exit criteria are changed, to add this condition: the battery voltage must be at least (CV setting minus 0.5 V). This is the main fix. If the PV curent is still rising, then the battery voltage won't be near the CV voltage yet, so the criteria are not met, so the charging continues. When the battery is fully charged, it reaches and briefly exceeds the CV setting voltage. (That's what absorb mode is about - staying near the CV voltage until the charge current drops down low, often C/5 or even C/20). * There are some trivial changes, to report a different version number, and to make the 7-segment "font" more readable. The current threshold remains as per the factory, which is: the maximum of (5 amps, and the maximum charge current divided by 5). So it will always be 5 A or more, but if you have set your maximum charge current (PV plus mains) to 120 A, then the threshold would be 120/5 = 24 A. If you want a lower threshold (i.e. charge the batteries a little longer), you could adjust the total charge current to say 100 A (for a 20 A threshold), or 80 A (for a 16 A threshold), and so on. Most of you would not need very high combined PV and mains charging, so this does give you a degree of control over how long the absorb stage lasts. The graph in the manual about staying in absorb for 10 x the time it was in bulk is just wrong, as far as I can see. This is the behaviour that the SCC would have in one of the Voltronic Power stand alone charge controllers, but it's completely overridden by the DSP when the SCC is combined with an inverter. At least, that's the situation for the Axpert MKS 5KVA models that I've examined. I think they just copied that graph from a SCC manual in good faith, and didn't realise that it no longer is relevant. I developed this patch as a fix for LiFePO4 batteries. For LiFePO4, we wanted a few extra changes (e.g. minimum of 1 A current threshold, and allowing the low voltage cutoff voltage to be as high as 52.0 V). It was suggested that I should make a version of this patch without these extra LiFePO4 changes; this was done and it is called the "lead acid patch". Most of you here seem to be using lead acid, so that's probably the version of the patch that you would need if you were to try this. Some of you are using 2015 models, which may come with firmware later than 72.40. (I'll find out in a few days, when my inverter gets re-delivered after the Christmas break). If necessary, I can apply the patch to the newer firmware. Anyone wanting to try the patch can read these AEVA posts: introduction (pardon the gushing start from my enthusiastic friend Weber), and the lead-acid patch. Note that I've added "this patch may not be necessary" to the top of the latter patch, because you guys didn't seem to be having this issue, But now I see that it may just be a little hidden (from my point of view) as the "excess switching" issue. Warning: the lead-acid patch is not as tested as the LiFePO4 patch. In fact, this version (I had to fix a bug in my bug-fixing patch ) hasn't even been downloaded to a machine (its predecessor has, and was tested as far as could be done on a machine with LiFePO4 batteries). But this may be the ideal time to test it, if you have a little more time this time of year. The zip file with the patch contains factory original 72.4 firmware in case you have to revert. All comments welcome.

I get the impression that the DSP wants to set what mode it's in. Perhaps you are setting only the priorities. In that case, it may take 5 minutes for the conditions to be right to switch modes. It will be interesting to check when you're back from the bush. I can certainly try. That sounds pretty weird; I can't see how the DSP cares or knows whether your comms software considers that the port is open or not.

That sounds like there is a missing call to send an event to the multitasking software. There are 8 tasks running in parallel, with a complex system of flags to tell the DSP when to dispatch the right task. What command were you using?

Yes. I was chasing a problem with PV charging LiFePO4 batteries (I don't know if it will happen with lead acid), and got sucked in further and further. It took months to figure out the charging bug, then a week or two to develop and test the patch.

> ... The Axpert doesn't recognize the power from the genset. The "AC icon" flashes and it beeps, but there's no error. > While looking for the other topic on this matter, I found this one: http://powerforum.co.za/topic/215-infini-axpert-firmware-solarpower-pro-software/?hl=generator#entry1481 where Chris Hobson quoted another forum: So Solamahn says that 52.25 was good (for generator tolerance), and 52.30 is bad. Someone else reported that 72.40 is good. I was surprised that 72.40 would fix this, since there seem to be so few differences between 52.30 and 72.40. But now I think I've found two instructions that are present in 52.30 and not in 72.40, and not in 52.02 (the only version I have prior to 52.30). It's a test for non-zeroness of eepromOutputMode (name will be different) after a test of non-zeroness of eepromModeSelect . Confused? Me too. Firmware is complex, so it's not surprising to see something like this slip in. It may also be that I have not found the significant difference at all, but it sure looks that way to me at this point in time. So there you have it: seemingly a bug introduced between 52.25 and 52.30, and fixed by 72.40 (perhaps well before, I don't know their version numbering system). Thanks for the Christmas day puzzle guys; it was a good one [ Update: there is evidence that this puzzle isn't (completely) solved yet. ]

As a point of interest, SilverNodashi, what does your manual tell you that U3 display setting is about? They used to be available from the MPP Solar web site, but they seem to have moved. Either they were deleted, or moved somewhere, and no web crawler has come across them as yet. I happen to have 52.30 and 72.40 saved away. and they can be downloaded here: http://forums.aeva.asn.au/forum_posts.asp?TID=4332&PID=59274&title=pip4048ms-inverter#59274 You might be interested in my patched version to fix a different bug: http://forums.aeva.asn.au/forum_posts.asp?TID=4332&PID=59884&title=pip4048ms-inverter#59884 (intro) and http://forums.aeva.asn.au/forum_posts.asp?TID=4332&PID=59908&title=pip4048ms-inverter#59908 (download, lead acid version). People on this forum don't seem to be using LiFePO4 batteries much, it seems. The lead acid patch is untested, so treat with caution, and please report back any results, good or bad. The original 72.40 firmware is int the download, just in case it's bad and you need to revert to factory firmware.

I should note that in firmware version 52.30, which happens to be the one I've examined the most, while the BTA0/1/2 commands are all there, and carefully calculate three mysterious values, and their magnitudes are checked (e.g. the main one should be 1024 +- 500), I can't actually find where they are used. It could be that I just haven't found that part of the code, or it might be that they planned to implement this but never finished it, or they had it implemented at one point, and had to comment it out for whatever reason. It may also be that later versions of the firmware have it implemented. I have found very little difference between 52.30 and 72.40. I'll look at this more closely, but for now, it seems that figuring out how to perform calibration might not be worth too much effort. Edit August 2018: I have since found what 2 of the three "mysterious" values are for; they are a scale and offset for the battery ADC measurement. So the calibration process seems real.

I totally agree. They used to supply the fans drawing the air downwards, instead of blowing upwards. We had a discussion of this on AEVA, starting here: http://forums.aeva.asn.au/forum_posts.asp?TID=4332&PID=54762&title=pip4048ms-inverter#54762 Note that this was an older unit with older firmware. But it seems worth changing the air flow if it's upside down, and possibly replacing the fans with quieter ones. We found that with quieter fans and blowing upwards, the temperature runs at only 35'C or so with a 2 kW load. But we don't run that unit all day; this was a "lab test". This will change in the next few weeks or months, when three of us will be running these inverters full time.

Yes, this appears to be the case. My reading of the firmware indicates that you can use any two voltages in any order (i.e. higher voltage first, or lower voltage first, but a valid BTA1 must come before BTA2). [ Edit: the BTA commands are also sent to the Solar Charge Controller; if it's powered up, it seems to expect the higher voltage first. ] However, they have to be at least 5.0 V apart (both the measurements and the arguments to the BTA1 and BTA2 commands), and the value in the BTA1 and BTA2 commands must not be over 60.0 V, and can't be zero. In addition, the difference between what it measures and what you tell it must not exceed 3.0 V, so you can't "spoof" the battery voltage by more than 3 V (but possibly a little more or less, depending on the natural error). Any violation of these conditions results in the command getting NAK'd instead of ACK'd. It looks to me that the inverter will still be expecting valid BTA1 and BTA2 commands. I don't think you can use really low voltages, say < 40.0 V, since it won't run the inverter. You could run it from mains or PV though. There doesn't seem to be a test for a low value, other than for zero, so that might work. However, best accuracy will be had by using realistic voltages. Yes, it's CCITT, as noted here: http://forums.aeva.asn.au/forum_posts.asp?TID=4332&PID=57733&title=pip4048ms-inverter#57733 I note that this is when I welcomed Chris Hobson to the Australian Electric Vehicle Association forum, and now this is my first post here. Thanks for posting about the calibration procedure. I had noticed the BTA commands some time back (along with perhaps fifty test commands) and wondered what they were about. [ Edit: added comment re 5.0 V difference applying to both measurements and the BTA1/2 arguments. ]