I can't quantify what the power difference is for the low power state yet, but as far as I can reason out, it must be lower. I am certain that the PIC itself is using less processing power, but the power draw of the psu depends also on the states (high or low) that the IO pins are set. I did a lot of research trying to ensure that each pin would be set to draw the minimum amount of power when the PIC is in low power state and I think I have them set optimally, but I can't claim it as proven fact. I am hoping to find a way to measure the current when the psu is in low power state, but I don't own anything that will measure a few mA.
The other situation where that might become important is if you are have the car key in the accessory position to run the computer without the engine running. You wouldn't want to drain your battery in that case either, I don't think, so just because the computer is on doesn't necessarily mean you want to ignore the battery voltage. I am not sure what the mini-box code would do in that situation. I would have to check.
i never quite understand the hard off feature myself, especially with the disclaimer "saying that this feature could drain your battery".
The question is then, how do you maximize the amount of time, and what is an acceptable voltage to let the battery get to? You could theoretically prevent car batteries from getting to the point where they would no longer start the car if you knew what the threshold voltage is. One problem in setting that threshold is that it is probably not the same for everyone. Another possibility is it can make benchtop testing difficult, as I found: the psu that I use to simulate my battery does not actually get 12V very well out of a single molex connector run through my simulated ignition switch, so my M2 was actually only getting about 11V at first when I started writing my code. My computer kept shutting down and the psu was signaling the battery low error (this is why the diagnostic codes are helpful) and I quickly fixed it by decreasing the threshold voltage... This is one possibility of why mini-box may have set the threshold so low...
I finally got the time to upload a couple of videos on youtube... They are pretty simple but at least demonstrate the basic functionality of my code. Check them out and let me know what you think and what else you would be interested in seeing!
I am planning to demonstrate the LED error flashing function by simulating a low battery signal in a video in the near future. I just need to decide exactly how I am going to change the supply voltage while the computer is running.
Youtube link: http://www.youtube.com/user/bluTDI09
Ummm...I didn't see any difference in your firmware and the original firmware??
Is the standby 5V rail on a timer??
And Jeezus!!! Please invest in a chip puller!!!
I mainly wanted to first demonstrate that my code functions the way that it is supposed to, because until this point, you all have been just taking my word for it So it shows that the amp delay, autolatch, off-delay, and hard-off do what they are supposed to do.
If you want to see it do something in particular, let me know and I will try to demonstrate its flexibility...
and yes, my chip puller is a little low-tech... hehe ... I just figured if people were ever going to want to replace theirs, they might want to see a way with a tool they might actually have...
looks good. so many people spend so much time worrying about optimizing windows to possibly get a second faster bootup time, this is 5 seconds! makes a huge difference.
When i first got my m2-atx, i thought the delay was to get through the initial starts voltage drop, but now that i realize it doesn't require that, it really bugs me.
keep it up, looks like there are quite a few people interested in this. I really like the led idea as well. I'd like to install it with a remote led on the console for easy viewing.