This week was centered around building a convincing design presentation. With midterms and other commitments, there were challenging aspects to preparing a 10-12 minute talk discussing the primary features of our product, but overall, such an experience went well and was invaluable for our group in sorting out some of the finer details present in our design plan.
Some of the key takeaways from the design presentation include the following:
- How much of the project do we want to implement by ourselves, as opposed to offloading the work to an API call?
- Re-evaluating the need for load cell amplifiers to be placed between the scale reading to the ADC port of our microcontroller
- Proper differentiation between labeled food items, versus standalone produce
- Validation metrics and subsequent justification
- Balancing how much complexity we want to offload to the backend. We are now working on the design report, which requires another level of understanding of our procedures in the development of our product.On my end (hardware), some of the risk mitigation strategies that I have thought about in the context of the microcontrollers include the following:
- Buffer Overflow: This can occur when incoming data from the scale exceeds the capacity of the micro-controller \texttt{receive} buffer, potentially causing data corruption or subsequent instability. To address this issue, our team plans to implement control mechanisms in the controller scripting, following XON/XOFF software flow control protocols.
- Data Loss and Recovery: In the case of failure, the data should be backed up on nonvolatile memory. This is present in each of our options for microcontrollers: Arduino holds the well-established EEPROM as an example of this, and SPIFFS is the equivalent option in the ESP8266 WiFi microchip. These are hardware backups that the database can read from if the system crashes.
- Mismatched Baud Rates: Arduino IDE handles synchronization, but because there is logic in the sampling of the scale values, this needs to be matched properly.
An additional consideration (pictured below) is a conversion from the RS232 serial protocol that the scale communicates data with to TTL logic employed by microcontrollers. This is something I realized in the building process. A converter, pictured and wired in the schematic below, will be necessary.
Progress-wise, we are doing well. We plan to finish the imaging component of the project by Spring break, so this upcoming week will be critical for Steven and me, while Grace is making good progress on the web application.