Yep, I'm working on this. But there has been a delay based on Fusion software development. The delay is also related to Analog output availability. If push comes to shove, I will try something else, but I hope analog output is coming down the pike. I want servo too, but I want analog out first.

Oh and my vehicle changed (completely different HVAC setup), so I had to come up with another shell (physical connections, and software methods to make the core of my control scheme perform the same functions IRL).

I should also be getting some really good HVAC info from a recognized OEM expert in the field. I'm even planning to go to one of his seminars later this year (Unfortunately I couldn't make the one that is going on this very moment).

But for right now, I'm beta testing the new MDX software, working with the developer so that it works well enough that I won't need to have my own software written at this point. FusionControlCenter software should be generic and powerful enough once completed and polish to handle this. There are a few functions I hope can be added down the line, like the ability to save variables that were calculated during runtime.

That's great to hear you are in touch with an OEM technical expert!

The thermodynamics itself isn't all that bad, but the lack of fan curves, heat transfer, and sunload functions makes this process very difficult. If he can give you some insight into how the OEMs do the calculations, it could greatly simplify your work. If you had a general idea of how they do things from the factory, the initial calibration might not be needed. Simply use the general approximation of the constants based off vehicle type (I'm sure the OEM's have general numbers in mind when they start the process too) and then fine-tune them by checking to see if the the temperature reached in a set period of time is lower or higher than what is predicted by energy balance.

You could even make it dynamic, fine-tuning the constants for a time interval based off the energy balance performance of the last interval. This would make the accuracy of the constants themselves nearly irrelevant. As you know, with multiple constants you are trying to solve for, there will be multiple sets of constants that will give the same solution, at least in the short term. By changing them dynamically, calculating the actual constants for the vehicle won't matter, because you have a solution, a set of constants, that will work for at least the next 5 minutes.

It's similar to how Solver in Excel works. Often, when using Solver in conjunction with least-squares regression to match complicated model functions to data, the constants you get are not physically possible (in the case of using Excel to model phsyical reality). Even with that in mind, the resulting solution does match the data over the range given. Eventually, the model will no longer match the data, but in the short term, it will match it very well, without actually knowing the constants.

Depending on what the mathematical equations of each function are (exponential, power-law, hyperbolic, etc... ), all you need is a model using that sort of function (or even the whole series of functions for all the thermodynamics inputs and outputs) and the energy balance data from the past 5 or 10 minutes. Then use Solver-methodology (I forget the numerical method used, I'll look it up in my numerical method book tonight, though it'll be much later) to tweak the constants so that the model match very closely to the constants in the past interval and apply those constants to the next interval.

Now that I think about it, an even shorter interval might be useful, to take into account varying sunloads, doors opening/closing, windows being down, stop and go traffic, and the adding/subtracting additional passengers. Possibly 1 minute intervals?

I'm a Petroleum Engineering student, and while we are often warned about not allowing constants to range outside their phsyical boundaries when using regression with Solver in Excel, that is because we are attempting to extrapolate trends 30 or more years past the end of the data for our reserve calculations, so the model must be technically sound, sometimes at the expense of model-data correlation. In the context of an automatic HVAC system, there is no need to extrapolate very far in the future, because you can simply take another measurement and do some quick calculations.

I've been reading all your threads on the topic, and I think you've been doing great work!

Originally Posted by greenman100

The biggest issue is interfacing our board with your truck.

It's like writing a book in english, and trying to get the rest of the world to read it.... you need a translator, and pretty much every car speaks a different language.

Luckily the vehicle I've chosen has simple variable resistor A/C controls (I think). It makes it a much simpler process on the hardware side. I could probably even do it with simple digipots. Not the most elegant solution, with the system having to step up and down through all the selections (low to high fan speed, cold to hot temp, and selecting the modes, etc), but it's no worse than the way it currently is. You have to roll over each selection when doing it manually, I don't really mind if it has to spend a splt second while doing it automatically.

Hopefully the software will soon allow coding it to save it's current position and load it when starting the following time, and just in case something crashes without saving the positions, a reset function could be written that increments the digipots until it is sure they are at a min or max value, resets the position variable, then restarts the incrementing from there. Again, not quite as elegant as a hardware solution (like the analog input feedback mentioned in the analog output board thread or storing the setting on the Brain itself), but it would work.

Luckily the vehicle I've chosen has simple variable resistor A/C controls (I think). It makes it a much simpler process on the hardware side. I could probably even do it with simple digipots. Not the most elegant solution, with the system having to step up and down through all the selections (low to high fan speed, cold to hot temp, and selecting the modes, etc), but it's no worse than the way it currently is. You have to roll over each selection when doing it manually, I don't really mind if it has to spend a splt second while doing it automatically.

