Coulomb

The Axpert doesn't count coulombs (amp.seconds, 1/3600th of an Amp.hour). The BMV does. The Axpert has the hardware and the controller horsepower to do it, but for whatever reason, the manufacturer feels that voltage is a "good enough" indicator of state of charge. Despite this limitation, the Axperts are still good value for money, even when you add the cost and complexity of an external coulomb counter. Edit: when you count coulombs (or amp.hours), you get a much better measure of the state of charge of the battery than you do by using only the battery voltage. So you are better able to prevent over-discharge of the battery, which prolongs its life.

Yes, exactly. Think of it as pushing against a higher pressure (higher voltage). That higher pressure (voltage) can do more work per time )power) with the same flow (with the same current). So you need more power now (charging a battery with rising voltage) so that the battery can provide more power later (58 V at 100 A is more power than 48 V at 100 A). Conservation of energy.

Fritz: re 7 strings. No, remember that the 60 A limit is at the output of the MPPT. With say 90 V at the panels and say 53 V at the battery, you have 90/53=1.7x less current at the input of the MPPT. So that's a limit of some 60/1.7=35.3 A, say 36 A with losses. So to max out the MPPT when the battery is at 53 V you need 90 x 36 = 3240 W of panels. Working with panel current, that's 36/8.5=4.2 strings. That's about1.7x less than the 7.1 you came up with. But that's at maximum panel output, which you rarely see. It's better to have more panel power available, so you get more use of the MPPT in cloudy conditions, at the expense of some clipping on sunny days around noon. So 7 strings is probably a reasonable number, just for the wrong reasons ☺ Edit: actually, 1.7x (as pointed out in an earlier post, it varies with battery voltage) is a bit high for an "overclocking factor". 1.3x is more reasonable, so 5 or 6 strings (4.2x1.3=5.5). Edit 2: ising Solamahn's factor of 1.4x, that would tip it towards 6 strings.

Considering your budget, you may do better second hand. Some older inverters used lower voltage MPPTs, before it was fashionable to use long series strings. In fact a friend of mine has such an inverter, a Sun Profi that is now redundant, but that one requires a 48 V battery. (That battery will be used with a pair of Axperts, hence that inverter is redundant.) The problem with that idea might be regulations; typically the older inverters are no longer approved for connection to the grid, as it costs money and time to maintain the certification with the various regulators.

? Micro inverters produce 230 V directly, don't they? So no inverter at the DB. But as far as I know, they're not available as a stand alone thing, they are allowed integrated into the panel. There is an Axpert model (so 60-115 Vdc MPPT input) that is grid tie, I think the V series. But I think they might require a battery, and have two inverters inside (a true hybrid), so I'd expect even a low end model to cost too much. I believe that solar optimisers work on a 48 VDC bus. So the back end of that has to be. 48 V input grid tie inverter. So that might be economical and available.

I have some Infini firmwares, but they don't seem to be the same as what you guys are running. So I can't help much.These commands come from a power meter via a Modbus card, right? It seems to me that you would not want much "intelligence" in that card; better to make all the important decisions in the main firmware. So I would expect the commands to be not very much more than a translation of the measurements. The LDPR commands seem to be a measurement in watts of the net imported power (utility to house is positive). I can't see how this card can figure out how much total battery power is needed, since it is presumably only making one power measurement (is that right?). So I suspect it is saying back off the power by 120 W in one case, and increase the battery supplied power by 1559 W in the other. So the + and - may indicate increase and decrease respectively, rather than a power flow direction (edit: and an absolute suggested power). [ edit: removed sentence about amounting to the same thing if aiming for zero export. ] Is it aiming for zero export? If so, your guess for the 120 W case seems wrong. I can't see how the modbus card would see the PV power either. An interesting problem. It's disappointing that Voltronic choose not to publish these commands, but perhaps they fear that Joe Average would get this wrong, and end up with net exports from batteries, which seems to be a big nono. So maybe Voltronic are expected to never allow net export. Perhaps their getting certified depends on this, so they feel they can't allow customers to have control of net exported power. If so, I wonder how Voltronic but also the regulators would view this. I think that as long as they pay less for exported power than they charge for imported power, then there is no possibility of "gaming the system", which is presumably the reason for the nono.

My memory from reading the firmware disassembly months ago is that the Axpert can conrol mains and solar combined charging without overcharging the battery. There can be temporary over or under voltage for tens of seconds, but that is to be expected when one source is intermittent. But if I remember correctly it adjusts the PV and utility chargers to achieve the present voltage setpoint. I'm hazy on how it asks the SCC (solar MPPT charger) for more current, since the panels might not be able to provide it. Maybe it just sets a maximum current, and the utility charger provides the difference if possible, or as much as it is allowed otherwise. I'll check on this if I'm in the vacinity of that code again.

