MPPT Gradient Descent Weird Behavior

[rbrenesh]

Running the command:

mutovis-control-cli --layout-index 8 --destination /home/onelab/data --pcb-address 192.168.1.11:23 --light-address ftdi://ftdi:232/1 --sm-address GPIB0::24::INSTR --pixel-address A4 --mppt 60 --mppt-params gradient_descent://1:0.001 -o roberto -r "MPPT test" -p test test

leads to weird, non-physical MPPT behavior, since the device was supposed to be ~13% PCE (see attached plot and zipped H5 file)

archive.zip

[rbrenesh]

Running on the same device the command:

mutovis-control-cli --layout-index 8 --destination /home/onelab/data --pcb-address 192.168.1.11:23 --light-address ftdi://ftdi:232/1 --sm-address GPIB0::24::INSTR --pixel-address A5 --mppt 60 --mppt-params gradient_descent://10:0.001 -o roberto -r "MPPT test" -p test test

Leads to the following behavior (picture and zipped H5 attached). Also, the Keithley was reading ~11V in both cases when the discontinuity happened.

archive2.zip

[greyltc]

@rbrenesh I think I've figured out why there's a large discontinuity in your tracking at t=10s. Fix incoming...

[greyltc]

Okay nevermind, I can't manage to recreate this. Though I can introduce bugs in the code that recreate similar issues.

[greyltc]

So maybe I'm missing some info that I don't know I'm missing. e35d9f909538a629de7366141a52df55742cb9a2 changes it so that all run parameters are recorded into the data file (should have done this before anyway).

So can you please update to v1.1.4 and make this happen again, then attach the resulting .h5 file here so I can have a look?

[greyltc]

And also, can you please paste here what gets printed to the terminal when you see this?

[greyltc]

I also added voltage to MPPT plot in the analyzer gui to help understand this a bit better. So you can update that to 3.0.5.

[greyltc]

So after having looked at this for a while, I think the issue might just be that a learning rate (alpha) of 1 or 10 is too high. This causes an applied voltage step that's too large especially in the first measurement point, then the tracker recovers back to the proper max power point. You can see things are too "jumpy" with large voltage dips and then periods of recovery from these steps that were too big.

Try --mppt-params gradient_descent://0.001:0.001 that should hopefully solve everything.

I might consider changing the algorithm so that the first few seconds actually "ramp up" alpha to the applied value to avoid large jumps caused by relatively large errors that are unique to the first few steps that the mppt takes. But that needs more testing!

[rbrenesh]

Sorry I've been MIA, I had to head back home for some family issues. I replicated the above in v1.1.4 running the command:

mutovis-control-cli --layout-index 8 --destination /home/onelab/data --pcb-address 192.168.1.11:23 --light-address ftdi://ftdi:232/1 --sm-address GPIB0::24::INSTR --pixel-address A4 --mppt 60 --mppt-params gradient_descent://10:0.001 -o Roberto -r "MPPTtest" -p test test

The terminal prints:

Software revision: v1.1.4
Using pyvisa-py pyvisa backend.
Sourcemeter found:
KEITHLEY INSTRUMENTS INC.,MODEL 2400,0637449,C34 Sep 21 2016 15:30:00/A02  /C/D
Connected to control PCB with Firmware Version: 53cebdb
Found MUX board(s): A
Creating file /home/onelab/data/roberto-19-05-03/Run_0_1556907828.h5
Virtually moving to 315mm
Intensity = [0.9692 0.9844] suns

Operating on substrate A, pixel 4...
New substrate using "MIT 1in" layout!
Virtually moving to 300mm
Measuring steady state voltage at 0 mA
New region of interest: [0,28]  V_oc dwell
V_oc is 1090.6776mV
Sweeping voltage from 1091 mV to 0 mV
New region of interest: [29,129]    Sweep
Measuring steady state current at 0 mV
New region of interest: [130,159]   I_sc dwell
I_sc is -3.9654mA
Snaithing voltage from 0 mV to 1636 mV
New region of interest: [160,260]   Snaith
Tracking maximum power point for 60.0 seconds
Teleporting to Mpp!
Soaking @ Mpp (V=752.53[mV]) for 10.0 seconds...
===Starting up gradient descent maximum power point tracking algorithm===
Learning rate (alpha) = 10.0
Smallest step (min_step) = 1.0 [mV]
Final value seen by the max power point tracker after running for 60.0 seconds is
0.6546 mW @ 290.94 mV and -2.25 mA
New region of interest: [261,1446]  MPPT

Closing /home/onelab/data/roberto-19-05-03/Run_0_1556907828.h5
Program complete.

Here's the graph and the h5 file is attached at the end:

archive.zip

[rbrenesh]

I then tried your suggestion of using --mppt-params gradient_descent://0.001:0.001 which seems to help quite a bit, but there still seem to be some spurious data points. Terminal printout, graph and data below.

