NOTE: In the previous Post.
If you trust the PSU to drop standby and/or shutdown in the event of a low battery condition then you can omit the circuit in blue.
If you don’t need the Vehicle Battery to support the AUX battery then you can leave out D1.
You can of course omit both of the above.
Sweet thanks for the info! I'm pretty sure I have all those parts already too. You have a pic of the assembled PCB, I should probably scroll back through the build thread eh?
This is the final connection circuit which now powers the LCD via a 12v regulator (optional) and +12v microprocessor sub systems from the AUX battery.
With this system the ADC inputs on the Vehicle interface microprocessor read and display the main battery cranking voltage accurately on screen along with all other ADC input voltages I monitor. That may not sound like much but with the ACC and Ignition voltages dropping to zero and the current paths changing and huge cranking currents flowing as the Main battery takes a bit of a dive; I think its pretty dam good.
I described the Isolator and charge circuit in a previous post, so moving on to the rest of the circuit.
What the system accomplishes.
1. Supply’s the PSU-PC, LCD and various USB devices with a stable clean voltage.
2. Dual powers the LCD for use with a reversing camera when the PC is off or the AUX battery is disconnected or flat.
3. Allows full and “quick control” of the Car-PC power system under all conditions.
4. Allows a quick one button push selection of Hibernate on exiting the vehicle when Automatic Sleep mode is not required.
5. Allows an automatic one button push (same button as above) reboot of the system while driving for the times when it may be needed – If you have a button you won’t need it, if you don’t you will (Murphy).
6. Supply’s an external +5v supply to the USB Hubs in case I need to draw extra current (charging) when the PC is running.
7. Results in a system that needs no intervention to run or stop and allows the vehicle to be turned on, off or started (cranked) without any thought for the current state of the Car-PC.
In other words for 99% of the time it should not feel or behave like an add-on Windows PC. The other 1% should only be when Windows being Windows decides to reminds you that it is!
It’s that 1% that can frustrate the living crap out of you if you don’t take steps to nullify it. That’s what I have tried to do with the Hardware and even more importantly the Front End software.
The circuit. Also A large clear jpg image 1.5MB in size
The M4 and other ATX PSU’s are normally supplied with a constant +12v directly from the battery, either main, AUX or both.
The PC is started by applying +12v to a control line to the PSU. A second or so later the PSU sends a short pulse that mimics the normal action of pushing the standard PC (MB) on/off switch.
When +12v is removed from the control line, the PSU, after a short delay, sends another pulse that once again mimics the action of pushing the standard PC on/off switch and the PC closes down into the state set for the Power Button Action in Windows power settings. In the M4 the control line is called the IGN line and is normally connected to the accessory line of the vehicle.
Keep in mind that the Accessory line in a vehicle is normally switched off during engine cranking and reapplied when you release the ignition key from the start position. Usually this happens to 12v supplied from the Ignition switch ON position as well.
There will be times when you don’t want the PC to start, so a Switch is normally connected in line to stop the PSU Control line going to +12v.
S1 in the circuit is this switch. However there is a second push button switch S2 in line in my circuit. Well actually S2 controls a tiny relay (RL6) that’s in the line; this is to allow a small low cost “normally open contact” switch to be used to control the line that requires a normally closed contact.
The first switch, S1, has a second connection that disconnects the main +12v supply via relay RLY2 to the PSU when the switch is in the off position. This is a seriously handy option to have.
For 99.9% of the time S1 is just left in the on position. With a bit of creative thought and a Microcontroller “like the Fusion Brain or any number of different devices available) you can make S2 perform multiple actions. I have programmed a Microprocessor to read the voltage from the Ignition Accessory position (S1 input), the Ignition On position “vehicle running position” and the voltage out of S2 (RL6) which therefore reads the state of S2.
By monitoring and sending the state of these 3 voltages to the FE you can tell the following:
1. S2 was pressed and the Vehicle is ON (or running).
2: S2 was pressed and the Vehicle is in Accessory.
3. The vehicle has been turned off. It looks like S2 was pressed but actually all voltages have just dropped when the Ignition was turned off.
With these 3 conditions the FE is programmed to, in each case:
1. Shutdown the PC.
2. Hibernate the PC.
3. Make the PC Sleep. As no button press is required this is the Automatic mode, IE. Ignition was switched off.
NOTE: The selected Suspend action in this system is controlled by my FE and NOT the on/off pulse from the M4. The FE sets the required suspend mode in the Windows OS.
While on the subject of PSU’s and in particular the M4. I had long ago found that any glitch on the M4 IGN line can cause the M4 to drop its Standby voltage in Sleep mode. This is the reason I have D6 and a 100uf cap on the IGN input to the M4. D6 stops the CAP from discharging back into the ACC control line. D6 is not needed with this revised circuit but as it was already inside the PSU case I just left it there.
RLY2 is a normally closed relay mounted right at the +12v input to the M4. It has to be energised to switch the M4 supply OFF. It’s wired this way for two reasons.
1. The PSU must be powered when in Standby (PC sleep) and therefore you don’t want relay current added to the sleep current. So the M4 is always in the powered state (default) and RLY2 is off.
2. If you have the PC turned off via S1 then whenever the vehicle is off, RLY2 is released and therefore not slowly discharging the battery.
BTW S3 is just a tiny switch mounted on the side of the PC case and, as it’s hidden, I can turn it off for the times that I may have to leave the car at the dealers. This stops prying eyes and God knows who else playing with the CAR-PC.
There is a second control line to RLY2. The first (as above) is from S1 via Q1 and the second comes from the yellow box above Q1. The FE signals the interface microprocessor that it is suspending and the second line is finally controlled by this Micro. The relay is powered for a second and interrupts M4 +12v to force the M4 to switch off; this only happens if the PC or M4 fail to Hibernate or Shutdown correctly.
There is also a second control input to the M4 IGN line via D10. This is also controlled by the interface micro (after a signal from the FE) to hold IGN line high for Hibernate or Shutdown and is needed to make the M4 elegantly drop Standby +5v in these modes.
D8 and D9 steer accessory +12v to the Charge Switch as discussed in the previous post and to the main +12v supply control circuit.
This supply circuit sends +12v from the AUX Battery to the LCD screen and the various Microprocessor regulators as well as the DAB-FM module, DAB-FM aerial amplifier and DSP module.
The circuit has a 5 second delay via D5 a 200uf cap and 15k resistor into Q6. This 5 second delay keeps +12v supplied via RL3Y during engine cranking. Another input via D3 from the ATX +12v line keeps it suppling +12v while ever the PSU is running (PC running and vehicle may be off).
I have these devices powered in this way because the AUX supply is the cleanest and most stable supply during engine cranking and is one of the reasons this system is so stable. There are 3 Microprocessors at the front of the vehicle and 2 of them control the interface to the vehicle HVAC system and HVAC Manual data link control. The 3rd is the Vehicle interface (controls) microprocessor. These devices need to be powered whenever the vehicle is on and supplying +12v to them from the AUX battery also ensures that I get accurate ADC readings from the various sensors during engine cranking and no funny transitions if the PSU USB +5v starts just as the vehicle is cranked. This is a cause for some USB devices to be not ready or disabled in Windows.
I also added a 3 terminal 5A +12v regulator to the LCD supply. This LCD can run down to around 9.5 volts and up to 16v but its nominal voltage is 12v. The AUX battery with this new wiring can see 14.6v so in the interest of longevity/caution I added a regulator. It of course runs cold and depending on the state of the batteries its output (below REG threshold) could drop to below 11 volts, not a problem here.
Last on the list is RLY4. As this relay is powered from the PSU ATX +12v output it is on whenever the PSU is on. It switches high current PSU +5v to the front USB hubs.
The relay is needed as some of the standby +5v can feed back from the HUB’s into this +5v output. This will cause all sorts of problems with HDD’s, SSD’s and any other device on the regular +5v line. The 10 x 5W 6.2v Zener Diodes will (hopefully) clamp and blow the 2A fuse if +12v were accidently connected/shorted to this line. There are better ways to do this but I had a box of them and wanted a quick fix for a bit of safety.
I hope that made sense?
I haven't got a layout on that one. I'll have to see what I can do.
Originally Posted by Roger555
Background: I tried to describe this a few pages back but it always comes out sounding so complicated. I think it still does although the implementation was simple. So here is another attempt that follows on from my last post about the final circuit operation.
Most vehicle ATX-PSU’s have a timer to set how long the PSU will supply +5v standby power to the system and is only required if you suspend to Sleep state. In the M4 it’s called the hard off timer.
The idea is that after say 6 hours, and hopefully before your battery has gone flat, the PSU will drop standby +5v and kill sleep mode. When you restart the PC it will do a cold boot or resume from Hibernate if Hybrid-sleep is enabled (only if you can get it to work reliably). In my case Hybrid sleep is totally useless.
However none of this solves the problem of long PSU-set Hard-off times from killing the battery. The ideal would be to have a simple menu item or even better, a hardware button. When required, a simple push of the button can initiate either Hibernate or Shutdown instead of Auto-Sleep.
No, setting the PSU to switch off at a pre determined low voltage in the hope that you can still start the vehicle is a bit iffy, especially as the battery ages, and I do this anyway (as a last resort). But why have the dam PC drain power for XX hours or more in Sleep mode, waiting for a low battery trip condition, if you know you won’t be using the vehicle for a longer period?
In the end I decided to use software initiated Hibernate, Sleep and Shutdown. This has to be made to work with the ATX-PSU’s programmed standby timer, so, how to make the M4 drop standby voltage when hibernating or shutting down but not in sleep mode? Well first, the FE has to control it.
Here is what I have done to have Sleep, Hibernate and Shutdown controlled by the FE and not the M4-PSU’s on/off MB pulse:
1. I set Windows to ignore the Mother board Power button action.
2. I use the M4 in Mode-1 (Normal car mode.)
3. Set the M4 Hard-off timer to whatever you want for sleep – just less than 18 hours in my case as this is the maximum allowed in the M4.
4. I have the M4 off-delay set to 5 seconds to allow the IGN line to the M4 to be interrupted for a few second without firing the M4 turnoff function. My FE is programmed to see this and initiate a software Hibernate or Shutdown depending on the position of the vehicle Ignition switch.
5. I added a Suspend switch. This is a push button switch and is the second switch in the 12v line to IGN terminal of M4 PSU. If you look at the circuit you will see it switching a (very small) relay. The only switch I had to fit the location was a normally open contact, so a small relay was used to convert to a normally closed contact. These are also described in the previous post on circuit operation (one post back).
PC Sleep - Turn the vehicle off. You’re finished, same as before.
PC Hibernate - Press the Suspend switch with the vehicle ignition switch in Accessory position and the FE announces Hibernate Locked, turn the vehicle off, you’re done.
PC Shutdown- Press the Suspend switch with the vehicle ignition switch in the ON position (or vehicle running) and the FE announces Shutdown Locked, turn the vehicle off, you’re done.
This also allows me to shutdown the PC if needed while I’m driving with no need to take my eyes of the road to do it.
What I did to make it work.
NOTE: If the M4 sends an off pulse “before” the OS is closed it won’t drop standby power. The OS closing signals the M4 via the MB to power down. After the M4 powers down it leaves +5v standby running for the M4-PSU programmed hard-off time.
When the FE issues a software Hibernate or Shutdown command to the OS it does the following first:
It commands a small interface microprocessor to hold the IGN line to the M4 high. This stops the M4 sending an off pulse 5 seconds (PSU programmed) after the vehicle is turned off (IGN line low). The micro holds the IGN line for a maximum of 25 seconds to give the OS time to suspend.
When the M4-PSU sees the OS close (MB signals the M4) the M4 switches off and drops everything except +5v standby. The relay that holds the IGN line high is also powered from the +12v ATX line so when the M4 powers down the relay releases and drops the IGN line after the +12v drops.
NOTE: Up to that point +5v standby was still running.
Dropping the IGN line AFTER the M4 had suspended caused the M4-PSU to override its internal Hard-off timer and drop the +5v standby line.
Now we have Hibernate or shutdown with no +5v standby.
When the M4 dropped +5v standby, the Micro, as it’s powered by standby, also halts.
If the M4-PSU does NOT drop +5v standby then the Micro will still be running. When the +12v ATX rail dropped, the micro started a 10 second counter.
If standby is still on after that 10 second timeout the Micro momentarily interrupts the power to the M4-PSU via a relay. This of course makes the M4 drop all voltage outputs. (See NOTE 1 below)
Now if Hibernate or shutdown failed or the M4 failed to close then we are still powered off with no +5v standby.
Finally Sleep Mode operation:
The FE is monitoring the ACC and main power. By just turning the vehicle off the FE sees both these drop and initiates a software sleep mode command. Once again the FE does housekeeping so that the time taken for the OS to go into sleep mode is longer that the 5 seconds delay the PSU needs to send a Power off pulse to the MB. The IGN line to the M4 was immediately dropped when the vehicle was turned off so the M4 will send a power off Pulse to the MB before the OS has gone to sleep. The OS has been set to ignore the M4 power pulse.
The M4 is now waiting for the OS and MB to signal it’s off, and it does this when the OS closes. The M4 now sees this as a response to its (ignored) power-off pulse and closes down leaving +5 standby running. The only difference between this and the normal way of turning the vehicle off for sleep mode is that instead of the Power off pulse from the M4 initiating sleep mode, the FE does.
By using the FE I still have fully automatic sleep mode, but I have the option of any other mode at the touch of a button and standby +5v on/off automatically set according to the suspend mode.
I should point out that the FE is also sending commands to the OS to enable or disable sleep mode in Windows. If you leave sleep mode enabled and send a software command for Hibernate to the OS, the OS (Windows) will not hibernate, it will sleep. The reverse is true of you have Hibernate enabled. So these Window settings are switched by the FE depending on the selected suspend mode. This suspend system is working faultlessly.
If the Ignition is left on after the Suspend switch as been pressed then after the PC hibernates or shuts down the following will occur:
1: +5v standby will not have dropped as the IGN input to the M4 is still HIGH because the vehicle ignition is on. It will drop if the vehicle is turned off before it restart’s (15 seconds).
2: The +12v to the M4 will be interrupted by the microprocessor 10 second timeout as it sees +5v still present.
3: The PC will restart shortly after that as dropping +12v input mimics the start sequence of the M4 (IGN line high and +12v reapplied.)
Pressing the PC ON/Off switch to OFF will instantly kill the M4 providing the vehicle is ON, which it is in this case.
This means that if you are driving and you turn off the PC using the suspend switch – The PC will shut-down and then restart – This is really handy if for some reason a USB device stops running, a driver fails to initialise or Windows is just being Windows after a few dozen sleep/resumes and you need to do a reboot- It’s a one push action.
You can of course then turn the PC off (PC-ON/OFF button) and it will not restart. It will still have full charging available from the alternator to the AUX battery in this mode.
I will add again that this setup is just so stable and wonderful to use. I really didn’t think I would get the entire system this stable along with one touch sleep or hibernate in every imaginable vehicle on-off condition, but it has not faulted once with this final build. Physical encoder and button operation / control of the FE feels like factory build, it just works!
Once again I take my hat off to the guys who write generic front ends that encompass different hardware and software configurations.
Just making a dedicated HW/SW solution work faultlessly has taken a long time because of one gotcher after another with hardware and software interactions and making desktop hardware and OS work with close to 100% reliability in a vehicle under ALL conditions.
Anyway the build is just about complete and getting close to the time when I move it to the finished projects. Still have that front panel to finish and I’m done. I’m sure I have said that before but this time I really mean it, otherwise I’m going to have myself certified :crazy:
I thought I would share a few of the strange things that happened as a result of changes to powering hardware during the build. This may or may not be of help to someone planning a build, but here it is anyway.
First a quick recap of the only Software complaint that I had with Garmin Mobile PC.
GMPC has been problematic for a number of users on this and other forums. When the latest version was released a number of people found the application would randomly close. Unfortunately restarting the app failed and this was due to part of the app still running in the background. I coded the FE to monitor the status of GMPC and if the GPS window disappears, my FE will kill any remaining task and restart the app automatically. It’s only happened twice in 12 months, no big deal as 3 seconds later the GPS app restarts and resumes exactly where it left off. I actually had to code a voice announcement to alert me when the FE restarts the GPS as I just don’t notice it.
The second problem is that sometimes after a cold boot, Garmin PC will not find the GPS receiver (mouse). Checking in device manager revealed the GPS device was disabled? This was easily overcome by always having the FE issue an Enable command for the GPS device at start up which is completely transparent to the user (me) and causes no extra delay in starting the GPS app.
However after another system change I started to notice other USB com devices not being ready.
I have coded the FE to constantly scan its com ports and silently connect/reconnect them if one is slow to come up or stops for some reasons. IE you can unplug a USB com port then plug it back in and the FE will just restart it when it’s ready, no error is reported. This silent behaviour was masking some slight initialisation delays with some of the ports. Shortly after that I noticed that the GPS mouse started to be not ready more often and occasionally had to be unplugged. So I started looking at what was going on.
Along with many other changes at that time I had also started powering the +12v line to the LCD and front microprocessors with a nice stable +12v from the AUX battery. During my fault finding search I turned the vehicle on and measured the USB +5v line without the PC running, I found around 800 mV on the rail. This was causing either the HUBS or the USB interfaces to behave strangely and in addition the GPS mouse or its repeater (it’s on a separate 15 ft USB cable with and inbuilt repeater direct from the PC) was now misbehaving.
To cut a long story short, the USB to serial interfaces from the HVAC and interface Microprocessors were feeding voltage from their RS232 IO lines back into the +5v USB line. A quick bit of coding to the micro code solved the problem and everything went back to normal. BTW these micros need to be powered by separate onboard +5v regulators via the +12v supply even when the PC is not running, hence the problem.
NOTE: Prior to the change to AUX +12v feed, the +12v to the devices had come from the vehicle Accessory line. This voltage drops to zero when you start the vehicle. The devices were obviously resetting and restarting when this occurred and therefore were ready when the PC resumed or booted. Sometimes an unstable supply hides an issue that would still have caused a random problem depending on when the vehicle was started.
When you get a few USB devices running and start powering them externally and you are having a silly problem with devices not ready, especially from a cold boot, then it may pay to check exactly what voltage is on the USB lines when the PC is off
Later another problem showed up where the SSD would randomly disappear from the bios boot list.
Now a day or so before this I had started powering the USB hubs externally and this is where I went looking. I power the HUBS from the +5v PSU line as I have plenty of current reserve on this circuit.
Once again the problem was a small voltage on the ATX +5v line but this time bleeding back from the HUBS external supply socket when the PC was in standby mode. Around 1.2v from the +5v Standby circuit was appearing on the normally off +5v PC supply output line and randomly screwing the SSD drive at start up. If you look at the circuit and my description of it you will see I placed a relay in the line that overcomes this problem by only connecting the 5v line to the HUBS when the PSU is running.
And finally, I got caught a second time with the PC randomly failing to resume from standby. Well it appeared to be random but was in fact due to something totally stupid.
Occasionally, while sitting in the Car with the system in Sleep mode, I would give the LCD screen (touch screen) a quick clean with a cloth. Of course I would forget about this action by the time my Wife arrived back at the vehicle. I’d turn the vehicle on and the PC would fail to resume and instead cold boot. That happened about three times before the penny finally dropped again! banghead
If the PC is in Sleep and I wipe the touch screen at any time then the PC will fail to resume every single time. I can only assume that the USB touch interface locks for some reason or the device driver doesn’t get the response it expects on resume. And no! Cleaning the screen does not draw extra standby current or make the +5v standby line drop. Furthermore, I’m not going to waste time looking at this as I rarely clean the screen anymore, rotary encoders and physical button control mean I no longer need to reach for the touch screen.
I have almost finished my user and service manual’s and this silly condition is now included in the fault finding section. Well, at least until (if ever) I get motivated enough to elimate it.:flypig:
This does look really sweet, just some I am clear -- this could monitor changes in the volume controls? The other is that these seems to be totally Windows based. Any feel for how much work would be required to read values under Linux? Again, thanks for taking the time to keep us (not so smart) people upto date!
Originally Posted by Mickz
Ok, as this is OEM vehicle software it would only have been written for Windows. Hacking theHonda OBDII device to access data would be almost imposable because of the high level of microprocessor control built into the Honda HIM interface module.
If you want to access and read the volume control (if possible in your model) you really need to interface to the CAN bus. There are GA-NET devices made for the Honda NAV bus interface but they look expensive and still may not do what you want, this was mentioned in posts 97, 98 there is also a link in the post.
Most times you need to hack the CAN-BUS and work through the streams of data in the hope of identifying various control messages from the sub systems.
This is what Iím doing now but my info will be of no use to you as my vehicle has absolutely NO CAN (or other) interface to the old RADIO-CD player and hence the Volume control. However I will share how I interface and get the data from the CAN and also what codes I can identify, so you may be able to go from there, then it would only be a matter of identifying the correct code.
I most likely just glazed over those post as my car doesn't have Navi (or even a factory touchscreen) -- I got the new model accord (2 door) in 03. It was later in that year before they started offering (or having available) coupes with those options. Doing some more googling, I came across this site:
Which has a interesting, but some what pricey solution. Detailed info is spare, but the pictures are pretty...
Mine had neither of those as well. In this case the GA-NET is not going to work unless you get the NAV interface or at the very least the second NAV vehicle interface cable which is not on the Standard system. People have retrofitted the NAV to the 03 accords but it’s an expensive exercise.
It’s claimed that others have used the GA-NET device on a standard 03 Accord but I can find no concrete information with circuits, components used or pictures of the components used in the system. IMHO It’s way too expensive to take a chance unless it’s guaranteed to work.
I did some more reading and digging around and it turned out just as I suspected. The standard Non Nav system does not appear to have GA-Net. From what I can gleam, the NAV system DVD controller in the trunk is the Gateway-Control for GA-Net to the NAV, climate control and Screen. The Non Nav Climate control (Radio 6CD only system) is a completely different board. I have accounted for every connection to this board and there are no GA-NET interface connections.