The "AK" part suggests to me a NAK that has intermingled with something else. I agree that it sounds like you need to sequence your requests properly. More than that, you need a delay after sending one command before it can handle the next; waiting for the response may not be enough. When sending initialisation strings to a PIP/Axpert, we allowed 128 ms per byte of the string (including carriage return and CRC bytes), plus 500 ms. That's for commands that just return an ACK or NAK, but I suspect that the 128 ms (easy to get using a swap byte and a shift) is quite generous. It does suggest however that for us, 64 ms per character was not enough. As for the fields after "x", yes I believe that there several undocumented fields after the last documented one. But alas, I'm away from that particular keyboard today.

Setting 16, Charger Source Priority, would be the first one to check. If set to CUt for example, "solar energy will charge battery only when utility power is not available". You want CSO, "Utility will charge battery only when solar energy is not available". I think you also want setting 31, Solar power balance, to be set to SBE (enabled), so that "Max. input solar power = Max battery charging power + Connected load power". That sounds to me to mean that solar power will be used for powering loads as well as merely battery charging. Oops! I've just realised this. For off-grid use, setting 01 (Output source priority) should normally be be UtI, so that the generator is used if connected. But they don't seem to cater for your "pre-emptive generator use", because with UtI mode, "solar and battery energy will provide power to the loads only when utility power is not available". Neither of the other modes does what you want either. So it looks like Axperts can't do this (unless someone comes up with a custom firmware that does this). For now, it looks like you have to wait till the battery SOC is low before starting the generator. Perhaps the dry contact can help with auto starting your generator (assuming it has auto start capability). Edit: actually, source priority (setting 01) = SbU (Solar then Battery then Utility) will probably do what you want. It runs the loads off the inverter (powered by the battery) unless the battery voltage is low (setting 12), but all the solar power will be used to charge the battery (and hence support the loads). It's not clear, but I believe that utility power will be used to charge the battery if needed. So it would only use enough generator power to charge the battery, but since the battery is providing the load, it is providing the load power as well (charges hard enough to cause the required current into the battery). I think. Hopefully a colleague will be running his system soon (perhaps today even), and we can figure out how these things work by trying them out. We have the luxury of having mains available, so we may have more scope for experimentation.

For off-grid applications, the source priority should be Utl, so the generator will be used if it's on. Axperts should also charge from solar at the same time; if not some other setting is likely wrong. As pointed out by others, mixing DC sources is trivial, and the Axpert certainly does it. There is a setting to do with solar balance, it never made much sense to me. But maybe it's for off-grid, where you can automatically use as little AC power as possible to satisfy the needs of the loads and charging. Otherwise, you may need to turn down the maximum utility charging current (but not the maximum combined charge current, which depends on your battery).

There are two service manuals for the 1-3 kVA models (KS and MKS) here; click on the below to go straight there: Thanks, @vandyh! Sometimes we do need to service our inverters ourselves. It makes them so much more valuable when we know that this sort of information is obtainable (even if hard to find at times).

Alas, the best I can do is this partial schematic of the DC power supply for a 5 kVA unit: http://forums.aeva.asn.au/forums/pip4048ms-inverter_topic4332_post59548.html#59548 The UC3845 indicated is the same as the UC3843 that you have, except for the low voltage lock out (UVLO) function; the UC3845 expects at least 8.5 V compared to the 3845's 16 V. The AC_PS_OUT signal on the left is from another UC3845/3 chip operating from the AC input. Oh, I've just noticed that I have a 1-3 kVA service manual here (likely available from this forum; check the files sections). Perhaps the rectifier is from the charger section; in this smaller inverters, they don't use the inverter backwards to charge the battery, but have a separate charger. The attached is from Figure 3.4, page 10, of "Axpert MKS 1~3KVA 24V Service manual". I might be able to help a little with remote diagnostics (basically wild guesses with the experience of having repaired one 5 kVA power supply to guide them) if you provide some more clues as to what part of the circuit this is. I know it's hard. [ Edit: I know the diagram is rather fuzzy (at least click on it and use the "full size" option), but it doesn't get better with higher zoom. They have embedded an image in the PDF with poor detail settings. Not unheard of. ] [ Edit 2: I'd check the diodes across the bridge (WTF?) as well as every other semiconductor in the area. Also check electrolytic capacitors for venting, any signs of burning; all the usual. ]

