PIP-4048MS inverter

Introductions, general chit chat and off-topic banter.
dakoal
Noobie
Posts: 5
Joined: Sat, 08 Jul 2017, 21:56
Real Name: Bernhard STrunz
Location: Europe/Austria

Re: PIP-4048MS inverter

Post by dakoal » Thu, 12 Oct 2017, 03:04

That's great.

THX

User avatar
weber
Site Admin
Posts: 2252
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Re: PIP-4048MS inverter

Post by weber » Sat, 14 Oct 2017, 11:52

Hacking the PIP/Axpert firmware to implement a dynamic charge current limit, has turned out to be more difficult than we hoped, but still not as difficult as it might have been. We still believe we can do it without having to patch the SCC firmware. I'll try to explain what we're attempting to do. I must warn you that the following may only be of interest to those with a computer or communications background, but I'll do my best to make it clear to anyone sufficiently interested to put in the work of following it.

Unlike lead-acid cells, lithium-ion cells cannot tolerate overcharging. So we want to be able to send a new maximum current limit to the PIP every few seconds, so that a lithium ion battery management system (BMS) can throttle back the charge current, based on the voltage of the highest cell, and eventually reduce the current to that which the BMS can bypass around the cells which are already full, thereby allowing the other cells to catch up, without damaging the already full cells.