Hopefully the software will soon allow coding it to save it's current position and load it when starting the following time, and just in case something crashes without saving the positions, a reset function could be written that increments the digipots until it is sure they are at a min or max value, resets the position variable, then restarts the incrementing from there. Again, not quite as elegant as a hardware solution (like the analog input feedback mentioned in the analog output board thread or storing the setting on the Brain itself), but it would work.

The plan for analog outputs is the following:

A 64-step digital pot, connected to a variable low LDO regulator rated at 5 amps. It would take up 3 digital outputs and 1 analog input for feedback.

the next stage would be PWM capable of 30 amps or better

also, check that car - my car uses a resistorpack for the blower motor, but the vent doors are all cable-actuated, so I'd have to retrofit servos.

The thermodynamics itself isn't all that bad, but the lack of fan curves, heat transfer, and sunload functions makes this process very difficult. If he can give you some insight into how the OEMs do the calculations, it could greatly simplify your work. If you had a general idea of how they do things from the factory, the initial calibration might not be needed. Simply use the general approximation of the constants based off vehicle type (I'm sure the OEM's have general numbers in mind when they start the process too) and then fine-tune them by checking to see if the the temperature reached in a set period of time is lower or higher than what is predicted by energy balance.

You could even make it dynamic, fine-tuning the constants for a time interval based off the energy balance performance of the last interval. This would make the accuracy of the constants themselves nearly irrelevant. As you know, with multiple constants you are trying to solve for, there will be multiple sets of constants that will give the same solution, at least in the short term. By changing them dynamically, calculating the actual constants for the vehicle won't matter, because you have a solution, a set of constants, that will work for at least the next 5 minutes.

It's similar to how Solver in Excel works. Often, when using Solver in conjunction with least-squares regression to match complicated model functions to data, the constants you get are not physically possible (in the case of using Excel to model phsyical reality). Even with that in mind, the resulting solution does match the data over the range given. Eventually, the model will no longer match the data, but in the short term, it will match it very well, without actually knowing the constants.

Depending on what the mathematical equations of each function are (exponential, power-law, hyperbolic, etc... ), all you need is a model using that sort of function (or even the whole series of functions for all the thermodynamics inputs and outputs) and the energy balance data from the past 5 or 10 minutes. Then use Solver-methodology (I forget the numerical method used, I'll look it up in my numerical method book tonight, though it'll be much later) to tweak the constants so that the model match very closely to the constants in the past interval and apply those constants to the next interval.

Now that I think about it, an even shorter interval might be useful, to take into account varying sunloads, doors opening/closing, windows being down, stop and go traffic, and the adding/subtracting additional passengers. Possibly 1 minute intervals?

I'm a Petroleum Engineering student, and while we are often warned about not allowing constants to range outside their phsyical boundaries when using regression with Solver in Excel, that is because we are attempting to extrapolate trends 30 or more years past the end of the data for our reserve calculations, so the model must be technically sound, sometimes at the expense of model-data correlation. In the context of an automatic HVAC system, there is no need to extrapolate very far in the future, because you can simply take another measurement and do some quick calculations.

I've been reading all your threads on the topic, and I think you've been doing great work!

Luckily the vehicle I've chosen has simple variable resistor A/C controls (I think). It makes it a much simpler process on the hardware side. I could probably even do it with simple digipots. Not the most elegant solution, with the system having to step up and down through all the selections (low to high fan speed, cold to hot temp, and selecting the modes, etc), but it's no worse than the way it currently is. You have to roll over each selection when doing it manually, I don't really mind if it has to spend a splt second while doing it automatically.

Hopefully the software will soon allow coding it to save it's current position and load it when starting the following time, and just in case something crashes without saving the positions, a reset function could be written that increments the digipots until it is sure they are at a min or max value, resets the position variable, then restarts the incrementing from there. Again, not quite as elegant as a hardware solution (like the analog input feedback mentioned in the analog output board thread or storing the setting on the Brain itself), but it would work.

Thanks for all the hard work guys, you've been an inspiration!

Thanks for the encouragement. Yeah, we're pretty much on the same page with the short term testing method of solving the multiple-solution-to-the-equation problem.

I hope to have something substantial done by the end of the year. I'm sorry so slow, but it is a hobby, I want to allow myself to use the training I'll get, and stuff takes time.

