Microchip ICD 2 and Windows Vista x64

While on Christmas break, I purchased a few things to get started on the stock clock project.  First was the Explorer 16 development board, which is the same one that I used while an a co-op (internship).  I bought this particular one since I was already familiar with its features and the processors that came with it (a PIC24 and a dsPIC33).  To save on costs, I bought the In Circuit Debugger from ebay (a Microchip one, not a clone) for about half the cost of a new one.  After playing with it for several hours, I could not get it to work.  Reading through the Microchip fourms brought something to my attention.  The old ICD2 modules do not work in Vista x64 but the newer ones do.  This left me with a problem, as I no longer have a 32-bit install of Windows.  I’m not willing to change my Vista install on my desktop, so this left me with a few options.  I could install Windows 2000 on an old computer, but I would rather not have to boot another computer every time I want to work on this project.  It then hit me that maybe Virtualbox could forward the USB connected ICD2.  So my current setup is running Windows 2000 with the Microchip software as a Virtualbox guest with a Gentoo host.  This also has the added bonus of not making me reboot into Windows Vista on my desktop (dual boot Gentoo and Vista.  Vista is used for games.).  I’ve only done some minor testing, but I have gotten MPLAB to talk to the board without any additional issues.  Depending on how much free time I have, I should actually make some progress on the stock clock in the coming months.

Internet Enabled Wireless Stock Clock

A project that a friend of mine wants to complete is to build a small clock type device that can connect to the internet and show something like +/- 10% for the stock market (or a specific stock).  The preliminary concept involves 2 physical devices and a program on the computer.  The program on the computer will obatin the information on the stock performance from the internet, and format it into a percentage to be sent to the actual clock.  The program will send the data to the first device, which will take the data from the program and send it wirelessly to the stock clock via a ZigBee controller.  The second device, which is the clock itself, will then recieve the data and adjust the clock accordingly.  The plan for the clock is to use a PIC microcontrollor to take the data from the ZigBee reciever and use the information to determine how to move the clock.  The look we are going for is an analog needle type clock, so a stepper motor will be used to control the position of the needle.

Since we have just started working on this, not all the details have been worked out.  My friend will be writing the computer software and the ZigBee transmitter; I will be building and programming the clock itself.

The choice of using ZigBee is to evetually allow multiple stock clocks to recieve data from the computer without needing to dramatically increase the complexity of the network.  Plus, its a good excuse to use the ZigBee controllors that we already have.

I just purchased one of the PIC development kits that I have used before at a previous job, so once that comes in next week, I will be able to get started programming the microcontroller.  I will eventually design a PCB and have one built for the final device.  Updates will be posted once work actually starts.

Infrared Robot Detection with Obstacle Avoidance

As part of a Robotics class I took as a professional elective, I designed and built two robots with the intent of having them interact with each other. My original idea was to have them play a hide and seek type game, where one robot would chase the other, while both of them would avoid hitting objects in the room. This idea was overly ambitious considering the amount of time I had to complete the project, so during the construction, I modified the design goals of the robots. In the end, I built two robots named Oedipus and Tiresias both based on a small 4 wheel drive platform used in one of the basic labs done in class. I fitted both robots with 2 proximity sensors to allow them to wander the room without bumping into objects. Tiresias, in addition to the proximity sensors, was fitted with 4 IR LEDs. These LEDs would be a beacon for Oedipus to see with a detection circuit, and thus take action. Oedipus was programmed to turn away from the direction that Tiresias was detected. If the other robot is not detected, Oedipus will wander the room in the same manner that Tiresias does.

The core of the robots is a OOPic controller, the OOPic-R board with the B.2.2+ controller worked well for this project. Its certainly not the fastest or most powerful board or processor, but provided the basic functionality I needed. This board has 4 ADC ports and 16 digital I/O ports and provides a regulated 5V supply to sensors or any other peripherals. The compiler for the chip uses its own custom syntax for many things, but also allows BASIC and C syntax for the code. The custom commands make setting up some sensors quite easy. On these robots, each wheel has its own servo, and the servo commands that are part of this compiler made it relatively easy to control them.

