4/1/01 - We finished our final lab a week early so we started working on the final. Here-to-be-named Project Mayhem. The project will consist of wireless pager devices(2) with a web interface. We were originally looking at 900Mhz transceiver devices from Laipac Technology Inc. but we have found another model from a British company Radiometrix the BiM2-433-64 with a serial interface so we are looking into getting some samples of that.

4/4/01 - We have a simple front end set up for the web interface. We have a form that talks to a servlet. We also got the servlet to send the text out COM1 serial port as a string. Right now a uCU connected through the normal serial UART is able to echo form data to an LCD. Nice :)

4/11/01 - A bit drained from the exam but we are in the lab. Go Mayhem! We have found a software UART on the Atmel site we think will suite our needs for connecting between uCU... the problem is it is all in ASM. We are trying to embed the appropriate parts into C but it is going slowly right now. We'll see what happens Friday.

4/13/01 - The Software UART doesn't work, either we can't get the timing right or something else, we don't know. The LCD is giving us very strange chars when we do a send from hyperterm. This is not looking good, we thought we would be onto data management stuff now but we can't get the right signals on a wire. I guess we'll try again Monday...

4/13/01 - Do you know what this means.... it means, this damn thing doesn't work at all (or something like that). The Software UART doesn't work, what can I say, either the mCU reboots or we get bad bits, whatever is happening it is not right. Anish is looking at implementing the simple software UART from the Atmel page rather than the interupt driven one... Hope it looks better on Wednesday.

4/17/01 - Transceivers we requested a while ago arrive in the States, Massachusetts to be exact. We are now expecting them by the end of the week so we can start testing.

4/18/01 - FINALLY got the software UART to work as assembly embedded in C. Well, sort of, we got the software UART on one uCU to send and another to receive, now we need to merge them into one file.

Later that night... - Yay, we got the merged file to work save some port twiddling (we use the HW receive on the remote and the SW everything else). It works! We sent our first message over the internet, through the serial, to a chip which sent it out a port, over a serial into another port out an LCD. Phew!

4/19/01 - Worked on the web interface some more... Firmed up which opcodes need to be sent between the devices and what needs to be sent from the web interface.

4/20/01 - Lots of progress now, feels that way anyway. Just had to get past that SW UART trouble. We started implementing the opcodes with addressing. Now when a remote device gets commands sent to him its address it does stuff and otherwise ignores it :) Works sweetly. We had some memory concerns, talked to the prof. seems if you set MCUCR we automatically get ~infinite memory! Well, not infinite but you know what I mean. OUr next step is to do some 3D arrays for the text. Oh yeah, Prof. Land also told us about a pair of 4x20 LCDs he has just sitting around, could be useful... };) Currently planning on finishing up the SW side next week and doing the HW conversion from the dev boards to proto boards the final week when computers are scarce...

Later that same day - Guess what came ??? Our transceivers finally made it and boy do they look sharp! The problem, they only sent me ~2~. This might be the end to our plans to do multiple remote stations!!! Too bad, maybe we can do some kind of wired hack. On the other hand, that's one less HW board we would need to construct. Still, I am happy to have the Xvrs, a bit sad they didn't send all 3.

4/23 - We finally got a chance to test the transceivers. We where VERY careful to wire it up appropriately. Would you beleive it worked the first time? NOOOOOOO. We seem to be having some level issues, we've tried to filter the input and output of the transceivers with verying levels of success. We know signals are going through and our routines are interupting, but thats all we know for now. We'll work again tomorrow night, hope for the best.

4/24 - Again, we are having issues, there seems to be a lot of noise happening, interupts all over the place, and no good signals...

4/25 - Argh, so discouraging, this thing just isn't working as expected... wait... ahaaaaa, it is working. In the documentation for the previous version of the trans. we noticed you have to send a square wave to initialize.... thats what we needed.

Later that day - I spent a couple hours finishing off the Web interface, should be good to go. I think we are going to abandon the software to update when users are on-line, maybe in the next version :)

4/26 - The lab is really starting to fill up, hope we can keep our computer and boards... :( On the other hand, we have our remote setup running off a 9 volt battery. We tried for a programmer but it just didn't work, no time for that now :(

4/27 - Another long day in the lab. We are mainly working on software at this point, hope we can finish something that looks decent. We seem to be having signal reliability issues now, could be an effect of other groups trying to work on our transmit frequency... We're working on some ACK features to try to fix it in SW.

4/28 - Yes, Saturday in the lab, this is what it has come down to. We are really worried about finishing by Wednesday and I think we need to shed features galore, KISS...

4/29 - Sunday in the lab too?!? Yes, I know. Our deadline is looming and we are having problems. It seems we deleted a few lines of code that were useful and now we are trying to get back. Let this be a lesson to you, always save and always back up working copies }:|

4/30 - I heard it was a nice day outside today... Our demo deadline is rapidly approaching and we are still having some bad reliability issues. We have set the watchdog timer now so that at least when the remote dies it will reset itself, doesn't just go off blinking and beeping. We have also started sending redundant message packets to attempt to improve relaibility and reduce the losses of we have been seeing.

5/01 - We made a number of breakthroughs today... To improve reliability and stability we have started a routine that turns off the remote receive if a carrier is not detected, seems to work well, we call this state sleeping. Problem: CD isn't enabled if the xceiver isn't in receive mode... Solution: pulse into receive every so often and poll the Carrier Detect, smart. Another smart thing I picked up on that improved reliability ~100%- the recievers are noisy when the transmitter isn't sending so you have to be very sure that all storage buffers are not allowed to climb no matter what or you will overwrite memory when you get noise :)

5/02 - It is very, very early. We have been up very late getting all this documentation sorted out. I wish I had found a good circuit schematic editor but I didn't find one that I liked so I did the schematics by hand, ouch.

Later that same day - We are done! We demoed to Prof. Land. We had spent the whole day tweakig and finishing up. When we came in to demo in the evening we where having a lot of trouble with the remote missing certain packages. We played with the timing in Java and it got better but it was never 100% as it had been in the morning. Could be noise in the lab, could be cosmic, who knows... In general it worked fairly well and we had fun so I would call it a success. -PM