Page 28 of 99
Posted: Wed, 16 Dec 2015, 00:46
Just did some research - actually the Noctua and Arctic 80mm fans both move the same amount of air (about 52 m3/h). This is substantially less than what I can see the average generic fans run (about 96 m3/h). Whilst being noisy.... but regardless better.
Posted: Wed, 16 Dec 2015, 01:09
Actually I can confirm it only speeds up the fans on higher loads not temperature.
My fans are at idle while running at 70 degrees and only speeds up when more load is applied.
Funny thing is is that the unit actually runs cooler under higher loads...
Posted: Wed, 16 Dec 2015, 01:15
Yes that's the impression I got to of how the fans where controlled even with the new firmware.
They have just shifted the (load trigger point) up higher for each fan speed.
Posted: Wed, 16 Dec 2015, 01:41
why havent they made the fans heat related speed instead of load?
Posted: Wed, 16 Dec 2015, 01:42
I can Also confirm that the fans are controlled by load
at about 200watt speeds up and at about 800 watt max speed
I've turned my fans around so that it blows into the case and also used tape to seal the gaps around the plastic air guide so that no air leaks out and miss the heat sink maximizing airflow over heat sinks and board.
I have 2 Arctic f8's in the bottom blowing in and installed 2 arctic f9's at the top sucking out . The air flow is more than with the stock fans but a lot less noise.
Posted: Wed, 16 Dec 2015, 02:12
I remove the plastic air guide
Posted: Wed, 16 Dec 2015, 02:29
weber wrote:By the way, when you update to the patched version, all your settings should stay the same, except for the low voltage cut-out, which will jump up by 4 volts. So if you had it set to 48.0 V, it will become 52.0 V. You might want to lower this to 51.5 V or 51.0 V to avoid nuisance cut-outs due to the battery voltage sagging under heavy loads.
I found I had to set mine to
Back to Grid Voltage
: 51.0 volts - If “SBU” is selected in output source priority, the inverter will transfer output source to grid when battery voltage drop to low battery voltage point.
Battery Cut-off Voltage
: 50.8 volts - In battery mode, when battery voltage is lower than cut-off voltage point, inverter will shut down battery and transfer to fault mode.
There seems to be a need to set both these values as such.
[ Edited Coulomb: Repaired bad Unicode chars in preparation for conversion to phpBB ]
Posted: Wed, 16 Dec 2015, 02:49
Tjadenw wrote: I can Also confirm that the fans are controlled by load...
In the 52.30 and 72.40 firmware, it takes into account:
1) percent load, if in battery mode and the output relay is on
2) average charge current
3) The maximum of 3 temperature measurements, inv, txt (?) and bat; these are compared with 48 and 50
4) The SCC PWM temperature; this is compared with 50 and 60
5) The warning code; if set, the fan speed is set to 100%, but there are two flags involved
6) More tests on the max of 3 temperatures, this time compared with 70 and 72 and 68
7) The SCC PWM temperature compared with 58
There are about 52 basic blocks in the function _SFanSpeedControl(). There is a much simpler function called _sFanSpeedCtrl() which only reacts to load control, but it appears not to be called. Perhaps the latter was replaced with the former around firmware version 52.30.
In summary: it's complicated, and does seem to depend on temperatures.
Posted: Wed, 16 Dec 2015, 03:17
That is complex. Why base it on load at all. Could it just be a fail safe if a temp probe went bad.
You mention (bat temp) I assume this is battery temp? If so, how is the pip measuring bat temp? Or is it because the mppt controller has a the ability but it isn't bring used ?
Though if it is taking various temps into consideration. why in practice don't we see the fans speed up in what you would think would be more than enough temp rise to trigger it. As mentioned load seems to be the predominant trigger. Although you do need more load in the new firmware than the old.
So I wonder what the temp has to be to have any influence on the fan 100C!
Posted: Wed, 16 Dec 2015, 03:32
PlanB wrote: ... if you happen to find out why it doesn't put fault codes in the QPGSn response (4th parameter) like it's supposed to I'd be very interested to know.
Well, the QPGSn command seems to use a field of struct _wSystemData which is only written to (as far as I can find) by function _sUpdateLocalData(). This, as the name implies, seems to only deal with data local to the machine, not other machines.
[ Edit Feb 2018: actually, I had that exactly wrong. wSystemData seems to be an array of structures of the local data for 6 or 9 paralleled machines, so really it's "global" or "system wide" data. These data are transmitted from machine to machine over the CAN bus; that's the daisy-chained set of cables that look like EGA display cables. The structure member involved is set in UpdateLocalData() by a call to GetFaultCode(), which is the same function that is used to display the currently active fault code (if any), in DisplayFaultCode() called by DisplayFaultWarning(). The latter is the function that displays the fault code interspersed with the parallel mode such as HS or MS for master, SL for slave, or nE for new (not master or slave yet). For non-paralleled machines (setting 28 = SiG), the fault code merely alternates with blanks, i.e. it flashes. This behaviour (displaying the fault code from wSystemData) is the same from 52.30 to 73.00, at least. So it seems to me now that it should work as expected, provided that fault data is transmitted over the CAN bus as needed. ]
It looks like a case of missing code to me.
All that non-local machine stuff is way beyond me at this stage, sorry.
Posted: Wed, 16 Dec 2015, 13:57
Interesting Mike, QPGSn would be local when the box you're plugged into is the nth box but all the boxes seem to know what the status of the others are so they must chat in the background. My hunch is they all hold an array of each others status rather than the box you're plugged into forwarding QPGSn queries that aren't for it on.
I reckon it's got something to do with the PEz/PDz cmds (enable/disable fault code record, it just doesn't seem to work. There seems to be a bit of tendency to simply ignore some cmds. I've noticed the PEj/PDj cmd has no effect on power saving status as returned by QMOD too. The cmd is ACKd but nothing changes. Maybe that's where the missing code is, in the cmd parsing routine?
Posted: Wed, 16 Dec 2015, 15:23
lopezjm2001 wrote: I should also mention I did the download patch using com8 instead of com1 as com8 was already setup for monitoring software for WatchPower. Why com1?
We were using com1 because at one point we were doing updates to the SCC firmware. That uses a totally different reflash tool, which allows you to change the input file name, but not the com port. So we forced the com port to com1 (using device manager). We noted that this seemed to stop WatchPower from working, but we rarely use WatchPower anyway.
So if you're not doing SCC firmware updates (and there is no reason to do them so far), and you use WatchPower, it's probably better not to change the com port to com1.
Posted: Wed, 16 Dec 2015, 15:39
PlanB wrote: I've noticed the PEj/PDj cmd has no effect on power saving status as returned by QMOD too. The cmd is ACKd but nothing changes. Maybe that's where the missing code is, in the cmd parsing routine?
Well, the PEj handling code checks to see what output mode you're in. If it's not 0 (single machine), then it branches around the code that sets the power save status. Interestingly, it still registers a parameter change, so the eeprom gets rewritten (presumably with the same value as before).
My guess is that when you're in a parallel or three phase mode, you're supposed to use a different command to achieve a system-wide change.
[ Edit: I've just noticed that in the Parallel Installation Guide, it says "Besides, power saving function will be automatically disabled." ]
Posted: Thu, 17 Dec 2015, 01:19
lopezjm2001 wrote:I found I had to set mine to
Back to Grid Voltage: 51.0 volts - If “SBU” is selected in output source priority, the inverter will transfer output source to grid when battery voltage drop to low battery voltage point.
Battery Cut-off Voltage: 50.8 volts - In battery mode, when battery voltage is lower than cut-off voltage point, inverter will shut down battery and transfer to fault mode.
There seems to be a need to set both these values as such.
Good point. Yes, it is now possible to make some useless combinations of settings. But all you have to do to prevent those is make sure that all of your other voltage settings are above your low voltage cutoff setting.
[ Edited Coulomb: Repaired bad Unicode chars in preparation for conversion to phpBB ]
Posted: Sat, 19 Dec 2015, 01:29
Here is some of my observations over the last 12months
I put a temp controller onto one of my units to watch the temp and the heat sink was at 50deg C so as I had a few 48v 125mm fans I screwed one each side of the unit at the top over the air inlet and set the controller to come on at 42deg and off at 36deg now the heat sink never goes above 42.
Now the unit I have working at another location went through the 40deg day without a problem without the added fans.
I am also running the two systems with different panel strings one has threes the other twos the one with twos the top heat sink gets warm on hot days only the one with threes gets hot when above 30amps and needs a fan.
I was lucky to find I had some temp controlled fans from some old HP servers so with one sat on top its speed varies with the temp of the heat sink and only lets it get warm.
I have been getting 62amps from the unit with three panels series 18 panels x 240watts so the solar charger limits itself as there is more power avaliable.
I have been getting 48amps with the system that has six sets of two panels x 240watts and when the temprature of the panels is taken into consideration this is the max output expected.
Now at 1 year with the units.
Great to see the firmware hacking maybe if some of the parts are upgraded we can get the 62v needed for the twice yearly equalization for Pb
Also china has a clone on the market.
Posted: Sat, 19 Dec 2015, 12:43
For a long time, I've been thinking that MPP Solar
was the manufacturer of these inverter chargers, mainly because of the documentation on their web site, and good email technical support. However, it turns out that they are just a distributor, that happens to be based in Taiwan. The real manufacturer is Voltronic Power
. They have a company introductory video
on their about page
, which I found interesting:
So the official page for the PIP-4048, whose real name is the Voltronic Axpert MKS 5KVA, is this one: http://www.voltronicpower.com/oCart2/in ... uct_id=132
For completeness, the product page for the dual/triple MPPT version is this one: http://www.voltronicpower.com/oCart2/in ... uct_id=152
In both cases, there are lower power and lower voltage versions; the 48 V 5KVA (4 kW) versions are the ones being discussed in this topic.
Edit 1: As further evidence of Voltronic being the real manufacturer, when exploring the innards of the WatchPower program, I found reference to "voltronic" in the directory path, and no reference to mppsolar. Thanks also to user fllniks for spurring this post.
Posted: Sat, 19 Dec 2015, 16:11
In the company youtube video where they show the board room presentation.
In my twisted imagination I was expecting a spy image of Coulomb with a laptop and a PIP on the projector screen.
Then In a B grade kung fu movie style.....(Monkey Majik) out of sync Voice over. The CEO would say...
"This man is making us look like fools. I thought you guys said this firmware was perfect?"
[ Edited Coulomb: this image was lost to the Flickr situation. Kurt kindly reconstructed it from two images he had on his computer, and sent it to me to repair the post. Thanks, Kurt! ]
Posted: Sat, 19 Dec 2015, 18:08
This may explain the delays between questions and answers, when we were dealing with MPP Solar many yrs back the feeling was that they were not actually the manufacturer but rather the middle men, but dealing with Chinese companies is often like that though.
Posted: Sun, 20 Dec 2015, 05:19
Today Weber and I went off to Black Monolith Number One to install the LiFePO4 patch, amongst a few other things that needed changing. Everything seemed to be going well, and it looked like we might be able to get away just after lunch. But alas, it refused to exit absorb mode now, even after the current fell to what seemed like a low enough level for well and truly long enough. We tried to guess what might have gone wrong, but could not, so we had to use the JTAG debugger to display various memory locations while the firmware was running.
This revealed that the counter was staying at zero, which in turn was because the flag that should be set by the patch was not being set. I turned to the patch itself, to check the values that it depended on. The CV voltage setting in memory was exactly as expected. But on looking for the next value to check, I realised that something was wrong with the patch code. The code just looked wrong. Sure enough, there was a typographical error whereby the subtraction of half a volt from the CV setting was not happening. So the criterion was that the battery voltage had to be exactly the setting voltage or higher, not higher than half a volt less than the setting. But how could this have worked on the test machine? It might have been to do with how the SCC and DSP report slightly different values for the battery voltage. Or it might be an accident of how well the control algorithm happened to track the setpoint voltage. At least the fix was obvious.
But now we needed a new version number for this bug-fixed version. The QVFW version number is easy - report the next highest version number. But on the LCD display, we show LIFEPO4.... we couldn't really call it LIFEPO5. Weber suggested changing the "I" to a "lower case i". "And fix the 'r's while you're at it", he added. The seven segment pattern they use for the letter "r" has always been (to my mind) rather ugly, and the fact that they use the same pattern for a "K" doesn't help. There is an obvious fix - make it look more like a lower case "r" by getting rid of the upper segment.
| goes to |
Gak - I must have screwed up! Now the "I"s displayed like apostrophes! However, we felt that the "r"s looked much better. The patch fix (patch of a patch) tested out well, I found the error with the "i" pattern, and tested a new version of the patch. The result is rather better, I feel:
You might notice that the image is somewhat dark. That's because by the time we fixed everything else, it literally was well after sunset, and we were using light and power from the old 24 V system that was still in place. I think Murphy's Law was punishing us for thinking we could have gotten away soon after lunch.
I'll be updating the LiFEPO4 and Lead Acid patch files with the fix soon. My apologies to LopezJM, offgridQLD, and anyone else who may have used the buggy patches.
Edit: I should point out that the change of letter rendering was to the "character generator", so this change to the "I" and "R" "shapes" applies to all displays that involve those letters. It is a constant reminder that the patch is in use.
[ Edit 2: exit bulk mode -> exit absorb mode ]
[ Edit 3: clarified lower case 'r' ]
Posted: Sun, 20 Dec 2015, 05:31
Kurt, your imagined overdub was funny enough, but when combined with your photoshop job using that image of Coulomb looking completely insane, it totally cracked me up. My wife had to ask me what was so funny.
Posted: Sun, 20 Dec 2015, 15:23
I have replaced the buggy patches with the fixed ones:
Post with the LiFEPO4 patch
Post with the Lead Acid patch
Posted: Sun, 20 Dec 2015, 15:30
Site; (noun) that location where stuff developed & tested at another location exhibits a range of behaviours hitherto unseen.
I love the idea of the legacy system shedding some light on the new system while you reworked it, Murphy has a delicious sense of irony too.
Posted: Mon, 21 Dec 2015, 00:36
For those with lead acid batteries some in depth reading
http://orbit.dtu.dk/fedora/objects/orbi ... 66/content
Posted: Mon, 21 Dec 2015, 12:43
Hello all really enjoyed reading all the posts on the pip-4048ms inverter and rom hacking which i found very interesting, i thought it was pretty good till it died yesterday in 45 degree heat, I myself have one of these i bought it in march 2015 and well found my self here cause after a few months use its broken
, the solar side which has 8x 250w 24v (37V oc) panels in series of 2 panels and four parallel connected is no longer even being seen by the inverter so something died in the mppt solar charger as the voltage is there and i checked all the panels, the AC inverter part still works in making power and grid side charger still works but no solar charge which is really upsetting considering im in a caravan completely off grid, which means the only charging i can do is via the generator attached to the grid side, and it cant really cope with running the air conditioner which sucks just as we started having 40+ degree days and it becomes an oven in the caravan.
I was hoping that someone would have documented a similar problem with the solar mppt charger and posted a solution , perhaps someone has a dead pip-4048 inverter that still has a working mppt solar charge controller ?
It really could not happen at a worse time as im sure its going to take at least a month to get a replacement and until then im basically without power and i have to sort this out quick as i have my 5yo son for a few days over christmas no power is going to be a problem when he wants to play xbox
I was thinking perhaps i would just go get a solar charge controller and hook that up , jaycar have one called a sunstar 50A mppt controller dont know how good they are but perhaps i hook one of them up to just solve my no charge issue for the moment but at $849 which is almost as much as pip-4048ms maybe out of my budget surely something out there cheaper that i can get reasonably quickly to rectify my current dilemma, any suggestions ?
Ive a background in electronics and computers but it maybe some surface mount ic thats died that detects the solar connected i need a circuit diagram and some kinda miracle to repair it .
please help me
Posted: Mon, 21 Dec 2015, 13:16
45c ambient temps perhaps a lot more where it's located in - on the van? Out of interest is there a big black finned heat sink on the top of your pip or is it the newer style with a smooth top surface?
Don't pay $800 for a Jaycar solar charger. That's way overpriced for what you are getting.
Where are you located ? I assume SA or VIC. Edit: I see now your in Melbourne, couldn't see that info on my phone.