Originally located: http://course.ece.cmu.edu/~ece500/projects/s23-teamb6/weekly-status-reports/nish-weekly-status-report-for-february-11th/
In the past week, we worked mainly on our proposal presentation. I worked on our “Thievery Flow” as well as flushing out the different components in our solution to try and make it more cohesive. I identified specific versions of products we could use, such as the STM32 + RAK4600 Bluetooth that would complement each other, and researched the other components we were considering working with. We worked as a team to edit all the slides together.
I think we are a little behind on our design. Though we tried to edit our use case requirements, I think we still have written our requirements based on our selected implementation, leading to aspects of our design that may seem unnecessary, such as having Bluetooth. To make sure our design review goes smoothly, I would like to go back and refine our requirements, or perhaps pick another use case where we can implement a similar type of sensing mechanism as people are walking through a certain space, allowing for identification of who is passing through. I think we have been trying to overcomplicate a simple solution with a lot of “nice-to-haves” without having a solid foundation.;
We plan to have a meeting to focus on our project, whether that be through a different use case or refining our current one and redoing the requirements. I plan to bring a few ideas for different use cases to this meeting.
Next week, I want to have a complete parts list and have ordered the different components we need. We might need some more time on the PCB side because once we decide on the components, we still need to put the actual PCB together. I want us as a team to revisit each component we were thinking about and make sure having it serves a requirement in our use case rather than something that would be making our project more complex for the sake of it. Once we have our components ready, we can also set up our repo with the starter code (especially for something like the STM32, if we choose to continue using it).