Jazzman's Blog

Schmoocon has arrived! We just completed our presentation. But first, we must discuss all the excitement from the beginning of the week. Starting monday night, Mike Natrin and I worked as hard as we could to get the ATD conversion to work properly within the RTI service routine. Late in the night, we finally were successful. The problem was the speed settings for the ATD conversion conflicted with the PWM timer settings. Once we worked out this problem, we had a platform that could read each of the different sensors and work properly:

- PIR
- Trip
- Audio

Unfortunately, after transferring his breadboard design to a finalized prototype, honcho's output changed drastically. So much so, that we had to drop that component for the Schmoocon demonstration. This eased up the work on the microcontroller due to the fact that the ATD continuous conversions no longer needed to be made. We also were having trouble with implementing the low-power mode without the system crashing. Since we just needed to program something onto teknick's board that would work and run the PIR and tripwire functions we left out the low-power capabilities. The platform is there, we just need to do a little more debugging. Hopefully, we will fix this problem if we can continue this project at a later time.

So, after spending an all-nighter before leaving for Washington, DC we made some significant progress in the project. We attached all the parts to the inside of a playstation module. This included an attached PIR, TRIP1, Micrcontroller, FON, and Port attachments for TRIP2 and TRIP3. I am sure a picture will be uploaded soon. This was what we needed for the presentation. Unfortunately, we were not able to actually test the project, but this will be completed on another day.

What an excellent experience Schmoocon has been! There were many great talks on cutting edge technology, really cool paraphernalia, and tight bonding experiences. Our presentation overall went well! We were a little unorganized in the presentation, but this was due to the fact that we literally completed the slide show an hour before we presented. I talked to a few interested security system managers afterwards, and they will definitely be keeping up with this website. Apparently, system platforms like ours are in need in heavily dangerous areas. I felt more prepared for this speech than the Motorola one, but that is because the team was together on this one! Again, I have really enjoyed myself here at Schmoocon, and I plan to continue to enjoy the rest of my stay here!

Thank you!

Continuing from last week, I have been concentrating my efforts in interfacing between the microcontroller and the router. Instead of using my dummy data, we now have managed to send actual data from rob3ar and cuddles work. First, I added cuddles' code to my “serialTest” code. This process ran much smoother than expected. We pretty much just added an RTI service routine and a counter() function that worked with the PWM settings. cuddles has written code that, from my level abstraction, will have changing values for the number of people entering and exiting the area. I was able to take the outputted data (IN and OUT counting variables from cuddles' code), add a ID tag made up of six bits, and send it out via serial port to the router. One problem I am currently troubleshooting is why the OUT variable is constantly 0. I am hoping it is a small glitch in cuddles' code.

Exciting news was that my interfacing work with afterburn has been successful. Whenever a trigger occurs from rob3ar's tripwires, the 'tripwire data' (consisting of the IN and OUT counts) is sent to the router. From the router end, you can send a character (from my look-up command table), and its corresponding data will be returned by the microcontroller. This is the flexibility we want. I will continue to test that the correct data is being transmitted and received. Also, teknick has informed me this week that he has changed the initial clock setting on his microcontroller so that we can have a serial COM rate of 115 kbaud - our ultimate goal! I will implement that as soon as I check his settings.

Lastly, “The Circuit Breakers” met up with Motorola just yesterday (Thursday). Motorola has built a very powerful platform for security systems across the nation. I was fascinated by all its capabilities and just being there in conference room filled with professional engineers. I will never forget the experience. afterburn gave a wonderful presentation on “The Circuit Breakers”, explaining its overall intent and progress. When I went to speak, I did feel quite nervous. The reason was simple: I was not prepared. It was obvious that my personal presentation was the weakest part of the group's overall presentation, but that really made me understand something. I need to have thorough understanding of not just my individual tasks in this project; I need to know how my tasks relate to the big scheme of the project. Because I was lacking in this knowledge, I fumbled. But fear not, for I will make sure I have complete understanding of my role and position before my feet step in Washington. One more week to go. It's game time!

