PIP-4048MS and PIP-5048MS inverters

non-EV Solar, Wind and other renewable power sources
non-EV batteries and other energy storage stuff
Forum rules
Important!
This forum is for discussion of Non-EV matters.
andys
Groupie
Posts: 75
Joined: Wed, 20 Jul 2016, 19:44
Real Name: Andrew Snow
Location: Sydney

Re: PIP-4048MS inverter

Post by andys » Sat, 07 Oct 2017, 06:06

By the way weber/coulomb, I've been meaning to ask: Did you ever come across code that governs AC charging? Specifically resetting charge back to zero for another "sweep" all the time. It really seems like a bug, since it happens even when charging off mains and not a generator.

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

Re: PIP-4048MS inverter

Post by weber » Sat, 07 Oct 2017, 22:38

I spent the day putting the patches into the hex file (at 10 new locations) and documenting them. Then I reflashed my PIP with the new hex file and confirmed that we had, at least, not broken the standard behaviour, including the MNCHGC command. Hoorah!

I also confirmed that the new dynamic current limit values work with AC charging. Awesome! :D

But there are some bugs. It fails to time out and go back to the EEPROM value, and it doesn't yet work with solar charging. But we think we know how to fix these.
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

dinu_tiberiu_george
Noobie
Posts: 7
Joined: Sun, 08 Oct 2017, 01:11
Real Name: Dinu Tiberiu George

Re: PIP-4048MS inverter

Post by dinu_tiberiu_george » Sun, 08 Oct 2017, 01:22

Hello,
sorry for my bad english..
I have an photovoltaic off-grid system with 2*5048ms inverter's in parallel. I have an generator for back-up. I don't know how to use the dry contact of the inverter's to automatically start the generator when the battery get's low. Can you help me?

User avatar
coulomb
Site Admin
Posts: 3713
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: PIP-4048MS inverter

Post by coulomb » Sun, 08 Oct 2017, 07:54

andys wrote:
Sat, 07 Oct 2017, 06:06
Did you ever come across code that governs AC charging?
I've concentrated on solar charging, so I've not specifically sought out details of the AC charging. However AC charging seems to be controlled at the high level (e.g. float versus bulk.absorb versus off mode) largely by the same code.
Specifically resetting charge back to zero for another "sweep" all the time. It really seems like a bug, since it happens even when charging off mains and not a generator.
I'm not aware of this behaviour, except with generators, and this all from other posters. Can you give details about when this happens?

Could you have poor mains quality? Perhaps third and fifth harmonic distortion, and/or particularly high or low voltage or transients caused by a large nearby load?

Setting 03 (AC input voltage range) seems to need to be set to APL in many cases, relaxing its standards for mains quality. But this usually seems to be an issue for generators, not utility mains. If your inverter-charger is doing this on mains, and there is nothing different about your mains, then perhaps there is something wrong with the filter circuitry.

The resetting of charging at a particular charge current (usually) when running on a generator is still a mystery to me. I have not found the time to investigate it as yet.
Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
1.4 kW solar with 1.2 kW Latronics inverter and FIT.
160 W solar, 2.5 kWh 24 V battery for lights.
Patching PIP-4048/5048 inverter-chargers.

User avatar
coulomb
Site Admin
Posts: 3713
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: PIP-4048MS inverter

Post by coulomb » Sun, 08 Oct 2017, 08:08

dinu_tiberiu_george wrote:
Sun, 08 Oct 2017, 01:22
I have an photovoltaic off-grid system with 2*5048ms inverter's in parallel.
Welcome. There isn't much experience with the 5048 models as yet. I assume that they work much the same as the 4048 models, merely with slightly different firmware and hopefully more silicon [ edit: and/or a bigger high frequency transformer ] to handle the extra power load on the DC-DC converter. What version of firmware (U1 display page) does your inverter come with?
I have an generator for back-up. I don't know how to use the dry contact of the inverter's to automatically start the generator when the battery get's low. Can you help me?
The operation of the dry contact is described in the PIP-5048MS user manual on page 10. I assume you'll have setting 01 set to UTI (Utility first output source priority). Then the dry contact will become active when the battery voltage falls to the same voltage where you get a low battery warning.

