HVAC Control on Car PC through Serial Port.

**Mastero** · 05-19-2005, 02:44 AM

Hello friends,

This project started as a/c control with lpt port.

Now the project has gone a total different way.

The unit is controlled through serial port of your car PC or with a small accesory can be controlled by your USB port also.

Has a lot of features usefull for HVAC control.

Has remote controller funtion for emergency use. (WHEN THE PC IS NOT WORKING

)

Full details on the product including manual , software , and VBfiles for making your own software can be found

This is the second version has lots of more features

IT COMES NOW IN TWO VERSION F and C

HERE

Cheers
Mastero

**0l33l** · 05-19-2005, 03:27 AM

Some suggestions:
Posts some pics
Have an option to use a LPT -> USB converter. Not many people want to run a huge parallel cable from their trunk

**Mastero** · 05-19-2005, 07:19 AM

Pics comming soon ..

And you dont have to run 25 wires ... only 9 wires

Mastero

**Chris31** · 05-19-2005, 09:43 AM

Its the ugly 25 way connector sticking out thats will bother me.

**god_of_cpu** · 05-19-2005, 09:50 AM

So does your hardware get around the boot up issues? i.e. Various bits on the parallel port can be randomly set high or low during bootup potentially triggering a device connected to your hardware. What does your hardware do to get around this?

**lostreception** · 05-19-2005, 09:51 AM

I think its a great idea no one utilizes there lpt hardly we need more sw/hw for it
its a wasted input for most of us

**evandude** · 05-19-2005, 09:55 AM

LPT<->USB converters are much harder to use than a built-in LPT port, from what I've heard, because the built-in ports are memory-mapped, so software interfacing is very easy (just read and write to memory locations), whereas the USB ones are not memory-mapped, so you would have to deal with whatever drivers the device uses to communicate with it; ie- a lot more work.

it could be done with a serial port, then you'd just have to use a microcontroller on the recieving end to convert the serial data to parallel outputs. (extremely easy... if mastero or someone else wants to tackle the software stuff, I would be willing to do the microcontroller stuff... mastero, perhaps you could add it as an option in your software?) and interfacing with a USB<->serial converter is the same as interfacing with a built-in serial port AFAIK, since they both just appear as COM ports to software (and COM ports are pretty easy to deal with for programmers, generally). That would make it more adaptable for people who are addicted to USB, especially since a lot of people already have USB hubs up front that it could be plugged into, saving having to run a new cable. And even if you ran a new cable, it would only have to be one wire (use chassis for ground, and power it via a 5v regulator off the closest 12v line)

**Chris31** · 05-19-2005, 10:11 AM

Originally Posted by god_of_cpu

So does your hardware get around the boot up issues? i.e. Various bits on the parallel port can be randomly set high or low during bootup potentially triggering a device connected to your hardware. What does your hardware do to get around this?

I was about to ask that. Some kind of a application verification is needed before the HW should react.

**Chris31** · 05-19-2005, 10:28 AM

Originally Posted by evandude

LPT<->USB converters are much harder to use than a built-in LPT port, from what I've heard, because the built-in ports are memory-mapped, so software interfacing is very easy (just read and write to memory locations), whereas the USB ones are not memory-mapped, so you would have to deal with whatever drivers the device uses to communicate with it; ie- a lot more work.

it could be done with a serial port, then you'd just have to use a microcontroller on the recieving end to convert the serial data to parallel outputs. (extremely easy... if mastero or someone else wants to tackle the software stuff, I would be willing to do the microcontroller stuff... mastero, perhaps you could add it as an option in your software?) and interfacing with a USB<->serial converter is the same as interfacing with a built-in serial port AFAIK, since they both just appear as COM ports to software (and COM ports are pretty easy to deal with for programmers, generally). That would make it more adaptable for people who are addicted to USB, especially since a lot of people already have USB hubs up front that it could be plugged into, saving having to run a new cable. And even if you ran a new cable, it would only have to be one wire (use chassis for ground, and power it via a 5v regulator off the closest 12v line)

From what I have notice, the USB-SERIAL controller is not solid when it comes to plug and play. The comport may appear as another port next time the PC is booted up. It can also crash the software if the device is unplug since the virtual comport will disappear. Replugging it back in doesnt help, the software already got confused with the virtual comport being gone. Only way is to restart the software.

Probably not a problem to some but I didnt like it. Reason why I went USB all the way on my design. Those who doesnt know what Im on about check the anyone "interested in serial relay cards" thread. A long thread, but read the last few pages. Its a USB card capable of controlling 8 relays, 8 digital inputs and 3 ADC.

**Mastero** · 05-19-2005, 05:23 PM

Ok

a) USB or serial is OUt (sorry but its out. As software coding is already done and me not going to start over again)

b) Db 25 connector only on the Mobo side. Other side Db9 connector. (Only D0 ~D7 pins used)

c) The Lpt boot issue is what i am currently working on should get around it soon....

Mastero