¹⁾ This week I finalized the Tx/Rx communication. We can fully transmit and receive data (one byte at a time) between the router and microcontroller. hal0 and I have worked to put any given data( e.g. trip wire, danger level, mic …) into a compatible format for both our serial communications and the data interpretation on the router end. Basically, hal0 created a struct 'SensorWord' which puts six bits of ID and leaves 10 bits for data. More information can be found at hal0's blog.

I started out this week thinking I was going to be using a sentinel loop with a buffer for interpreting commands from the router. However, I found this will not be needed because we will only need to send one byte at a time for the router commands. Therefore, I am simply using SWITCH cases for our design. For a given input (the command table can be found at the router⇔microcontroller link in the 'projects' section), a flag will be set which then calls a corresponding function. As of now, I only have dummy functions that transmit arbitrary constants. These will eventually be replaced by the actual functions each sensor team rights. The point is that we are ready to communicate data between systems, which is crucial for the rest of the development of the project.

For next week, I will be working with honcho to write the ATD conversion code. First, I will make sure digital values are properly generated from the given analog input. Then, I will start writing the 'brain' code for a given input. I will primarily be using pulses from the waveform generator to simulate analog input of screams and hollers. And now, I just found out that the project must be working by 9:00am Thursday. Let's get it done!

¹⁾ This past week, I have tried my best to interface the microcontroller with the router. Although it started out slow, our accuracy of transmitting and receiving data has increased quite rapidly. Steve has a large part to do with this. He figured out that we needed to use 9600 buads per second, as opposed to our original rate of 104,000 buads per second when talking between the microcontroller and router. He also noted some of the completion flags (i.e. a received-byte flag) necessary to have only one character being sent at a time. Before, we were sending (unintentionally) seven of the same byte at a time.

I just recently updated the code for receiving data. Originally we were going to use a circular buffer to be able to deal with strings. However, since this would require changing much of Nick's code, I decided to try a different method. Instead, we will use a sentinel. I chose the semi-colon character (;) to be the sentinel. In this case, the receive interrupt will store the inputed data into an rx-buffer array until the inputed data is (;). When a semi-colon is present, the rx-buffer array will transfer its data to a new array, where the contiguous characters can be interpreted and be used to execute a particular instruction. We just need to make sure that after every command is entered from the router a semi-colon is included. One possible issue with this technique is that the data will be sent using an extra byte for each command. I hope and think that this will not be too big of an issue.

After two weeks of work, I feel that we can be successful if we all stay calm and listen to each other without our individual nerves getting in the way. I am here to do this… so lets do this!

My task for week one centered building the interface between the input feed (microphones and infrared sensors) and the router. I have been working with Mike Natrin, and so far we have made most of our progress in setting up the output of the microcontroller (using a serial port) to (eventually) the router. I say “eventually” because we have only been testing the output of the microcontroller by connecting it to a computer and seeing if the correct characters were transmitted to a terminal screen while running; we have not connected to the router yet, but that is our future goal. I shared my code with Larry today, and we were able to take an analog input, convert it to digital (using the ATD port), and send it out of the microcontroller through the serial port. This was very exciting for us because we now have the option to take both analog and digital input for the trip wires and/or microphone depending on the type of devices we invest.

Mike Roman has graciously provided the winter research crew with a passive infrared motion sensor. This will act as the most outer level perimeter of the security area because it is both a transmitter and receiver in one and will provide the interrupt for the microcontroller to enter “running mode”. Mike Natrin and I have found and tested the code for the microcontroller that will shift it between “low power mode” (for when no one is in the security area) and normal “running mode” (for when someone enters the area) whenever a digital signal interrupts the KBI port on the microcontroller. When the microcontroller in “running mode”, it will be able to take the trip wire and microphone inputs, but only when it is in this mode.

For next week, I plan to test the connection between the microcontroller and router, making sure that the data is transmitted correctly through the serial port. I also want to be able to have the microcontroller receive data from the router so that the base can have control over the microcontroller's operations. I also hope to finish configuring the trip wire (Rober and Larry's assignment) and microphone inputs.