If you want to know how to connect that to your specific generator, the details will vary with every generator. My guess is that you will only need the C (Common) and NO (Normally Open) terminals of the dry contact terminal block. Not all generators have an auto-start capability. If yours does not, but you want to add that capability, you'll need a small electronic circuit to drive a large relay or contactor to parallel your inverter's start switch, and then to release the start switch somehow as soon as the generator is running. That's probably not as easy as it sounds, especially since you might have to retry if the generator conks out a few time before it starts properly.

[ Edit: corrected manual link. ]
[ Edit: Added "and/or a bigger high frequency transformer". ]
Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
1.4 kW solar with 1.2 kW Latronics inverter and FIT.
160 W solar, 2.5 kWh 24 V battery for lights.
Patching PIP-4048/5048 inverter-chargers.

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 » Sun, 08 Oct 2017, 16:26

Hello,

Betatesting the Firmware should be no Problem.
A Problem could be that my PIP4048 is a HS not a MS.

If I don't use Solar (MPP), can I still use your Firmware?
I mean using the PIP as Battery charger :-)


THX ind advance

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

Re: PIP-4048MS inverter

Post by weber » Mon, 09 Oct 2017, 13:51

dakoal wrote:
Sun, 08 Oct 2017, 16:26
A Problem could be that my PIP4048 is a HS not a MS.
If I don't use Solar ..., can I ... use your Firmware?
I mean using the PIP as [an AC] Battery charger :-)
Hi dakoal, See the first note in red here:
viewtopic.php?title=pip4048ms-inverter& ... 332#p64096
In short, it might work, or it might damage your inverter. We can't be any more definite than that.

For readers who may not be aware, the HS suffix means that its Solar Charge Controller (SCC) does Pulse Width Modulation (PWM) which merely limits the voltage, whereas the MS suffix means its SCC does Maximum Power Point Tracking (MPPT) which converts any excess voltage into more current.
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

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

Re: PIP-4048MS inverter

Post by weber » Mon, 09 Oct 2017, 14:07

Progress has stalled on the firmware patches to implement a dynamic current limit.

The timeout (as suggested by hennejg) is now working. We're presently using 20 seconds. And, as mentioned earlier, the modified MNCHGC command correctly controls AC charging without restarting it, but then the unmodified MNCHGC command already did that. The only difference is that we've made it possible to use any whole number of amps as a current limit (by adding 500 to it). The dynamic values are not limited to multiples of 10 amps.

However the solar charge controller (SCC) completely ignores any dynamic current limit. And we're fairly certain we're correctly sending the information to it. It's possible that the SCC really does need to be reset (which stops it charging for 40 seconds) before it will use the new current limit. So we need to analyse the SCC code some more. We really hope we don't need to also patch the SCC firmware to make this work.
One of the fathers of MeXy the electric MX-5, along with Coulomb and Newton (Jeff Owen).

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 » Tue, 10 Oct 2017, 14:17

Hello,

I only need the AC-Part, not the Solar part.
So if you allow me to test the beta, I will be happy to do so.

If my PIP is going to brick, it's my fault, not yours :-)

Best regards and thanks for your work.

User avatar
coulomb
Site Admin
Posts: 3713
Joined: Thu, 22 Jan 2009, 20:32
Real Name: Mike Van Emmerik
Location: Brisbane
Contact:

Re: PIP-4048MS inverter

Post by coulomb » Wed, 11 Oct 2017, 18:20

weber wrote:
Mon, 09 Oct 2017, 14:07
Progress has stalled on the firmware patches to implement a dynamic current limit.
One of the reasons has been a hard drive failure on my computer. I've recovered from that, but had to re-install Windows, and I'm still restoring various data files and re-installing applications. So I'm back at 80% capacity after being crippled for two days. Weber has come up with some good ideas in the mean time.
Nissan Leaf 2012 with new battery May 2019.
5650 W solar, 2xPIP-4048MS inverters, 16 kWh battery.
1.4 kW solar with 1.2 kW Latronics inverter and FIT.
160 W solar, 2.5 kWh 24 V battery for lights.
Patching PIP-4048/5048 inverter-chargers.

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: 2601
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: 75
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: 2601
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: 75
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: 2601
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: 75
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: 75
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: 185
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: 75
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: 185
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: 75
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: 185
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: 2601
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).

Post Reply