I have a deam... Nah, that's a bit too grand, let's just say I have an idea, an idea to get more out of my car and my Palm IIIc this page is a collection of my notes on the project.
About the name: The name Oggster was chosen because it's going to be storing the audio in the ogg vorbis format mainly because ogg vorbis gives much better audio quality than mp3, but also that that ogg vorbis is truly Free of any silly patents.
I resently talked with a friend of mine and he came up with the idea to use a Palm pilot as the head unit of an OGG player for the car and the other day I stumbled over a really nice deal on a Palm IIIc, a very nice model that has a 256 color display (out of 4096 colors) so I got it thinking that I'd always wanted an extra gadget and that this project might be ripe for implementing soon (read: within 2-3 years:)
The goal is to produce a system that will play ungodly amounts of ogg-vorbis and be able to display a gps-controlled map, it would be much cooler to get hold of a detailed vector based map of scandinavia in stead, but I've had no such luck.
My old car (Ford Mondeo) didn't have OBDII, but my brand new Lacetti does, so in time I hope to add stuff like an accurate flow meter and a km-left-in-the-tank-gauge, but that's for later.
Read: cheap, intelligent 240x320 TFT touch screen, head unit, I was meaning to use my Palm IIIc, but I got my hands on a Compaq IPaq, its battery is dead, but the screen is better and it has more CPU and RAM than the IIIc so I'm going to use it for the headunit.
As I'm now using an ipaq for the headunit there is very little software that I need to write for it, it has a USB port which as aroudn 100 times more bandwidth than the serial cable (12 Mb/s vs 115kb/s), so I might end up simply using VNC on the framebuffer and let all software run on the main pc.
The ipaq has a lightsensor and it's easy to control the backlight so I'll write a small utility that will read the lightsensor and control the backlight.
Having the super-bright black-on-white colors shining in your face while driving at night is a bad idea, so I want to be able to change the color scheme of the system without too much fuss (maybe even let the built in lightsensor of the ipaq control it and automagicly switch to night colors when it has been at minimum brightness for a few seconds.
The jukebox functions I need have been Implemented by a project named Giant Disk but as it's Palm based I'll just have to do it all my self, but it's not too hard and I'll have fun doing it.
I'm currently thinking that one of the hardware buttons (notes perhaps) should become the 'mode-selector' when the ipaq is in the car-cradle, so it would select Jukebox -> FM Tuner -> Navigation in turn or maybe the 4 hard-buttons should simply become direct short-cuts to the different modes, I think the Tuner mode should also implement the pre-amp controller (select source / ajust volume)...
A car-cradle for the Ipaq, I have a sleeve, which is just a hunk of plastic, and a USB cable, together with some sort of mounting arm it's all I need to fix the unit in the car, I'll leave the cable more or less unattached so it can be pulled out and a passenger can operate the system without leaning over.
The main system will be a VIA EDEN based box with 80 GB of diskspace.
The box will be mounted in the trunk of the car, so it doesn't really matter what it looks like, the machine will also be given an ethernet interface that will be brought out near the drivers seat, to allow me to interface with the main system via my laptop, it could get wireless in stead though as that would allow me to manage the system from my appartment as well as from the car...
The EDEN is good because it is basicly a standard PC and it's faster than the laptop I have around, it has 4 USB ports, one parallel, one serial and one PCI port.
To avoid draining the battery the main system will need to auto-power off along with the car, I'll build a simple circuit that will keep the system powered up until it turns on a certain pin on the parallel port and the car is off at the same time this means that once the computer is powered up it will stay powered up until it turns itself off, to know when that is the power controller also includes an input so the computer can sense the ignition on signal from the car. This is so simple that it could be wired up on a small prototyping board, but it will get integrated in the headunit so it might even come under control of the headunit processor.
I've just done some actual measurements on the EPIA box, and I found some interesting pieces of information:
This means that I'll need to find a way to make a regulated +12V 4.5A supply from the cars 9-18V with plenty of noice in it.
Luckily others have solved the same problem before so it shouldn't be too hard to find a good solution.
I've now built Bob Blicks UC3843 based switched mode powersupply and it works like a charm, although there were some components I coun't get my hands on, see the car power page for the details.
The software that's going to run on the main system will be mostly home-cooked as well, it will do all the hard work and use the Ipaq as a smart terminal. The first job will be to make it do the ogg playing with a friendly interface on the ipaq, the Giant Disk packace got the software side of things covered pretty well, but only for PalmOS, so I'll need to do it all my self.
The mapping and routing stuff is probably going to be done via Mapfactor Navigator at 129.99 GBP it's quite fairly priced, although the application is very rough and unstable at the moment.
I'm going to need some extra software for the route planning, it's probably going to be Mapfactor Navigator with some sort of facility for transfering roting information to an USB keychain so I can move that information to the car easily without having to do all the planning in the car.
The current Mapfactor Navigator is quite user-hostile:
I hate having to use closed-source software, everything is just so hard!
I've found a *cheap* GPS, one with no interface other than usb, the cheapest one I've found is about 99 USD: GPSU at delou, I've taken it for a few drives and it works really well.
The only problem with the delou gps is that it's completely undocumented, luckily Delou doesn't really make the unit, they only rebrand the EverMore GM-X205 unit (like just about everybody else that sells small integrated gps units), which means that the datasheet from EverMore can be used, the original datasheet could probably be found on EverMores website, but they seem to be completly Internet-illiterate, so to save your the trouble my copy is here: GM-X205_UG_revB.pdf []
I've written some perl code to decode the NMEA data and present it to the application in a nice nested hash: gps.gz [12K]
Building my own USB device has the sideeffect of forcing me to write a USB driver for Linux to drive it, that should be a lot of fun as the unit would contain several functions that would probably need to be driven by separate drivers (like audio output).
Currently I think the device should end up with these standard interface classes:
This means that there will be 2 interfaces and they will be driven by existing generic drivers, meaning less mucking about with Linux kernel (or worse windows driver) source.
There doesn't seem to be a standard serial port class, this is very unfortunate (probably a case of "rs232 is what we are replacing so we must punish its users"-mentality at the USB cartel), so it might end up being a custom interface after all, but it will probably consist of an IN and an OUT bulk endpoint for the data.
I could go ahead and build the finished unit from scratch, but it would probably end up being expensive as my electronic-hacking-skills are pretty rusty after many years as a software hacker, so I'll start out slowly:
