Trouble-Shooting

As easy as the whole design of the lab sounds, it wasn't without the typical baffling problems that slow down any design process indefinitely. With that said, almost of all my difficulties were easily solved with a simple solution that usually involved me thinking things through slowly. The first problem I came across involved the power supply. Once I had the basic opto-isolation circuit, I thought that it would just run off the adpater that came with the race set. Apparently there wasn’t a transfomer in the track itself and that all the power was coming out of the adapter. The adapter appeared to convert an AC voltage into an AC voltage, instead of the DC voltage that was specified and I expected. This was was useless for the circuit that I had designed and overall jst didn't make sense. Apparently, the AC power was ideal for the variable resistor in the user-friendly handheld controller that originally came with the race car set. Instead, we needed a power source that drove about 10-15V. Fortunately Professor Land had a variable voltage source in his office that would crank out up to 16V. Once I had this I was able to hook the voltage source directly up to the track and the car would run at top speed.

To slow down the car, I needed to figure out how PWM worked. When I originally started working on this study, I was using Atmel’s 90s8515 which had different register names for PWM. I eventually switched over to the MEGA32 which needed TCCR1A set to 0x81 and TCCR1B to 0x02. The first register value is used to tell Timer1 that it as in 8-bit normal PWM and the second register value determined the clock prescalar. If for some reason the power source was too strong or weak I could adjust the prescalar by factors of eight. When I was trying to figure out PWM, I didn’t set the clock prescalar which its default setting was 0x00 which meant there wasn’t a clock and thus PWM wouldn’t work. Once I fixed that, the car would run.

The next thing that needed to be implemented was the use of sensors on the track. The idea was that the students would use the signals from the sensors to determine the location of the car and change its speed accordingly. The sensors actually were quite difficult to use. At first it took me a while to realize that I needed to run a 33K resistor between Vdd and the output since the sensor was open-collector. The application notes failed to mention anything useful about that. Once I had that, I hoped everything would run smoothly. Unfortunately the sensors were somewhat sensitive and directional so they would only detect magnetic fields in a certain direction. I had situations where the sensor would turn on and off repeatedly when the car passed overhead. To solve this, I found that I could place a sensor really close to the metal strips underneath the track and have it detect the magnetic field that was coming off the magnet that controlled the motor. Ideally, I had hoped to use the magnetic field that was produced by the motor, but the sensors were unable to pick up that field. I also found that the best way to get the sensors really close to the track was to solder them to long wires and the resistor and tape them on. Any other way of attaching the wires to the sensors proved to be really bulky and unusable underneath the track. Even after figuring out all of this, the sensors still proved to be quite difficult to use since if they strayed even a little bit from the track, they wouldn’t be able to detect the car’s magnets.

Once I was able to figure out how the sensors worked, I still had to find a good way to implement them in the code. I actually planned on using the external interrupt function of the MEGA32 because I thought it was a interesting feature and would have a useful application because we would want to adjust the speed of the car as soon as possible. I wanted to "or" all the sensors together into the external interrupt and then use a counter in the code to determine which sensor was on. This turned out to be a bad idea. When the car runs over the sensor, it apparently pulses multiple times, causing all types of chaos. The original code I had would increment its sensor counter each time the interrupt was pulsed. Obviously this is bad if one sensor induces multiple interrupts. Since there are only three external interrupts and I needed at least four inputs for sensors, I had to scrap the idea of external interrupts. Instead I had each sensor’s output connect to a different pin of one port and then if that pin was on, I would compare it to the sensor counter that I had. This would allow the code to recognize each sensor in order without repeating one.

The last significant problem I encountered was incorporating the LCD. I hadn’t worked with one of these since early in the spring semester so it took awhile to remember how everything worked. I wanted to make sure that the LCD code I added to my program wouldn’t mess up the detection of the sensors, so I added some LCD code, but didn’t actually connect the LCD. This actually caused problems in the execution of the original code. What I found out was that the LCD must be hooked up correctly for the program to execute properly. Apparently there is communication between the LCD display and the MEGA32 such that the MEGA32 waits for a return signal from the LCd before continuing with its execution. This is a problem when the LCD display isn't connected to the MEGA32. Connecting the LCD to its correct port fixed this final problem.