Software revision: v1.1.4
Using pyvisa-py pyvisa backend.
Sourcemeter found:
KEITHLEY INSTRUMENTS INC.,MODEL 2400,0637449,C34 Sep 21 2016 15:30:00/A02  /C/D
Connected to control PCB with Firmware Version: 53cebdb
Found MUX board(s): A
Creating file /home/onelab/data/roberto-19-05-03/Run_1_1556908503.h5
Virtually moving to 315mm
Intensity = [0.9454 0.9597] suns

Operating on substrate A, pixel 4...
New substrate using "MIT 1in" layout!
Virtually moving to 300mm
Measuring steady state voltage at 0 mA
New region of interest: [0,28]  V_oc dwell
V_oc is 1009.2047mV
Sweeping voltage from 1009 mV to 0 mV
New region of interest: [29,129]    Sweep
Measuring steady state current at 0 mV
New region of interest: [130,159]   I_sc dwell
I_sc is -3.7121mA
Snaithing voltage from 0 mV to 1514 mV
New region of interest: [160,260]   Snaith
Tracking maximum power point for 60.0 seconds
Teleporting to Mpp!
Soaking @ Mpp (V=575.25[mV]) for 10.0 seconds...
===Starting up gradient descent maximum power point tracking algorithm===
Learning rate (alpha) = 0.001
Smallest step (min_step) = 1.0 [mV]
Final value seen by the max power point tracker after running for 60.0 seconds is
1.8666 mW @ 546.99 mV and -3.41 mA
New region of interest: [261,1415]  MPPT

Closing /home/onelab/data/roberto-19-05-03/Run_1_1556908503.h5
Program complete.

archive.zip

[greyltc]

It definitely looks like an alpha of 10 is too huge for your devices. It's making the algorithm perodically make voltage jumps that are too big and then most of its time is spent trying to recover from these large voltage steps. alpha = 0.001 above looks like it solves the problem entirely. The max power point voltage looks like it's tracking reasonably except for the blips. I notice that those blips appear even before the 10 second mark when the MPPT algorithm isn't even running and the keithley is simply applying constant voltage (whatever the max power point voltage was, taken from the best IV sweep previously done). I think those blips could be caused by device instability (I've seen shunt pathways that burn out during testing cause stuff like this, or also maybe some instability caused by silver/silver iodide). You can check if you get those blips while running on the photodiode loaded dummy PCBs I gave you. If they're there, then the voltage blips are a setup issue and we can try to address that, otherwise I think the instability you're seeing might actually be device instability.

The voltage blips suggest that the device might actually be very unstable which could explain the noisy power/current as well.

If you've got some time, upgrade all your software. I've made a bunch of changes recently and the current control software is now v1.2.1. (I changed the executable to mutovis-control, no more -cli). It has a new gradient descent parameter that slowly ramps up alpha over the first n seconds of tracking. That might help in some cases if you want to play with going to larger alpha values by preventing the shock of using the big alpha on the very first step. MPPT documentation

[rbrenesh]

I updated the software and ran the test with the photodiodes with the command:

mutovis-control --layout-index 8 --destination /home/onelab/data --pcb-address 192.168.1.11:23 --light-address ftdi://ftdi:232/1 --sm-address GPIB0::24::INSTR --pixel-address A4 --mppt 60 --mppt-params gradient_descent://0.001:0.001:10 -o Roberto -r "MPPTtest" -p test test

Terminal output was:

Software revision: 1.2.1
Using pyvisa-py pyvisa backend.
Sourcemeter found:
KEITHLEY INSTRUMENTS INC.,MODEL 2400,0637449,C34 Sep 21 2016 15:30:00/A02  /C/D
Connected to control PCB with Firmware Version: 53cebdb
Found MUX board(s): A
Creating file /home/onelab/data/roberto-19-05-07/Run_2_1557241965.h5
Virtually moving to 315mm
Intensity = [0.9246 0.9636] suns

Operating on substrate A, pixel 4...
New substrate using "MIT 1in" layout!
Virtually moving to 300mm
Measuring steady state voltage at 0 mA
New region of interest: [0,28]  V_oc dwell
V_oc is 519.7730mV
Sweeping voltage from 520 mV to 0 mV
New region of interest: [29,129]    Sweep
Measuring steady state current at 0 mV
New region of interest: [130,159]   I_sc dwell
I_sc is -2.1685mA
Snaithing voltage from 0 mV to 780 mV
New region of interest: [160,260]   Snaith
Tracking maximum power point for 60.0 seconds
Teleporting to Mpp!
Soaking @ Mpp (V=343.05[mV]) for 10.0 seconds...
===Starting up gradient descent maximum power point tracking algorithm===
Learning rate (alpha) = 0.001
Smallest step (min_step) = 1.0 [mV]
Ramp up time (fade_in) = 10.0 [s]
Final value seen by the max power point tracker after running for 60.0 seconds is
0.5859 mW @ 348.85 mV and -1.68 mA
New region of interest: [261,1484]  MPPT

Closing /home/onelab/data/roberto-19-05-07/Run_2_1557241965.h5
Program complete.

The MPPT plot is below. It seems to be better than the device, so the outliers might just be a device instability thing.

[greyltc]

Okay, good. That downward drift in power is probably just the diode heating up. You think we can close this issue for now? You can open a new one if you see any more weird stuff.