Poster Fair
The project poster fair was on Monday. I decided that it would represent the deadline for all of the aspects that were on the to-do list in the presentation.

As such, over the two weeks preceding the poster fair, I invested a total of about 60 hours of time. While not by any means technically advanced, the power control unit represented a lot of that time, and it certainly represented many hours of learning Atmel microcontroller technology and how to actually design simple circuits with transistors. Looking back, it seems completely straightforward, but there was some resistance in moving from lecture-hall theory to actual design.

The poster show went well, the demo mostly worked. Of course, not when the professor came to see it. Report-writing is slated to start any day now. I seem to be well-off in terms of quantity of content. The quality is also present, but it could still use some polish. An end is in sight.

Microcontroller Success
After staying up half of the night, the program for the Atmel microcontroller power control unit was deemed satisfactory. Then I spent half of today ironing out glitches inherent to moving from the test chip to the real one (they are different models). After all of that, it only took 15 minutes to build a breadboard prototype of the final circuit. Though the prototype is designed to work on only 5V, it should not take long to modify it to handle 12V and build the final unit.

These past three days have been extremely educational.

Critical Mass
As the project deadline quickly approaches, I have been spending considerable time putting my ideas into motion.

Last week I decided that the power control unit, while simple, would benefit from being microcontrolled. I have spent a good portion of this week researching the options, and concluded that the Atmel Tiny series is perfect for this and other applications. It is amazingly versatile, simple to program, and conveniently has an on-chip clock (other chips need an external crystal). After programming, literally all that is needed is Vcc, Vss, and any inputs/outputs. Having spent over 20 hours so far practicing writing software for it, I am completely inpressed with this chip. The software will be simple to write, and the hardware will hopefully be easy to design.

Additionally, some time this week was spent creating the GTK theme for DashUI. A reference engine, HighContrast, is being used. The goal will be to thicken up borders so that they are several pixels thick, and possibly modifying the colour scheme so it is not as high contrast as it was originally designed to be. This still needs work.

Lastly, library research was performed to obtain research about ergonomics of vehicle multimedia hardware and its interaction with humans. Two excellent books were found: Automotive Ergonomics and Human Factors in Driving, Seating, & Vision. These books contain invaluable information and considerations regarding revolutionary human interaction mechanisms, as well as numerous related safety studies.

Project Progress and Setbacks
This reading week was to be used for completing several key phases in the Dashbox project.

An initial goal of the project was to produce a plugin or some sort of application that could communicate over OBD-II to the vehicle's CPU and extract meaningful statistics about its usage. While this is an attainable goal, my vehicle is a year too old and only contains a non-standardized OBD-I interface. This means that custom hardware would have to be built to communicate over the interface, and it would be useless to others. Therefore, this component of the project report will be more of a research area. In searching for relevant information, I came across a professor at NMSU.edu who is currently doing a project with his students whereby a USB OBD-II interface communicated via a kernel module. Also, freediag.sf.net has OBD-II tools, without a GUI. These tools would be a good candidate for existing serial port hardware.

Progress has been made on another component of the project, the relay-mouse status sensor. This plan has been modified to use a USB mouse, as it makes more sense then using a serial-USB dongle. The daemon is nearing completion, with the ability to execute and terminate programs based on button status. There is no fancy IPC, though such a facility could be implemented to communicate with the DashUI element. I cannot see any use for this, however. The software and hardware should be completed shortly.

Two software elements that should be examined over the next week or so are the high-contrast/visibility GTK theme, and the project web page. As more and more content is added, it would be good to house it somewhere. A web page could also focus the work in these final stages. There is little over a month left to complete the whole project!

A Possible Interface
When this project began, there was a fairly clear vision of what the interface to the car computer could look like. Seeing as the presentation is coming up this week, I felt it was high time to put the idea into a format where it can be shared with others. This touch-screen would stow-away in the slot designed for optional cd-changer units, and would slide out like a drawer, then hinge down so that it could be easily usable from the front seats.

While I had initially intended to build this unit into a car, I am having difficulty locating a reasonably-priced touch-screen that has a diagonal of 6 inches or less. The units I found generally tend to be for medical equipment or factory equipment purposes, and as such, are far more expensive than common sense would indicate. Understandable, seeing as the general consumer would not find such equipment very useful.

The difficulty in obtaining a screen coupled with the Xbox's green-tint VGA output are making the unit look less and less appealing for car-pc purposes. The initial benefits of low cost (~$200), good durability (designed to be handled by children), and fairly low power requirements (~100W) seem to be offset by minor annoyances that make it impractical to build a fully-functional in-dash unit. The very cold weather of this January has not been helpful either. Would it even be safe to spin up a hard drive at -30°C temperatures?Would the electronics be able to handle the condensation that would follow shortly thereafter?

For the project, it should be possible to work without actually building the computer in. For the poster-fair/demo I have come up with a simple method of exporting the display to a touch-screen laptop that should show how things are to work. This model may even be considered as an alternative to VGA output, using a PDA mounted on the dash to interact with the car computer. Still, I was hoping to have a fully-functional car computer in the end.

DashUI Progress
Tonight was dedicated to adding configuration file parsing to DashUI. I decided to use the standard IniFile format, as it's easy to understand and easy to parse.

