As an example, I will use my system as an example. The PVI-5000-OUTD-AU efficiency plot is given below.

Aurora Efficiency Plot

Panel: TH175M24
Pmax: 175watts
Vmp: 36.2V
Imp: 4.85A
Voc: 43.9V
Isc: 5.30A

It can be seen from the inverter efficiency diagram that the sweet spot is at 50% full power and 345V string voltage. Note that it has 2 MPPTs. These may be independently specified.

Now the 28 panels for 4.9kW need to be split between the MPPTs such that the Pmax string voltages are near the optimal 345V. This gives us 2 optimal and a symterical choices:

1. 2 x 9 Panels in parallel + 1 x 10 panels. This gives string voltages of 325.8V and 362V.
2. 2 x 10 panels in parallel + 1 x 8 panels. This gives string voltages of 362V and 289.6V.
3. 2 x 7 panels in parallel + 2 x 7 panels in parallel. This gives string voltages of 253.4V

The open circuit string voltage for this inverter must be less than 600V. This is 439V for 10 panels, so this parameter is ok.

By inspection of the efficiency plot, configuration 1 is the best. In fact is it 0.3% better than the symmetrical configuration, which would result in about $10 per year more income/power at 68c/kWh.

The MPPT which has 2 strings in parallel has a greater weight attributed when choosing panel configuration as it supplies more power.

Refs:
Aurora PVI-5000-OUTD-AU Datasheet
TH175M24 specs

All things going well, we should be generating power and income in June some time, fingers crossed. Hopefully AGL wont stuff us around like others I know when we apply for the premium rate tarrif too.

4.9kW PV Panel Install with 28 x 175W Mono

Researching udev a bit, I found /lib/udev/rules.d/60-persistent-serial.rules (mine is a debian system). This file shows how the standard symlinks are done. Since each USB port is unique, I should be able to use that uniqueness to map another symlink to the device.

Firstly plug in the device in the chosen USB port and issue
udevadm info --query=all --name=/dev/ttyUSB1

This shows a heap of stuff but mainly we are interested in
P: /devices/pci0000:00/0000:00:1a.0/usb2/2-1/2-1:1.0/ttyUSB1/tty/ttyUSB1

Create a file in /etc/udev/rules.d/70-persistent-serial.rules which contains

#see /lib/udev/rules.d/60-persistent-serial.rules

ACTION!=”add|change”, GOTO=”persistent_serial_end”
SUBSYSTEM!=”tty”, GOTO=”persistent_serial_end”
KERNEL!=”ttyUSB[0-9]*|ttyACM[0-9]*”, GOTO=”persistent_serial_end”

IMPORT=”usb_id –export %p”
#IMPORT=”path_id %p”

ENV{ID_SERIAL}==”", GOTO=”persistent_serial_end”

# usb nearest ethernet connector
ENV{DEVPATH}==”*usb2/2-2/2-2:1.0*”, SYMLINK+=”serial/by-name/envi”
#bottom front connector
ENV{DEVPATH}==”*usb7/7-1/7-1:1.0*”, SYMLINK+=”serial/by-name/rs485″
# usb below nearest ethernet connector
ENV{DEVPATH}==”*usb2/2-1/2-1:1.0*”, SYMLINK+=”serial/by-name/rs485″

LABEL=”persistent_serial_end”

Replug and voila you get /dev/serial/by-name/rs485 which will always be the correct device.

Now I just have to run the wire to where the GCI will be installed.

test.c: In function â:
test.c:6: warning: unused variable â


This is due to the default locale being set to something other than the default.

in /etc/default/locale you will have a line like

LANG="en_AU.UTF-8"

add

LC_CTYPE=C

Restart the shell and compile again and the errors are now meaningful.

test.c: In function 'main':
test.c:6: warning: unused variable 'x'


Naturally you could set it in the local shell for the session, but then you would have to do it every time.

A better but not intuitive explanation is that the mechanical vibration of each unit alters the behaviour of the other, increasing the total VA (since that’s what the current sensor measures). The 2 units are located next to each other so are mechanically coupled through the floor.

Of course this explanation could be wrong too but I can’t think of another ATM.

All you need is a tool from microsoft called subinacl.

Download and install the msi. Install path is

C:\Program Files\Windows Resource Kits\Tools\subinacl.exe

So use this for the command name below.

First find your old userid. Use a file you know you used to own. E.g. the projects directory.

Subinacl /file c:\projects /display

Copy and paste yours for use in the commands below

Now for the commands. Do for all drives if you have multiple disks.
The lines below are for me of course so sub in your cut S-xxx and new user id

Subinacl /subdir c:\ /accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\username

also the primary group, which can be found up the top of the display dump.

Subinacl /subdir c:\ "/accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\Domain Users"

all registry keys

Subinacl /subkeyreg HKEY_CURRENT_USER /accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\username

Subinacl /subkeyreg HKEY_LOCAL_MACHINE /accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\username

Subinacl /subkeyreg HKEY_CLASSES_ROOT /accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\username
(none found, so optional)

and the groups
Subinacl /subkeyreg HKEY_CURRENT_USER "/accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\Domain Users"

Subinacl /subkeyreg HKEY_LOCAL_MACHINE "/accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\Domain Users"

Subinacl /subkeyreg HKEY_CLASSES_ROOT "/accountmig=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx=newdomain\Domain Users"

After you are happy

Subinacl /subdir c:\ /suppresssid=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx

Subinacl /subkeyreg HKEY_CURRENT_USER /suppresssid=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx

Subinacl /subkeyreg HKEY_LOCAL_MACHINE /suppresssid=S-x-x-xx-xxxxxxxxx-xxxxxxxxx-xxxxxxxxx-xxxx

When you are finished, everything you used to own you will own again.

I had read about the 144 Bug. I suspect it is related to this.

This has to do with the way that the transmitter samples the current sensor. I have noticed that the resolution is much better at lower power than higher power. I suspect this is because the ADC reference in the PIC is connected to a PWM output (smoothed of course) to provide a variable dynamic range sampling system. As you would expect, there would be quite a few range change points in the sampling algorithm. The 144 bug details one at 3kW. I suspect there is also one at somewhere between 450W and 600W which is not calibrated correctly. There are probably others too.

If these range change points are known, it would be easy enough to add fudge factors during datalogging to correct for this. Alternatively I could disassemble the transmitter PIC code and just fix it.

No time for this now.

Another possibility is that the sampling system is non-linear, increasing apparent measurements. Not enough calibrated sample points to prove. Anyhow the former is more likely.

Fridge + Freezer Power Usage

As can be seen, the base load is about 320W which consists of 2 PCs and incidental standbys. The fridge cycles more frequently than the freezer. The fridge power alone is about 75W and the freezer alone is about 100W. You would thus expect their combined power to be 175W. However, this is not so! Measured combined power is about 250W.

Given that the mains power monitor is power factor insensitive, and the compressors of both devices have inductive power factor, this result is unexpected. I’m also assuming that the power factor of the baseload is 1.0, which I think is reasonable as using another power meter showed a power factor of 1 for the PCs and these predominate the baseload.

I would expect the vector sum of fridge+freeze+baseload to be less than the sum of their magnitudes.

To make this work with wordpress, edit wp-admin/includes/file.php in function get_filesystem_method() and comment out

if ( getmyuid() == fileowner($temp_file) )

to

#if ( getmyuid() == fileowner($temp_file) )


If the test file can be written, who cares if it is not owned by the webserver.

You will have to reapply this edit every time wordpress core is updated.

Ref: why-wordpress-asks-connection-info