Tag: status report

This week I finished up researching IoT devices and instead of using the XBee devices from last week’s research, I decided to go with the ESP8266 NodeMCU. They consume less power, are cheaper, and have more documentation on projects similar to ours. I ordered three of these modules with dev boards and I’m excited to get working on wiring this to the sensors that Minu ordered next week. Alongside the NodeMCU decision, I also researched long-term power supplies for these boards and have come across other people’s trade-off research: https://diyi0t.com/best-battery-for-esp8266/. Once we get the boards and set them up with the sensors, we will do some of our own comparisons of power supplies. In class, I worked with Neville to figure out how the ESP8266 dev boards can communicate with our database directly. I also worked on the Design Review slides, making a detailed block diagram and writing up our system specifications. After our meeting with our TA and professor, we were able to make really specific decisions and we are excited to present this week!

Our team prepared and practiced for our proposal presentation. Our design plans did not drastically change, it only became a bit more specific to save cost + accuracy. We decided to use as few ioT devices in the field as possible rather than our initial 1:1 model where an Arduino might be running in each spot. We also decided to use a time-series database as those are custom-made for periodic data. We are looking into the specific types of wireless technologies that would best fit the requirements of our system. We found that ultrasonic sensors are the best type of sensors for this project application, and PIR sensors should be used as an additional “verification” tool. Whether or not the final implementation includes both sensors will be determined after testing our system on the field and the data from cost + accuracy tradeoff. We are looking into using the Digi XBee 3 Zigbee 3 RF Module to communicate from the sensor to the larger database. Once we test how this works, we will be able to start making the physical sensor set up. Our biggest risk currently is being able to detect an available curbside parking spot with accuracy, even in inclement weather. We will continue to research and adjust requirements if needed in the future. Overall, no big changes have been made to the existing system design or schedule this week.

I started this week by working on the proposal presentation slides, as I made the Gantt chart and researched the use case requirements. After Minu presented, I stuck to our schedule for this week and started to compare IoT communication devices. I started with Xbee modules because I saw some in our inventory. The different aspects that were compared were the range, power consumption, size, and price of different RF modules (https://www.digi.com/products-compare/56576/56577/56460). From our use case requirements, I know that we want to keep the price low but also want to make sure we can have a long lasting power supply that will be easily replaceable. Out of the modules that I looked at, I have decided to go with the Digi XBee 3 Zigbee 3 RF Module (https://www.digi.com/products/embedded-systems/digi-xbee/rf-modules/2-4-ghz-rf-modules/xbee3-zigbee-3) because of the low 6.3mW to 79 mW power consumption paired with 2 mile radius and the advanced ZigBee networking protocol. I looked through the inventory but did not find this so I will be putting in an order by the end of the week for at least one so we can start working with them physically. Before ordering, I will communicate with Minu and Neville in order to make sure this device is going to be compatible with the sensor we choose and the networking protocol we want to use. I think I want to spend a couple more days researching other modules, like the NodeMCU protocol ones, so this will take out maybe two days of the schedule. Super excited to get working on the physical module!

The beginning of this week was spent by me practicing and delivering our proposal presentation. As per our gantt chart, I spent the rest of the week researching sensors and a literature review of existing curbside sensor module systems. Specifically, I focused on ultrasonic sensors and tried to find out if it sufficiently provides all the information that we will need. After watching some videos (https://youtu.be/7a1fiUJtp_k) and reading some articles (https://www.avnet.com/wps/portal/abacus/resources/article/pir-and-ultrasonic-sensors-whats-the-difference-and-how-do-they-work/), I concluded that ultrasonic sensors would provide all the required baseline information, and the PIR sensors would help in cases such as detecting human/animal movement in front of our spot modules. Next, I proceeded to think about the technical requirements for weatherproofing our system. When snow is plowed throughout the city, curb side parking is almost never included. This could be one edge case that we might not be able to handle. Next week, I will focus on researching the best way to arrange the sensors on the curb to be able to detect cars with high accuracy.

I spent the very early part of this week completing my section of slides for the proposal presentation. The latter part was spent researching the communication and storage design requirements our system might need. I looked into wireless techniques that were applicable to smart city parking lots and explored their tradeoffs and implementation subtleties. The wireless technologies I explored were Cellular (4G), Zigbee, Wi-Fi and LoraWan  (https://blues.io/blog/network-connectivity/). Wi-Fi was a widely-adopted solution on Arduino boards and had documentation on connectivity to an MQTT broker or upstream database. Cellular and LoraWan (https://www.thethingsnetwork.org/) )had smaller bandwidth but more easily usable outside and consumed lower power. This week I hope to settle on one of these three choices after experimenting with E2E that its protocols are compatible with an Arduino/Raspberry IDE to send data to a subscriber.