Demo Presentation

Final demo presentation: Tuesday, 4/24/2018

View Demo Presentation


How much time do you spend in the kitchen each day to prepare meals? 30 minutes? 60 minutes? 0 minutes? How would that change if kitchen products were smarter and more efficient? Allen and I have a passion for cooking and we understand the value gained from more automated products integrated into our kitchen. Therefore, we came up with the idea to prototype our own smart kitchen exhaust fan.

What it does

Our board integrates the temperature and humidity sensor (HDC1080) and uses them to gather information about the surrounding environment. This gathered information is then used to determine whether there's activity on the stove top and used to adjust the appropriate speed setting for the motor (fan) to ventilate the area. Additional features (ie. user CLI interface, Node-RED dashboard) allow users to control the fan operations from remote settings through a GUI or a command prompt/terminal session.

How we built it

From the beginning of the process, we went through and developed a power budget which allowed us to get a sense of how much power our device will require and how long it will last from a battery (3.7V, 2500mAh, single-cell Li-Po). After clearing the power budget stage, we began the development proecess for our CLI and testing each IC we planned to use with development boards and the Microchip SAM W25. The SAM W25 was used throughout this development cycle as a testing platform because it contains all the necessary components for us to develop our device with. These include the SAMD21g18A (ARM Cortex M0+) microprocessor, ATWINC1500 for enabling Wi-Fi capabilities and interaction with the cloud, and finally the ATECC108 as the hardware crypto chip to help encrypt and authenticate data for the over-the-air firmware updates (OTAFU).

After this had been laid out, we then begun to draft up the schematics for each module that we planned to incorporate into our PCBA design. The schematic capture was done using Altium Designer (version?) and included modules such as the device's power circuitry, the sensor/actuator interfaces, and Wi-Fi connections. This was a multi-level design where each module was contained within its own circuit schematic, which is then linked to a top-level schematic. The schematics were used as a road-map for the development of our PCBA layout and routing. Before shipping our finished PCBA to the manufacturer, the generation of output files were processed. Output files included (files).

The steps following the hardware development is to design the bootloader and application to allow for OTAFU. This enables flexibility when programming as well as the capability to do future improvements for our device.

While developing the device's OTAFU capabilities, the physical PCBAs were retrieved from the manufacturer. This involved board bring up and debugging of hardware to make sure the components are working as expected.

Finally, to finish the project, we enabled cloud capabilities and user interaction by developing a online user dashboard for users to monitor real-time sensed data from the device, operating mode of the fan, history of acquired data, as well as manual controls to change fan speeds.

Challenges we ran into

During this project, we had gone through ups and downs through the product development process.

One important takeaway is during the schematic capture process to review, review again, get someone else to review, and review one more time before shipping it out to the manufacturer. A big issue for us is during the board bring up process, we realized we had made some mistakes that required us to do some additional re-routing of our circuit. While figuring out what to re-route was not difficult, in the process of soldering on fine-pitch components, we had created additional issues.

An example of a hardware issue that required us to do wire jumping was during board bring up when we observed very high frequency noise radiating from the board and the power IC chip became extremely hot to the touch. After careful examination of schematics, we realized the schematic library used for our regulator did not match with its footprint, which caused a pin flip on our board. This was mended by cutting through the original routing on our board and soldering on two wires to the correct pins. This can be seen as the black wires from the pictures. The process of soldering these wires on had caused us to lose a board due to short-circuiting nearby components.

Software challenges that we faced had to deal with integration of our different modules. When we developed the modules for each assignment, they were tested and saved as separate projects. When it came time to integrate the different modules, conflicts started to arise. An example is our CLI interface integrating with our MQTT module. Both module functionalities were fine until integration when we found out the "i2c_scan" command in our CLI no longer works. It came to realization that while developing each code, the I2C and MQTT configurations had both been set to SERCOM2. After some debugging and help from fellow classmates, this was resolved by changing the SERCOM configuration of our I2C to SERCOM0.

What we learned

Full product development process. Building/modifying design based on requirements and tradeoffs (power budget, monetary budget, etc.) Altium Designer as an ECAD tool to allow schematic capture, layout and prototyping for a 4-layer PCBA design. Hardware debugging through the board bring-up process. Software debugging through the entire process. MQTT protocol and interfacing device with Node-RED for additional capabilities.

What's next for Michelin Stars: Smart Kitchen Product

We initially set out to design a kitchen product that is smart and creates unrecognized efficiencies in the kitchen. We would love to continue developing this product to incorporate additional functionalities and features that will allow it to also create a safer kitchen environment.

An idea that was discussed was to include a smoke sensor that would enable a third degree of sensing and validation for us to determine whether there might be an unsafe operating condition. During these conditions, the twilio service can be used to alert users that there could potentially be an issue.

Built With

  • altium-designer
  • atmel-studio
  • c
  • bluemix
  • node-red
  • samd21g18a
Share this project: