PackTrack

This is the a graph of some accelerometer data from the device
This is a screenshot of the Figma prototype for the phone app

Inspiration

Imagine you're returning from your favorite chateau deep in the vineyards of France and have with you a sweet, aromatic 1936 bordeaux. You're flying back to the states, but you're concerned about the bottle in your checked bag. What if it gets dropped? What if the extreme temperatures ruin the flavor? PackStats is our solution to provide peace of mind while shipping valuables. While the original idea was for individuals to use this for their personal items, we realized that this also has applications in industry. Companies that ship fragile products spend thousands if not millions of dollars on quality control. Products that arrive non-functional leave the company to wonder what could have happened in the shipping process. Our device can provide valuable insights into the shipping conditions that led to the failure, and allows them to simulate those exact conditions in-house.

What it does

This hardware-software system collects data during the shipping process. The user simply secures our IoT chip inside whatever package or suitcase they want to track, and turns it on. From then on, the chip will record data from multiple sensors many times every second. The user then sends the package off to its destination. Whatever extreme environments the package encounters during shipping period will be recorded, even without an internet connection. When the package arrives, the recipient can download all of this data using our web app. The web app presents the data in an easy-to-read format, but all the details are available for more advanced analysis.

How we built it

This system is centered around the T-Mobile DevEdge platform. This is used as the physical device that travels with the package. This was an ideal choice due to the number of sensors on the chip, which allows us to collect data from multiple sources. It also allows for multiple forms of data transmission, which was good freedom to have. To make it work, we wrote custom firmware for the DevEdge that collects data and sends it over the internet to our web app. The web app uses web sockets and React to present the data to the user as a graph.

Challenges we ran into

From a high overlook, the entire project is one of the most "full-stack" development experience that any of us have had. We went from changing Zephyr driver code at night, to making a quick front end interface in the morning. From manually managing memory and sockets, to simply using a couple libraries. With that, a bunch of unique challenges came up. At first, to even set up the dev environment, it took quite a bit of effort to find all the required dependencies, and then one step further to find entry points and figure out how to insert our own code. Then began the interfacing step, where we tried out all the drivers on their own (with the given POSIX-like system calls) to find exactly what this chip can do, and how accurately. The file system was it's own challenge, mounting, opening, and writing a file took quite some time after setting up the simple state machine to represent the different modes. But then reading from a log file into a large allocated buffer was even harder with the limited memory of embedded systems. Communicating this data to a server took by far the most time - we initially considered using Bluetooth, and therefore learned the ins and out of attribute tables and such, but then settled on opening a socket to make a HTTP POST request to our own server. After chipping away at a 404 bug for about an hour and a half, we were finally able to get our data to a server, and therefore we quickly made a fast front end to make a graph display as the end result. Overall, not a single part of this project went without effort - it took learning, experiment, guessing, revising, debugging, and planning on both small and large scales. Overall, we are all incredibly proud of our team for pushing through on such a relatively polished product, made in just one day.

Accomplishments that we're proud of

We worked very hard to get this project to where it is now. It all ended up paying off because now we have a fully functional system. The fact that we were even able to learn and use the platform that was completely foreign to us until very recently is impressive in itself. We are so proud of how far we have come since the start of the project. We ran into so many issues and errors every step of the way, from missing dependencies to firmware issues to socket not connecting. But in the end, we pulled through and created a complete prototype that is not only functional but also user-friendly. From understanding nothing about IoT devices and the firmware to working deep in networking and POSIX-like calls in C, we were able to reverse engineer the SDK provided by T-Mobile and use it to create our own firmware that interacts with a web server and website. We have had a few moments where we had no clue what was going on: system faults, 404 error, host unable to resolve. But through various ingenious solutions, we were able to move past each and develop what we have here today.

What we learned

We learned so much from this project because of its wide reach into completely different topics in computer science. No one on our team had much experience with Bluetooth, web sockets, or even firmware. We had to figure out how to manage states, interact with GPIO, create and connect sockets, and send HTTP requests from the systems level. But then, we had to develop a full-stack companion app equipped with a web server and website and learn to connect all three things together. Additionally, some of our team members didn't have much experience with hardware prior to this and learned a lot about communication between the chip, the computer, the server, and then the front end of the product.

What's next for PackTrack

Beyond Dubhacks, we first want to make the mobile and web apps fully functioning and interactive. Currently, the data is static and updates once a button is pressed in the app to get the data from the chip. However, we hope to provide live data later on in graph format in the "raw data" and log pages by implementing better two-way communication between the device and the app. Additionally, we want to provide an automatic notification system in which the user or owner of the package, as well as the receiver, can review texts or notifications when the chip experiences certain specified actions (e.g. spike in accel above 30m/s^2, major temperature drop, etc.). Finally, we want to provide more customizations to users with specific needs, such as accessibility features like spoken text, larger fonts, as well as more detailed raw data communication with pie charts or other ways to display data. This will also allow the user to have more control over what sensors the device logs, and the rate at which it logs them.