Hummer Forums by Elcova - Put computer in H2

Hummer Forums by Elcova (http://www.elcovaforums.com/forums/index.php)

- Technical Discussion and Customizing your H2 (http://www.elcovaforums.com/forums/forumdisplay.php?f=5)

- - Put computer in H2 (http://www.elcovaforums.com/forums/showthread.php?t=461)

Has anyone toyed with putting a computer in their H2 (a more integrated permanent mounting).

I have been mulling around an idea for over a year but really haven't given it much thought. I have an extra notebook computer and that is where the thought was born from.

My idea is around this: taking a notebook and permanently mounting it hidden somewhere. Utilize a wireless keyboard and mouse and utilize the monitor output to send the monitor signal to a video switcher. One could run a gps and nav software on the computer and have a DVD-radio installed in the dash for the multimedia. I was thinking of a LCD monitor to hook up to a hitch-cam, I think the hitch-cam allows for another video input and will autoswitch.

If one wanted, they could install a card in the notebook to have wireless internet access, but I really have no desire for that right now.

You could also use the computer to "hook" into the vehicle to get the real time data out using software. As a matter of fact there are a lot of neat things you could do and with the computer you would have different options such has playing mp3s directly from the computer, hooking up 4 cameras outside while wheeling and having all 4 split into quarter panels on the screen, etc.

Thoughts?

When I was looking into this, the problem I found were:

1. Long boot-up time, repeated everytime you're starting the truck.
2. Messed-up files from the sudden power loss when you turn engine off.
3. Rough ride risk on delicate hardisk.

I guess in theory you can put in somekind of relay for power, or a "hibernate" switch? But seemed too much effort.

Seperate components (Lyra video jukebox, video switcher, GPS-PDA) will be easier & cheaper. My 2cents.

There are a couple of companies that specialize in Car PCs. I have been tempted to try this, but have not had the time to mess with it yet. Here are a couple of links.

http://www.xenarcdirect.com/
http://www.wirelessinnovations.us/

Let us know if you end up putting a PC in your H2.

Thanks for the links. I found this on the xenarcdirect site

Those were the ones I was looking at -- which would have the power probs. Have not considered a notebook, since I figured the extra expense of an unused screen can go towards better CPU/HD/RAM (not everyone have an extra notebook lying around

)

<DIV class=titlepage>
<DIV>
<H2 class=title>Reducing Boot Times Step by Step</H2></DIV></DIV>

Now we're going to look at each step of our boot process and see where we can
shave off time. </P>

1) Power stabilization in car: The ideal solution for this step would be to
have a sleeping computer that simply woke up the moment the user started
cranking the ignition. In fact, this sometimes is possible. If the
aforementioned cron functionality exists in the car, the software can be
programmed to learn when the daily commuter starts their car in the morning and
adaptively wake up in time for the person to start their car. </P>

2) Power supply stabilization: Because engine cranking lasts several seconds
itself, starting the computer at the beginning of engine cranking can shave time
off booting. This functionality requires a power supply that can survive engine
cranking, such as the Morex 80W power supply. </P>

3) Power sequencer hits ATX button: There are two common approaches to
starting an ATX-based computer. One is wake-on-power-loss feature, available in
many motherboard BIOS settings. When the board loses power for any reason, it
reboots when power is reapplied. This is fairly low-latency, but measurements
show it still runs on the order of a second. An ideal situation would be to go
back to the old AT days where power-on automatically would boot the PC; alas,
those days are gone. Even if the ATX power supply is shorted (purple to ground)
to automatically power itself up, the motherboard does not automatically power
up unless the power switch is hit. This is the other approach, and power
sequencer boards such as the ITPS from Mini-Box can connect to the power header on the
motherboard and press the switch when the car's accessory power (key on) is
activated. However, the drawback of these systems is they add their own delays,
both to help with 2) (waiting until a smooth 12V is achieved) and waiting for
the ignition cranking to stop. For instance, this ITPS sequencer has exactly
three seconds of additional delay from key on to pressing the computer's power
switch. To alleviate this delay, the firmware on this ITPS can be reprogrammed,
which we've done, and the wake-on-power-loss feature can be used instead. </P>

4) Power-on self-test (POST): There's not much to be done about POST without
replacing the BIOS. With a BIOS replacement, memory testing and initial board
diagnostics can be exactly controlled. However, it is a good idea to have a
hardware test when any system boots up to determine properly if it's safe to go
on booting. You wouldn't want to get in an undefined state that drained the
car's battery, for instance, and part of controlling what state the machine gets
into is making sure it is working. POST generally takes a second, and for our
purposes we assume that even if we reprogrammed the BIOS we would not completely
eliminate POST. </P>

