Lab 2

The questions below are due on Tuesday February 17, 2026; 06:00:00 PM.
 
You are not logged in.

Please Log In for full access to the web site.
Note that this link will take you to an external site (https://shimmer.mit.edu) to authenticate, and then you will be redirected back to this page.

Objectives

We're going to undertake several activities this week in lab, which will actually start in lecture. It's gonna by fun and busy!

  • Team logistcs: team name, set up google drive, team communications, etc.
  • Start brainstorming, and get going on some of the subsystems
  • First meeting with mentor

Activities in Tue Lecture

Google account username

We'll store various documents in a Google Drive team folder. To share those documents with you, we need your preferred Google Docs account username. Enter that now.

Enter your preferred Google Docs username.

Introductions [5 min]

  • Go around and introduce yourselves.
  • For each intro mention your interests (sensors, power, FW, server/front-end, industrial design)
  • Feel free to describe not just what you know, but what you want to learn

Requirements [5 min]

  • Read thru the requirements for your project, which are linked from the course project page. Make sure you understand what each one means!

Activities for rest of week

On-boarding

To-do: Work through our On-boarding guide this first week.

This week's plan

At this week's mentor meeting, we'll spend some time going over the project requirements and brainstorming about different concepts. Then we will go thru the milestones and deliverable for the coming week to make sure everyone is in agreement about the plan.

Starting next week (yup, next week) we'll be evaluating team progress via the milestones and deliverables table.

To-do: Once you have Google Drive team folder access, navigate to your milestones and deliverables table and fill in the subteam members and in-charge person now for each milestone.

Here we provide some details about the milestones and deliverables for next week. You can adjust these in consultation with your mentor.

Concepts

You'll want to spend time with your team talking through the requirements and making sure they make sense to you. If you have questions, check the project page, any FAQs on that page, ask staff, and we can help you ask questions to our partners.

Every team member should develop an overall concept for the system -- how it might work, how it might look, any implications for the resulting system architecture. An annotated sketch is fine.

Sensors

A good activity for the sensor subsystem team is to research different sensing approaches, and determine which sensing approaches to want to prototype. We have 3 milestones covering those activities. To help in making a table comparing approaches, we've provided here a sample table for a totally different approach. Your table will have different columns, but you get the idea.

We have a variety of sensors already on-hand, so if the subsystem team determines that they want to prototype a particular sensor or two and we have it, they can get started on that this week. Otherwise, you should at least have specified which sensors (down to the part numbers) you want to order to start testing.

Power management

It's good to start to get a sense of battery capacity, lifetime, and how that stacks up in real life.

The power management team should set up two systems from lab01 and have them post their battery voltage to an endpoint every 15 sec for 24 h. You'll want to use a system with a battery voltage of at least 3.3V to start.

So that you don't have to have your ssh tunnel active for many hours, we set up an endpoint on the class server. You can basically re-use the post endpoint from before like the following:

http://efpi-10.mit.edu/efi_test/lux_logger

with x-www-form-urlencoded data have the following key/values:

  • kerberos: a unique identifier (maybe separate from your actual kerberos and/or related to your team) so your data doesn't get mixed in with stuff you already posted.
  • lux: The lux (could be a dummy value for this undertaking)
  • bat: The battery voltage with at least three significant figures...no integer of voltage in volts or something.

And then retrieve from this (using a consistent kerberos/id):

http://efpi-10.mit.edu/efi_test/lux_reporter?kerberos=None

Then, you'll want to estimate the starting and ending battery capacity to estimate how much energy you used. Then compare that you what we'd expect given the battery and power usage of the ESP32 when connected to WiFi and when transmitting. There is a discharge curve for the cell used in our battery here.

Firmware

Fault reporting is going to be very important for debugging, especially once you are no longer connected to your computer's serial monitor. Develop and implement a scheme to communicate status information using an external LED or LEDs (single color, RGB, your choice).

Your system should report when everything is ok, and also report at least two faults (or their lack), such as:

  • Error collecting sensor data
  • Error connecting to WiFi
  • Error posting data

Basically, we want to be able to look at the indicator LED and know within 30 seconds or so that the system is working correctly, or that the system is not working correctly and which parts are not working.

Backend/frontend/server

Here we envision two tasks:

  • Get a team server up and running w/ fastapi/sqlite so the rest of your team can start posting

  • Develop an initial wireframe model of the front end. Some people like Figma but use whatever you want. This will be your initial front-end specification. To get inspriration, find dashboards on the internet. There are some very good ones out there. You can also go to last years' websites, and see what you like and what you don't.

Industrial design

  • Determine an initial set of specifications for your enclosure: size, weight, ingress protection, access for maintenance, etc.

  • Find 3 examples of related enclosures that you can use for inspiration, and make a table noting the pros/cons of those approaches.

  • Develop initial drawings of the enclosure and how it might interact (or not) with the community.

Communications

  • Develop an initial communications strategy, making a table comparing the different possible approaches and their pros and cons

  • From that table, decide which approaches to prototype and what parts you'll need to do that. Like for sensors, we have cell, LoRa modules around, and of course your ESP32C3 has WiFi.