Time for a very overdue update...
This is without a doubt the top of the list for most-everything in the sub-project category... It took a lot of time and patience, and as predicted, it absolutely had to be running on solar to be correctly fine tuned. Some things just really can't be properly emulated.
In the end, the entire score system had to be essentially completely rethought, which wouldn't be a first, but there really was no way to tell exactly what was needed while it was still bypassed to grid.
Just so happens that today catches just about every aspect of typical operation, so rather than snag and post individual plots, I just took screenies of the portion of the still rather primitive webapp that is used to observe/control it.
They don't all fit on one screen, so here it is sectioned up starting at the top... In this shot, the vitals.
This section is the final version of the brain, a bit different than originally envisioned...
And here we have the "extras", for quick reference to assist in setting up the various triggers and factors that pertain to energy production, use, and storage.
I'm holding out on what's behind "button number manual"... the rest of the webapp being slated to be revealed in a special way, just for you guys... I did tell you, after all, that graph pool comes together in a sensible way...
The vitals section hasn't really changed much, still reports the crucial info needed to know at a single glance what "state of charge" it's in, and the condenser temp thrown at the end of that because it was the best fit. It's used primarily to gauge thermal efficiency; deciphering such being more a black art than science really.
The decision system, as mentioned, was totally redone. My "score" idea was useful but I wasn't implementing it effectively to run on solar.
The score plot is still basically a set of weights and a balance, there's just less of them now, with most of the input being in the summing counterpart, "Pyro DSP". But before I go into that, a quick sentence or two about the remaining "score":
The two grey lines form the normal operation start and stop boundaries, start being on top. Green is an amplified and clipped version of "Pyro_Final_DSP" in the DSP plot. Black is a suppressed zero component representing the top 5% of battery SoC, and Red is the average of those two values. There's a third hidden value that never changes; it's the leftover remnants of the "user subjective" value... This is all delicate enough that for simplicity and expedience, I just tucked it away and hardcoded it in the software. This is what's responsible for the seemingly not-quite-average the astute eye might pick up on...
When red crosses the upper line, it initiates the compressor start sequence. Likewise, crossing the lower line shuts it down.
The source of the green line, the above mentioned "Pyranometer (DSP)" plot's final value, is somewhat complex in the way it's derived. First and foremost, the pyranometer is the basis of the entire signaling mechanism. This, in a nutshell, measures the available energy in the light hitting the panels, and while not a true pyro in the usual sense, it's close enough for all I needed it for, and that's strictly to cue the fridge. The light grey line ("Pyro_Raw") is the signal as the ADC sees it, and as you can see, can be very volatile. In order for this signal to be useful, it needs to be smoothed out somewhat, enter "Pyro_20_Min_Avg", in blue. This line is the "crystal ball" so to speak that attempts to give the algo a heads up about what the sky is likely to be doing next. It doesn't tell the future obviously, but uses the last 20 minutes (in 5 minute sample intervals) to pass trending light conditions to the decision system. This is a balance in the sense that if it's too short, the compressor cycles potentially unnecessarily, and if too long, can leave it running on battery, the primary condition the whole design is intended to avoid.
Next up is "Pyro_Boost", in green, which is kinda mislabeled, as it's function is to attempt to start the fridge early if the quality of the earliest light meets minimum criteria to do so. This is probably one of the most difficult entities to work out and set up... and only experimentation and observation over time with many different conditions presenting can properly configure it. This also isn't a static pulse. It is slid earlier and later based on a crucial but borrowed piece of code. Thanks goes out once again to Ross for helping me with this, math certainly isn't my strong suit and there's plenty of it going on in there. As mentioned earlier, this graph views primarily the summed weights, and this bump is added to the 20 minute average.
The last piece of magic in this puzzle is the magenta line, "SoC_DSP". Again, somewhat misnamed, it's also somewhat of a redundant input. It's purpose, when combined with the other battery SoC (in the score plot), is to encourage it to stay running when the battery has been recovered. The two weights serve slightly different purposes. This value effectively increases the perceived available energy, while the other is used primarily to keep the compressor running until it actually IS running on battery. This is essentially the boost pulse's counterpart for extending operation until the last available light of the day is gone.
As previously mentioned, all of the major features of the algo are visible in these two plots for today. The Boolean plots above the two control plots represent the various states of different aspects of the rest of the system. There's a lot happening there, but the keys that I'd like to really like to point out are the "Truck_Running" and "Fridge_Emergent"... the others are either low/no relevance to the fridge, or are fairly self explanatory.
The "Truck_Running" key is just what it says, the mystery for some is in the "why"... It might not have much actual effect on the compressor, but my thinking behind checking for this was to prevent excessive forces on the internal components of the compressor. I tried my best to reduce risks as much as I could given everything going on overall, this was one of them. I can't afford to replace the unit, even tho it wasn't that expensive really to start with (around 100 bucks at Lowe's). Nutshell version of "compressor 101"; the motor/compressor assembly is suspended by springs inside the black ball many of us are familiar with. I've personally seen that one mode of failure is the compressed side tubing leading back to the case breaking off, leading to a "running but not doing anything" unit. Bumps, gyro effects, etc. So the ultimate last piece of code in the software kills it no matter what (can't be manually overridden even) to protect it.
The other key worthy of mention at the moment is "Fridge_Emergent". Normally, the blower between chambers is disabled, and natural "pooling and spilling" is exploited to give the ice core the advantage during operation on solar. Aside from the truck running and manual operation, in auto mode it starts and stops by one of two sets of criteria. The above describes the normal cycle. It also is shut down when the fridge chamber gets too cold, presently set at -2.5C.
Fridge_Emergent however causes it to start when the fridge chamber gets too high (presently +5C), and runs the inter-chamber blower at full throttle, so as to drop the temp as quickly as possible and shut back down. It's very likely that if this condition occurs, everything is already short on energy supply, and it's just about certainly running on battery (again, this entire thing's point is to avoid that if at all possible). It keeps track of which trigger started it so that it knows which criteria should shut it down. This unfortunately induces an undesired behavior if the sun should come out, but it actually still remains an unverified function - it's never actually reached that point during operation since this was finalized. I've emulated it best I could without actually letting it "fall up" to temp. I may try it some day, as occasionally it does need defrosting, but in the mean time, I'll likely already be very aware that things have gotten to that point.
The blower, when the compressor is not running, operates via analog feedback, just as in the original design, attempting to hold the air/water temps just barely above freezing.
That's all I've got for now (Whew!). Until next time...