Team Status Report for 4/30

This week Ryan and Jake focused on performing a further examination of the the power consumption of each component of our hardware. Using an ammeter we found the thermal sensor, PIR and esp8266’s current draw under reading and wifi uploading, as well as under DeepSleep and light sleep. We also attempted to monitor current draw through a typical detection and upload cycle by using the oscilloscope to grab voltage off of a resistor leading into the entire circuit however this effort was unsuccessful as we tried using a tiny resistor so we could use our original power supply while still allowing every component to be in its operating window. The data we got on the oscope was far too noisy to draw any conclusions from.

For our verification and testing of the front end for capacity ( i.e how many people are website could support) we utilized an industry testing platform called Load View which is a cloud based load tester that essentially creates a simulation of however many concurrent users you want and creates load stress for your website. This is a common industry testing  method taught in Jeff Epinger’s web app class called “Web Page Load Testing.” Within our application, the EC2’s point of stress is in responding to the XML requests sent out by users browsers asking for the latest data on table occupancy.  What Load View provides  for us is the ability to easily create a set of browsers concurrently that all have our website open and are all sending these XML requests. As our original use-case requirement was that we wanted to support 25 users we ran a stepped load where we gradually built up to 25 websites open in browser to see how load times would react. Our apache2 instance of our Django server running on an EC2 performed well we had 100% success on each test and load times even under max capacity remained under 2 seconds which is satisfactory for our user experience.

From a hardware perspective, we have a serious risk to our design which might not be resolvable this semester with our failing battery power tests (for more details on this, refer to Ryan’s Status Report for 4/30). There are two easy ways to mitigate this risk by decreasing the power consumption enough for the system to stay powered for 107 hours. The first way is to order additional hardware which will turn off the power to the thermal sensor while it is in deep sleep (which we cannot control from the processor).  In order to last for 107 hours, our system has to consume at most 11.2mA per hour, and it is currently consuming 14.76mA in its most optimized state. However, the thermal sensor is responsible for 5mA of that consumption, so turning it off when the processor goes into deep sleep will reduce that number to around 9.8mA which is well under that mark. The second way would be to order a battery with an increased capacity. Our system currently consumes about 7.8Ah of energy, so any battery larger than that would be sufficient. While both of these options are very feasible, we would not be able to make these adjustments by the end of the semester. Fortunately, though, we won’t need to last nearly as long for our demo, and should have no problems with staying powered for the whole time. From a hardware perspective, all that’s left to do is to fine-tune occupancy detection algorithm thresholds for Weigand Gym and potentially figure out a more elegant way to mount the sensors than with tape, and we should be ready!

For frontend, we should be mostly ready to go for the web app, and we plan to migrate that to a mobile friendly version as well. The planned statistics are implemented and we also plan to do user testing in the UC before the demo to make sure that the integration between hardware and software is seamless enough to not interrupt user experience.

Ryan’s Status Report for 4/30

This week, I worked on two things. First, I helped finalize the final presentation and watched other groups’ presentations (which were all great)! Second, and more importantly, I did a lot of power testing for the system. Specifically, I tested the power draw of both sensors, as well as the power draw of the system with different code/states running (including no optimizations, delay statements between loops, and deep sleep). Unfortunately, I ran into a big issue in that the processor was consuming far more power than specified by the datasheet. While the datasheet rated the processor in deep sleep consuming only 10uA of current, the measured system current consumption in deep sleep was consistently 14.6mA, a factor of 1000x higher than expected. This included the PIR sensor consuming around 50uA of current (regardless of state) and the thermal sensor consuming around 5mA of current (regardless of state), so the processor is still consuming much more than we had accounted for. With all this being said, our battery should only last about 82/107 hours required by our use case. This creates a clear risk to our design meeting our use case which I will outline more in the team status report.

Next week, I plan on completing a couple of battery tests to confirm that the battery will not last its full duration. In addition, I will finish out the semester by finalizing our poster, doing some fine-tuning on thresholds of the occupancy algorithm for Weigand Gym, and turning in the final report. I am more or less on schedule — I am adding in some confirmation battery tests to tie a bow on the power testing which would have been nice to have done by now, but I shouldn’t have a problem getting those in for the final report.

Team Status Report for 4/23

From a hardware perspective, we were fortunately able to avoid any design changes, as we were able to integrate the thermal sensor into the design both hardware- and software-wise after many tribulations. We began battery tests and will have results for those tests on Sunday before the final presentation is due. Additionally, we will complete power unit testing with different sections of code on Sunday before the final presentation, and we hope to get a much clearer picture of how closely our design is matching our use case. One big risk is either power or battery testing failing, both of which would indicate that our system consumes more power than expected and we won’t be able to meet our battery life use case. However, should that be the case, we have a couple of risk mitigation plans that we hope will solve the problem. We still haven’t introduced specific optimizations to the code which should significantly reduce power draw, including better use of deep sleep and potentially using a light sleep in the few seconds between the processor taking readings from each sensor. Additionally, we should be able to reduce the amount of readings required to determine an occupancy change without any major sacrifices in accuracy, which would allow us to take less readings per minute and further reduce power draw, while still meeting our use case of accurately updating occupancy status within a minute of it changing.

Ryan’s Status Report for 4/23

I made a bunch of progress this week. Most of my work was put into integrating the thermal sensor into the final design, which ended up being much more painful than anticipated. The one thermal sensor we had was broken and I unfortunately didn’t have any good way of verifying that the sensor worked until the rest of them arrived on Wednesday, so I spent a lot of time early in the week writing and running different segments of code in an attempt to debug things. Fortunately, after getting new thermal sensors, I was able to get the system running on an Arduino Uno pretty quickly, and then after a bit more work I was able to transfer everything over to the ESP system, which is now running a functional occupancy detecting algorithm using both sensors! The final hardware design can be seen below (although the design will be on a smaller breadboard for the final demo).

As a very important note to future teams looking to do something similar, we made the design decision early on to use an ESP8266 dev board with both a processor and a wi-fi chip built in as opposed to using an Arduino with an external wi-fi chip to reduce the amount of hardware, since the ESP can still compile Arduino code. Although this was a good idea in theory, it made things much harder for both myself and Jake, as the Arduino is much more user-friendly than the ESP for software development and has much more existing uses and documentation to learn from. If we were to restart this, we would definitely develop things on an Arduino instead.

After finishing all that up, I then assembled the rest of the hardware nodes to work with Jake to kick off battery testing. While we shouldn’t have definitive results until tomorrow (fingers crossed, because it means the batteries will have lasted at least a day), those results will be in on time for the final presentation. I am also planning on working with Jake tomorrow on unit power testing to further verify that our system is within our power consumption use case requirement. We will be measuring power draw out of different components while running different sections and libraries of code in a further attempt to optimize power, and preliminary results for those should also be done by the final presentation. If all ends well, I will spend the rest of next week hearing other presentations and preparing for our demo. If not, which is probably the more likely scenario, I have a risk mitigation plan which I will detail in the team status report. Currently I am pretty well on schedule to finish everything out, and I am hopeful that will stay the same for the rest of the semester!

Ryan’s Status Report for 4/16

This week, I spent my time in two areas. First, I put together a bill of materials and ordered components for three more hardware nodes for the final demo, as well as for fuller system testing. Fortunately, most of the parts (all of them but the thermal sensor) came in the day after I ordered them, so I was able to assemble the rest of the hardware nodes, including soldering male-to-male headers on the battery converter boards and level shifter boards. The thermal sensor is pretty trivial to wire up, so I’m not worried about having to integrate those in a timely fashion.

The other thing I worked on was integrating the thermal sensor into the hardware design. I first went through hardware specs to figure out how it wires up, and realized that the pull-up resistors built into our level shifter board were sufficient enough in creating a voltage difference between the data and clock lines for the thermal sensor I2C and no additional resistors were needed. Most recently, I have spent time writing code to actually turn on and obtain readings from the thermal sensor. I am currently working on that now, and expect to have that up and running by class on Monday, which is within my planned schedule.

Next week, I plan on finishing up the thermal sensor integration, hopefully assembling the rest of the hardware nodes once the thermal sensors get in, and then I will run battery and power consumption tests to make sure our hardware is in spec with our use case requirements. If this is not the case, the risk mitigation plan is to increase the power efficiency of the code, either by using lower power libraries/using resting states more effectively or by limiting the uptime of the PIR sensor, which according to my calculations (and pending unit testing) should be the heaviest power consumer of any individual component.

Ryan’s Status Report for 4/10

These past two weeks, since I missed a weekly update last week, a lot of work was done. I first identified that our thermal sensor, which had been ordered earlier this semester, can only communicate between I2C and has a specific header that needs purchasing, as well as a logic level converter. I talked to Tamal and made a contingency plan of ordering a breakout cable and level converter needed, with the understanding that the thermal sensor will not be a part of our interim demo.

I then soldered male header rows onto both of the regulator boards and built the hardware for the interim demo. A completed picture of the hardware can be seen below!

The battery runs into a 3.7V to 5V boosting regulator (which doubles as a charging board). That 5V powers both the ESP8266 dev board (which powers the processor and wi-fi module) and the PIR sensor. During the demo, the PIR sensor was taped to the bottom of a table, however the idea is to eventually mount the entire system under a table so it is out of the user’s way. After further testing, I determined that we did not need the 5V to 3.3V buck regulator, since the dev board steps down voltage levels internally.

