Valerie Project Beta

The beta is our final demo of the class. We are looking for complete, professional-looking systems that we can all be proud of.

The beta presentations will be in class on Tue May 16, where each team will have 10 min plus 5 min Q&A.

For the beta, your system should be complete, in that it meets the specifications you have laid out, which in turn should meet the Valerie project requirements.

Needless to say, this means we expect a battery-powered system with a solar cell charger [req 3], sensors, all in an enclosure that can be easily mounted on a bus stop pole [req 4]. We will want evidence that the system can accurately assess the number of people waiting at a stop and how long they have been there, and the system should report the "heat experience" while they are waiting [reqs 1, 2].

The system should have an intuitive front-end that we can access [req 10].

Think about the data you are sending and work to preserve privacy [req 7].

Your cost (electronics BOM) should be based on your spec [reg 5].

And you should demonstrate how the data displayed on the front-end can be tied to a location [req 6].

We won't make you demonstrate that your system can withstand shipping [req 8], though it is encouraged to do a drop test (or similar). We also encourage you to do an ingress (water/dust) test, with a hose, sprayer, dust source.

Finally, make sure the architecture of your system is amenable to having multiple nodes [req 9], though we will not make you fabricate and test multiple nodes.

Part 1

One central element to demonstrate is the system operating. We will want a video montage showing the system working at an actual bus stop (Tech shuttle, MBTA, etc.). The video should be split-screen or picture-in-picture demonstrating that people are arriving and departing the stop, and that your front-end is accurately displaying the occpancy information and environmental information ("heat experience"). The video needs to be a montage because your system needs to be installed long enough to see multiple sets of people arriving/departing.

Part 2

A second part of the video should be a demonstration of your team installing the system on a pole. This does not have to be a Cambridge bus stop pole: we will provide a pole similar to the ones used in Miami-Dade for this test.

Part 3

To demonstrate the accuracy of your environmental "heat experience" data, we will want a separate video (could be split screen or not) showing the raw environmental data (temperature and RH, and, for those who use it, rain, VOC/NOx, etc.) alongisde either a reference temperature/RH probe (we will provide one), or alongisde the current temperature/RH from a weather website.

Part 4

To demonstrate physical robustness (req 8), you may decide to conduct a drop test (1 ft, 1 m, you decide) and ingress test (water from a hose or shower, dust blown into your device with a fan, etc). You'll want to document this on video. This is optional.

To demonstrate that your sytem consumes less power than you can generate from your solar cells, your team should provide:

• measurements of the power consumption of your HW system in its different states
• a detailed power budget calculation that uses those measurements (not data sheet values!) to estimate your overall average power consumption across your different operating modes
• measurements of the power provided by your solar panel. This is the power after any conditioning circuitry, i.e., the power delivered to charge the battery (not the power coming directly out of the solar panel). This measurmement can occur outside, on a nice sunny day. Record your measurement parameters and then use reasonable assumptions to extraoplate to what you'd observe during the daytime in Miami.

We will want the following documents:

• final specifications document (including the FW, server diagrams), with a listing of both the desired specs and your final achieved specifications. So, for example, your size specification might be (20 x 20 x 10 cm LxWxH) and your final achieved size might be (15 x 12 x 6 cm LxWxH0) and you would list both
• your specifications document should note how the specifications collectively meet the requirements. So, for example, the FW & server diagrams might indicate how data can be privacy preserving (req 7) and tied to location (req 6), and how multiple nodes can be used (req 9).
• final complete electronics BOM
• final industrial design drawings
• final system diagram
• final data budget, including overhead from packet headers
• team reflections survey -- each team member will need to fill this out

You can't possibly present all this information in 10 minutes on May 16. So focus on the following:

• the main idea behind your sensing approach and why you chose it
• system diagram
• videos of installation, operation, drop/ingress test (if you have it)
• power management approach and results
• total electronics BOM cost

Below we have a suggested timeline to avoid last-minute scrambling for the beta. You are not obligated to follow this timeline, but you are well-advised to do so.

As for the alpha, we will ask you to create a set of milestones each Tuesday for us to check each Friday in lab.

Fri April 28 If you want a PCB made, you should have a layout ready by now, including incorporating staff design reviews of the schematic and layout. We will aim for 24-h turn on the reviews. It takes ~ 4 days to get the PCBs back. This schedule gives you time for two rounds of design/fab/test.

You should be printing your first enclosure by now. This gives you time to test it out and print another iteration.

Your system should be operating on battery power, to make it easier to perform field testing.

You should be field testing the prototype. We suggest setting up your system at Briggs field or some other open area, and then walking up

Fri May 5 You should have your system charging from the solar cell, sleep cycle implemented, and so on, so that you are meeting power/lifetime specs.

You should have be reliably sending occupancy and heat experience information to your server via cellular (which every team has chosen to use).

You should be field testing at a real bus stop now, tweaking parameters to get acceptable accuracy.

Note the final day to submit PCBs for fabrication is Mon May 8. The final day to print enclosures is up to you and EDS staff, so please check with them.

Fri May 12 Your system should be fully tested and working by this day, meeting specs and requirements. You want to spend the time between May 12 and May 16 working on your presentation, videos, documents -- not debugging your system.