Goals

MAQS is our staff-guided HW/SW system. The overarching goal with the MAQS project is to ensure that every student gets to learn some skils that will be useful for the final project and for life.

Schedule

To help keep everything straight, here is the current schedule for the MAQS project.

Overall

MAQS is an indoor air quality monitor. It has some sensors to measure air quality, a MCU to collect that data, communications to send that data, and a server to receive that data and present it to a web front-end. In addition, MAQS has a power board to manage the battery and deliver power to the rest of the system.

Requirements

As we learned in Lecture 3, MAQS is an air quality monitor intended primarily for indoor use. It should measure several aspects of air quality and send that information to a database where it can be retrieved and viewed on a website.

Based on this, the overall requirements of the system are:

1. It should accurately measure indoor air quality **
2. It should be portable ***
3. It should be possible to get the data off the device **
4. It should be a useful pedagogical exercise ***
5. It should maintain privacy *
6. It should be low cost *
7. It should be rugged and robust **
8. Multiple systems should be able to be used simultaneously ***
9. It should be easy to view the current and past data **
10. It should leverage MIT facilities **

where the number of ' * 's denotes the importance of that requirement.

Specifications

From the requirements, we develop specifications. This is an iterative process, in that we can't always determine all specifications prior to going into system design. So there is some iteration between setting specifications → system design and partitioning → research, modeling, and prototyping, and → updating specifications.

That said, for the HW/SW systems of interest in this class, there are classes of specifications that routinely arise:

• Financial
• Regulatory
• Industrial design
• Environmental resistance
• Engineering
• Security & Privacy
• Packaging
• Installation and servicing

For MAQS, here are some specifications:

• Financial
  • BOM <= $20 for electronics components, PCB
  • BOM: TBD for enclosure , mechanical parts
  • Time to market: ~8 weeks
• Regulatory
  • FCC certification for WiFi radio module
• Industrial design
  • Weight: < 300 g [~2 iphones]
  • Size: <10 x 10 x 10 cm [kinda small]
  • Survive 12” drop onto table
  • Enclosure materials: 3DP plastics available in EDS, laser-cut plastics available in EDS
• Environmental
  • Operating temperature: 0 to 70°C [commercial temp range]
  • Humidity: 10 to 95% RH
• Engineering
  • Sensors
    • Particulates, part PMS7003
      • PM2.5 range: <12 to >500 mg/m3
      • PM2.5 accuracy: ?
      • Response time: <=1 min
    • T: 0 to 70 °C, part SHTC3-TR-10KS
      • Accuracy: +/- 0.2 °C
      • Response time: <= 1 min
    • RH: 10 to 95% RH, part SHTC3-TR-10KS
      • Accuracy: +/- 2% RH
      • Response time: <= 1 min
    • Measurement interval: <=10 min
    • Communications: I2C for RH/T, UART for PMS7003
  • Compute
    • MCU: ESP32-C3-WROOM-02
    • Firmware in C/C++ via Arduino libraries as needed
    • Firmware diagram below
  • Comms
    • At least WiFi 802.11a/b/g/n 2.4 GHz
  • Energy management
    • LiPo battery – 18650 w/ JST-PH 2-pin connector
    • Lifetime between charging: >12 h
    • System voltage: 3.3 V
    • Charge from USB-micro connection
    • PMS7003 requires 5V @ 100 mA for fan
  • Server
    • RPi 3 or 4, one for each student
    • SSH access for students and staff
    • OS: Raspian, any recent LTS
    • Web server: NGINX
    • HTTPS GET/POST connections
    • DB: SQLite via SQLAlchemy
      • Store data perpertually
      • Fields: Index number, Timestamp, RH, T, PM
      • No location information transmitted (or stored)
    • Server architecture
      • See architecture below
    • Web front-end
      • Plot.ly
      • See wireframe below
• Security & Privacy
  • Included above
• Packaging
  • Not relevant here
• Installation and servicing
  • Hardcoded SSID to connect to EECS-Lab

System diagram

Here is the current system diagram:

Subsystems

Hardware node

The hardware node for MAQS is going to be a small "box" with three circuit boards, one for sensors, one for the MCU, and one for power management. These three boards physically and electrically interact with each other, and the MCU board communicates with the server via the internet.

Each student in the class will design, fabricate, assemble, and test a sensor board and a power board. We will use the ESP32-C3-DevKitM-1 for the MCU.

Sensor subsystem

The sensor subsystem will be a PCB that contains two sensor chips, one for temperature & humidity, and one for particulate sensing. This board needs to communicate with the MCU subsystem to relay data, and with the power subsystem to get power. The sensors need to interact with the outside world to sample air, while we want the rest of the subsystem to be protected, which will have impact on the electrical and mechanical designs. The detailed design of that subsystem is in EX02 (schematic capture), and EX03.

MCU subsystem

The MCU subsystem will be the ESP32-C3-DevKitM-1 board that we are used to using. The firmware block diagram looks something like:

Power management subsystem

The Power management subsystem will be a PCB that has several roles: it must be able to send power to the rest of the system, where that power comes either from a battery or the USB port (when plugged in). It should also be able to charge the battery when plugged in. Finally, the board needs to output a well-regulated 3.3V power to the rest of the system.

Because 5V is only needed by the PMS7003 particulate sensor, we choose to have a 5V boost converter on the sensor board rather than the power management subsystem.

The detailed design of this subsystem is in EX03 (schematic capture), and EX04 (board layout).

Server

The server must receive data from the MCU over the Internet via HTTPS GET/POST statements. The server will host a database and a web server. The server must also serve up the dashboard.

The web front-end should show historical data and allow download of the raw data as a csv:

Enclosure

The enclosure will be a 3DP part that must contain all the hardware, including the battery, and should provide visual access to the status LEDs. Connections to charge the battery and update the MCU firmware must be made. We'll need to think about how to expose all those connections and the sensors, while protecting the rest of the electronics from the outside world.