Problem statement
Tracking inventory effectively across multiple locations presents significant challenges. Current methods range from basic barcodes to advanced GPS-enabled devices, often either lacking in functionality or being prohibitively expensive for many applications. RFID technology, which sits between these extremes, offers a balanced solution by being both cost-effective and capable of supporting substantial data within a compact space.
Solution
This project explores the implementation of RFID tags to streamline the tracking of inventory items. Using NFC technology, these tags can be easily attached to items and tracked through a network of scanners. This solution is designed to be both affordable and efficient, filling a niche between simpler barcoding and more complex tracking systems.
Bill of materials
Particle Photon 2 – Primary controller with built-in WiFi.
3.7V LiPo Battery Cell – Power supply for the scanner.
MFRC522 NFC Reader – Supports NTAG215 standard, capable of reading and writing up to 504 bytes to RFID tags. Includes encryption capabilities.
RFID Tags (NTAG215 Standard) – Tags attached to inventory items.
External Button – Triggers the writing sequence to RFID tags.
Why RFID tags?
NFC tags exist in a nice middle ground of being inexpensive themselves, having a simple reader, and can support hundreds of bytes of data within a compact area. This project explores how these convenient tags can be attached to various inventory and then used to track their latest location via a set of known scanners.
Reading and writing tag information
In this case, inventory simply means items of a certain type (SKU) that range in quantity, similar to how a single barcode is attached to a single variety of packaged food. And just like how UPCs are unique to a SKU, each tag also needs to contain a unique identifier for tracking. Every scanner is based on a Particle Photon 2 since it has built-in WiFi connectivity and is easily powered by a 3.7V LiPo battery cell. The reader is a common MFRC522 NFC scanner which supports the NTAG215 standard and can read/write up to 504 bytes in the tag while simultaneously allowing for encryption if desired.
Even though reading data is quite simple, writing data to new tags takes slightly more effort. In each loop of the Photon 2’s program, the device checks if an external button has been held down, and if it has, will begin the writing sequence. The first step involves checking for the existence of a tag, and when one is found, will copy the tag’s new ID into a buffer and send it to the MFRC522 module for writing.
Particle cloud event ingestion
With the tags now holding their items’ IDs, it was time to get the data from the Photon 2 and persist it for later viewing and analysis. Other projects typically implement this type of functionality by directly calling a REST API, but this has the drawback of either needing a local network gateway or reaching over the internet to a deployed service. Rather, the Photon 2 can leverage the Particle Cloud’s publish function to send a serialized JSON object containing several important keys/value pairs:
- The scanner’s ID for location cross-referencing and logging
- The changed quantity (ingress or egress in the system)
- Item ID being scanned
- A current timestamp in ISO8601 format
The data gets published as an Event named INVENTORY-SCAN which is both logged by the Particle Cloud and stored by a custom web server that is subscribed to the Event Stream.
The database and web app
This system’s persistence layer is a Postgres database instance which is connected to a Nuxt application running in a development environment. It houses several tables for the scanners, items, and scanning events while relating them together and displaying relevant data through a pair of views: item_inventory for current inventory levels and latest_scan which shows the most recent scan by timestamp. One concern with tracking quantity is guaranteeing consistency, as scanning two items at the same time could lead to the wrong total being calculated. Because of this consideration, the application utilizes a ledger where the incoming Event simply contains the changed quantity so that the total sum can always be up-to-date and correct when fetched.
Retrieving all of this information and even modifying some aspects of it is made possible through the webserver’s RESTful API. The front-end has a page for showing a list of scanners, including their name, a short description, and physical coordinates for displaying on a map. Meanwhile, a second page lists the items along with their current quantity and total number of scans. Clicking on the ID pulls up a dialog that retrieves all of the scans in-order. Here, one can view the frequency of scans for particular items and where they are physically headed.
Going further with Particle Logic
The Nuxt web application was purpose-built for this project, so it works seamlessly with the JSON objects being sent by scanners. However, what if the system needed to integrate with an existing API for additional functionality? Particle Logic, which can be thought of as a serverless function that executes on certain triggers, makes it possible. In this example, the scanner sends a raw_inventory_event that has a few missing/misnamed fields. The Particle Logic function takes the Event and transforms it into an INVENTORY-SCAN Event that the web app’s API can accept, including the timestamp.
To learn more about this project, you can visit its repository here on GitHub for all of the source code. Additional information for the Particle Photon 2 and Particle Logic can be found at these links: