SmartIO AnalogInput voltage steadily climbing

[Ornamus]

We've been coming across an issue with trying to use AnalogInputs - the voltage reading appears to steadily climb a non-insignificant amount for a sustained period of time, which makes it nearly impossible to utilize something like a potentiometer for homing or controlling a mechanism. We initially wondered if this was just an issue with our potentiometer or another sensor plugged in to the SmartIO, so we made the following changes:

1. Unplugged everything from the SmartIO
2. Added a jumper cable that connects the 3.3v SmartIO output rail to the signal port, allowing us to read the rail voltage as an AnalogInput itself.

This still demonstrated the issue, which leaves us wondering if we have a hardware issue or not. We've also tried the jumper in multiple different SmartIO ports.

This chart shows roughly an increase of about 0.0075v per minute, which is 0.227% of the total range (0 - 3.3v), which means our potentiometer drifts about 0.81 degrees per minute if my napkin math checks out - enough to make mechanisms consistently initialize incorrectly. Notably, this steady climb seemed to continue for about 40 minutes, until the value seemed to stabilize at approximately 3.295v. This makes me wonder if maybe something is causing the 3.3v SmartIO rail to not reach it's intended target for a sustained period.

I'm curious if anyone else has seen this behavior or can replicate it. The charted value is the output of AnalogInput.getVoltage() - we're using Java, and are on firmware 166.

The next thing we going to test is to attempt to use our jumper cable reading to account for the drift manually, since RobotController.getVoltage3V3() is not implemented fully. This will hopefully let us normalize our potentiometer reading similar to how the AnalogPotentiometer class does.

[Kevin-OConnor]

I know LL root caused this to gradual heating of the Gnd protection fuse and had some ideas for (I'm presuming HW) fixes. @bhjelstrom anything you want to add here?

[desertgreg]

It does appear to be related to the GND fuse resistance changing as the board warms up. We are building a prototype to test an alternative fuse implementation. We might have to remove the fuse since fuses are sensitive to temperature. The GND fuse was only needed to protect against a direct short from battery/PDH to smart port IO GND which seemed to be an extremely rare event for Robo-Rio. We would of course prefer to have all pins fully protected but it might be an unacceptable tradeoff. This was a great find!