5) BIOS: This part of the boot process can take 2-10 or more seconds to
complete, because of all the mostly unnecessary functions it performs. We've
already been able to get it down to several seconds by disabling any unused
devices and disabling auto-detection of any kind. However, because the OS simply
reinitializes all the devices anyway, this time should be zero. </P>

Several BIOS replacements were found in the process of trying to get the boot
times down, including Linuxbios, Tinybios, General Software's embedded BIOS 4.3/2000 and Phoenix's embedded BIOS. </P>

The most interesting candidate for BIOS replacement is, of course, from
linuxbios.org, which uses it for bootstrapping nodes in a high-performance
computing environment. The Epia-M motherboards we are using are one of the more
popular boards they support. The Tinybios option would cost us about $3000, but
it also looked extremely promising from a time reduction standpoint. This link
from 2001 documents merely 800ms from power up to LILO using General Software's
embedded BIOS. Both General Software and Phoenix BIOSes look increasingly more
expensive (judging from their Web sites; I haven't received pricing yet), but so
did the original $10,000 quote we got when we asked one company if they could
help us boot Linux faster. So we're getting better. </P>

Some vendors are giving up on the OS altogether and putting application
functionality into the BIOS itself. This article on LinDVD is a Linux-flavored example of a
general trend to replace the PC BIOS. And that may be the approach we eventually
have to take. If we simply took the GRUB boot loader and added a splash screen,
sound drivers, an MP3 player and a DMR, we would be pursuing a similar path to
other pre-OS multimedia environment vendors. </P>

In the research for this article, I learned of a general desire to replace
all PC BIOS with some more modern firmware. <A
href="http://www.intel.com/technology/efi/" target=_blank>The Extensible
Firmware Interface</A> has been introduced by Intel and other vendors and is
available on some boards. I imagine, however, this would tend in the direction
of lengthening boot times with more digital-rights management, diagnostics and
other bric-a-brac instead of helping our goals of creating an embedded system.
</P>

6) Bootstrap from disk: This particular step is noted mostly because the
disks can vary in speed and because parts of the OS might be able to be crammed
into the BIOS chip itself. However, the fractions of a second that can be
recovered at bootstrap are less useful than the many tens of seconds that can be
reduced through improving the speed of storage device during OS load (see 8)
below). </P>

7) Run boot loader: This is the beginning of our journey into OS code.
Although the boot loader is strictly not the OS, it was found in testing that
boot times for Win98 DOS are almost identical to the boot times for GRUB. In
fact, over several tests with our hardware, we got about 13-14 seconds from
power on to a GRUB screen or DOS prompt. </P>

Looking at it another way, ignoring the OS, GRUB is actually our first chance
to do some useful work for the end user. Several eye candy solutions for Linux
boot screens were found for LILO, and I'm sure GRUB has some of the same. Adding only the
EPIA-M sound driver, it would be possible to emit both a product splash screen
and start playing some music--either off the disk or canned--while the OS
loaded. </P>

Using DOS boot times as the baseline, we found that it should be possible to
get the system displaying an image and playing sounds within approximately 15
seconds of boot, without any of the aforementioned BIOS time reductions. </P>

8) OS load all drivers: After all the prior optimizations, we have to look at
how actually to get the system up and fully running by booting the operating
system. One question yet unsolved is that if we use a boot loader hack to get
audio playing, we may not be able to keep audio playing without interruption.
The solution to this is instead of shoving the OS functions into the BIOS or the
boot loader, we keep them where they belong while starting the essential (video
and sound) services first. So there are two aspects involved. One, because we
have a controlled hardware configuration, we can create a deterministic boot
process, analyze it carefully for dependencies and parallelize boot tasks that
don't depend on one another. Two, because we need splash screens and sound as
soon as possible, we would put these as early in the boot process as possible
and perhaps finish the booting process as a lower priority task. </P>

An IBM article written by James Hunt documents how to speed up
the Linux boot process by parallelizing dependencies in the boot process. This
article confirmed my long-held suspicions that the computer was sitting there
waiting for much of the boot process. </P>

On the vendor-supplied front, <A
href="http://linuxdevices.com/news/NS9566960946.html" target=_blank>FSMlabs
documents a 200ms boot</A> until user code execution with its optimized Linux
boot. However, FSMlabs are focused on delivering Linux with a hard real-time
kernel, something we don't need. They were one of the two vendors that offered
to solve our problem for $10,000, a rather steep budget for a solution that
would be tied to the particular hardware we were using. </P>