Here's a diagram showing the normal pattern of communication between the PIP/Axpert's main processor, sometimes referred to as "the DSP" (digital signal processor) (a 16 bit TMS320C28x), and the secondary processor in its built-in solar charge controller, "the SCC" (an 8 bit HCS08x).
DSP			SCC
	--RST----->		reset (command)
	<----(ACK--		acknowledge (response)
	<-----QRI--		query rating information (command)
	--(RI...-->		rating information (contains settings) (response)
	<-----QGS--		query general status (command)
	--(GS...-->		general status (contains measurements) (response)
	<-----QGS--
	--(GS...-->
	<-----QGS--		this repeats indefinitely 
	--(GS...-->		until the DSP sends another RST command
	...
In simplified terms: The DSP sends a reset command. The SCC acknowledges it. The SCC then requests the "rating information". The DSP responds with an "(RI" packet, or message, containing the various settings such as float voltage, absorb voltage and maximum charge current. The SCC then repeatedly requests (about once a second) the "general status". And each time, the DSP responds with a "(GS" packet containing the latest measurements of the battery voltage and current, and the stage of charging (off, bulk/absorb, or float). I have omitted some other message types, sent once after a reset, because they are not relevant to our story. For more detail see viewtopic.php?p=65988#p65988

The DSP has two serial ports. The one that it uses to communicate with the SCC, as above, and the one it uses to communicate with an external computer (in our case the BMS master unit), using the protocol described here:
uploads/293/HS_MS_MSX_RS232_Protocol_20 ... pgrade.pdf
You will notice that the protocol used between the DSP and the SCC is very similar to that used between the DSP and an external computer. An external computer can request the "rating information" with a QPIRI command, and the "general status" with a QPIGS command. In both cases (SCC and external computer) every packet (command or response) must end with two bytes of cyclic-redundancy-check (CRC) that allows checking for errors, and a carriage return. That's what makes it a "packet" rather than merely a message. And in both cases a response always begins with a left parenthesis "(", while a command does not. There is no matching right parenthesis.

When an external computer sends one of the commands that change the "rating information", such as PBFT (float voltage), PCVV (absorb voltage) or MNCHGC (maximum charge current), then the DSP's present way of informing the SCC of such a change is to send a RST command to the SCC, which causes the SCC to request the rating information again. Unfortunately, a RST command has the horrible side-effect of causing the SCC to stop charging for about 40 seconds, apparently due to to restarting its maximum power point tracking sweep from scratch. This is completely intolerable if we want to send a new maximum charge current every few seconds.

So we are attempting to change the operation of the MNCHGC command (which we pronounce as the "munch" command), so that instead of sending a RST command to the SCC, it just sends an "(RI" packet containing the new max current, without having been asked for it.

There is no a priori reason why the SCC should take any notice of an "(RI" packet that it didn't request, but fortunately, the SCC code is written in such a way that it does take notice. However, we have implemented the above, and it doesn't work. Sure, the SCC no longer does that horrible reset, with its 40 seconds of no charge, but it doesn't change its charge current either.

Figuring out the reason for this, was a scientific adventure spanning several days. It involved repeated cycles of forming hypotheses and testing them, by (a) discussing them with each other (mostly by email), (b) mentally simulating the existing code in both the DSP and SCC, and (c) performing experiments after loading patched code into a PIP and crossing our fingers that there would not be a loud bang, or a whimper.

There was also one very important case of (d) a lucky accident, where coulomb put a wrong number into the code and sent the "(RI" packet to the external computer instead of to the SCC, and we got to see that it "collided" with an "(ACK" packet that was correctly being sent to the external computer in response to the MNCHGC command! We received "(RCK" followed by the normal CRC and carriage return of the "(ACK" packet, followed by the last few numbers of the "(RI" packet and another CRC and carriage return.

When we fixed this bug, and it still didn't work, and while coulomb was recovering from his hard disk crash, I wondered whether the "(RI" packet might now be colliding with the "(GS" packets that are repeatedly being sent to the SCC. This was confirmed by experiments where, by sending 20 MNCHGC commands at random intervals about a second apart, causing 20 "(RI" packets to be sent to the SCC, the SCC would change to a new current limit, although it wasn't always the current limit I had specified in the MNCHGC command. Presumably, by sending enough times, eventually one "(RI" packet got through, but sometimes with a corrupted maximum current value. But apparently with a CRC that said the message was valid! :o

Some reading of the disassembled code, painstakingly commented over many months by coulomb, showed that the reason for the collisions was that the out-going packet buffer, a region of memory in the DSP, was not implemented as the usual circular buffer which would have allowed two or more messages to be queued up, one after the other, but instead overwrote each message with the next. It assumed that there was a long enough delay between messages, that a message would have been completely transmitted at 240 characters per second, before the next packet overwrote it. But we could not guarantee such a delay between our "(RI" packet and the preceding "(GS" packet.

But I reasoned that the original "RST" packet had exactly the same problem, of possible collision with a preceding "(GS" packet. So all we had to do was figure out how the designers of the DSP firmware avoided such collisions in the case of the "RST" packet, and apply the same method to our unrequested "(RI" packet. Our various hypotheses about how they did that, turned out to be wrong, until eventually coulomb showed that in fact they did not avoid collisions when sending RST packets. They just kept on sending the damn things until one finally got through! They would know one had made it thru when an ACK was finally returned. So it was like this.
DSP			SCC
	--(GS...\		crash
	--RST---/
	--(GS...\		crash
	--RST---/
	--RST---\		crash
	--(GS.../
	--RST----->		reset (command)
	<----(ACK--		acknowledge (response)
	<-----QRI--		query rating information (command)
	--(RI...-->		rating information (response)
	<-----QGS--		query general status (command)
	--(GS...-->		general status (response)
	...
:o Extraordinary! There was no way coulomb and I were going to implement something that awful for our unrequested "(RI" packet. For one thing, it is a much larger packet, due to all its settings numbers, and it would be sent far more often. And for another thing, coulomb and I have some pride in our workmanship. :geek: :ugeek:

So yesterday we got together for another 12 hour intensive brainstorming and coding session, fueled by tea and pizza, and we believe we have something that has a good chance of working. Unfortunately, it was out of the question to implement a proper circular buffer, as it would have required patching every command in the system, So we just patched the sending of the "(RI" packet so that it would check if there was another packet in the buffer, still being sent, and if so, disable sending temporarily while it added itself after the end of the existing packet, instead of overwriting it, and fooled the sending code into sending them both as if they were a single packet, except it had to ensure that the second CRC was calculated only for the second packet, not the combination of the two. This is so complicated that coulomb will first check it in a TMS320 simulator, before we are brave enough to test it on the real thing. :)
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

andys
Groupie
Posts: 62
Joined: Wed, 20 Jul 2016, 19:44
Real Name: Andrew Snow
Location: Sydney

Re: PIP-4048MS inverter

Post by andys » Sat, 14 Oct 2017, 14:12

So if you get it working, we'll be dynamically setting the voltage, right? Not the current.

Which makes sense: when we want to stop charging, we want the current to be 0A (at float voltage), not 2A (the minimum current you are able to specify).

User avatar
weber
Site Admin
Posts: 2252
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Re: PIP-4048MS inverter

Post by weber » Sat, 14 Oct 2017, 14:40

Hi andys. I'm afraid we really are working on dynamically setting the current, not the voltage. But it will not be limited to the values you can presently set. You will be able to set it to any number of (whole) amps from 0 to 140 inclusive.

Our BMS has a bypass current of 0.65 amps, so in this way of operating, when the first cell becomes full and we are balancing the cells, we would be telling the PIP to charge at 1 amp for about 65% of the time, and 0 amps for the rest of the time, so the average would be 0.65 amps. So about every third command would be MNCHGC0500 while the others would be MNCHGC0501.

This would happen automatically due to the operation of the PI control loop we would be running in the BMS master, to keep the voltage of the highest cell constant, until all the cells are full. During that time, it wouldn't matter what the battery voltage setting of the PIP is, provided it is higher than the actual battery voltage.

We already use this method successfully in charging an electric vehicle with 208 LFP cells in series. However this is done with a TCCharger that already had dynamic current control, not a PIP.
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

andys
Groupie
Posts: 62
Joined: Wed, 20 Jul 2016, 19:44
Real Name: Andrew Snow
Location: Sydney

Re: PIP-4048MS inverter

Post by andys » Sat, 14 Oct 2017, 15:20

Thanks for the explanation weber. I can still work with that, but if it stops receiving commands (something broken or an emergency), could it default to 0A instead of 2A?

User avatar
weber
Site Admin
Posts: 2252
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Re: PIP-4048MS inverter

Post by weber » Sat, 14 Oct 2017, 16:36

You make a good point -- that you might well want it to go to zero current if communication was lost -- and indeed that's what the TCCharger does. But up until now, we have been writing the PIP patches so that it falls back to whatever is set in the EEPROM, in other words, whatever was last set using either the LCD and its buttons, or a standard MNCHGC command (i.e. one whose argument has not had 500 added to it). I thought we were going with hennejg's suggestion in that regard, but in fact he wrote:
hennejg wrote:For robustness reasons [they] would remain in effect only for a few seconds unless refreshed continuously which would let the charger fall back to safe defaults [if] the charger/BMS communication was lost.
And the EEPROM value is not necessarily a "safe default". In fact the lowest value of maximum total charge current that can be set with the LCD or a standard MNCHGC command is 10 amps. You are probably thinking of the maximum utility charge current setting (or the MUCHGC command) when you mention 2 amps. We pronounce that as the "much" command as opposed to the "munch" command. You can think of the N as standing for "entire", i.e. solar plus utility, as opposed to the U for utility alone. We're not planning to fiddle with the "much" command at all.

So we'll give your suggestion some serious thought. If anyone has any ideas about when it should go to zero current versus when to go to the EEPROM value, or whether we should try to allow the EEPROM value to be set to zero, please let us know.
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

andys
Groupie
Posts: 62
Joined: Wed, 20 Jul 2016, 19:44
Real Name: Andrew Snow
Location: Sydney

Re: PIP-4048MS inverter

Post by andys » Sun, 15 Oct 2017, 05:46

Zero would be great. I always thought it was a serious deficiency that they don't allow you to simply stop charging completely (except by swizzling voltages).

(There really should be a physical input terminal that disables all charging)

andys
Groupie
Posts: 62
Joined: Wed, 20 Jul 2016, 19:44
Real Name: Andrew Snow
Location: Sydney

Re: PIP-4048MS inverter

Post by andys » Wed, 18 Oct 2017, 08:47

Does anyone know if the remote on/off inputs can be "daisy chained" ? Can I switch on/off two or more inverters at the same time by connecting their NC/NO contacts in parallel or series and a single switch?

paulvk
Groupie
Posts: 126
Joined: Fri, 23 Oct 2015, 23:45
Real Name: Paul
Location: Sydney

Re: PIP-4048MS inverter

Post by paulvk » Wed, 18 Oct 2017, 12:02

I would use a 4 pole switch and 8 wire cat5 cable you can do 4 that way.

andys
Groupie
Posts: 62
Joined: Wed, 20 Jul 2016, 19:44
Real Name: Andrew Snow
Location: Sydney

Re: PIP-4048MS inverter

Post by andys » Wed, 18 Oct 2017, 12:08

Sure - but I actually wanted it to be computer controlled and 4-way or 4x relays is overkill unless absolutely necessary :)

paulvk
Groupie
Posts: 126
Joined: Fri, 23 Oct 2015, 23:45
Real Name: Paul
Location: Sydney

Re: PIP-4048MS inverter

Post by paulvk » Wed, 18 Oct 2017, 12:27

Computer control easy I can do that already , you only need a relay with 4 poles less than $5.
Do you want control with a web page so any device can be used eg smart phone?

andys
Groupie
Posts: 62
Joined: Wed, 20 Jul 2016, 19:44
Real Name: Andrew Snow
Location: Sydney

Re: PIP-4048MS inverter

Post by andys » Wed, 18 Oct 2017, 13:34

paulvk wrote:
Wed, 18 Oct 2017, 12:27
Computer control easy I can do that already , you only need a relay with 4 poles less than $5.
Do you want control with a web page so any device can be used eg smart phone?
No, I've got a little embedded computer which will power up extra units depending on time of day, load, and battery %soc .. do you have a part number for a cheap 4P relay?

KG666
Noobie
Posts: 8
Joined: Fri, 30 Dec 2016, 02:16
Real Name: kristof
Location: belgium
Contact:

Re: PIP-4048MS inverter

Post by KG666 » Tue, 24 Oct 2017, 01:53

hoi,

i read this in this 70pages lol:
SOL mode is for on-grid use as a solar UPS. It will not use the battery at all, keeping it fully charged, until you lose both solar and grid at the same time. It will reduce but not minimise grid usage. It will maximise the life of a lead-acid battery. Not so good for Lithium.

SbU mode is for on-grid use where you want to minimise grid usage. It will use the battery whenever solar is not available. It will only use the grid when the battery gets low.
BUT has someone installed a, parallel system?
if yes, i understand you have to choose SOL but i dont want that! i tested it in single mode and when no solar, it goes to battery, so where is use of that? (like i read in qoute..)

can you tell me if you still can make it to use SBU?

my situation will be :

pip4048msd 1 = connected to AC input and AC output and 2x3330wp solar
pip4048msd 2 = NOT connected to AC output and AC input and 2x2664wp

pip1 = SBU
so i make it short= pip1 is master with everything and pip2 is slave with only solar

grtz kristof

paulvk
Groupie
Posts: 126
Joined: Fri, 23 Oct 2015, 23:45
Real Name: Paul
Location: Sydney

Re: PIP-4048MS inverter

Post by paulvk » Fri, 27 Oct 2017, 07:19

If you just want more solar charging there is the option of two solar chargers in the new PIP series or you can do the same as I have and get another external charger , I have the eSmart 3 130volt MPPT charger working with my PIPs it provides 40 amps and is working well with the inverters , it is even providing a fix for the tendency of the solar charger in the PIPs to cut off early from bulk charge by continuing the bulk charge , they can also be paralleled for more amps

User avatar
weber
Site Admin
Posts: 2252
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Re: PIP-4048MS inverter

Post by weber » Fri, 27 Oct 2017, 08:25

paulvk wrote:
Fri, 27 Oct 2017, 07:19
I have the eSmart 3 130volt MPPT charger working with my PIPs ... it is even providing a fix for the tendency of the solar charger in the PIPs to cut off early from bulk charge ...
Just in case anyone doesn't know, our patched firmware for the PIP also fixes that problem.
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

paulvk
Groupie
Posts: 126
Joined: Fri, 23 Oct 2015, 23:45
Real Name: Paul
Location: Sydney

Re: PIP-4048MS inverter

Post by paulvk » Fri, 27 Oct 2017, 13:56

weber wrote:
Fri, 27 Oct 2017, 08:25

Just in case anyone doesn't know, our patched firmware for the PIP also fixes that problem.
Not totally it is indeed much better, but it will cut off if a large load is applied to the inverter for a period of time thus spending too short a time in bulk , whereas the eSmart remembers its not been at bulk volts for long enough and picks up the ball and finishes the job. My battery performance has been better since adding the eSmart charger. I have two eSmart MPPT chargers the older version with two digit LED display running on my small one inverter set up (had to modify it to work with 3 x 24v as it cut off at 100v PV input) and the new one with LCD display on the large two inverter system this comes in a 130v PV input version

T1 Terry
Senior Member
Posts: 584
Joined: Thu, 30 Sep 2010, 20:11
Real Name: Terry Covill
Location: Mannum SA

Re: PIP-4048MS inverter

Post by T1 Terry » Sat, 28 Oct 2017, 08:31

Are there updates for the 4000w 24v unit that stop the fan running 24/7? I've turned the fan over so it now blows up and that has greatly improved the noise and cooling, but the fan running 24/7 just wastes battery storage that isn't really necessary.

If this should have its own thread, please move it so it doesn't distract from this 48v version thread

T1 Terry
Green but want to learn

vulcanescu35
Noobie
Posts: 2
Joined: Mon, 30 Oct 2017, 17:09
Real Name: Cristi

Re: PIP-4048MS inverter

Post by vulcanescu35 » Mon, 30 Oct 2017, 18:14

hello guys,

i am new to the forum and i have found here a great documentation for MPP, i own a PIP 4048 MSD and i wanted to know if the modified firmware is suitable and for this version because the bulk current with the original firmware configuration is just some seconds,

thnak you in advance for you answers,

User avatar
weber
Site Admin
Posts: 2252
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Re: PIP-4048MS inverter

Post by weber » Mon, 30 Oct 2017, 19:55

vulcanescu35 wrote:
Mon, 30 Oct 2017, 18:14
i own a PIP 4048 MSD and i wanted to know if the modified firmware is suitable and for this version because the bulk current with the original firmware configuration is just some seconds
Hi vulcanescu35. Thanks for your kind words. Sadly no, we do not have access to a firmware update file for the MSD or MST models, so we are not able to patch them. Can you please tell us what the "U1" firmware revision number is for your PIP?
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

vulcanescu35
Noobie
Posts: 2
Joined: Mon, 30 Oct 2017, 17:09
Real Name: Cristi

Re: PIP-4048MS inverter

Post by vulcanescu35 » Tue, 31 Oct 2017, 00:23

weber wrote:
Mon, 30 Oct 2017, 19:55
vulcanescu35 wrote:
Mon, 30 Oct 2017, 18:14
i own a PIP 4048 MSD and i wanted to know if the modified firmware is suitable and for this version because the bulk current with the original firmware configuration is just some seconds
Hi vulcanescu35. Thanks for your kind words. Sadly no, we do not have access to a firmware update file for the MSD or MST models, so we are not able to patch them. Can you please tell us what the "U1" firmware revision number is for your PIP?
hi again,

Yes, of course,

MAIN CPU Vers: 75.20
SCC1CPU :1.02
SCC2CPU: 1.02

regards,

frnandu
Noobie
Posts: 1
Joined: Wed, 01 Nov 2017, 23:02

Re: PIP-4048MS inverter

Post by frnandu » Wed, 01 Nov 2017, 23:07

I've been playing with my PIP, trying to charge from AC (utility), I have no solar connected to it at this moment.
I have to change not only "Charger source Priority" to a setting that includes Utility, but also I have to change "Output Source Priority" to Utility otherwise it will not charge the battery from AC. That makes some kind of sence, because I guess it isn't able to do simultaneously charging and discharging battery. Which means that either the DC->AC is working or the AC->DC is. Battery mode or Line mode, one or the other, both it's not possible.
My problem is that when I decide that it's enough charge from AC and want to change back to battery, changing "Output Source Priority" to SBU doesn't make the PIP change back to Battery Mode, it stays in Line mode. Only after turning power button off and on will it come back to Battery mode.
Did you guys notice this same behaviour?
Is there any workaround?
I'de like to remotely/programatically be able to charge from AC if the battery is below certain SOC during night cheap tariff.

User avatar
weber
Site Admin
Posts: 2252
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Re: PIP-4048MS inverter

Post by weber » Thu, 02 Nov 2017, 06:08

Hi Frnandu,

1. When you change output source priority (parameter 01) from UTI to SBU (or SOL), the PIP will only change back to battery mode when the battery voltage has been higher than or equal to the back-to-battery setting (parameter 13) for 10 minutes. In the next release of our patched firmware (72.70c) we will reduce that time to 1 minute.
2. Setting charger source priority (parameter 16) to OSO (only solar) will stop utility charging while still in line mode. The serial command is PCP03. You are correct that utility charging can never occur in battery mode because the utility charger uses the same hardware as the inverter, operating in the reverse direction.
3. By setting the back-to-utility voltage (parameter 12) appropriately, you can leave the output source priority set to SBU, and then you only need to send PCP02 at the start of the cheap off-peak tariff and PCP03 at its end. I am currently doing this.
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

User avatar
weber
Site Admin
Posts: 2252
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Re: PIP-4048MS inverter

Post by weber » Tue, 07 Nov 2017, 11:25

Beta-versions of Patched Firmware 72.70c with Dynamic Current Control

[Edit: Superceded by version 72.70c, but the following is the only description of these bug-fixes and features, which are retained in later versions.]

After 5 weeks, and about 18 cycles of analysis, design, programming and testing, Coulomb and I are finally making the result of our latest PIP-patching effort available for those brave and kind souls who are willing and able to test it. We are of course running it in our own systems, but these are of limited variety, both being single-inverter systems with LFP (Lithium Ferrous Phosphate) batteries.

The new version has all the features of version 72.70b, plus the following additional features:

1. We have fixed the bug found by paulvk where slave inverters in a parallel or 3-phase setup would still count time spent well below the absorb voltage setting (parameter 26), e.g. due to heavy loads, as if it was absorb time, after having once been within 0.5 V of the absorb voltage setting.

2. When the inverter switches to line mode (utility mode), due to the battery voltage falling below the back-to-utility setting (parameter 12), there is a minimum time that it must stay in line mode, even though the battery voltage may reach the back-to-battery setting (parameter 13) sooner. We have reduced this time from 10 minutes to 2 minutes.

3. We have improved the accuracy of the battery charge and discharge current readings, particularly for low currents, as displayed on the LCD, and as given in response to the QPIGS and QPGS serial commands. There is more explanation of this in the Dynamic Current Control manual linked below.

4. We have made it work with SCC firmware revisions from 1.24 to 4.10 (and probably later), irrespective of the setting of maximum total charge current (parameter 02), so there is no longer any reason to upgrade your SCC firmware, which is a difficult and dangerous process.

5. While the version number shown on the LCD, for the LFP release version, will still begin with "LF", the version number for the non-LFP release version will no longer begin with "Pb". It will instead begin with "LC", which stands for both Lead-aCid and Lithium Cobalt-blends (LCO, NMC, NCM, NCA, LTO). But for these beta versions, a "B" has been substituted for the "L" in both cases.

6. And finally, for lithium battery users, what this version is really all about: We have succeeded in implementing (drum roll please) Dynamic Current Control. :) You can read all about this in its own (3 page) manual linked below. This manual is also included in the zip files linked below.

Dynamic current control.txt
(9.08 KiB) Downloaded 16 times
[Edit: Updated to release version]

Here are the zip files with all the software you need, to reflash your PIP-4048MS or Axpert MKS 5K-48 with these beta-test versions, and to revert to standard 72.70 firmware if required. The instructions are the same as for version 72.70b except that upgrading the SCC firmware is no longer recommended.

[Edit: You can now download the release versions here.]

For lithium ferrous phosphate (LFP) (16S)
dsp_BF1_72.70c.zip [beta version no longer available]


For lithium cobalt-blends (LCO, NMC, NCM, NCA) (14S), lithium titanate (LTO) (21S) and lead acid (24S)
dsp_BC1_72.70c.zip [beta version no longer available]

Please let us know if you have used it for a week with no problems.
Any problems you find should be reported to me via this forum's private message facility. Please give as much detail as possible to enable us to reproduce the problem, including the versions of both the main and SCC (u2) firmware as displayed on the LCD, and the values of parameters 01 02 11 12 13 16 26 27 29 31 32 and any others you think might be relevant. Also the type and capacity of your battery and PV arrays and the number of inverters and their configuration. Thanks.

[Edit: Changed feature 2 description from: about 1 minute after above param 13, to: a minimum of 2 minutes after below param 12.]
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

JvdSpoel
Noobie
Posts: 5
Joined: Sun, 19 Feb 2017, 04:08
Real Name: Johan
Location: Male

Patched Firmware 72.70c

Post by JvdSpoel » Wed, 08 Nov 2017, 03:34

Hi, I am running 3 x inverters in parallel. They are currently running 72:70B - (4:10) Running on lead acid batteries. Happy to test new version. I assume it is the dsp_bc1?
Also running Inverter control Centre on my system. Anything I need to check before upgrading.

However what will be the main benefit for doing the upgrade? My system runs in SOL mode.
Regards,
Johan
JPS

User avatar
weber
Site Admin
Posts: 2252
Joined: Fri, 23 Jan 2009, 17:27
Real Name: Dave Keenan
Location: Brisbane
Contact:

Re: Patched Firmware 72.70c

Post by weber » Wed, 08 Nov 2017, 07:59

JvdSpoel wrote:
Wed, 08 Nov 2017, 03:34
Hi, I am running 3 x inverters in parallel. They are currently running 72:70B - (4:10) Running on lead acid batteries. Happy to test new version. I assume it is the dsp_bc1?
Also running Inverter control Centre on my system. Anything I need to check before upgrading.

However what will be the main benefit for doing the upgrade? My system runs in SOL mode.
Regards,
Johan
Thanks Johan, for being willing to test. Yes, it is the dsp_BC1 for lead acid. Since you are already running 72.70b and 4.10, there is nothing you need to check before upgrading. The main benefit for you will be the bug-fix for the absorb time for the slaves, assuming your slave inverters have PV arrays attached.

After upgrading, you should re-set parameter 02 on all inverters. It will have been reduced by 10 amps.

For the benefit of other readers with similar questions: Counting backwards through the new features, as listed in my previous post:

6. Lead acid users will not benefit from the new dynamic current control feature. That requires a battery management system (BMS) to send commands to the serial input of one of the inverters. BMS are typically only used with lithium ion batteries. The BMS will need to have its software modified, or perhaps have an add-on controller, such as an Arduino, programmed to send the commands.

5. Changing the battery type code in the version number from "Pb" to "LC" (temporarily "BC" for the beta version) is of no benefit to anyone. It's just something we needed to tell you about. But maybe it saves some users of Lithium Cobalt-blend batteries having to explain why their version number has lead (Pb) in it. While Lead aCid users can now explain that the authors of the patches apparently can't spell, since they seem to think "acid" starts with a "C". ;-)

4. Since you're running 4.10 in your SCC, this will be of no benefit. But those running earlier versions will benefit from being able to set parameter 02 higher than 60 amps, for when solar and AC charging are happening at the same time.

3. Everyone will benefit from the greater accuracy of charge and discharge current reporting. It's refreshing to have some honesty from the inverter for a change. ;-) e.g. When operating with no load, it now admits that it is still drawing 1 amp from the battery.

2. On-grid users may benefit from not always charging the battery from the AC input for a minimum of 10 minutes despite having reached the back-to-battery voltage much sooner.

1. Users of parallel or 3-phase systems will benefit from fixing the absorb-time bug for slaves with PV arrays.
Last edited by weber on Wed, 06 Dec 2017, 21:03, edited 1 time in total.
Reason: Changed "despite having reached the back-to-utility voltage much sooner" to "despite having reached the back-to-battery voltage much sooner".
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

Post Reply