The record and playback features of the RC car are in great working order. The car can record what it does for a maximum of between 20 seconds and 4 minutes (depending on resolution). Over 4 minutes as a maximum record time and it begins to lose control. I'm in the process of turning the whole thing into VCR and TV combo like controls. It'll have "Play(back), Record, Stop, Pause (works with both playback and record), and Play(live - same as record but dosen't record).

Did a bunch of work with the Java server, the GPRS can connect to it and the sever stores whatever is transmitted to it. Need to get the HC08 to properly transmit the GPS data to the GPRS modem.

Today we moved our newly written code onto the TPM2 module (5 channels) so we can use 4 to capture both throttle and steering (2 channels each, one for rising edge and one for falling edge) and moved all the output code to TPM1 (3 channels) so we can use 1 channel each for outputting the signal to both the steering and the throttle.

We may have run into a snag though...
We programmed the record and playback feature. We programmed the board to record until it runs out of ram and then playback. It actually works! We still need to get it to run at the correct speed in playback mode though and it only records about 25 seconds... We may be running out of RAM space to run the program. 4K of RAM only goes so far. Andre thinks it may be because we're using a demo compiler, it may limit the space we can use until we shell out a bunch of money for it. I'm not sure though. We may need to find ways to optimize our code further.

Finished Writing the code to get the 68HC08 micro-controller to capture both rising and falling edges, determine the time between them that is a logic HIGH (this is based on the number of clock cycles the processor has went through divided by a prescalar), and then calculate the hex value that will result in duplicating the same duty cycle with a logic HIGH and outputting it to a TPM channel. After working out some kinks in the code (if the rising edge is near maximum number of the counter the falling edge will be near ZERO resulting in a "twitch"), its working smoothly. The wheels turn in both directions super fast and very smoothly with lightning fast response... a simple IF statement removed the "twitch". Next up on the agenda: recording the signal so we can "replay" a path.

Got the serial connection between the motorolla board and our GPS module working. Turns out the 2 bits which controlled parity in the serial control register were for generating parity bits (i.e. creating new content), not for configuring the serial ports for communication... seeing as the GPS module was already creating a parity bit for odd parity, we were ending up with 2 parity bits - confusing the hell out of the software. As soon as we set both bits to ZERO, we were able to get communication.

Andre received the GPRS modem with the breakout board and antenna in the mail today. The SMA to MMC connector he already had was the wrong size on Antenna side so we were unable to use the Antenna. I put in an order for the correct adaptor and its being mailed to Andre.

Using the same UART breadboard we built to do initial testing on the GPS module, we hooked up the GPRS modem to a serial port on the school's computer. Loaded up Hyper-Terminal: Com1, 9600 baud, etc... typed "AT"... and got the response "OK"... yaay! something finally works right off the bat. The GPRS has auto-bauding, but it says to ensure accurate communication to manually set the baud once you're inside. Typed "AT-BR=9600" to manually set up the baud-rate (I think that was the command anyway) and got the response "OK". My cell-phone's SIMM card was inside and we typed the AT command to determine whether it was password protected... it wasn't so we skipped the password steps and got to the check network status. Even without the antenna it was able to detect a( or several) network(s) but it was not allowed to connect to them. It could be because I don't have GPRS as part of my plan. Tried the same thing with Sophe's and Andre's SIMM card and got the same result each time.

One of us needs to sign up for GPRS access and we need to hook up the antenna once Andre gets the adaptor in the mail.

One small piece of bad-news, Andre ordered the digital thermometer at the same time as the GRPS modem so we went ahead and opened up the casing. Apart from the LCD module which displays the temperature, there's just 1 connector at the bottom... a serial connector. ARGH! Our GPS module uses a serial connector, our GPRS modem uses a serial connector, and now the thermometer is going to use a serial connector. The motorolla board only has 2 serial connectors. Hopefully we can manually wire in a UART and turn a standard port into a serial port but I have a feeling we won't be able to.

Did the first "formal review" for our car. Demonstrated the Micro-Controller turning the wheels left and right instead of the Remote Control Receiver. Did a pointless power-point presentation that had a couple of pictures, some of our flow-chart, and a couple examples of the code we're using.