Finally, we completed our interim demo! I think that it went well overall, and we were able to take a reading from the PIR sensor and send it all the way to a mocked up version of the web app. My major next steps involve integrating the thermal sensor into the rest of the design both hardware- and software-wise, now that the parts have come in, and finally doing some battery testing and work on power saving to round out the end of the semester, and I am currently on schedule to finish that out.

Ryan’s Status Report for 3/26

This week, I mostly focused on the ethics side of the project. This involved participating in a very interesting discussion between many groups about the ethics in both our projects and others, and we got some very interesting feedback that I considered and thought of solutions for. Specifically, two main points of concern were addressed:

  1. Anybody can access the data through the web app, and this data can be used for many purposes besides finding a free seat in the UC. To address this, we are going to restrict web app access to those with Andrew logins. While this may restrict access to a minority of the use case members, as some Chartwells employees use the tables as well and the UC is technically open to all people on the weekdays, we believe that this is a necessary step to secure the safety of the data of the remaining users.
  2. If this system is set up in the UC, people do not have the option of not having their occupancy tracked or opting out. Although this is definitely of concern, there are cameras in the UC that can be used to track someone’s location. More importantly, though, we would intentionally spread flyers notifying people of the way the hardware works and that no personally-identifiable data is being gathered as we advertise the app. We believe that the vast majority of the users, once informed, would not have concerns with the system; conversely, there is no easy solution to implement for the edge case of users that still do have concerns.

Unfortunately, since the rest of the hardware arrived very late in the week and due to some personal issues, I was not able to put forth much work on the project design this week, which has pushed me a bit back on schedule. Since I have a lighter schedule this upcoming week, I am hoping to be able to make up for the lost time. This week, I plan to assemble all of the hardware together, and I intend to at least get started on writing code to initialize all systems and get the sensors talking to the processor, in preparation for the interim demo coming up.

Ryan’s Status Report for 3/19

This week, I finalized ordering the rest of the hardware for the project, including picking switching regulators to supply 5V and 3.3V from our 3.7V battery, and figuring out a charging solution for the battery as well. With this, the hardware should all be ordered and in house next week, and once the last of these components arrive, I am excited to put everything together! In addition, I worked on the ethics assignment and thought about various aspects of the ethicality of our project, and started to look at some of the existing hardware code Jake has written to familiarize myself with it.

Next week, I will be looking forward to some interesting ethics discussions, and am hoping that the rest of the parts will be in so I can assemble everything! Although I am slightly behind schedule, as I would have liked to be writing some code to initialize the sensors by now, I am not worried about getting this done by the interim demo, and hope to have everything up and running by then.

Ryan’s Status Report for 2/26

This week was spent mostly on design review. To start off the week, I helped put together the slides for our design review presentation, and then practiced the slides and eventually gave the presentation in class. I also got to listen to a bunch of awesome design reviews from other teams! I then reached out to some previous capstone students about using a similar battery to ours before placing the order for two batteries, one which we will test with and another (smaller) one for our demo. Finally, I got started on our design report which is due at the end of next week.

I am about on schedule, pending the status of our parts being delivered, as I initially planned on having a full design completed and all parts ordered and in hand by Spring Break. The only hardware that has yet to be ordered is a voltage converter stepping up to 5V and stepping down to 3.3V, however I don’t anticipate choosing one to take that long.

Next week, in addition to getting a voltage converter ordered, I will be spending most of my time writing up the design review report, including incorporating any feedback from the presentation which we may receive next week. After a nice break and when everything has arrived, I’m excited to start wiring everything together and playing with the sensors!

 

Ryan’s Status Report for 2/19

This week, I was able to catch up on some work I was behind on. I was able to create a BOM of all the hardware we are going to need to purchase for the project so far, including doing power consumption analysis of all the hardware to determine the approximate specs of a battery that we would need. It turns out that we are either going to need a pretty big battery or (more likely) we are going to need to be smart about how long we leave our sensors powered to detect occupancy! Finally, I helped work on the design presentation that we will be giving at the beginning of next week.

I am a bit behind from where I’d like to be in that ideally all parts on the hardware BOM would have been ordered by the end of the week, and I’m still waiting on approval from a couple people before I go ahead and place the order. But once that comes through, placing the order shouldn’t take much effort, so I’m not worried about this being a long-term setback.

Next week, I plan to finalize a battery to purchase and place an order for the rest of the hardware. While I wait for parts to arrive, I will work on writing up the design review report and incorporating any feedback that we get from the presentation. Finally, I will help finish up the rest of our design proposal slides, and am looking forward to seeing the presentations of other groups!