TL;DR: New TFC V1.5 software update fixes some nasty bugs!
While I wait for Nifty Shifter parts to arrive, I spent some free time and finally finished the much needed V1.5 Software Update for Trinity V2 Fan Controllers. As it turns out, there were quite a few pretty nasty bugs in v1.4 so I’m glad to have stomped all the ones I’ve found so far.
https://drive.google.com/open?id=1vkFcHYKjEh7g-uJK9JvkhCO3rLrcXKSS
So, the summary then; Added a back option to the main sub menu so you can actually go home, tweaked the light sensor value to be more sensitive, Temperature will be more accurate and faster now, fixed an issue where active relays would mess with the temperature, fixed an issue with the GoHome timer getting stuck, and fixed an issue with the Manual Temp Shift option causing havoc when trying to adjust fan temps.
So, from the top then. Figuring out the actual temperature based off a thermistors resistance is tricky, but with some hella nerdy formulas it can be done. I have switched from BetaC to the Steinhart-Hart equation which is the standard for calculating a temp sensors resistance curve. This formula is a lot more accurate then the previous, especially at the far ends of the scale, so expect to see the real temp throughout the entire range now.
With this formula update, so too has the User Adjustable Temp Probe variables been updated. There are now 3 inputs, Coefficient A, B, and C to be adjusted. The menus are broken down into +-0.050 and +-0.001, indicated by the decimal in the title screen, to adjust the numbers more efficiently. To find these 3 numbers you will first need 3 data points of your sensors resistance at a specific temperature, spaced fairly evenly and at least 10ºC apart.
These will get fed into a Steinhart Calculator(Link Below) and it will give you the 3 Coefficients to put into the TFC. Notice these numbers are at negative powers, but still get entered into the TFC directly as shown; A = e-3, B = e-4, C=e-7. It’s a lot I know, but this will guarantee an extremely accurate estimated curve for nearly any sensor you’d like to use through only 3 points.
https://www.thinksrs.com/downloads/programs/therm%20calc/ntccalibrator/ntccalculator.html
Accuracy was a common theme here as I have adjusted a lot of other things, like getting a better reference voltage which helps us find better resistance, adjusting the ohm calculation accuracy down to 0.5% now, adjusted the analog limits to stay within range better, and even figured out a basic way to remove temp spikes caused by added relay current.
So more on that last one. I didn’t find this out until many months later, but apparently you do not want to run your sensor analog ground through the same ground wire that might be subject to “large” load changes, in this case the relay coils. Each coil can pull 100mA or more, and each one would throw off the resistance that we read from the sensor. This is problematic because when a relay was activated, the temp would artificially rise and might even trigger the next relay, continuing a domino effect and scaring the crap out of a watchful user. Seeing 245ºF when you’re expecting 225ºF is a big difference! haha.
So I got stupid nerdy on this a while ago and tried to calculate this load based offset curve across the whole input range and eventually got down to a formula that could be offset by the amount of current flowing for near perfect correction, but the issue then became how to calculate the relay current without a reference resistor. The temp sensor changes and the relay current actually changes a bit too as it warms up which just over complicated things too much. So I went KISS and just took the difference before and after a relay is activated and just subtracted that from the current temp for a “close enough” approach. In short, the temp shouldn’t jump around when fans are turned on now, yay.
In the previous update, the temp reading had a fair bit of averaging applied to keep the reading stabile. This also masked the relay problem a bit making it harder to notice. Well now that we have fixed that best we could, I switched to an exponential averaging technique which is dead-nuts simple, requires fewer resources than the old style, and will respond to new temperature faster while still staying fairly smooth. In short, more weight is applied to newer readings, so the average is more biased towards the current reading. Also with infinite-impulse-response based averaging, we only need to keep track of 2 variables instead of an array of 10 or more which saves precious space!
So onto some more mischievous bugs now! I found an issue with the GoHome menu timer that would cause it to bug out and leave the user stuck in the home screen till a power cycle. I found a check flag with a wrong comparator (== instead of = for a normal flag set, opps,) but that still wasn’t it. After digging deeper, I found that the wait time variable was being overloaded and once it looped back to 0 it would always be lower than the current time, trapping the user in the home screen.
For the super nerds, the time variable is stored as a byte (0 – 255 seconds,) then it is expanded to milliseconds (* 1000), and finally added to the millis flag so it knew what time to go home. Well when arduino did the math, even though the final variable was a 32bit, it was only doing the millisecond upscaling at 16bit, so at 35 seconds the 16bit was overloaded and giving us a bogus smaller number. The fix was to force it to convert to 32bit math and then all was happy again, sheesh.
Now, if that wasn’t annoying enough, I also found a huge bug with the Manual Temp Offset Shift variable that made it basically unusable and a little dangerous. So in manual mode, you are allowed to pick the on and off temp for all 3 fans. That means you are trying to juggle 6 different temps which is a drag if you just want to move your range up or down a little bit. Well, the Shift variable would let you modify everything up or down by what you select, then you could go in and do more fine tuning later if needed.
Well the first issue was that adding 1 to shift actually added 2 which was our first sign of an issue. Second, if you then tried to edit any of the temps with Shift set, the temps would cycle wildly and you couldn’t adjust them at all. This was especially not good because the EEPROM that saved this value only has a limited lifecycle of like 100k so you really don’t want to go saving over something tons of times per second! Issue turned out to be that Shift was adding to the main temp value every loop, so when we got back to the edit menu loop, that value would be different and so it would save the new value and it would continue again. Now I subtract the offset before it is saved and everything is happy again.
I also adjusted a few things to save some space since we’ve been floating around the 99% full mark for a while, like moving some simple repeated tasks or menus into their own function, and in one case doing a bitshift for division since it was smaller in size then the regular way. Oh the fun of pushing things to their limits, that’s why I’m so relieved that I have tons of space on the REMs now so I don’t have to do this all day! Anyway, my brain is mush so enjoy the TFC V2 closer to what it’s full potential should be now!
Trinity V2 Fan Controller v1.5 update log:
- switched from betaC to Steinhart equation
- added better ref voltage calc
- switched to exponential averaging
- fixed analog limits
- 0.5% ohm accuracy
- fixed bool averaging
- basic relay drop temp correction
- added main menu back option
- fixed GoHome timer overloading on certain numbers
- adjusted dim sensitivity
- editTimer Functioned for space
- tOffset function to fix temp looping and saving issues
- updated custom temp edit menu to Co A,B,C