After the review, tried all day to get the GPS to come in 1 serial port, and go out the other... again. Its been a whole week now! We did make some minor progress, however, we got the hardware configuration of the interface between the GPS module and the micro-controller down correct beyond any reasonable doubt. Unfortunately it still dosen't work... so it HAS TO BE the program. Sophy sent an email to me:

"The microcontroller uses a uart chip. You can't do it with a uart chip, you have to use a usart because the gps module sends out burst of transmissions every second. It uses synchronized serial communication and you would need a 8251 USART chip."

I Cleaned up the code a bit. Its not exactly object oriented, but at least everything is out of the main function... Finally got around to testing the GPS module by wiring it directly to a UART Circuit Andre built onto a bread board. He soldered a loose serial connector onto the UART and we ran a serial cable into one of the school's computers... anything Andre wires is staying well away from the serial port on my laptop. Using a couple of TSIP (the protocol our GPS module uses to communicate) programs we were definately able to get some information out of the thing. The problem is, it was being powered by a laboratory power supply bolted to the table. The data-sheet for the GPS module clearly says you can't pick up crap from the satelites while inside. Despite this we were able to pick up a couple of satelites... unfortunately it still wasn't enough to give us even any kind of longitude or latitude. Its now my job to wire something together that is exactly 3.3 volts and portable so we can drag it outside to test. The 3.47 volt cell phone battery DID NOT WORK! I've never heard of something being so picky. We disconnected the UART and hooked the GPS back up to the micro-controller to get back to coding. Unfortunately Andre mixed up the ground and power cables. The GPS module which ordinarily draws 0.078 amps at 3.3 volts was drawing 3.5 amps at the same voltage... needless to say it warmed up a bit before we noticed and corrected it. Fortunately there was no magic smoke and once it cooled down it started to work again. Everything we've tried to get the serial communication to work has failed miserably. Anyone know about 6808 coding? Specifically 68HC08GB60!

Rewrote the code for the Motorolla micro-controller in C... using 2 different PWM channels and outputting the idle signal for steering on one channel and outputting idle for throttle on the other. The board has no trouble producing both signals simultaneously.

So far the RC Car is coming along nicely. Andre and I finished writing the assembly for the motorolla chip so when you pulse port A1 low it turns right and when you pulse port A2 low it turns left. The wiring job we did was pretty shoddy but it was only for basic testing, when we are ready for open road testing we'll be sure to put it together a little bit better. The servos for the steering, shifting, and throttle are all using pulse-width modulation, all with only 1ms duty cycle difference between the maximum and minimum values. Luckily, pulse-width modulation lets you use any frequency you want as long as the period is long enough for you to squeeze in adequate duty cycles. The original radio receiver used 50Hz singals (20ms period) and we're using closer to 300Hz (if I remember right less than 4ms period). We could only get it down to that frequency because the maximum scalar divisor for the output is 128... so to get a lower output frequency we would have to lower the speed of the processor. The motorolla chip can go anywhere from less than 1MHz to 40MHz, if we get it much lower than 18MHz the signal starts to freak out... like the board is having trouble generating it. We're just lucky that the frequency we got it down to works perfectly with all the servos.

Next up, sending GPS data over a GPRS cellular modem to an SQL database via the internet and then pulling up the data with a GUI on an internet connected computer.

Andre and I tweaked the code a little bit. We changed the 8-bit analog-to-digital convertor to 10-bit and decreased the delay, this resulted in the servos running more smoothly.

Also finally completed the calculations of converting our desired duty cycle in mili-seconds to the appropriate hex value based on the frequency of the signal being output. I'll see if I can post the equation in a future journal. Changed the hex values in 3 places for each servo, so now the steering will turn dead-center when you power on the car and it can only turn so far in each direction... the servos can turn more than the gears allow them to. Don't want to burn them out. Andre calculated so precisely that the steering stops turning at the exact moment the pulse-width stops increasing or decreasing. Very effective coding.

Everyone dosen't like things that smell bad, but perhaps they will like things that don't smell so bad as long as they have a good disposition.