The C parser is about one hunded lines in length, and handles comments, whitespace, any field order, and the various data types that would be found in a configuration file.

The format is extremely simple, For example, to embed the xlogo program:

# This example swallows the xlogo program [X Logo] program = "xlogo" window = "xlogo" icon = "applet3-48.png" resize = 1

However, the main problem with the approach to DashUI is that it still requires a window title to swallow any application. This is problematic for some programs because of either synchronization, or unpredictable window titles. That should be the next problem to solve.

Success
The DashUI program is now moderately useful. It runs cleanly, has a low overhead, and looks pretty good too.

At this point, it can swallow just about any window, even complex programs like media players such as Totem. However, one problem that needs solving is selection of which window to swallow. In programs that have unpredictable titles, the window cannot be specified in advance. In others, like gpsdrive, the splash screen gets in the way. Have not decided how to get around this yet.

From using DashUI with a mouse, it is fairly clear that the solution would work very well on a touch screen. Large tabs that are always where they should be, quick switching between applications, and the ability to swallow anything really work. From here on, it should be mostly cleaning up the code, as well as adding configuration file parsing.

Beyond a Mock-up
The previously-designed mock-up is now a reality. Written in GTK, with code borrowed from gnome-swallow, the xeyes program was swallowed into this preliminary design. The program is actually attached to the tab pages, so when a tab is switched, the eyes are hidden. They return when the first tab is once again focused.

There are still many things to work out. The immediate concern is whether it is possible to have multiple applications swallowed. There is no reason why this should not be possible, but the current code does interesting synchronization magic by forking the swallowed program off and then attempting to control the main program loop. This, obviously, cannot work with more than one program at a time. At the same time, with a small number of programs swallowed, perhaps it is not a significant performanceissue to overcome.

The step after that is to be able to dynamically specify which programs belong to which tabs, rather than hard-coding. Related to this is the ability to set the swallowed applet's size. Currently, the eyes are scaled to fit the tab content area via command-line argument to xeyes. This solution is not practical when there is a configuration file, as the size of the tabs is not known in advance. Since the window identifier of the swallowed program is known, it would be cleaner to suggest to the program to resize to given dimensions via an Xlib call after the program is started, much like a window manager would.

Overall, this design is working out fairly well.

User Interface Idea
Now that exams are over, as are Christmas festivities, I am proceeding full-steam with producing software I envisioned while studying for exams.

It occurred to me that the flaw in DashPC's design philosophy is that it's just a launcher. It sits on top of a window manager and launches applications (and a few other things). What is needed in an automobile is an interface, something that does not hide behind windows, but rather allows control over them, and is always available to switch to other programs. However, it should not be a window manager, as that would have to take control of any child windows that a program starts, and that is not the goal. The idea is that child windows are the exception rather than the rule, and those should be handled by a window manager when they do occur.

The result of my ideas is a tab interface with large, simple tabs on the driver side of the screen. Tabs can be added or removed from a configuration file, and each tab corresponds to a different program, always running. The program corresponding to each tab is held within the tab's content area, as pictured for gpsdrive (this is only a concept graphic).

The difficulty lies in embedding the program. Several protocols were considered, including xembed. However, it needs to set up a socket and communicate with the client program, which would require modification for each program to be used. Finally, today, I came across gnome-swallow, which literally swallows any window into its panel window. The whole program is approximately 500 lines, with 75% of that being the panel code. The remaining swallow code should be very easily portable to any other GTK application. If all goes as planned, this means the program will be fairly trivial to write.

To make things even easier on the user, a high-contrast GTK theme could be easily designed to make it very clear which tab is selected. This theme could also enforce larger text, as needed for readability on smaller screens. I am also thinking of designing a hardware switch that would make the software automatically tint to a dark green or red when the vehicle's lights are on. This could be executed right at X11's level via colour-correction functions.

VGA Output
The majority of this evening was spent constructing a simple converter that takes output from the Xbox and converts it into mostly spec VGA.

The Xbox has a video encoder chip that takes the raw digital input and converts it to (usually) composite video, although it also outputs luminance and chrominance for S-Video, as well as both current HDTV standards. From a combination of signals from all of these formats, a VGA signal can be formed. The problem is that the sync signal for the whole picture is encoded within the Green channel. This is not VESA-compliant.

The solution to creating a more-or-less VESA compliant signal is to use a video sync splitter chip. In this case, the National LM1881N was used. The input to the chip is the Green channel and the outputs are the horizontal and vertical sync signals, which go directly to pins 13 and 14 on a VGA connector.

While the rest of the PCB is mostly pass-through for the video signals and their ground lines, there Xbox also outputs audio through the same connector as video. Therefore, there is a stereo headphone jack, and it works surprisingly cleanly.

Unfortunately, the video portion of the converter is not ideal. It was expected from the start that there would be a slight greenish tint, since the colours are not weighted for VGA display. However, the green tint is quite heavy wherever other colours are not displayed. Also, there are occasionally some sync issues. Upon investigating the completed circuit, it appears that the resistor is approximately half as resistive as it is supposed to be. Perhaps the resistor is faulty. This may explain some of the issues, so it will be replaced at some point in the near future.