You've Got Mail

Are you promptly notified when you receive mail in your mailbox? Here, is an IoT device that will not only notify you, but will also secure the mailbox with a single click! Check it out!

Comment 1

Inspiration

Package theft is an issue that many people face on a daily basis. Mailboxes without a locking mechanism are also uncommon outside of major cities. Fortunately for them, we wanted to create a system that allows the user to receive notifications and provide access to lock/unlock their mailbox remotely. The ultimate goal is to be able to turn an ordinary mailbox into a "safebox" and allow access only to the user and the courier.

What It Does

After mail is deposited into the mailbox, the system detects that the door has been closed and sends a notification to the user. It will then wait a few seconds and proceed to lock the door, ensuring your mail is safe.

Components

MCU

The heart of the device is the SAMW25, which is in part a SAMD21 microcontroller with a WINC1500 Wi-Fi chip built in.

Sensors

The sensors used are the VL53L0X time-of-flight sensor and the VEML7700 ambient light sensor. We wanted to have a dual-sensor based system in order to be able to sense the mailbox door opening in different conditions, as well as for redundancy. For example, during the winter when it gets dark outside much sooner in the day than other parts of the year, the ambient light sensor might not detect a spike in the amount of light that it sees and would not trip the locking mechanism properly. Here, the time-of-flight sensor would take over and detect that the door was moved and it is reading a distance that is much further away. Both of these sensors communicate via I2C and allow for easier integration with the SAMD21's existing peripherals.

Actuator

Our actuator is a SG92R micro-servo motor that is controlled via a PWM signal. The servo toggles between the 0 degree and 90 degree positions depending on what state the device is in and whether the user chose to lock or unlock it.

Challenges

A considerable amount of time was spent to troubleshoot the complex software and hardware problems.

Hardware

For our group, board bring-up turned out to be our biggest challenge. In our PCB schematic, we accidentally connected one of the auxiliary power and grounds on one of our sensors together and it shorted out the power supplies for the rest of the board. We used a multi-meter and an X-acto knife try to isolate the short, but thermal imaging showed that it was under the sensor and would not be trivial to fix. The most important takeaway from this is that during the schematic capture process, always double-check the pinouts of components and even get someone else to review.

Software

Both team members come from hardware backgrounds and writing software proved to be a major challenge for both of us. Not only did we have to try to relearn C, but also the different libraries that ASF uses along the way. Both of us were familiar with the language coming into the class, but neither of us had any real software writing experience prior.

Many hours were spent trying to learn the I2C library and debugging issues with the software entering the dummy handler whenever a read operation was performed. It was found later on that we were trying to read the data from the slave device into a single 8-bit variable, but the function needed a pointer to an array to work properly.

Bootloader

From a clean device, the bootloader sees that there is no application code on the device and loads a very basic v1.0.0 version of the application code into the NVM. Once it finishes updating and jumps to the application, it will download the latest version of the application code (v2.0.1 in our case) and will allow the user to request a firmware update once the device is up. The application will set a flag in the NVM and call for a NVIC reset of the device. Once it enters the bootloader again, it sees that the flag has been set and will proceed to verify the download as valid via CRC. If it finds that the version that was downloaded is the same or older than the current version, it will skip the update and jump to the application.

One feature that we were not able to implement was downloading of multiple files, and thus a metadata file was not able to be downloaded to the SD card to verify the downloaded file's CRC. However, the application allows the user to manually enter the CRC into the console to verify that the two CRCs match. Once it verifies that the two match, it will proceed to copy the new update into the update partition of the NVM.

Again, a CRC is performed in copying the update from the SD card over to the NVM. If the two CRCs match, it then moves the update into the application code sector of the NVM, performing the CRC again. If the CRC fails to match, the device will attempt a total of 3 times before it exits and reloads the v1.0.0 "golden version."

Application Code

The application for the device is fairly straight-forward - it constantly polls the I2C devices for data and sends them to the Node-Red interface via an MQTT broker (CloudMQTT). Whenever new data is received from a sensor, it is published from the device and displayed on gauges on the GUI. It has functionality to perform an over-the-air-firmware-update and allows the user to request an HTTP download of the latest update. Similarly to the OTAFU, we added in a remote reset feature in the event that the device encounters a fault or behaves erratically, it can be reset and sent back to the bootloader.

At the end of the semester, we had added in code that would check if the light data received would cross a certain threshold (i.e. door is currently open with mail being deposited) and wait until it fell back under the threshold (i.e. door is now closed). The device would wait 3 seconds and then engage the servo locking mechanism. Unfortunately, there was a timing issue with our I2C bus and we were unable to properly read the data off of the sensor to implement this.

Accomplishments that We're Proud Of

Not many people can say that they were able to brainstorm an idea, design and create a PCB, AND write all of the firmware for it in a semester. While this has proved to be a massive undertaking for us, we are proud that we are able to put both hardware and software design skills into our knowledge base.

What's next for You've Got Mail

There are still some features that were originally planned that did not come to fruition. Here is a list of what is to come in version 2:

Full integration of both sensors (including using the VL53L0X API), downloading of multiple files during an OTAFU after the firmware update is requested.

Built With

  • c-atmel-asf-love
Share this project:

Updates