I doubt very much that you will find a complete schematic diagram. You may find partial sketches of similar models; I'll look later to see if I can find something. I'm amazed at the relative lack of damage from that short. Perhaps it confirms something I've wanted confirmed for some time: that when inverting, the output is synchronised with the grid for rapid and relatively glitch free switching to the grid should that be necessary. Do you know if it was inverting at the time, or bypassing? If bypassing, one would imagine that nothing would happen, as AC input and output would be connected anyway (though perhaps via a common mode rejection filter).

@plonkster : note that \r is a carriage Return, and \n is a Newline (line feed). You stated them the other way around, which may have confused things. Historical note: Windows uses \r\n because DOS and CP/M did, because teletype printers needed to return the physical carriage (the thing that does the printing) and advance the paper (line feed) as separate things. One reason is that the carriage return might take some 250 ms (a quarter second), which is about 3 characters at 110 baud (bits per second). The printer could still be returning the carriage while receiving the line feed, and often a null or two (do nothing character) would be needed after the line feed so the first character of the next line would be printed where expected, in the first column. The separate carriage return character also allowed for overprinting, if you didn't follow it with a line feed. Early printers used mechanical decoding, where a system of levers and a motor synchronous with the incoming bit stream selected the next character to print. Mechanical marvels. Bit there was no buffering. With the coming of 300 baud (30 characters per second!), they had to make the switch to electronic bit decoding using UARTs. Decwriters were actually able to print at just over 60 characters a second, so they would actually type that fast after a carriage return or form feed until they caught up. I hacked my Decwriter to receive characters at 600 baud, with the cost (I think, memory is hazy) of having to send some nulls. It had a small buffer (some 6 characters I think), but that sometimes wasn't enough. Still, I got a printer that was nearly twice as fast as standard for minimal cost.

The trouble with ASCII characters that have the sign (most significant) bit set is that there is no standard on how to send them or even how tp display them. For example, in superdiy's post, the CRC values B7 and A9 come out on my phone as a centred dot and a copyright symbol. I bet others have seen them as other characters. On my favourite terminal program, TeraTerm, you send such characters using the right-alt key in combination with another key. For example, B7 = 80 + 37 (in hex), so 37 is B7 with the sign bit stripped off. From any ascii table, the character whose hex representation id 37 is '7' (the seven character), do you can send B7 (in TeraTerm, when it is set up correctly) by pressing right-alt and the 7 key together (use right-alt like a shift or control key). Similarly A9 is right-alt and ')' (i.e. shift zero on most keyboards). You can't type QPIGS without the CRC characters, or by typing thr two hex characters (e.g. 5 and 1 for Q). If you have a terminal program where you can send everything in hex, then don't forget to add 0D at the end for a carriage return. These things are difficult to explain on a forum, bit once you get the idea, and have the right software tools, it's pretty easy.

You send the actual text string (e.g. "QPIGS") and a carriage return, but before the carriage return you need two CRC characters. If the command is the same (e.g. always QPIGS), then you can hard code the CRC characters. For the actual QPIGS command, the CRC chars are 0xB7 and 0xA9. (So you need a way of sending hex values as characters, some with the sign bit set, as these two do.) If the commands are changing all the time (e.g. you need to set the float voltage to many different values), then you'll need to be able to calculate the required CRC characters. It's only a dozen lines of code and a short table if that's needed. The inverter will respond with a long string of data, as per the protocol document, which you need to parse to get the information that you need. The only other thing you need is a way to open the comms port and set it to 2400 BPS, 8 bits, no parity, one stop bit. it's quite possible to talk to the inverter with a comms program, though it's a pain looking up and sending the CRC characters. To find the CRC characters required, you can use an online calculator such as this one: https://www.lammertbies.nl/comm/info/crc-calculation.html . For that page, use the results from the line "CRC-CCITT (XModem) ".

