It looks like the hardware capabilities should be available to make this soon.

After that, I'm sure there will be plenty of coding to do.

Once I have my new vehicle, I'll get to work right away on getting my carputer into it so I can begin recording data. It'll be interesting to see how H3rk's approach and mine play out. I will play to my strengths and stick to mainly dealing with modeling and correlating, basically using what I talked about above, completely ignoring the thermodynamic functions involved, and develop a completely novel model using my professor's software, based only off the input variables of cabin temp, outside temp, desired temp, and possibly humidity (I'd rather not use humidity, but I think it has enough of an impact to make it worth accounting for, at least in the data gathering stage). By it's nature it will account for the thermodynamic processes involved, but I highly doubt the model generated will match anything the OEM's use, as it will be unique to my vehicle and I very much doubt the auto industry uses the oil-industry correlation-generating software that I will be. When generating the model, I'll solve both with and without the humidity data and see how well the models work out.

I think the upside to this method would be a minimized number of constants needed due to the novel nature of the model versus the combination of multiple thermodynamic models as used in H3rk's method.

From there, I'd use a similar approach to H3rk's, with a rolling array for each constant (though the constants themselves would be different because of the different models) of the past x iterations to calculate an average constant to be used for the next iteration.

From what I understand, H3rk's approach will use previously established thermodynamic models, starting from approximate constants and fine-tuning over the life of the system. The nice thing about this method is that it is based on established thermodynamic models that are currently used by the OEM's.

The simultaneous upside/downside of both our methods is the necessity of using a numerical method to find a solution for fan speed and door position, the upside being that you don't actually need to know the constants (though if fairly simple numerical methods are to be used, you need a reasonable approximation as a starting point; if more complicated methods are to be used, you don't even need reasonable starting points, just start all the constants at 1 and let her rip! ).

The flip side of that coin is that by not actually knowing the constants and instead solving them iteratively, you don't get a unique solution. Multiple solutions will exist for the same set of data, and most of the results will likely not make sense when viewed from a physical reality context. H3rk, you will likely find that if you attempt to set realistic boundaries for the constants, one or more of the constants will quickly go to the max/min of your realistic range and won't shift from those values, no matter the number of iterations. Much of this will depend on the level of sophistication of the numerical method you use to find the solutions and the starting point you are solving from, but it will likely present itself.

It'll be interesting to see how both the models work out. I'll have to see how adaptable my model will be to a new vehicle. I have a feeling it will be slightly more touchy, especially if it reduces the necessary number of constants needing refinement, as the variance between vehicles will have to accounted for with less variables to tune with. Once again there is a flip side to this, as less variables/constants means less possible solutions and an increased likelihood of reaching the correct (or close enough to correct) solution.

Like I said, should be interesting

## Bookmarks