csatt / iv_swinger Goto Github PK

The cell version of IV Swinger 2 has two relays (and two sets of binding posts). The second relay controls whether the input is connected to the bias battery by itself, or to the bias battery in series with the PV cell. This allows an IV curve to be taken of the bias battery immediately before swinging the curve of the two in series. This feature is called "dynamic bias battery calibration".

The Arduino code needs to control this second relay. In order to keep most of the complexity of the dynamic bias battery calibration support in the host Python code, the only change needed on the Arduino side is to add support for a new configuration message that turns the second relay on or off. This is also generic enough that the feature could be used for a different purpose.

The new config message will be called SECOND_RELAY_STATE and specifies the value (0 or 1) the relay should be set to (0 is inactive, and 1 is active).

Config: SECOND_RELAY_STATE 0
Config: SECOND_RELAY_STATE 1

The voltage and current calibration are stored on the hardware based on the assumption that variations are due to differences in the hardware. This is only partially true. A significant part of the calibration error can be caused by the reference voltage seen by the ADC (Vref) being something other than exactly +5.000V. The Arduino has a voltage regulator, but it is bypassed when power is obtained from the USB port. The USB voltage can vary quite a bit from one laptop to another. Fortunately, it is pretty consistent on a given laptop.

Therefore, an enhancement to the calibration strategy is to support a separate Vref calibration. Since this calibration is laptop-specific, it should be stored in the configuration stored on the laptop and should not be written to EEPROM on the hardware.

This should make results more consistent when different laptops are used with the same IVS2.

Still, if accuracy is important, it is best to use the same laptop. Powering the Arduino with an external power supply can provide even more consistency and accuracy.

This is really just one more manifestation of Issue #12.

