Austin Mam:

I learned a lot from this project. There was a lot more I learned about embedded systems including designing one and then actually implementing and debugging it. I learned a lot more about UART and how to utilize various microcontroller features such as RTCC and Power Saving Modes.

The biggest problem I faced was how we would deal with getting data out of the data logger. I thought that it would not be as difficult as it was and that changed the scope of the project for the semester. Additionally, another problem was having to wait for parts which was on us for not ordering them as soon as possible or figuring out what we needed exactly.

Once I figured out that the data logger was going to be an issue we tried to work to get everything around the data retrieval working so that once it was functional ideally everything else should function as well. To combat the time lost waiting for parts I tried to work on as much as I could without the parts. I did more research and made sure once I got the parts that I knew what I could and would do with them.

I learned that it is very important to have a timeline and keep a close eye on it because it can help you stay on track and not waste time. I also learned that I should anticipate things to not go as well as it seems and leave some kind of buffer to accommodate those difficulties.

From this project I think I will take more time when I approach a design in the future and carefully plan out and note any potential areas of concern or difficulty.

Matthew Hyde:

I learned several valuable lessons from the final project, not limited to further technical understandings of embedded systems. While this project strengthened my basic understanding of embedded systems and how they operate, I feel I learned more about working in a project environment. There were several mistakes that we made along the way that we will both be cautious of in the future.

I believe the biggest mistake we made was underestimating the number of tasks we had to complete compared to the amount of time we had left. When the tasks we have left to complete are only 3 bullets long, it is easy to look at them and shrug them off without thinking of the design and debugging time each task will take to be flawlessly integrated into the system.

Another point about time constraints we did not take into account was the time it took for ordered parts to come in. It would have benefited us greatly to have all of our parts planned and ordered at the beginning of the project. More research into our solution early on would have saved us trouble when waiting for parts later on. There were days where there was not much work to do because we had finished one task and were still waiting on parts for the next time.

We were also hindered toward the end of the project by having one of our radio transmitters break when we accidentally supplied too much current to it. Although the system had mostly been designed and integrated already, this cost us a lot of debugging time.

A crucial lesson I learned this project is that there is no such thing as over-preparing. Especially on this project since we were not limited to an $80 budget, it would have helped us if we found all of the necessary parts early on and had everything to work with. It also would have helped us to not underestimate the tasks left to complete. One example is getting data out of the data logger. Although we had a manual for the CR10X data logger instructing us how to get the data out, the process was not as straight forward as we originally had hoped.