Despite my lack of posting, I actually have been working on my bluetooth hardware, and am proud to report that I have had my first successful bluetooth wireless communication between my Windows machine and my CB280 microcontroller (its based on an Atmega128). Using Hyperterminal, I connected to the outgoing COM port created when the bluetooth dongle makes a connection. The program running on the microcontroller switched LED’s and relays on and off depending on the ASCII character that was sent. Currently, the program only recognizes single character commands, and the next step is to expand that to include entire character strings. On the hardware end, I want to eliminate the use of RS232 as the communication method between the microcontroller and the ACODE-300 bluetooth chip. By using RS232, I am required to use a RS232 converter board for the bluetooth chip. If I eliminate that, I can use direct TTL for the communication, which will give me reduction in power consumption and in the amount of hardware needed.
Getting this far was not without its problems, however. I did manage to fry 2 of my RS232 conversion boards ($20 each) as well as one of my bluetooth chips ($60). First mistake was using what turned out to be a 9V AC power supply on the chip. This proved disastrous for the bluetooth chip, but also means that I now have a power supply for my Alpha 210A LED sign. Programming that will come later, since increasing the functionality of my bluetooth setup is my current priority.
After putting off working on this project for a bit, I’ve taken in up again this week and successfully used the bluetooth chips to send data between two computers. I set up one of the chips on my server (using a RS-232 adapter board), and used my D-Link DBT-120 bluetooth adapter on my desktop. Using hyperterminal, I was able to send ASCII characters and small files between the two machines without too much trouble. One of the issues I noticed is the inability of the two bluetooth devices to reestablish a connection when one of them is turned off. I think the problem lies with the settings on the ACODE-300 bluetooth chip that I’m using but I am not sure. I need to do more testing, but I’m pleased with the success of the chips so far.
After getting the bluetooth to work between two computers, the next logical step was to test it with the microcontroller that will eventually be placed in the car. I was unable to get the microcontroller to communicate wirelessly. The only reason for this that I can think of is the serial cable may need to be a crossover cable. I have a crossover adapter, but I can’t connect it until I get a male to male gender bender. I’ll probably run down to Radio Shack (they’re not big on carrying useful stuff anymore…) tomorrow to try get one so I can get this thing going.
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.
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….