When the log file is viewed via File -> View Log File, after the dialog is closed the File -> View Log File and File -> View Config File entries are grayed out. This is only on Mac, and is due to a bug in the (old) Tk library that is used by the built-in Mac Python (see Issue #12).

The fix for Issue #12 acknowledged that it was not a complete fix. But this is pretty annoying and should be fixed too.

There is a bug in the IV Swinger 2 Arduino sketch version 1.3.1 and earlier that can cause it to not discard points that are too close together. This results in a curve that has very closely spaced points and is missing the end of the curve.

This only occurs in unusual situations. It is caused by an integer overflow in the code.

The IVS2 hardware design calls for a relay module that has an active-low trigger pin. It is easy to make the mistake of buying the wrong type, however. It is easy to work around this in software, so support should be added for active-high relays.

This should be implemented as an option on the Arduino tab of Preferences. Since it is specific to the hardware instance, the flag should be stored in EEPROM on the Arduino, and not in the config file.

At startup, the Arduino code should read the EEPROM location containing the flag to determine if the relay is active-low or active-high. If this location in EEPROM is not valid, then active-low should be assumed. The Arduino code should also snoop writes to this EEPROM location, and immediately start using the new value, including setting the relay(s) to inactive immediately (Config messages are only received when the relays should be inactive).

RevA of the SSR cell version PCB connects Arduino pin D1 to SSR4 pin 3.

Unfortunately, this does not work. Pin D1 on the Arduino UNO is connected to the serial TX line, which is used by USB.

SSR4 pin 3 should be connected to Arduino pin D8 instead.

This does mean that a full 10-pin connector must be used for A1 on the SSR cell version.

It is easy to rework a RevA board to fix this problem:
- Cut off pin 7 of stacking connector A2 after soldering to the PCB. The connection to the PCB needs to be maintained, but the connection to the Arduino must be broken.
- Use a jumper to connect from stacking connector A1, pin 10 (D8) to stacking connector A2 pin 7 (D1)
- This results in a connection from Arduino pin D8 to SSR4 pin 3

When building an overlay with the Results Wizard, it should be possible to check the "Lock" checkbox on the main window and type values into the Max V and/or Max I boxes to override the automatic selection of one or both of the axis ranges. This currently has no effect.

This could be useful, for example, when there are collisions between the Isc labels and the legend.

I am labeling this as a bug because I'd intended it to work this way, and I believe that it did work at some point in the past.

The current Python code attempts to maintain compatibility with downlevel Arduino code by comparing the sketch version with the level at which a feature was added and taking different actions depending on that result.

This is correct but difficult to read and maintain. Instead, these comparisons should be made inside properties whose names reflect whether a feature is supported or not. For example:

    if not self.arduino_sketch_supports_eeprom_config:

is much clearer than:

    if self.arduino_sketch_ver_lt("1.1.0"):

I have received requests to add support for irradiance sensing (W/m^2 of incident sunlight.)

A real thermopile pyranometer can cost thousands of dollars. A commercial silicon photodetector-based pyranometer costs hundreds of dollars. Dr. David Brooks from the Institute for Earth Science Research and Education has a kit available for $25 (shipped!) that contains the parts needed to build a pyranometer that has comparable performance and limitations to a commercial silicon photodetector pyranometer. The kit is designed to connect to a standard data logger (i.e. its output is analog). In order for the Arduino to read values from a Brooks pyranometer, an ADC is required. Dr. Brooks has built Arduino-based data loggers that use the ADS1115 ADC.

The cost and performance of the Brooks DIY pyranometer are in line with the goals of IV Swinger 2 (not necessarily research-grade, but good enough for educational purposes, and inexpensive).

This GitHub Issue is an enhancement request to add support for a Brooks DIY pyranometer connected to the IVS2 via an ADS1115 ADC. It must be possible to calibrate the readings to a reference pyranometer.

The SSR-based cell version has four SSRs: SSR1, SSR4, SSR5, and SSR6. The Arduino code needs to control SSR4, SSR5, and SSR6 appropriately for the cell version, but in a compatible way with the other versions.

The Arduino code skips Isc polling if Voc is zero. However, the current code still activates the relay (or SSRs) in this case, which is unnecessary and could cause unwanted effects.

The Arduino sketch reads the voltage 400 times with the circuit open, before activating the relay and swinging the curve. The current code chooses the highest value read and uses that as the Voc value. If the highest value is an outlier (due to noise, etc.), this results in a Voc value that is too high.

It is much more accurate and repeatable to choose as Voc the MOST COMMON value read during the polling.

IV_Swinger2_gui.py has a mix of:
if sys.platform == "darwin":
and
if self.win_sys == "aqua":

both of which are used to determine if we're running on a Mac. "Darwin" is another name for OSX/MacOS. "Aqua" is the name of the GUI that runs on OSX/MacOS. Since this is the GUI module, it seems more appropriate to test for the "aqua" windowing system in all cases. This is certainly purely cosmetic, but it will be nice for it to be consistent.

Loop mode is very useful when the user wants to experiment in real time with different shading conditions.

It is very annoying when a non-fatal error is detected while looping, since that terminates the looping and displays a dialog. The most common example of this is the case where the PV becomes so shaded that an "Isc stable timeout" error is detected. This is normal and natural even though it is an "error". The user must go to the laptop to dismiss the dialog and click the Swing! button again.

The requested enhancement is to add a new mode option on the Looping tab of Preferences to choose to continue looping even when there is a non-fatal error. It is still desirable for the user to know that the error has been detected, however. But in order to keep it completely "hands off", a dialog doesn't work because it would have to be dismissed by the user. Instead, the main screen itself should be used for the error message with no dismissal required. Since the minimum interval between loop iterations is one second, the message will stay up for at least a second.

The code that attempts to identify which USB port has an Arduino attached looks for the string "uino" in the names of the serial ports. But newer Elegoo Arduino clones have the name "Generic CDC".

At some risk of this matching a non-Arduino device on a different USB port, the code should assume that a device called "Generic CDC" is the IV Swinger 2 Arduino.

RevA of the SSR module version PCB attempts to use a single Arduino pin to control both SSR1 and SSR2. The idea was to emulate an SPDT EMR with two SPST SSRs. SSR1 is active-low and SSR2 is active high. The problem with this is that it creates a path from +5V through resistor R6, through SSR1's LED, through SSR2's LED, through resistor R7, to GND. When the Arduino first powers on, the D2 pin is high impedance, and the two SSRs can both turn on. The full current of the PV module then flows through both SSRs and the bleed resistor, which destroys both the bleed resistor and the SSRs.

The fix is to drive SSR1 and SSR2 with separate Arduino pins, which breaks the connection between the SSRs, so there is no path from +5V to GND.

Currently, the scaling of the voltage and current values based on the calibration is done after the ADC values have been converted into Volts and Amps.

It is better to perform this scaling on the ADC values themselves before they are converted to Volts and Amps. In particular, it makes the logic simpler in the battery bias calculation in the next change.

At the module level, the noise reduction algorithm works well. However, there are some improvements that produce noticeably better results for PV cell IV curves.

• Increase the number of iterations from 25 to 40

• But make this a maximum number of iterations. Keep track of the
  magnitude of the largest change made each iteration (in
  parts-per-million), and skip the remaining iterations if the max PPM
  falls below a threshold

• Change the definition of the "far" points used in the inflection
  calculation to be 1/20 the number of points instead of 1/25

• Sort the points by the magnitude of their rotation angle and process
  them in order from largest rotation to smallest rotation

The Results Wizard disables the Resistors and Bias Battery items on the Calibration menu. They should be re-enabled when the Wizard is closed, but are not.

When a normal non-biased IV curve is used as the basis of a voltage calibration, a calibration scaling factor is calculated simply by taking the ratio of the Voc measurement to the externally measured Voc voltage.

It's not so simple when a biased IV curve is used as the basis of a voltage calibration. In this case, the Voc voltage seen on the final IV curve is really based on the difference between the bias battery Voc voltage and the combined Voc voltage. There really is no way to determine a more accurate scaling factor for the absolute voltage values. For this reason, it is important for the user to perform a non-biased calibration before performing a biased calibration.

However, there is another correction that needs to be performed on the biased value. This is due to the fact that when dynamic bias calibration is used, the second relay causes an additional droop in the reference voltage.

To keep this as transparent to the user as possible, when a voltage calibration is performed and the current curve was taken with dynamic bias calibration enabled, the calibration will calculate the Vref droop value of the second relay. This calibration value is saved in the config and used for subsequent dynamic calibration swings. It is not (currently) saved to EEPROM.

The IV curve of the bias battery changes with temperature and other factors. A bias battery calibration that was performed even a minute or so before the combined curve with the battery in series with the PV cell can easily be "out of date". The result will be a very inaccurate PV curve for the cell.

The only really viable way to get accurate IV curves for a PV cell with a bias battery is to record a bias battery calibration curve immediately before every biased curve. This requires a modification to the hardware design to add a second relay to switch between the bias battery alone and the battery and PV cell in series. The final "cell version" of the IV Swinger 2 hardware has two sets of binding posts, a second relay, and the circuit design modifications needed to support this dynamic bias battery calibration.

The software needs to add support for dynamic bias battery calibration. A prerequisite is that the Arduino sketch has the support for controlling the second relay.

The control to enable dynamic bias battery calibration should be added to the Bias Battery Calibration dialog that opens when the Bias Battery entry of the Calibrate menu is selected.

In this mode, every press of the Swing! button (or loop iteration) swings two curves - one for the bias alone (2nd relay OFF) and one with both in series (2nd relay ON).

When "View Run Info" is selected from the File menu before there is an active run (i.e. when the splash screen is still displayed), an exception is thrown. This menu item should be disabled when there is no current run.

Now that full battery IV curves are used for battery bias compensation, we really don't want to keep these curves (or even just their data) in the same folder as the PV curves. Instead, they should be kept in their own subfolder.

The messages from the Arduino code that identify the DS18B20 temperature sensors by their ROM codes are only sent after the Arduino is reset. These messages are written to the sensor info file, but since the Arduino is generally only reset once per app session, this information is missing from the sensor info files for all but the first run.

This could be fixed in the Arduino code by resending this info for every run, but since Arduino code space, memory space, and time are all precious, it is better to fix it in Python on the host side.

RevA of the SSR module version PCB measures values for current that are much higher than they should be. This is because resistor R3 is connected to net LOAD_CAP- too far away from the (+) end of the shunt resistor. Despite the use of large "copper pour" polygons on both sides of the PCB, the resistance of the copper is significant relative to the resistance of the shunt resistor, effectively resulting in larger shunt resistance. Furthermore, the amount of copper in the path from SSR3 to the shunt resistor is greater than the amount of copper in the path from the load caps to the shunt, so the measurements taken when SSR3 is ON are even higher than they are when only SSR1 is ON. The magnitude of the error is greater than can be practically compensated for by calibration since the ADC saturates at a current that is too low for most PV modules. The fix is to make sure resistor R3 is physically connected directly to the (+) shunt resistor pad with a dedicated trace that is not part of the LOAD_CAP- polygon.

Additionally, RevA has a long path in the GND plane where the load current flows. This path is between the (-) end of the shunt to the screw terminal block pads. This current causes a voltage drop in the GND plane, which can cause ADC errors since GND is the reference for the single-ended measurements. The load current should not be flowing in the GND plane per se. Instead, the load current path should be a stub off of the GND plane. The linkage between this stub and the GND plane must be made at the shunt (-) end pad so the voltage of the GND plane is equal to the voltage at the (-) end of the shunt.

Arduino code should declare boolean variables as "bool" rather than "boolean", and these variables should be assigned values of "true" and "false" rather than TRUE and FALSE, which required #defines.

This complies with the recommendations in the Arduino Reference:

https://www.arduino.cc/reference/en/language/variables/data-types/boolean/
https://www.arduino.cc/reference/en/language/variables/constants/constants/

The SSR versions sometimes have a slight undershoot effect at the tail of the curve. This is not completely understood but may be due to the current draw of the SSR LED. In any case, the best thing to do at this point is to allow the overshoot correction to correct negative overshoots. Unfortunately, this means that battery curves have their undershoot corrected, and it is believed that the undershoot in that case is "real". But since this is a PV IV curve tracer, the priority is making the PV IV curves correct.

Currently, configuration options that are no longer used stay in the IV_Swinger2.cfg file. They are ignored by the software, but clutter up the file and should be removed.

When resistance is present in series with the PV DUT and before the point in the circuit where voltage and current are measured, the effect is a reduction in the slope of the tail end of the curve. For example, long cables cause this. This is a simple Ohms' Law effect. Any point with current "I" will have its voltage reduced by I*Rseries. This effect doesn't change the current at the Isc point nor does it change the voltage at the Voc point. But it does change where the MPP is. The power at the MPP will always be lower when there is series resistance because power is lost in the resistance (I^2*R).

It can be generally useful to have the ability to compensate or "factor out" the effect of series resistance.

However, the main motivation for adding a feature to compensate for series resistance is to correct for an error that is seen when dynamic bias battery calibration is used. This error is believed to be due to the difference between the series resistance of the 2nd relay in the inactive state versus its resistance in the active state. Since the bias battery curve is taken with the 2nd relay inactive and the combined curve is taken with it in the active state, this results in an error in the final curve that can be on the order of 10% (MPP power).

This feature will be added to the Plotting tab of Preferences despite the fact that it is a calibration of sorts when used to correct for the dynamic bias calibration error described in the previous paragraph.

The compensation will be specified in units of milliohms. Negative values are allowed. This is necessary for the dynamic bias calibration error compensation because it is really a series resistance -delta- that matters, and that delta can be positive or negative.

Separate values will be maintained in the config for the non-bias and bias cases since they will most likely be different.

Calibration values are stored in the Arduino's non-volatile memory (EEPROM).

In order to test the case of a new IV Swinger 2 hardware, the application should have a feature that allows the user to easily invalidate the values in EEPROM. This could potentially also be useful if somehow the EEPROM gets corrupted.

This should be added as an option on the Calibrate menu.

When File->View Log File is selected, the dialog that comes up selects the current log file as the default choice. But when looking at previous results using the Results Wizard, the user wants to see the log file associated with the selected (old) run.

In the 25-Jan-2018 commit, the correct_adc_values method was modified to use parameters for the options rather than using the class properties. A battery_bias parameter was also added, but the code was not changed to use this parameter's value. This is a bug.

I have received requests to add support for temperature sensing.

The DS18B20 is a good choice for this because of the following:

• Only one Arduino input is needed
• Multiple temperature sensors may be connected to the same one-wire interface
• They are inexpensive
• Arduino library code is available
• Accuracy is more than adequate

When a bias battery is used with the PV cell version of IV Swinger 2, the final IV curve after the bias adjustment doesn't look right. Here is an example:

The tail end has a "hockey stick" appearance.

The reason for this is that the bias adjustment makes the simplifying assumption that the battery IV curve is linear. When the bias battery calibration is performed, the only values that are captured are the measured Voc and internal resistance of the battery (slope of the line). The battery curve is actually not quite linear - it is slightly bowed.

The curvature is subtle, but failure to account for it results in the hockey stick effect in the final IV curve. There is a magnification effect because the voltage range of the final curve is so much smaller.

To fix this, the actual battery curve must be captured and used for the bias calculation.

The photodiode used for the pyranometer has a sensitivity to temperature that causes the generated current to decrease when the temperature increases. To compensate for this, a TMP36 sensor can be placed close to the photodiode and connected to the ADS1115. The Arduino software needs to read the temperature value and the application software needs to process it and perform the temperature compensation. It should not be required that the TMP36 be present.

Observed when testing battery-biased PV cell curves with an old Dell Windows laptop:
- There are some large deviations in the curve that are not being corrected with noise reduction
- The points near the Voc end of the curve are unreliable

The first of these doesn't occur when I use my 2013 Macbook Pro. The second does, but to a lesser extent. There was already code to exclude the points near the Voc end of the curve, but it needs to be enhanced.

Presumably, the difference between the laptops is the quality of the +5V provided via USB to the Arduino (and used by the rest of the hardware).

The general noise reduction issue can be addressed by performing n.r. on the combo curve before performing the bias subtraction. This is in addition to the existing n.r. that is performed after the bias application.

The other issue can be addressed by always excluding the points with current measurements that are some percent (say 7%) or less of the first point's current measurement.

When the battery bias scheme was changed to use the full IV curve of the bias battery, the V_BATT and R_BATT values became obsolete and were no longer written to EEPROM. However, the EEPROM_VALID_COUNT value was not changed from 9 back down to 7. For a "new" IV Swinger 2 this results in the Arduino code reading garbage from those two locations. The "Swing!" button does not turn red, and the following message is found in the log file:

Bad EEPROM value message: EEPROM addr: 36 value: nan

Changing EEPROM_VALID_COUNT down to 7 is undesirable since there's an assumption that the number of valid entries never decreases in newer versions of the code - namely this check:

    elif eeprom_addr == EEPROM_VALID_COUNT_ADDR:
        if int(float(eeprom_value)) > EEPROM_VALID_COUNT:
            warn_str = ("WARNING: EEPROM contains more values than "
                        "supported by this version of the application: {}"
                        .format(self.msg_from_arduino))
            self.logger.print_and_log(warn_str)

Therefore it is preferable to just continue to write valid values (e.g. 0) to these locations.

When the "Battery Bias" option on the Plotting tab of Preferences is changed from Off to On or vice-versa, the currently displayed curve is redisplayed with the new mode. This is usually not what the user would expect or want. For example, suppose you swing a curve without a bias battery. Then you connect a bias battery for the next curve and change the Preferences option in preparation for that. You really don't want it to change the previous curve. On the other hand, it can be useful to toggle this option for cases that did have a bias battery so see the raw battery+PV curve before the subtraction.

The solution is to NOT redisplay the current image when this option is toggled UNLESS the run is selected from the Results Wizard.

Another related problem is the effect of the Restore Defaults button on the "Battery Bias" option. If Battery Bias = ON, it is unlikely that the user expects or wants that option to be restored to its default of OFF. It is better to exclude Battery Bias from Restore Defaults.

The description of the bias battery calibration process in the Bias Battery calibration dialog needs to be updated for the current quad binding post cell version design. Also, the first dialog that comes up when the Calibrate button is pressed needs to be updated.

The "relay is active-high" checkbox on the Arduino tab of Preferences should not be possible to check when the Arduino isn't connected. Currently it does complain, but it gives the misleading message that the Arduino code doesn't support that option. It also leaves the box checked even though the action was not taken.

The "sensor info" file should be changed to a more generic "run info" file.

The sensor info will continue to be written to this file, but it can also be used for any other hand-entered info about the run such as: module/cell type, tilt angle, shading conditions, sky conditions, etc. (It is also possible to enter temperature and irradiance info by hand as long as the exact same format is used that the software generates.)

For the most part, this is just a naming change since it was already possible for the user to edit the file when File->View Sensor Info File was invoked, and all lines that don't match the specific format of the sensor info lines were ignored. But this menu entry was disabled when there was no sensor info. So now the menu entry should never be disabled, and if the file does not exist (because there was no sensor info), then it must be created. It should have a boilerplate comment at the top of the file explaining what it is used for. Since the sensor info file was part of a release (2.3.0), this change should be backward compatible - i.e. the old file name (sensor_info*.txt) should still be recognized when looking at old runs from the Results Wizard. If File->View Run Info File is used on an old run with a sensor info file, it should be converted to a run info file.

When the Python code detects downlevel Arduino code, it displays a dialog with instructions on how to install the -latest- Arduino code.

Although the intent is for the Arduino code to be backward compatible, it is possible that the latest version isn't compatible with older versions of the Python code.

Therefore, it is better for the instructions to point to the URL of the Arduino sketch that was in the same release as the Python code, i.e. has the same tag as the version number of the application.

Although dynamic bias battery calibration is the recommended mode when using a bias battery, it should still be possible to perform a manual bias battery calibration and then, with the "Dynamic calibration" radio button set to OFF on the Bias Battery calibration dialog, swing a biased IV curve.

This works only if the bias battery and the PV cell are also manually connected in series external to the IVS2. It should also work if the bias battery and PV cell are connected to the 4 binding posts of the cell version IVS2.

That requires activating the 2nd relay before the curve is swung, even though no battery curve was swung with the 2nd relay inactivated first. If the battery and PV cell are connected in series manually external to the IVS2 (and connected across the bottom binding posts), turning on the 2nd relay is unnecessary, but harmless. In fact, even if there is no 2nd relay, this will still work.

The Arduino code now supports configuration messages at any time. Previously when the user changed an option on the Arduino tab of Preferences, the Arduino had to be reset. There was a noticeable delay when this occurred.

This wasn't a big issue, but it will be much cleaner to send config messages to the Arduino only for values that have changed and to not reset the Arduino.

The current Arduino code only accepts configuration messages from the host after a reset, i.e. in setup(). When the host code needs to make a single configuration change, it must reset the Arduino and resend ALL of the config messages. Until now, this hasn't been an issue since the only time config changes were made was when the user made a change on the Arduino tab in Preferences. A couple seconds delay in this case wasn't a problem.

In order to add support for dynamic bias battery calibration, however, it will be necessary to send config messages to change the state of the second relay. It is important that this takes as little time as possible since it is done twice per IV curve.

It is a simple change to the code to process config messages in the loop() function on each iteration, just as they are processed in the setup() function. This could be useful for other things in the future too.

The Arduino sketch version is normally of the form N.N.N. But for non-released versions, it may have a suffix of "beta" or other. This suffix should be displayed in the "About" dialog. It should not, however, be included in the support comparisons.

The apply_one() method in the Configuration class supports options whose value is the string "None" in the configuration file and sets the associated property's value to None (the Python unassigned value). This can be used to communicate that the configuration simply does not have a value for that option.

Currently, the only options that can have a value of "None" in the configuration file are those that are of type CFG_STRING, i.e. strings.

Support should be added for options with numerical/boolean types to have the same behavior if their value is "None" in the configuration file. This support will be needed for some future changes.

The fact that the IV curve "overshoots" the Voc point is finally understood. It is because the Voc voltage is measured when the relay is inactive and the rest of the points on the curve are measured when the relay is active. The current draw of the active relay causes the +5V supply voltage (from USB) to droop slightly. This means the reference voltage to the ADC (Vref) is lower. The digital readings from the ADC are always relative to Vref, e.g. a reading of 2048 is Vref/2. If Vref is 5.000 V, a value of 2048 translates to 2.500 V. But if Vref droops to 4.900 V, a value of 2048 translates to 2.450 V. If we don't compensate for this Vref droop, the voltages look higher than they should.

Fortunately, the overshoot correction that has been in the software all along is just what is needed. Voltage calibration is performed to the Voc point. Since we know that the curve should intersect at the Voc point, scaling the voltages of all points such that that is the case is just the correct thing to do. The Vref droop also affects the current measurements. Current calibration is performed to the Isc point. The Isc point (or the closest point to it) is measured with the relay active, so scaling the current of all points based on the calibration results in accurate values and no additional correction is needed.

For the most part, the only changes required are to comments and Help text.

The only code change is to only correct for positive overshoot, i.e. not correct for undershoot (as the current code does). It turns out that batteries have the property that their current goes very nearly to zero at a voltage below the Voc, and then the voltage slowly rises to the Voc value. For the bias battery calibration curve, we don't want to spuriously "correct" for this real phenomenon.

The algorithm for subtracting the bias battery voltage from the points recorded with the bias battery in series with the PV has the following problems:

• The battery curve has an undershoot effect at the Voc end. This
  affects the combined curve too, so it should "come out in the wash".
  But due to noise and the imperfection of the interpolation, it
  results in deviations near the Voc point. The solution is to simply
  discard points with very low current.

• If two points in the battery curve have the same ADC value for CH1
  (current), a divide-by-zero error will occur in the interpolation
  algorithm.

Additionally, the gen_bias_batt_adc_csv() method should set fix_isc and fix_overshoot to False for the correction.

There's a bug in version of Tk (8.5.9) that is included with OSX/MacOS versions since 10.7 (Lion) and up to at least 10.13 (High Sierra) that has the effect that menu items may become permanently disabled (grayed out). See https://bugs.python.org/issue21757.

The easiest way to reproduce this problem in IV Swinger 2 is:

• Open Preferences
• Try to pull down any menu - they will all be grayed out, as they
  should be
• Close Preferences
• Try to pull down any menu - they will still be grayed out, which is
  no good - only way out is to close the app and reopen

The bug is encountered when we use the grab_set() method to make a dialog "modal".

This can be solved by installing Python from python.org, but it would be desirable to avoid the problem as much as possible so anyone can run the (raw python) app on a stock Mac without hitting this bug. Not calling grab_set() in the Dialog class avoids the problem, but removes the "modal" quality of the dialogs that inherit from it. But this means that dialogs now may have to take specific precautions to restrict what the user can do while the dialog is open.

Note also that the built-in dialogs (tkMessageBox, tkSimpleDialog, and tkFileDialog) are all modal. They probably call grab_set() themselves. These are used for error/warning dialogs, simple prompts, etc. It is not worth the time it would take to convert all of these to non-modal custom dialogs. It's also much less likely that someone will trigger the bug when one of these dialogs is open.