Since I’ve solved the issues around the software portion of the system, I decided to get started on the hardware aspect of the project. I can’t really finish the software until I know exactly how the hardware will interact with everything. Most importantly, I need to determine how the chip will interface with the car itself. Also to be done is the actual connectivity of the bluetooth modules, which I have just started to work on.
The basic system will work like this: bluetooth enabled PDA will conect to the bluetooth chip in the car. The PDA will send the desired command to the car. The car’s chip will receive the command and send the command to the microcontroler. The microcontroller will execute a series of actions based on the command, such as unlock doors, start car, and boot main carputer. Upon completion of instructions, the car will send an acknowledge back to the PDA. The microcontroller in the car will most likely use relalys connected to the I/O ports to perform most of the actions. The bluetooth chip will communicate to the microcontroller through one of the two RS232 COM ports the microcontroller has. The other COM port will be reserved for monitoring the status of the chip, if necessary.
With a system like this, it is necessary to prevent any bluetooth device from connecting. Bluetooth does have a built in authencation system with encryption, however getting a device like a PDA to play nice with that seems to be a problem. Each bluetooth chip has a ID number similar to a MAC address so that it can be uniquely identified. For authencated sessions, bluetoth chips can have a 12 character PIN. Both chips attempting to connect to each other must have the same PIN stored. Setting the PIN on the chips that I am using for the car is not a problem, however I am unsure if I can have the PDA set its PIN for use to connect to the computer. I could make a FOB type thing that uses one of the chips that will be in the car (that I can set the PIN on), but that would ruin the purpose of using bluetooth in the first place (to be able to use a PDA or cell phone). One possible way to get around this problem is to only check the ID number of the bluetooth chip. Main issue there is the ability of someone to spoof the correct ID number and gain control of the car, assuming they know the correct commands to send to the car. Obviously someone would have to be rather knowledgable and determined to use such an attack to steal the car, but its something I would like to avoid none the less.
I was having some problems getting the microcontroller I’m using for bluetooth development to recognize certain characters being sent to it via serial. What was baffling me was the fact that certain keys worked, but other did not. For example, characters such as @, #, $, etc were working fine, but letters were not. I’m using Hyperterminal to send the characters to the development board, which is in turn taking the ASCII value and performing an action based on that value. For my testing I was having specific LED’s turn on when a particular character was sent to the board. After being stumped for a few hours, it turns out that a little Counter Strike was exactly what I needed. Some annoying youngster was having fun yelling into the microphone and typing IN ALL CAPS in the chat. Thats when it hit me: the code in the microcontroller was expecting a CAPITAL letter when I was only sending it lower case letters. I blame this on the fact that the ASCII chart I had was missing the 2nd page that had the lower case letters. No matter, now that I’ve gotten that annoyance out of the way, I can expand the functionality of the program to accept more complex inputs.
I had bought a Hauppauge PVR-500 a few months ago with the plan to build a MythTV box. My first attempt at this resulted in a 866MHz PIII with a 10GB hard drive running xubuntu being converted into my first MythTV machine. As you can imagine, the computer was a bit too slow for it to work well and the hard drive was far too small to be useful for recording programs.
I’ve finally gotten around to making a good effort into the myth box, due primarily by this deal on Tiger Direct. The price ($400, plus $24 shipping) was excellent, considering the AMD Athlon FX-60 processor alone is $399 at Tiger Direct, and $525 at Newegg. The Tiger Direct package deal included an OEM Athlon FX-60, Ultra CPU cooler, Ultra V-series 500 watt power supply, Asus A8S-X motherboard, and Ultra X-blaster case. My main desktop machine has an FX-55 chip in it currently, so I stuck the FX-60 into my main machine and am using the FX-55 for the MythTV box. This just leaves me to buy RAM and another hard drive to have a very nice MythTV box. The old MythTV box has been retired, and will most likely spend the rest of its days crunching SETI@home work units. The case that came with the deal is useless to me since I have everything rackmounted… to ebay it goes!
The only snafu with the new FX-60 in my main machine is that my BIOS doesn’t know what processor it is. I have a Asus A8N-SLI mainboard, which supports the chip. Its not a significant issue, as the processor runs the way it’s susposed to, however the BIOS reports it as “AMD Athlon: Model Unknown”. I checked for BIOS updates, but there are none… oh well. Its a lot faster than the FX-55, so I’m pleased with the purchase.
The MythTV install on the new box is great, definitely runs better than with the old PIII machine. Its running on Xubuntu and once I get a bigger hard drive, I’ll reinstall and do a more detailed analysis.
Earlier this week, my development board with bluetooth chips arrived. The kit is from Comfile and uses their CB280 microcontroller. Their development software is very easy to use and will make developing applications a lot easier than using the Texas Instruments MSP-430 microcontroller that I had to use for one of my classes. You can use BASIC or Ladder Logic to write probgrams, however I have never used Ladder Logic before. To be honest I have never used BASIC before either, but since its a normal programming language rather than a pictographic conglomeration, it wasn’t hard to pick up on. Its a hell of a lot easier than the assembly that I had to write for the MSP-430. As you can see in the picture below, the development board has a bunch of fun stuff on it, like switches, LED’s, and a few potentiometers (really for A/D stuff). Also shown in the picture are the two bluetooth chips that I’ll be using in a project with a friend of mine. The smaller circuit board shown allows the bluetooth chips to be initialized and connected to a RS-232 serial I/O.
The main purpose for the kit is to develop a few bluetooth applications with a friend of mine. We had the idea to use bluetooth to control several aspects of his car, namely the door locks and the ignition. This would act as a remote ignition system with the added feature of being able to be controlled by a cell phone or PDA. There are other extensions of the bluetooth control that may be developed later, such as allowing the PDA/cell phone to have control over additional aspects of the car and the carputer.
Currently, I’ve been working on the program that will take the signals form the bluetooth chip, do the proper interpretations, execute the desired action, and send an acknowledge back to the sending device. Since the bluetooth chips require a separate initialization and can take regular RS-232 inputs, I will work on the wireless implementation once the software portion is working. As it stands, the microcontroller can interpret single letter commands from hyperterminal via serial. The next step is to extend this to character strings. If necessary, an encryption scheme can be implemented on the data being sent, however whether that will be an issue will come later. Hopefully I’ll have the board recognizing character strings by the end of the week, as long as I don’t spent all my time skiing….
Now that I’m safely at my destination, I can continue where I left off. Recently I’ve been trying to see how long I can extend my battery life on my Thinkpad T30 (aka darkstar, running xubuntu). One of the methods I’ve been trying is not starting x (and thus not starting xfce). Of course there are a lot of variables that determine battery life, but so far under normal use I seem to get about 30 more minutes. Normal use would be internet (elinks vs firefox) and typing (nano vs open office). I’m going to continue to track battery life over time to get a better estimate over longer periods of time and for different amounts of CPU usage.
In an airport just doing a test of elinks. Working better than I expected on wordpress, glad to see that they’ve included text only support. I’ve discovered that my battery life is extended when I don’t start X on my laptop. More on this later, they just called my flight.
Back again, and this time it should be for good. Rather than host this off of my own server, I have moved things to hosting at 1and1.com. This should fix most of my problems, and for the price, outside hosting was a good deal.
My internet connection is still pretty sketchy, and Time Warner has no idea why. Only good part of this is that I don’t have to pay for the few hours a day that it actually does work (they’ve been giving me credit for the downtime). When everything is straightened out, updates should be more common.