The obstacle avoidance used in each robot is quite simple. Each robot has two Sharp GP2D12 infrared rangefinders mounted on the lower platform on the front of each robot. They are angled out from the center of the robot by about 30 degrees so that an object that would clip the side of the robot will be detected. When an object is detected within the range specified by the code (in this case, about 40cm) the robot will turn away from the object until there is no longer an obstruction. The proximity sensors themselves are analog and will output a voltage that is very nearly linear to the real distance of the object detected. The sensors are connected to the first two ADC ports on the OOPic board. In the code, the voltage read by the ADC is compared to a predetermined value that I found through testing the sensors. These sensors were very easy to use and seemed to be quite reliable in the testing that I did on my robots. They did not fail to detect an object even under bright fluorescent lighting, but I’m sure one could find a situation where they may not be ideal. The only time I could cause the sensors to fail was to put something about 5cm in front of the sensor in which case they would fail to see it, but due to the rather slow movement of the robot, it is very unlikely that something could get that close before the robot could react.

Perhaps the most important part of the robot was the infrared detection of the other robot. The circuit to do so is rather simple and consists of just a comparator connected to the photo transistor, a voltage divider, and an output LED to provide visual confirmation that it is working.

Infrared Detector Schematic
Infrared Detector Schematic

The IR LED is shown on the schematic for reference. To demonstrate the capabilities of the robots, I took two short videos of them in the lab. The LM339 comparator chip used is a quad package. I used three of the comparators to allow Oedipus to sense from the left, right, and behind. I could not get the fourth to work and I was not able to determine why. Tiresias had 4 of the IR LEDs in it with the 470 ohm current limiting resistors on each LED. I could have run all four of the LEDs in series and used a single resistor, but I did not think of that until after I started building the board.

The only issues I had in getting the robots to work properly, besides my own inability to build a perfboard right the first time, is that the phototransistors could detect the IR LEDs from behind and on the side as well as in front of them where I wanted. This meant that when the IR LED was supposed to trigger the right detector, the left would also trigger due to IR light going into the bottom of the left phototransistor. To solve this, I put a small piece of electrical tape to cover the side and bottom of the phototransistors which solved the issue. The robots work to my expectations, but there is certainly more that could be done with them. First of all, only one robot is able to detect the other. One robot wanders around the room without any knowledge that there is another robot involved. I would like to put detectors on both robots, and have one actively chase the other. In its current state, on robot runs away from the other, but no attempt is made to make chase. Since this project has already been completed for a grade, I doubt I will continue working on it. Below is a zip file with the code used for the OOPic controller and an EAGLE schematic of the controller board.

robotics_project.zip These files are released under GPL version 3 as specified in the COPYING file contained within.

Here are some images of the robots.


Tiresias with 4 IR LEDs

Oedipus with Infrared Detectors
Oedipus with Infrared Detectors

Oedipus Rear View
Oedipus Front View

Oedipus Rear View
Oedipus Rear View

Webcam on a Telescope

One of my previous project ideas, stemmed from an article in Astronomy magazine, was to use my low cost webcam (Phillips SPC 900NC) to take high quality images of the moon and other objects.  I have recently been putting more time into this, but have been frustrated by an inability to focus properly.  I had intended to use my TeleVue Pronto refractor, however this will not be possible.  When used together, the scope is unable to focus on objects more than about 30 meters away.  Hardly far enough to focus on anything useful.  I think the problem arises because there is no lens in front of the CCD sensor to allow the correct compensation.  If my thinking is correct, a telescope with a longer focal length should be able to allow proper focus at astronomically reasonable distances.

So hopefully I’ll be able to make use of another telescope soon, so that i can at least get some images to play with.

Edit (12-27-2008): As noted below, the problem is solved by using the camera adapter that goes with this particular telescope.  I do have it, and it does work as intended, but time constraints have prevented me from following my initial plans.  Maybe after graduation I’ll have some time to spare…