And for our motherboard in particular, Mini-box provides a <A
href="http://www.mini-box.com/linux.htm" target=_blank>fine-tuned Linux
distribution </A>that suppresses all text output and goes straight to an OS
prompt. We purchased and tested their distribution. Out of the box, it did a
full Linux boot--all drivers for our board--to a prompt in less than 30 seconds.
Unfortunately, this still isn't quick enough for our needs, so we're going to
need to optimize further, as well as adding video display to the booting
process. </P>

9) Show user prompt: The system can't be considered booted until it stops
thrashing and can provide uninterrupted functionality of all applications. If
the boot process is going to make the MP3 playback sound choppy, then it's going
to need to be modified to take a lower priority than the sound driver. However,
if the user immediately tries to have their e-mail read to them or tries to
activate a GPS, the illusion of readiness provided by getting audio and splash
screens up quickly is be broken. Thus, the entire boot process must be fast
enough. Getting the user prompt available (or its equivalent, such as a menu, or
a spoken "I'm ready to accept input" for voice activated systems), is the
primary concern of the system. Although this is easy to do for a single-purpose
embedded computer, such as a navigation system, the real challenge of our system
is to get a general purpose computing device to behave like an embedded
device.</P>

40 GHz hard drive, huh? (In response to the advertisement for the MIS.)

<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Originally posted by PARAGON:
Has anyone toyed with putting a computer in their H2 (a more integrated permanent mounting). <HR></BLOCKQUOTE>
I have built three different AutoPCs, though the most recent is the only professional one.

<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Originally posted by PARAGON:
My idea is around this: taking a notebook and permanently mounting it hidden somewhere. Utilize a wireless keyboard and mouse and utilize the monitor output to send the monitor signal to a video switcher. One could run a gps and nav software on the computer and have a DVD-radio installed in the dash for the multimedia. I was thinking of a LCD monitor to hook up to a hitch-cam, I think the hitch-cam allows for another video input and will autoswitch. <HR></BLOCKQUOTE>
The keyboard and mouse I prefer is the Gyration wireless keyboard and mouse set. Both are RF, not infrared, providing up to 100' of range, depending on the model. The mouse is gyroscopic, allowing you to use it in the air, not requiring a mousing surface.

Using a GPS receiver mounted to the roof, I was able to use navigation software on the PC to provide driving locations and maps.

And of course, the PC plays MP3s, DVDs, etc. (I went with a Xenarc touchscreen display. They were just starting development of their own AutoPC at that time.)

<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Originally posted by PARAGON:
You could also use the computer to "hook" into the vehicle to get the real time data out using software. <HR></BLOCKQUOTE>
There are several pieces of software that allow you to connect PCs to your vehicle for diagnostics and vehicle data. Most connect to the serial port but some use USB. Regardless, this would be easy to do once the PC is in place.

<BLOCKQUOTE class="ip-ubbcode-quote"><font size="-1">quote:</font><HR>Originally posted by H2Finally:
When I was looking into this, the problem I found were:

1. Long boot-up time, repeated everytime you're starting the truck.
2. Messed-up files from the sudden power loss when you turn engine off.
3. Rough ride risk on delicate hardisk.

I guess in theory you can put in somekind of relay for power, or a "hibernate" switch? But seemed too much effort. <HR></BLOCKQUOTE>
Boot time varies based on operating system. Some have reduced this amount of time drastically by using various tweaks. (Using Windows XP Embedded, one is able to remove all device drivers except for what is installed, speeding things up drastically.) The best solution is to have your computer go into sleep mode instead of turning off. Using a DC-DC power supply from OPUS Solutions, you can do all of this. When the vehicle is started, it signals the motherboard to start the computer automatically. When the vehicle is turned off, it will then either turn off the PC, put it to sleep, or enter hibernation mode, depending on your settings. It can do this immediately, or wait a programmable amount of time to do it. Either way, it eliminates the problem of the PC just turning off.

Hard drives tend to be more durable than we give them credit for. In my Avalanche, I used a 60 Gb Fujitsu hard drive and even with offroading, I never encountered problems with drive crashes. Keep in mind Fujitsu hard drives tend to be slower and more rugged whereas Hitachi/IBM hard drives tend to be faster but more prone to crashes. If you are really concerned, you can use a solid state hard drive with no moving parts. They are more expensive, but prices are coming down.

If anyone is interested, here are a couple photographs of the old AutoPC setup. It is almost complete, apart from a final layer of vinyl that will match the texture of the dash:

If people are interested in other photographs of the installation or larger photographs, let me know and I will send them as people request them. Also, if anyone has any questions or comments, please let me know and I will respond as quickly as possible.