Originally Posted by drk
You can do all this with the MDX version, using mathematical functions, variables, and IF/THEN statements. All we need to add is the ability to save variables long-term in some file.
It looks like the hardware capabilities should be available to make this soon.
Originally Posted by greenman100
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! :cool: ).
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 :nutz:
The "coding" shouldn't be bad, it's all logic-block based
Originally Posted by drk
And as always, beyond the core control scheme, and even for those happy without automatic, there are a few different ways the physical connections can be done, categorically speaking. Most will be happy with simulating button presses and knob turns, thus interfacing with the stock control head as a robotic controls manipulator, some will want to fully tear out the control head and hand over the low level controls to the computer, and some will want to retain both.
I was originally signing up myself for the middle version, but being that each of my servos are controlled by a (what appears to be) 1wire bus, where locally the servos decode the message (if it's meant for that servo) and adjust the servo to the position rrequired by it's packet of data, and then it sends a 'done' message to the control head. I know that FB can't do this, and I don't want to gut the servos so I am going to interface with the factory control head. I wanted to make it so that I can still use the factory controls as inputs to the brain, where the display will keep up on the status, but then the physical controls would turn by servo if I changed the setting with the touchsreen... but looking at the setup, I'm not so sure it's remotely possible... but that's just fancy extra stuff.
I was actually looking into something similar earlier today. What I found was motorized potentiometers. All the ones I found weren't too expensive (something like $4/unit), and seemed fairly simple to adapt into use with an FB. The motor controls the potentiometer, or it can be adjusted manually with a knob.
Originally Posted by h3rk
The motor turns anytime it recieves anywhere between 3-12V DC and turns in reverse when the voltage is reversed. Would it be possible to control this with the new FB's servo controls or analog out? :confused: You'd need to be able to reverse the polarity of the charge to go in reverse. The potentiometer itself would basically be a feedback loop for the FB, hooked to an analog input to monitor knob position (in the case it has been changed while the system is off or booting).
Then you could rig up one of the motorized potentiometers behind each of your current A/C knobs and be able to use your A/C when the PC power is on AND off. I'd probably relocate my factory A/C controls to the glove comparment or inside the center console, just as a backup when the PC is down.
You could even mount the controls out in the open and watch the knobs turn on their own when you change the settings on the PC or the automatic system adjusts itself! :cool:
EDIT: Maybe you can use a digital output to control a smaller scale version of this.....
http://www.adc9001.com/index.php?src...current-MOSFET in conjunction with a relay that blocks the circuit. So when nothing is being changed, polary is normal and the relay is closed. When you want to turn the motor clockwise, the FB just opens the relay, when you want to turn counter-clockwise, it reverses the voltage and then opens the relay. This may be outside the realm of possibility, but I'm just brainstorming. It's probably easier to find a motorized potentiometer that operates without a polarity reversal.
2nd EDIT: http://www.specsensors.com/custom.asp#motor If you go there and scroll down to the motorized potentiometers, they have a compact .674" designed to be used in aircraft cockpits. It might be right up your alley, though it doesn't mention the input voltages necessary to turn the motor either direction. That would be much simpler than what I just mentioned above, just using a single analog output and input on the FB. Output to control movement, input to read current position.
The problem then remains of keeping the factory controls. You could possibly use 2 of those motorized potentiometers, one attached to the AC control board, the other to the factory knob mounted somewhere, and have them sync with each other in the FB software, using 2 analog inputs and outputs per A/C control knob.
Well, I think that's pretty much the right idea with the MOPs you were talking about. In fact, I just purchased a few of the ones you're talking about. At first I was looking for 10K pots, and a few companies look like they have them, you can even get custom shaft lengths. But I think the cheapies will be fine for starters. I called the guy up and had him swipe it, since he didn't have any more specs than what are on his site, and from the sounds of things, they are 340 degree electrical. I was whipping up some stuff with a simple PIC16F684 (since that's what I have with my PICkit1 Flash starter kit) to play with PWM, ECCP, and the circuit shown in their Application Note AN893. But I think these motors will work just fine, probably with a DPDT relay. Using the 20K pot as a calibrating and feedback tool. I'll just leave the rest of the circuit hooked up to the switches. It doesn't get easier than that.
I had some problems with figuring out how to turn these switches, since the rotating part is the outer shell of the donut. The inner sleeve goes all of the way out too:(. To make things worse, this setup relies on the PCB mounted LEDs to light up the switches, so inside of the donut shaped pot is a white sleve (reflector) which moves in and out just about 2-3mm for the center pushbutton. Inside the white sleeve is a clear plastic used to carry the light to the front of the dial (like fiberoptics).
My plan is to cut a groove to in the sleeve and the clear, to allow for a turning center shaft to rotate as far as needed at the front end of the shaft will be a 90 degree flat piece that will be locked to the outer, movable(shown in blue) part of the dial potentiometer used in the factory unit. I will have to shorten the inner (shown in red) part to allow for this.
As far as going through the PCB from behind, I will have to remove the center LED which illuminates the light on the front pushbutton through yet another thin white sleeved clear plastic piece. That piece is going away and I will add another LED up front.
I will be trying out some crystal clear cast resins for the rotating shaft and 90 degree piece and hopefully passing through a few gaps wont totally kill the light transmission for the symbols on the front button plate (still coming from PCB mounted LEDs hopefully).
I don't have to worry too much about drilling the PCB the only thing I will go through is the trace for the removed center LED, and I have some pass-through holes upstream (but downstream of the resistor) I can use to connect the relocated center LED.
That was a mouthful. This part wont take too long, hopefully, as I want to get back to the software part soon. I'll have something more when the servos come in, that is if I don't die from the resin fumes.
I forgot to show the second relay driven by the brain to turn the motor on/off in addition to the on-forward, off-reverse relay; it goes up in series with the 3-12V power supply, before it branches, if anyone cares or didn't know. lots of outputs...
Just in case anyone wondered, my car only has manual factory HVAC. I wanted one to play with. I also wanted one with "AUTO" positions. So the head I'm working with came in the mail. There will be some tricks (circuitry)...and more outputs involved with having the fan and mode dials go to auto during automatic operation, while allowing the brain to take control of the mode and fan speed and adjust without using the aforementioned motorized pots. And all of this will be in manner such that in addition to the front panel controls being inputs to the brain's HVAC control logic; without the brain, the front panel controls will function like normal.
Awww but that takes all the fun out of watching the dials spin magically on their own while it's working automatically :p
Originally Posted by h3rk
How will you deal with the time in between starting the car and the PC being fully loaded? Seems to me like there'd be an issue with the dials being on "Auto" when you have no OEM auto-AC capabilities. Would you have to wait for the PC to be fully loaded for the AC to come on if the dial was left on "Auto"? :confused: That might lead to the same issues as having just the FB control you AC: having to wait until the PC is fully loaded to have your AC work. Now you could adjust the system manually until the PC is loaded, then turn it to "Auto" and let the PC take over, but that almost defeats the point IMO.
I like the idea, because I'm sure the OEM HVAC dials weren't designed to be twisting and turning all the time with an automatic system controlling them, but if it costs me start-up functionality, I doubt I'd implement it.
I guess there could be a few ways around it. One that immediately comes to mind is that when the PC is shutting down, the FB automatically turns the MOPs from the "Auto" position to whatever dial position is the equivalent of it's current settings (blower speed, door position, vent settings). That way, at least you'd have some AC while the PC is booting, and it would be somewhat effective. Then, when the PC is loaded, it would automatically turn the dials to "Auto" and take over.
Also, when the dial is turned to "Auto", how will you control the blower/temp/vents? :confused: Since your system is set up such that you want to control your AC through MOPs mounted to the original control head rather than using direct connections to the individual components, how would you implement the "Auto" position so that all the knobs didn't turn when the settings were changed. The motor will have to move to change the setting, in turn moving the dial.
I guess you could maybe do like I mentioned above, and have 2 control heads. Use the new one with the "Auto" position as the one that is physically seen (and usually set to "Auto", letting the FB do it's thing). You wouldn't even need a motorized potentiometer, just a simple dial potentiometer hooked to a FB analog input, tracking the dial position. When the dial is on "Auto", the potentiometers on the visible dials aren't used for anything except to check if the setting is still "Auto". Then the PC can control the MOPs on the original, hidden control head to change the settings continuously without turning the visible dials.
Now, when the dial is not on "Auto" on the visible controls, you could have the AC software be a pass-through, with the MOPs on the hidden board copying the position of the dials on the visible board. Once again, we run into the problem of having to wait for the computer to boot, even if you want to take manual control. Maybe you could rig up an independent relay that would switch control from the hidden board to the visible board whenever the setting is off the "Auto" position? I don't quite know how you could do that, but there's got to be cut-off relays out there, that have a certain required min/max voltage value before they switch. Then you could connect the potentiometer on the visible dials to the relay, and have it completely switch a series of relays from the MOP-operated board to the manual board whenever the manual board isn't set to "Auto", giving you a hardware solution in case your PC dies on you.
Wow, this is pretty complicated stuff.....
My personal solution will probably just be to have MOPs mounted to the original board, mounted in the center console, turning whenever the system changes settings automatically. It's simple, and I like simple whenever possible :nutz:
EDIT: I really pray my new truck will have AC controls that are just simple variable resistors. That way, I can do what you are planning, and buy the "Auto" AC head to fully replace the regular one. Then I can just add regular pots to the control head. When the FB detects the voltage relating to the "Auto" position, it will power on DPDT relays that disconnects the control head from the components, and switches to the analog outs of the FB to control the system. If the PC is dead or off, the relays will be unpowered, leaving the system to be manually controlled without any interaction from the PC.
So after doing a bit of digging online, I found a hi-def pic of the controls I'll be working with.
Check out the A/C controls for this.
Basically what it comes down to is that I'll be in the same boat you are unless all of those controls are simple variable resistors. That picture is from the H3T Alpha, so this is the top of the line, and I guess I won't have a control head with an "Auto" setting available to me.
If they are all simple resistors, I'll stash the control head away (probably in the center console) with either A) a manual switch to switch DPDT relays from FB to manual control or B) have DPDT relays that stay set to manual control until a digital signal from the FB switches it to FB control.
Maybe even use a relay (or 2 actually) like this....
Controlled directly through a serial port. Set it to default to manual control, and have the FB software interact with the relay through the serial port, switching it to automatic control when the system is ready.