Bluetooth Comes Alive!

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.

Successful Bluetooth Transmission

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.

Philips SPC900NC Camera On Linux Is A Go

In researching information about using a webcam as a low cost camera for astrophotography, many people recommended the Philips SPC900NC camera due to its use of a good quality 1.3 megapixel CCD sensor at a decent price. I bought mine from ebay, but its also available on Amazon and Newegg. My first attempt at playing with this camera was on my main desktop running Windows XP x64. This proved useless, however, as the drivers will not work. The Philips software will install fine but it cannot recognize the camera. Windows detects that a USB device is plugged in but can’t do anything with it because of the incompatible driver. I currently do not have a 32 bit version of Windows XP, so the next course of action was obviously Linux.

My laptop currently runs Ubuntu (was running Xubuntu until yesterday, just did a little swap of GUI’s) and was a prime choice. The camera did not work “out-of-the-box” as can be expected, but a little searching netted me a working driver for the camera, known as pwc. The pwc driver works for many Philips cameras, including the SPC900NC that I’m using. Installation is very straightforward for anyone who has compiled programs. Once the driver was installed, Camorama didn’t have a problem detecting the camera and capturing images from it. Next step is to work on capturing video from the camera, which mplayer may do for me.

Since the camera is working, I took a few pictures to test it out. Image quality is pretty good and should work perfectly for my astrophotography plans. Here is a picture of my Tele Vue Pronto refractor that I’ll be using for this project:

tele vue pronto hires

LED Display

A while back one of my roommates bought 2 LED displays as part of a project idea. The signs kind of fell on the backburner as other things came up, but I thought that I could start playing with one of them since it shouldn’t need much work to get it operational again. The display is an Alpha 210A, and is missing both its power supply and controller. Normally a missing power supply wouldn’t be a problem, however this sign uses 7.5VAC. Finding a transformer with a secondary rating of 7.5VAC proved to be rather difficult, but I finally managed to find a place that had something usable. Herbach & Rademan carry a transformer that provides 7.5VAC at 1.5 amps, so I need 2 of them, as the sign is rated at 2 amps, but for $3.95 a piece I can’t complain. They do have a $15 minimum order but they had other items that I needed anyway. Their site does not have a secure checkout, so you might want to consider calling or faxing your order.

The next issue, of course, is the programming controller. According to the Alpha website, the displays use either RS-232 or RS-485 to communicate with the controller. I’m not sure which standard my sign uses, but if its RS-232 conectivity will be easy. RS-485 shouldn’t be a problem but will require an adapter. I’ll look for the specifics of the communications once the transformers come in and I can verify that the sign actually works.

Webcam Astrophotography

An article in the December 2006 issue of Astronomy magazine about using cheap webcams for astrophotography got me quite interested.  After doing some research this evening, it seems like it can be a cheap and fun project to undertake.  I think I have my heart set on a Philips SPC900NC webcam, which goes for about $50-$70 on ebay.  It would require a telescope adapter which goes for $20 shipped on ebay.  My plan is to use this webcam and experiment much more fully with astrophotography than my past musings, which consisted mostly of taking an occasional film photograph of the moon or other easy targets.  By shifting to a digital medium, I’ll be able to experiment a lot more without the guess work of traditional film, plus the webcam is cheap compared to specialty cameras.

My first target will most likely be the moon, as its easy and provides a good starting point to developing the techniques, starting with single pictures, and then moving on to mosaics.   Images are  captured by  taking an AVI video for a length of time, using software to turn the AVI into a series of stacked images, and then combining the stack to reduce noise and provide a much clearer image.  I’ll be able to provide more details once I get going with the project, but two popular programs used for this kind of photography are K3CCD ($49.00 after 35 day free trial), and RegiStax (free!).  I hope to use my dad’s 8″ Schmidt-Cassegrain telescope for most of the images, however I’ll probably have to use something a bit smaller (like a Tele Vue 76) most of the time.  This might have to turn into a spring project to take advantage of warmer weather…

Bluetooth Developemnt

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.