This project showcases how developers can build a low power IoT asset tracking solution using Qualcomm technologies and the Bluetooth® Low Energy Asset Tracker built on the Arduino® UNO™ Q board. By combining Bluetooth LE connectivity with real-time location and status monitoring, the solution demonstrates how intelligent tracking applications can be developed for everyday assets. The project highlights key aspects of the development process, including hardware integration, software design, and the end-to-end workflow required to create a connected tracking device.
In this project, you will build a BLE asset tracker that scans for a Bluetooth Low Energy beacon tag, estimates proximity from its RSSI (signal strength) value, and triggers local hardware feedback an RGB LED, a servo gate, and a buzzer when the tagged item moves between proximity zones.
The build highlights the dual-domain design of UNO Q, powered by a Qualcomm Dragonwing™ processor: one unified board where a Linux-capable MPU handles scanning, state logic, and orchestration, while a real-time MCU handles instant physical responses all deployed as a single Arduino App Lab project.
Objective
| 1. Set up Arduino App Lab on UNO Q | 2. Install a BLE beacon scanner on the board’s Linux shell |
| 3. Estimate asset proximity from RSSI signal strength values | 4. Communicate proximity state to the MCU via Arduino Router Bridge |
| 5. Trigger visual and audio alerts when an asset moves out of range | 6. Deploy a complete App Lab application spanning both processors |
By the end of the project, you will have a working asset-tracking prototype adaptable for tools, demo kits, inventory, backpacks, or any item you need to monitor.
Equipment Required Parts List / Tools
| Hardware | Software |
|---|---|
| Arduino UNO Q | Arduino Lab for Modules (App Lab) |
| BLE beacon tag (FSC-BP106A) | Python 3 (pre-installed on board) |
| Servo motor — signal wire to D9 | Bleak — Python BLE library |
| Modulino Buzzer — Qwiic / I2C | systemd — background service host |
| USB-C cable | Arduino Router Bridge library |
| Wi-Fi or Ethernet connection |
System Architecture
The application is split across three cooperating pieces. Understanding why it’s split this way will save you time it reflects a real current limitation of Arduino App Lab, not just a design choice.
1. BLE Scanner Service (Linux shell, outside App Lab)
Linux shell • outside App Lab
Python script using Bleak scans continuously for your beacon’s BLE advertisements. Runs as a systemd service on the board’s Debian Linux—installed once over SSH—and exposes the latest reading as JSON on port 5000.
2. App Lab Python Brick
Linux MPU • inside App Lab
Polls the scanner’s /latest endpoint every 2 seconds, maps RSSI into a proximity state (NEAR, MEDIUM, FAR, or OFF), and calls Bridge.call("set_beacon_state", state, rssi)—only when the state changes.
IMPORTANT App Lab Python bricks run in their own network namespace. 127.0.0.1 inside App Lab is NOT the board’s loopback. Use the board’s actual LAN IP address throughout.
3. MCU Sketch
Zephyr RTOS • real-time control
Registers a handler with Bridge.provide_safe() and reacts instantly to each state: driving the RGB LED and servo to reflect proximity, and triggering buzzer alerts on zone transitions.
Why Build This
UNO Q pairs a Dragonwing Linux brain with a real-time MCU on one board and this project is a practical example of why that split matters. Arduino App Lab doesn’t have a Bluetooth brick yet, so Bluetooth Low Energy tracking “shouldn’t” be possible from inside an Arduino App Lab app. This project routes around that gap with a lightweight background service on the Linux side, then uses the Arduino Router Bridge to hand off just the meaningful state changes to the MCU for instant, zero latency physical response.
That’s the real takeaway for developers: UNO Q lets you mix Linux-side tooling that the sandbox doesn’t yet officially support with rock-solid real-time MCU control in the same app, today. If you’ve ever wanted to bring a Python library the sandbox doesn’t officially support into an Arduino project, this is the pattern to use.
Grab the full source, wiring, and setup steps from the repo and have your own tracker blinking within the hour: GitHub Link
Project Walkthrough
Let us dive right into it.
Step 1. Bring up the UNO Q and Arduino App Lab
Power on the UNO Q and open Arduino Lab for Modules. Three operating modes are available:
| Mode | Description |
|---|---|
| PC Hosted | Connect via USB-C to your development machine. No separate power supply needed. Best for most development work. |
| Standalone | Connect keyboard, mouse, and HDMI directly to the board. Best for peripheral and sensor projects. |
| Network | Connect over your LAN from any machine on the same network. Available after first boot. |
Step 2. Install the BLE Scanner Service
This step runs over SSH on the board’s Debian Linux shell not through App Lab because it needs direct Bluetooth Low Energy / D-Bus access.
Find the board's LAN IP
scp -r ble_scanner_service/ arduino@<board-ip>:~/Copy files to the board
nmcli -g IP4.ADDRESS device show eth0
# or for Wi-Fi:
nmcli -g IP4.ADDRESS device show wlan0
Configure your beacon MAC address
nano ~/ble_scanner_service/ble_scanner_service.py
TARGET_MAC = "78:9F:38:09:9B:4E"
ASSET_NAME = "Towel"
NEAR_RSSI = -60 # dBm threshold for near
MEDIUM_RSSI = -80 # dBm threshold for medium
STALE_AFTER_SECONDS = 8
Install and verify
cd ~/ble_scanner_service
sudo ./install.sh
# Verify:
curl http://127.0.0.1:5000/latest
Expected response when the beacon is in range:
{
"status": "ok",
"asset_name": "Towel",
"mac": "78:9F:38:09:9B:4E",
"rssi": -58,
"proximity": "near",
"zone": "inside",
"timestamp_utc": "2026-07-19T20:00:00Z"
}
Step 3. Build the App Lab Python Brick
Open python/main.py in Arduino App Lab. Set API_URL to the board’s LAN IP from Step 2:
API_URL = "http://<board-lan-ip>:5000/latest"The key design pattern is change-detection in send_to_mcu: the Bridge call only fires when the proximity state changes, not on every 2 second poll. Stale readings are held for 10 seconds before sending OFF preventing rapid flickering during brief gaps in BLE advertisements.
Step 4. Add the MCU Sketch
The Arduino sketch registers set_beacon_state as a Bridge-callable function and translates each proximity state into LED color, servo position, and buzzer behavior.
| Proximity | RSSI | Servo | LED | Buzzer |
|---|---|---|---|---|
| NEAR | ≥ −60 dBm | 90° open | Green | 1 beep on entry |
| MEDIUM | −60 to −80 | 45° | Blue | — |
| FAR | < −80 dBm | 0° closed | Red | 5 beeps on entry |
| OFF / stale | — | 0° | All off | — |
NOTE The sketch includes #include directives for sensor libraries not used in this project (VL53L4CD, VL53L4ED, LSM6DSOX, LPS22HB, HS300x, LTR381RGB). These are required because the UNO Q uses Zephyr LLEXT—the sketch compiles as a loadable module. Without these includes, the host firmware does not export the C++ runtime symbols that Arduino_RouterBridge needs at link time, causing undefined reference errors.
Step 5. Package and Deploy Through App Lab
Open the ble-tracker-servo-leds folder in Arduino Lab for Modules as an App Lab project and click Run. The App Lab compiles the sketch and starts the Python brick together as a single workflow, with the BLE scanner running in the background.
Project structure
ble-tracker-servo-leds/
app.yaml
sketch/
sketch.ino # MCU firmware
sketch.yaml # board + library config
python/
main.py # Python brick
assets/
index.html # browser dashboard
BUILD TIME The first build is a cold Zephyr compile and takes 10–20 minutes. Subsequent builds use the cache and complete in under a minute. If you see "core.a: file truncated", delete the cache and retry:
rm -rf ~/ArduinoApps/ble-tracker-servo-leds/.cache
What you should see
Once deployed with the beacon powered on nearby, the onboard LED turns green and the servo swings to 90° with a single beep. As you carry the beacon farther away, the LED shifts to blue (medium) then red (far), with the servo stepping down to 45° and 0°, and 5 beeps on the FAR transition. When the beacon goes out of range for more than 10 seconds, all outputs turn off.
Real-World Applications
The same architecture can be adapted for practical tracking and monitoring scenarios, including:
- Tool Tracking - Monitor equipment in workshops or labs
- Inventory Control - Loss prevention and stock management
- Backpack Tracking - Personal item monitoring
- Demo Kit Management - Track hardware assets at events
- Smart Workspaces - Zone-based acess and alerting
- Check-in Systems - Asset check-in / check-out workflows