Interesting. Using a PTC element means it's somewhat able to overcome the problem that as the voltage across a fixed resistor decreases by a factor f, the power dissipated decreases by f². (Since power = V²/R and R is fixed.) So using a few panels is pointless - you get next to no heat. But using a PTC (positive temperature coefficient) element, it can run at say 30% power at 40% of the voltage. (30% of a common 2.4 kW element is 720 W, about what you could get out of three 250 W panels in full sun.) And if you need to boost, you can connect 240 VAC to it, and it will not overheat or draw insane amounts of power. That's because the R (element resistance) is no longer fixed - it depends on the temperature of the element. It's non-linear, like a light bulb. A light bulb will draw lots of power when it's cold, but will quickly draw less power as the filament increases in temperature. A PTC element has this effect, but more so. However, the claim that you can use 1.5 kW to get the same effect as 3.0 kW is simply nonsense. I *might* believe that you can get 6% more power from the element through titanium as through stainless steel, but 6% is a lot less than 100%. Presumably, these elements are designed to be a crude MPPT (maximum power point tracker), designed to work with a particular set of panels. In this case, it seems to be 3 250 W panels in series. It's not clear to me what happens if you add more panels; I think it might work but only give say 70-90% of the maximum power available from the panels (depending on how bad the mismatch is, between the design number of panels and the supplied number of panels). So you can feed it say three panels all day, or boost it with an hour of 240 VAC if necessary. With the three panels, the voltage is low so the element temperature is low, so its resistance is low, so it draws more current from the three panels than a fixed resistor (that could also take 240 VAC) would. If there is shade, then the panel voltage under load goes down even further, but the resistance goes down even further to keep the E² factor from losing most of the available power. In a way, the element adjusts its resistance to get close to the maximum power available from the panels. I hope the above isn't too confusing.

My rule of thumb is don't exceed 2S of 72 cell (200 W) or 3S of 60 cell (250 W) panels with the 4 kW (5 kVA) models. There are lower limits for many of the lower power models (especially the 12 V and 24 V models). This is partly to keep the working voltage of the panels under the ELV limit (120 Vdc); this is an Australian requirement that may not apply in South Africa. But the MPPT voltage range (which is difficult to truly pin down) seems to force that limit anyway. I would certainly not do 4S (all your panels in series), as Voc evenxat room temperature is often over 44 V, more on cild mornings, so that's over 176 V right away. That's very likely to blow up the Solar Charge Controller, and if it didn't is most unlikely to turn on, let alone generate power.

