4 hours ago, Gnome said:

changed?

They changed something.... 🙂

 

9 hours ago, Gnome said:

Any idea what they changed?

In the main 71.92 firmware:

QFLAGS has a new flag 'm'/'M', for BMS commanding float.

QPIGS battery capacity comes from BMS if active. Maybe it did that before, and does it differently now.

New DIY BMS? command PBMS, mentioned elsewhere.

New in remote display firmware 02.40:

Massive rework of the BMS code, to handle several new BMS types. Some of them seem to support CAN bus, so the very latest King models (maybe earlier, I don't know) may have CANH and CANL hidden amongst the 6 documented-as-unused pins (other than 3 and 5) on the BMS port (which was an RS-485 only port). It's too early to tell whether the Pylontech support has improved, or just had other BMS support added.

12 hours ago, Gnome said:

Any idea what they changed?

One thing that is (almost) fixed is that the inverter no longer charges at 2A (per inverter) from utility when set to UDC (Utility Don't Charge) in setting 16.

When in Line mode and no PV is available it now correctly sends no charge to the battery.  It is still not quite right when blending PV and Utility: it still charges about 3-4A (in a 3-in-parallel setup), irrespective of settings.

Biggest disappointments:

1 Settings 12 & 13 still make no provision for being percentage based when running in PYL mode.

2. Still no way to override the ridiculously high Charge and Float voltages the the inverter uses when in PYL mode.

So, unless you don't mind overcharging your Pylons the PYL mode is still unusable.

 

18 hours ago, Calvin said:

2. Still no way to override the ridiculously high Charge and Float voltages the the inverter uses when in PYL mode.

But presumably, with BMS control of the maximum charge current, this is not an issue?

Or does the Axpert still overshoot and force the BMS to disconnect on a semi-regular basis?

Or are you mainly worried about longevity of your battery?

4 hours ago, Coulomb said:

But presumably, with BMS control of the maximum charge current, this is not an issue?

Or does the Axpert still overshoot and force the BMS to disconnect on a semi-regular basis?

Or are you mainly worried about longevity of your battery?

Hi @Coulomb,

The answer is a combination of the overshoot and longevity.  I only ran my setup in PYL mode for 10 days, when I first installed it (firmware 71.86 at the time).  During this time I accumulated 86 SOH events over my 8 Pylons, and 3 complete system shutdowns. One of my Pylons was terminally damaged and replaced under warranty.  They were all related to overcharging the Pylons.

I changed to USR, 52.4V bulk, 52V float and built a micro-controller based system that communicates with the batteries and the inverters (a simplified ICC if you like).  In the subsequent 6 months I have had zero shutdowns and zero SOH events.  The batteries always get to 100%.

It seems absolutely bizarre to me that the manufacturers of the inverter and the manufacturers of the batteries could collaborate to produce a "solution" that so effectively cripples/damages their own product. The forums are full of excellent posts explaining why 53.2V is simply too high.  Can they not read / do they not care / do they not even test their own "solutions"?  I am gobsmacked.  They have done all the difficult bits, and then they screw it all up by using the wrong voltages? 

(Apologies for the rant, but I get sooo frustrated...)

6 minutes ago, ThatGuy said:

Just to confirm though: Are the pylon batteries you've got also nominal 51.2V? Do you think your USR/USE settings for pylon would be a good place to start for my Soltaro Lifepo4 as well?

Pylontech is 15 cell, nominal 48V.  I understand that the Soltaro is 16 cell (more normal), so I would up the voltages by 16/15.

My experience has been that it is not too critical - I have successfully run with float from 52.0-52.4, bulk about 0.4V higher.

58 minutes ago, ThatGuy said:

This brings me to my question: Does anyone have access to the original (non-hex) firmware? I'd like to make the changes myself, since it seems like Voltronic are not currently capable. Or can someone advise how to decode the .hex file? I wasn't looking for another control system project, but it looks like that's what I've bought Still, rather do it myself and know it's done properly...

Ah, if only.

My understanding is that people like @Coulomb and @weberhave no access the the source code - they reverse engineer and add their improvements into unused program flash through hooks.  We would all love to have the actual source code so that this can be fixed properly.  The firmware is compiled C2000 C/C++ code - no decompiler exists to my knowledge.  (Some useful insights can be gained by looking at the INV.OUT file.)

I have a similar experience as you (appear to) have: many years of hardware and software developement in all sorts of things including assembler and C/C++.  I have (in my more optimistic moments) dreamt about creating a firmware from scratch - Voltronics programmers are either utterly incompetent or so hampered by backwards compatibility or budget related constraints (or whatever) that I would really like them out of my life.  Problem with high power electronics is that the process of debugging is likely to result in lots of expensive blue smoke...

19 minutes ago, ThatGuy said:

So you're aiming for about 3.4-3.5V / cell? I wonder if the Soltaro actually is 16 cell then... I've tried 55.8v C_v and it still results in faults. My inverter must be overshooting more than I thought. Will try the lower value and hope for the best!

@Youdaposted an excellent article on how to best charge the Pylontechs - most of the principles would apply.  Well worth reading.

https://powerforum.co.za/topic/2322-youdas-off-grid-lab/page/4/ halfway down the page.

Also, I am pretty sure your battery is 16 cell - the 15 cell batteries (Pylontech) can't handle anything like the voltages you are talking about. 

 

 

I have added remote display firmware version 02.49. It supersedes 02.40, and also should be used with main firmware version 71.92.

My apologies to those that recently downloaded 02.40.

23 minutes ago, Coulomb said:

I have added remote display firmware version 02.49. It supersedes 02.40, and also should be used with main firmware version 71.92.

My apologies to those that recently downloaded 02.40.

Thanks for this.

There is a file called "important.txt" that is a bit difficult to read.  Is the procedure for reflashing the same as for main mcu reflashing?

 

6 hours ago, ThatGuy said:

Since I'm stuck on USE battery type for now: What would be the best C_v and Float settings for a Soltaro SOL-R16-5KWH with Nominal Voltage 51.2V (40V - 58.4V range)?

The Soltaro (seems designed in Australia, huh) seems to be 16S (16 cells x 3.2 VPC nominal = 51.2 V nominal). So my suggestion would be the same as for my 16S LFP: 55.2 V absorb/CV, and 53.7 V float.

However, it happens that Soltaro is now supported by King remote display firmware versions 02.40 and 02.49 (the latter uploaded half an hour ago). It might be worth trying it with the special cable, to see if they got it right. It might be that as the maximum charge current ramps down, the overshoots become tolerable, and it all just works. You'll need a special cable; good luck obtaining one, or even the pinout required. Though if it's RS-485, that should not be a problem to work out. Maybe you can get the pinout or even a cable from Soltaro.

4 hours ago, ThatGuy said:

I'm hoping I'll eventually wear them down and someone there will send me the firmware out of shear annoyance

Source code for the firmware are considered the crown jewels. I very much doubt that they would just send it to you. Also, firmware is incredibly complex. I suspect that the annoyances we see are created my far more junior engineers than the engineers that wrote the control and interrupt code.

I'm open to sharing my reverse engineering files with others, but they have to be at a suitable level of competence, or they'll get really frustrated and it will cost me a lot of time. If you know what Ida Pro is, can handle DSP assembler, know the difference between branch on carry and branch if less than, etc., then send me a PM and we can discuss.

On 2020/07/19 at 11:15 PM, Calvin said:

There is a file called "important.txt" that is a bit difficult to read.

It's important for the Voltronic engineers, not for end users. 🙄 How hard would it be to clean up the files before archiving?

Quote

Is the procedure for reflashing the same as for main mcu reflashing?

Remote display firmware re-flashing is the same as for main firmware, IF you are using the RS-232 port and a Windows PC. There is a different reflash tool, which sends different commands, but it's nearly identical as far as the user is concerned. In Axpert terminology, the acronym "MCU" seems to be reserved for remote display firmware (the one that handles the display and also BMS communications).

For main firmware, you can also use a USB On-The-Go cable to a flash drive with just dsp.hex on it. I don't believe that the same will work for the remote display firmware, though I don't know why. I suspect it can be done [ edit August 2020: actually, it can't ], but there may be a wrinkle that the first users didn't realise.

Edited August 24, 20205 yr by Coulomb
Can't update MCU (removable display) firmware with USB OTG cable

7 hours ago, ThatGuy said:

Hi All

 

First time posting here, so hopefully nobody minds me just jumping onto a thread

 

I just bought a new inverter, and unfortunately didn't read all these posts before settling on an Axpert King variant (RCT-AXKING-5K48V)... Shame on me for trusting the supplier

Voltronic sent me new firmware to try out (71.93) after I was having the BMS disconnection issue Coulomb asked about. The 71.93 firmware seems to have partially resolved the PV dropping out completely when you get the Fault 69 from a connected BMS (not always, but definitely better than the 71.90 firmware I had previously). And yes, the Axpert overshoots and still causes a fault 69: My battery regularly goes into fault mode once full. Points 1 and 2 from Calvin are still the same on the new firmware.

 

Unfortunately, having the BMS dynamically alter the Max charge current has introduced another bug, which I've tested on video and sent to the supplier, so hopefully will have a response soon.

Basically what's happening: Battery gets fully charged - BMS limits Max. charge current to 10A (the minimum setting) - Inverter overshoots the 56.5V C_v - BMS freaks out, shuts off charge MOSFETs, sends Fault 69 to Inverter - PV drops to 0W - PV enters continuous cycle of 0W to (MAX)W, and doesn't ever have time to start load tracking before the battery faults again - Battery alternates between Fault 69 and charging, probably once per minute, since the battery has to supply current while the PV W is below the load W - (Now here's the interesting part) IF while the battery is in Fault 69 the current draw out of the battery is more than 10A (DISCHARGE, not CHARGE) then Utility kicks in and doesn't go away! Sometimes disconnecting PV and reconnecting will work (or wait overnight), but usually utility wants to stay on forever or until the inverter is reset.

As far as I can tell, the Charge and Discharge current are being limited to the same value, and while the BMS is in fault mode the inverter can't override the set 10A value, so utility has to kick in to supply anything over (+/-)500W. The easiest way for Voltronic to fix would be to just give us the ability to set C_v and Float voltages ourselves so it doesn't enter fault mode... better yet would be to just have some BASIC error handling, or additional settings around ramp rate and load balancing.

 

This brings me to my question: Does anyone have access to the original (non-hex) firmware? I'd like to make the changes myself, since it seems like Voltronic are not currently capable. Or can someone advise how to decode the .hex file? I wasn't looking for another control system project, but it looks like that's what I've bought Still, rather do it myself and know it's done properly...

 

Also - Since I'm stuck on USE battery type for now: What would be the best C_v and Float settings for a Soltaro SOL-R16-5KWH with Nominal Voltage 51.2V (40V - 58.4V range)? 56.5V seems too high, but what do the experts on this forums recommend to start with? Just want to get to the point where the battery doesn't continuously fault, because it's costing me money while Voltronic decides whether or not they can help!

 

 

 

Hi

Fault 69 under 02.49 has been changed to notification 69 and now won't flash red fault. It is just to let the user know the lithium pack is on 100 percent. 

The Lib protocol is very stable and the Hubble has certified integration with the Lib protocol. It will support up to 16 Hubble batteries with addresses set.

 

I've posted remote display firmware version 02.49 for Axpert Kings in the files section.

This version adds two more BMS options (BAK and LIB) compared to 02.40. It also fixes a few bugs with the Lib Voltronic protocol and works with up to 16 batteries in parallel now.

On 2020/07/19 at 4:51 PM, ThatGuy said:

And yes, the Axpert overshoots and still causes a fault 69:

 

On 2020/07/19 at 4:51 PM, ThatGuy said:

Voltronic sent me new firmware to try out (71.93) after I was having the BMS disconnection issue Coulomb asked about. The 71.93 firmware seems to have partially resolved the PV dropping out completely when you get the Fault 69 from a connected BMS (not always, but definitely better than the 71.90 firmware I had previously). And yes, the Axpert overshoots and still causes a fault 69: My battery regularly goes into fault mode once full.

I believe it's warning 69 now; it just means the BMS said to stop charging altogether. Though perhaps it used to be more annoying that it is now. An inverter warning is mostly just a For Your Information thing, or slightly more serious, like battery is low, best to cut down the loads or light the candles now. A fault causes the inverter to enter fault mode, where the entire machine does very little, perhaps not even charging the battery. If you're lucky, in fault mode the outputs will be powered by AC-in, but never the inverter's DC-AC converter ("inverter proper"). So faults are way more serious than warnings.

Warning 69 could be completely normal (battery is now full). But if the battery turns on its fault light, then that's bad, but it's the battery that has raised a fault, not the inverter. It could well be due to actions by the inverter (i.e. the inverter is to blame, let's not confuse things with the phrase "at fault").

I've had the opportunity to compare main Axpert King firmware version 71.93 against 71.92. The first change I've found is in a function called ChgCurrHighUpdate(), which is one that varies in complexity from model to model. In the King, it's about 5 times more complex than in an Axpert MS, for example. It's called only once, from the Grid Task, when that task receives event 1 from the line zero cross interrupt, signalling that the line period is within bounds (the AC-in frequency is not too crazy). The change is near the start of the function. It's a rare case where the new software is shorter than the older; three tests have been removed.

These test:

• the global flag g_ubBatLTUnderWarning (set by a function called BatLongTimeUnderChk()),
• the result of calling GetFChgStatus() (I believe it returns 1 if the BMS orders float charging of the battery), and
• g_uniSysBMSBatFlag bit 8 (I haven't figured out what that one means as yet).

So in 71.93, there are three conditions that no longer lead to the "old school" code, and instead lead to the "new school" code that examines other BMS flags and executes a spectacular cascade of conditional code. That code ends up setting a local variable (I only know it as "var2" at this stage).

This variable is always compared with g_wPFCPowerMin; if g_PFCPowerMin is less, that becomes the value of var2 (keeps the higher value). PFC refers to the AC to DC converter inique to Kings. At the end of the function, var2 is assigned to gi_dwInvChgLimit. So this is presumably all about an inverter charge current limit.

PV charge current does come into the logic (both old school and new school), but it's one of very many things being checked.

Overall: it's not clear to me whether what problems this change will address. Only because I don't know the code well enough. I thought some of you may enjoy a taste of the detail I often deal with.

I'm yet to compare the rest of the firmware, to see if there were other changes. [ Edit: no other changes were detected, by checking function sizes. ]

Edited August 24, 20205 yr by Coulomb

8 hours ago, Coulomb said:

It also fixes a few bugs with the Lib Voltronic protocol

Any elaboration on this Coulomb?

Edited July 20, 20205 yr by Gnome

I have upgraded from 71.92 to 71.93 (also remote unit to 2.49) and I seem to have a new problem: The system stays in bulk charging mode and does not lower the voltage to float at all (several hours now). (Note that I am using Pylons but in USR mode).  QPIGS confirms that the system is not in Float mode.

@Coulomb did you perhaps see anything that might explain this?  Anyone else see this behaviour?

26 minutes ago, Gnome said:

Any elaboration on this Coulomb?

I was just passing on information from @HubbleLithium. I wasn't even aware at that point that the Hubble batteries use the LIB protocol.

15 minutes ago, Calvin said:

The system stays in bulk charging mode and does not lower the voltage to float at all (several hours now).

Is the battery charge current decreasing?

Do you perhaps have a very low value in setting 02 (maximum total charge current)?

If you're confident that it's the new firmware, you could perhaps prove it by flashing back to main firmware version 71.92.

4 minutes ago, Coulomb said:

I was just passing on information from @HubbleLithium. I wasn't even aware at that point that the Hubble batteries use the LIB protocol.

Oh I see, this is from another thread.  The "lib" being the new method to communicate with the inverter using the BMC port

12 minutes ago, Gnome said:

The "lib" being the new method to communicate with the inverter using the BMC port

One of many new methods. I have never heard of the LIB protocol before, or most of the new batteries supported, such as Weco.

17 minutes ago, Coulomb said:

Is the battery charge current decreasing?

Do you perhaps have a very low value in setting 02 (maximum total charge current)?

If you're confident that it's the new firmware, you could perhaps prove it by flashing back to main firmware version 71.92.

No, battery current was constant (approx 0 - battery was full)

Setting 02 allows 130A over 3 inverters.

I had made some changes to 12&13 - pushed them up to  54 & 55V (I always want Line mode when Utility is connected - I control that with an external contactor).

Anyway, I reverted them to previous settings (51 & 52V) and Float mode returned.

Went back to 54/55V and float mode disappeared.

Have now gone back to 51/52V and still no float mode.

So no, I am not confident about anything.  Still investigating - will revert when clearer.

 If necessary will revert to 71.92, but flashing 3 inverters is a bit of a pain...

 

12 minutes ago, ThatGuy said:

Hi Calvin

 

Do you have the comms cable connected from your battery to the inverters? I know you said you're in USE mode, but I found with mine on 71.93 firmware that even when in USE, as soon as I plugged a BMS into the inverter the Float and C_v values reverted to the "high" values that the BMS sets by default (in my case 56.5v). The only way to successfully change it back was to disconnect the load, set USE mode, power down inverter, power back up, and then change float and C_v. If I plugged the cable in, the values immediately reverted again, even though in USE mode.

Thanks for the thought, but no, I do not have the BMS cable plugged in.

The upgrade to 71.93 appears to have been a red herring: the problem seems to be related to the fact that I had changed the "Back to grid" to a value higher than either bulk or float setting.  For whatever reason, that forces the inverter to be in bulk charge mode.  I am not sure if that would have been the case with 71.92 - I never tried such a high setting for Back-to-grid while using it.

It is not too big a deal - I should be able to achieve the same result (keeping the inverter in Utility source) by having only the "Back to Battery" setting very high.  The gap between the settings is hysteresis and the inverter should only switch to Battery source when it reaches the (unreachable) Back-to-battery voltage setting.

5 hours ago, ThatGuy said:

Makes sense, you can only switch in at zero crossing... at least I hope they know that

I can't speak to the other models but the King frequency is synchronized to the input frequency.  So it can theoretically switch at any point.  It is a fairly common feature on even very old UPS.  I can't see any other reason why they would synchronize the inverter output to the input frequency

Edited July 20, 20205 yr by Gnome

On 2020/07/21 at 7:41 AM, Gnome said:

I can't see any other reason why they would synchronize the inverter output to the input frequency

They still attempt to switch at a time that minimises the current when the relay contact opens or closes. There is a special tricky function to handle time critical relay switchings.

The function that updates charge current isn't time critical; grid task event 1 comes from the line cross interrupt merely because that's where the period is measured.

Edited November 8, 20241 yr by Coulomb