Project Overview
A client approached us to develop a smart bag prototype with fingerprint authentication, an electronically controlled lock, and mobile connectivity. The owner needed to unlock the bag using an enrolled fingerprint or a phone app, manage access settings, and track the bag remotely.
We designed the PCB and developed the embedded firmware. Our work covered component selection, schematic and PCB layout, peripheral drivers, and the application logic connecting authentication, lock control, wireless communication, and power management.
Constraints and Challenges
Unlock Response
Opening the bag involves several steps: detecting a finger, matching the fingerprint, and operating the lock motor. Delays at any stage affect the user’s experience.
The fingerprint module handles matching internally. We therefore focused on reducing delays in the driver sequence, firmware scheduling, and the transition from a successful match to motor movement.
Reliable Lock Operation
The motor needed to stop when the lock reached its end position and respond if the mechanism became blocked. The system also needed to detect when the latch was reinserted so that the bag could lock automatically.
The firmware needed feedback from both the motor driver and the mechanism to determine the lock’s state.
Compact Wireless Integration
The electronics combined BLE, LTE, and GNSS in a compact assembly alongside the motor driver, fingerprint interface, and power circuitry.
Integrating these subsystems required attention to signal integrity, electromagnetic interference, and thermal design. Fitting three radio systems into a small space also required work to limit interference and maintain reliable communication.
Debugging Inside the Bag
Once the electronics were installed, connecting a physical debugger became difficult. We needed a way to investigate crashes after they occurred, without requiring a debugger to remain attached.
Approach
Hardware Architecture
The PCB, battery, and lock motor fit together in a housing inside the bag. We selected the following components to support access control, connectivity, user feedback, and power management.
| Subsystem |
Selected Component |
Notes |
| Processing and BLE | Nordic nRF5340 | Dual-core Arm Cortex-M33 controller, up to 128 MHz, with integrated BLE for the phone connection. |
| LTE and GNSS | Quectel EG916Q and 1NCE eSIM | LTE Cat 1bis connectivity and multi-constellation GNSS for remote reporting and positioning. |
| Authentication | DFRobot SEN0348 | Capacitive fingerprint module with onboard matching and storage for up to 80 fingerprints. |
| Lock control | Maxon 386781 / 0615N4, 5 S motors, TI DRV8215 driver, and Hall sensors | Motor-current feedback for end-stop and blockage detection. Hall sensors detect motor position and latch insertion. |
| Indicators | IN-PI33TBTPRPGPB status LEDs, NXP PCA9745BTWJ driver, VLMRGB6112-00-GS08 interior LED, and ERM 316040004 vibration motor | Visual and vibration feedback, with RGB lighting inside the bag. |
| Motion sensing | TDK ICM-42670-P | Six-axis IMU included for motion-based features in later firmware versions. |
| Power | Rechargeable lithium battery, Microchip MCP73871 charge controller, and USB-C input | Supports battery charging while powering the system, with a battery-temperature sensor on the battery connector. |
The fingerprint module and modem communicate with the controller over UART. The motor driver and IMU use I2C, while the LED driver uses SPI.
LTE and GNSS have dedicated antennas. BLE uses a PCB trace antenna. The firmware reads the two Hall sensors through the controller’s ADC.
Firmware Scheduling
The firmware runs on Zephyr RTOS using Nordic’s nRF Connect SDK. The nRF5340’s application core runs the application firmware, while its network core runs Nordic’s BLE controller.
Each subsystem has a separate thread: fingerprint authentication, lock control, LEDs and vibration, BLE, LTE and GNSS.
Fingerprint authentication and motor control receive the highest priorities, followed by LEDs and BLE. LTE and GNSS run at lower priorities. This gives the unlocking sequence priority over background communication.
Fingerprint Authentication
A touch on the fingerprint sensor triggers an interrupt. The firmware then instructs the module to detect the finger, capture an image, generate a template, and search its stored fingerprints.
We developed the driver for the module’s UART command protocol and optimized the sequence to reduce the time between touching the sensor and opening the lock.
New fingerprints are enrolled through the app. The user scans the same finger three times, and the module combines the scans into one template. A name associated with each fingerprint is stored in flash so that the app and server can identify which enrolled fingerprint opened the bag.
Lock Control and Feedback
While the lock motor runs, the firmware monitors its current. This tells the firmware when the lock has reached its end position and protects the motor if the mechanism becomes blocked.
Two Hall sensors provide additional feedback. One detects the motor’s end position, and the other detects when the latch is pushed into the bag. The firmware uses these signals alongside motor current to control the lock.
The lock closes automatically when the latch is reinserted. It also closes after a fixed delay if the bag is unlocked but remains unopened.
BLE and App Controls
We implemented a custom Bluetooth Low Energy GATT service for communication with the companion app.
Through the app, the user can:
- Open the lock and check whether it is locked.
- View the battery level.
- Enroll, name, and delete fingerprints.
- Set the interior light’s color and duration.
- Adjust the duration of vibration feedback.
Settings are saved in flash using LittleFS, so they are retained after a restart.
LTE Reporting and GNSS Positioning
We developed an AT-command driver to control the EG916Q modem over UART.
At startup, the driver checks the SIM, waits for network registration, configures the mobile data connection, and opens a TCP connection to the server. It also obtains time from an NTP server to timestamp reported events.
The bag sends three types of messages:
- Location updates.
- Successful fingerprint unlocks, including the associated fingerprint name.
- Failed unlock attempts.
Unlock events are sent to the server over LTE even when no phone is within BLE range.
GNSS operates within the same modem. A separate thread parses its NMEA output, extracts the position and passes it to the LTE thread.
Position updates are sent periodically or when the bag has moved significantly, limiting unnecessary mobile data use.
Power Management
Power enters through USB-C protection and ESD circuitry before reaching the charge controller. The controller can charge the battery while supplying the system.
Conversion stages provide the supply rails required by the controller, modem, and lock motor. The firmware measures battery voltage and reads charger status, with LEDs warning the user when the battery is low. It also ensures that a flat battery does not lock the owner out of the bag.
A separate micro-USB port connects to the nRF5340’s USB interface during development.
Figure: System Block Diagram
LEDs and Vibration
Different LED colors, blink patterns, and short vibrations indicate successful authentication, failed matches, locking, unlocking, and low battery.
An RGB LED lights the inside of the bag for a configurable period after it is unlocked by fingerprint or through the app. Lighting and vibration settings can be adjusted from the app.
Firmware Updates and Crash Diagnostics
We integrated MCUboot with two application slots. Firmware updates are loaded over USB through serial recovery, and MCUboot verifies the image signature before starting the new firmware.
For faults that occur inside the assembled bag, we enabled Zephyr’s core dump feature.
After a crash, diagnostic data is saved to a dedicated flash partition. On the next startup, the firmware prints the dump to the log in small blocks. A script extracts it, and Zephyr’s core dump tools load it into GDB to inspect the captured call stack and variables.
This provides a way to investigate failures without a debugger connected at the time of the crash.
Outcome
We completed the PCB design and embedded firmware for the smart bag prototype. Fingerprint authentication, motor-driven lock control, BLE app communication, and LTE/GNSS reporting were integrated and validated.
Component selection balances functionality, reliability, and cost. The compact PCB brought the communication modules, fingerprint interface, and power management circuitry together.
The firmware also supported saved user settings, LED and vibration feedback, signed firmware verification, and crash diagnostics.
FAQ
How can the bag be unlocked?
The bag can be unlocked using an enrolled fingerprint or through the companion phone app over BLE. The fingerprint module stores up to 80 fingerprints, which users can enroll, name, and delete through the app.
Can the bag report its location without a phone nearby?
Yes. GNSS provides the position, and LTE sends it to the server independently of the phone connection. Position updates are sent periodically or when the bag has moved significantly, rather than continuously. LTE also reports successful fingerprint unlocks and failed unlock attempts.
How are firmware updates loaded and verified?
Updates are loaded through a USB cable using MCUboot’s serial recovery mode, a built-in mode for loading new firmware. MCUboot checks the firmware image’s signature before running it.
If you’re developing an IoT product or a similar connected product and facing these challenges, we’d be happy to help. Feel free to Contact Us for hardware design, PCB development, and embedded firmware services.