I thought that this might be a question that I could answer with my firmware reading skills. Although I don't have an Infini, and they don't seem to have type approval for grid connection in Australia, I did come across one firmware archive (.rar file) in my travels, and had noted that they use the same software, and the same multi-tasking "OS". However, there the similarities seemed to end. * There are no symbols with the firmware archive that I found. (I don't even know the version number; the files have 20150311 in their names). That makes it hard going, but I could apply some of the symbols from the Axpert firmware reading. * The serial command handling is very different, and initially I could not even find the command handler code. * Handling of the LCD display seems quite different. The LCD display itself is different, of course, but I had hoped not vastly so. * There is a lot of orphan code in there, that doesn't seem to be called from anywhere. So when I tried to find the LCD handling code, I eventually found a reasonable match, only to find that it appears to be uncalled! I've since checked for initialised code pointer arrays (there are two), and that reduced the orphan code proportion, but only slightly. So I still don't know if that code is truly unused, or if I'm missing some important way that a lot of it is called. So far, I'm leaning towards this code as being truly uncalled. Yesterday I decided to give the Infini code another push. Now I have a better idea of how the commands are handled. I have the RS232 protocol manual, but I can't find a single command that matches the protocol. The commands seem to be separated into three groups; the query ones, the parameter updating ones, and a few miscellaneous ones. All he query commands appear to be two letters, or at least unique to the first two letters. There are 21 of these two character commands, though several of them do nothing. The QP command seemed like it might be similar to the Axpert QPIGS (Query Parameter Inquiry General Status) that is also documented in the RS232 protocol manual. But the reply i totally different; instead of spaces separating the numeric responses, there are the capital letters A, B, C... V, W, I, J, K. At least one other command is like that. Also, the RS232 document indicates 22 response fields; the QP command has 27, and the Axpert QPIGS command has 17. So that makes it hard to make progress. I know that several of you are developing monitoring software, some of which include the Infini, so you must know the format for at least a handful of commands. Are you prepared to share this information? Or can you point to a source of documentation that I haven't seen so far? I suppose I could decompile the Voltronic Power Systems monitoring software, but I'd prefer not to have to do that. On the parameter updating side, the handler appears to be using some sort of hashing, though I haven't found the hashing code. The hash table has 45 entries, but as with any hash table, there are unused and duplicate entries. Most of the real functions pointed to by this table end with a call to a function that emits a different to usual acknowledgement: instead of the usual "(ACK" and checksum,. it sends three binary characters in place of the open parenthesis; the three bytes are 0x01 (ASCII SOH, Start Of Heading), 0x05 (ENQ, ENQuiry), and a byte that varies with the command. It always seems to be the third byte (char?) of the sent command. Does this sound familiar to any of the monitoring software developers? So unfortunately, so far I've not been able to help with this question. I would note however that the Axpert battery charging software relies entirely on the charge current falling below a threshold for 50 seconds; the main point of the patched firmware was to also include a voltage threshold. However, this would not help in this case. For this case, it would be better to base the charge termination solely on voltage. As it is, the Infini would be leaving the 500 Ah battery in bulk / absorb all day, which would not be good for the battery. The RS232 document suggests that the battery capacity is reported, but it does not mention a way of changing it. The protocol documents I have seen only seem to document about half of the commands that are available, so not all hope is lost.

I believe that the second entry on this page has what you are looking for: http://www.ostrovni-elektrarny.cz/index.php?page=podpora I have not used or otherwise looked at this.

I think you'll need to borrow or buy a Windows PC for thr upgrade, sadly. Small notebooks are relatively inexpensive, but I agree it's a shame to force people to use Windows. You could use a Virtual Machine on your Mac, but you'd need a Windows license.

I think you might have to have the same AC input connected to both invertets, if paralleled. But I would have expected an error or at least warning if that was the problem.

No way! It's hard enough with a good disassembler and symbols. I use Ida Pro; the Professional Edition has TMS320 C2000 as a processor option, as well as Freescale HCS08 for the SCC firmware. I don't do anything particularly tricky; it's mostly a lot of hard work sorting out offset verses constant, separating the data from instructions, and so on. There is no ASCII in the hex image, so directly interpreting the hex code would be more than tedious, it would be impractical. There is some 160 KiB of flash memory in the DSP, and it's about 80% full. Maybe one day Ida Pro's Hex Rays decompiler will work with all processors; last time I looked, it was limited to just 4 (x86, x64, ARM32, and ARM64). Then there would be less code to wade through. This is answered pretty well above. I think the present limit is 58.4 V for the CV voltage (parameter 26). That could conceivably be increased to say 60.0 V, but I think it would decrease the reliability unless you replaced the capacitors and MOSFETs with higher voltage parts (this has been done before, but it's a lot of work and presumably would shred any warranty, despite improving the inverter's reliability).

I don't know the grid-tie models (InfiniSolar etc) very well, but it's possible that they use a similar technique to determine the hardware's capabilities (read from a general purpose digital input port some number that varies with the hardware capability). It's possible that the SolarPower is asking the inverter what its capabilities are, and adjusting its menus depending on that is read back. That would explain the differences seen. But the various operating modes are quite numerous, so it also seems possible to me that jcn is using an inappropriate mode or other configuration detail.

I may be misunderstanding, but here is how I think this works. WatchPower (and the other BlahPower series) monitor one inverter's serial data stream at a time. (They are also sending commands to the inverters, to have the data come back. You have to ask for the data; it doesn't continually stream out.) So the software can only be aware of one inverter's status changing. For the others, you can use the PEz command to turn on fault recording. This copies to EEPROM the operating mode (battery / line / standby etc)which copies fault information, some of the important GPIO (General Purpose digital Input/Output pin) statuses, and some operating values (e.g. output power and VA, battery voltage, etc.). But this information is a single record; it's not a log as such. So you will get the instantaneous load and inverter power, battery voltage, and so on at the time that FaultInfoCollect() was called. This seems to happen at various parts of the firmware, usually when about to enter fault mode, or an overload was recorded, but I have only checked a few calls. This information only seems to be available via the QFS command (Query Fault Status? It's not documented as far as I know). My guess is that WatchPower remembers all the various machines it has seen, and uses QFS to somehow display the last fault or overload condition, before switching to live data. Or maybe there is a way to interrogate the last fault or overload, I'm not familiar with how it works. But in this scheme, there is no way that WatchPower or any other piece of software can record all the faults and/or mode changes for more than one inverter at a time. Well, unless they were connected to all the inverters through separate serial ports. Three serial ports might be doable. I suppose you might be able to run three copies of WatchPower, and connect them to three inverters, and each one would log all the events from each inverter. But the "enable fault recording" facility is not going to cut it. [ Edit: so this is not a software bug, it's a limitation of the data recording scheme of the inverters. They only have so much RAM and EEPROM. ] My apologies if I'm misunderstanding what you're trying to do, or how it works. As mentioned above, if you had three serial ports (or one serial port and two USB connections perhaps), and three copies of WatchPower or any of the several other monitoring programs could run without interference, then this may be possible Essentially, no. The protocol is fixed. There are several, perhaps half a dozen, many written by members of this forum. I point to three of them here: http://forums.aeva.asn.au/forums/pip4048ms-inverter_topic4332.html (Scroll down to "Monitoring software").