I think one of the great things about solving for constants on a continual basis, and not starting with "exact" values, is that it takes into account the changes and even though the total square inches of aluminum in the heater core is unknown, we will have a variable that represents it and others over time, and over time it will more closely represent the actual value.(quite optimistic point of view though)

Wow, now that I think about this, you could possibly even do this without any sort of thermodynamic calculations Though it wouldn't be applicable to every vehicle like the dynamic approach.

I'll have to wait until I have my new truck with a CarPC with a FB and sensors installed, but I think I can come up with a model (specific to my vehicle). I'll simply gather a large amount of data, with varying outside temperatures, desired inside temperature, blower speed, hot/cold door position, and possibly humidity. I'll probably set it to record data points every 15s or so for the 1st ten minutes I drive, every time I drive, for a few months.

Then I'll use a software package created by a world-renowned professor of mine in the field of numerical methods and correlations (Dr. Peter Valko) to create a model based off just those variables measured. The true constants will be built into the data gathered and his software package comes up with amazingly complicated correlations and models. If I gather enough data points, the model will match my truck's thermodynamic behavior very well. Then I'll just have to plug my current interior temperature, current exterior temperature, desired temperature, and humidity, and it will spit out a fan speed and hot/cold position.

I'll just set it to constantly update the speed and position based off the variable data being gathered. The model itself will take into account energy balance to maintain temperature once the desired temperature is reached.

I think I would prefer this to the thermodynamic method, instead of matching the theoretical model the to the data you are using a model derived directly from the data. The nice thing about this method is that it will take into account any "hidden" variables that the thermodynamic equations do not account for. You are operating based on the behavior of the vehicle, not the thermodynamic theory, which may be imperfect.

Unfortunately, this method would not be dynamic. So it's a trade-off. More accurate in predicting real-world performance, but less adaptable to change (would be different with passengers, tint, etc... )

I've thought a lot about that. And perhaps I may use similar method, but still constrain it with boundaries based on thermodynamics. I really want whatever I do to be fully portable. Great ideas.

Have you ever thought of combining the two methods? Develop a data-derived model using all the input variables, but still have it vary the constants based off the the past interval's actual performance?

That might be the best of both worlds, a model derived directly from the data that takes into account all variables and constants, known and unknown, and then you tweak the constants in the model using the dynamic method based off energy balance performance.

Though the only way I can think that would work would be to develop a general model based off data from multiple types of cars. Gathering data would be an issue, because I don't think there's too many people aside from you and me who would be willing to install multiple sensors and gather months worth of data in order to improve the general model.

If I was an OEM with all kinds of R&D money, that's what I'd do. Of course, that's probably what the OEM guys have already done

My plan is that the tests are developed such that, despite the make or size of the vehicle, the model is the same.
There is very little data I think the user will have to manually enter... if everything goes as planned.
It doesn't really matter what the initial values are, if they tune in over time.

My plan is that the tests are developed such that, despite the make or size of the vehicle, the model is the same.
There is very little data I think the user will have to manually enter... if everything goes as planned.
It doesn't really matter what the initial values are, if they tune in over time.

I just meant the data that would need to be gathered to develop the model, the end user wouldn't need to input much of anything except desired temperature.

How are you planning to have the value update? Will it be an average over time (possibly the past x hours/days)? Or will the values for the last interval recorded simply over-ride the previous values? I can see how both would be of value. Maybe both? Track the previous interval, factor it into the overall average, and then make a weight average of the two, with the previous interval being more heavily weighted?

I don't know if I'd want the last 5 minutes solely determining the performance for the next 5 minutes, because things can change rapidly and I'd prefer a better overall average performance. Then again, I also don't want the overall average for the past x hours/day solely determining the next 5 minutes of performance if my current conditions aren't average. Something like a 70/30 past interval/time average weighted average maybe?

it was a half-step method where the constant was an average of the last X stored values while thowing out the ones that didn't fit the trendline within a tolerance. Then as a new test is satisfied, the new constant canidate is averaged with the currently used average constant value. That watered down average of current and recent becomes a new value in the array of X stored values (the oldest is bumped out).
The evolution of the constant would be very slow and conservative that way, I think.

it was a half-step method where the constant was an average of the last X stored values while thowing out the ones that didn't fit the trendline within a tolerance. Then as a new test is satisfied, the new constant canidate is averaged with the currently used average constant value. That watered down average of current and recent becomes a new value in the array of X stored values (the oldest is bumped out).
The evolution of the constant would be very slow and conservative that way, I think.

Very nice, I musta missed that post!

It looks like servo control and analog outputs for the Brain should be along shortly, making this project much closer to a reality!