Tracking 100k Assets Before Having 100k Assets to Track: A Complex IoT System Built with AI Coding Agents | Adam Dunkels

closing tag, Google Analytics can be placed here -->

iot,

bluetooth,

ai,

Tracking 100k Assets Before Having 100k Assets to Track: A Complex IoT System Built with AI Coding Agents

Adam Dunkels, PhD Follow<br>May 19, 2026 ·

13 mins read

Share this

How do you ensure that your asset tracking system works with 100k+ assets when the hardware to track those assets exist only in sample quantities? We used AI coding agents to build a city-scale Bluetooth asset tracking simulator in a matter of weeks, covering Birmingham and Wolverhampton with 70 stores and thousands of simulated assets, so that the system would be ready when the hardware arrived.

Blecon, a startup based in Cambridge, UK, founded by the team behind the ARM Mbed OS, is known for its Bluetooth technology. Recently a new Bluetooth-based device entered the market: Bluetooth stickers. Those are peelable stickers that have a built-in Bluetooth chip and a printed battery.

Asset tracking is an established market, but Bluetooth stickers open up new possibilities: assets can be tracked from any nearby smartphone. They cost less than GPS trackers and don’t need the dedicated readers that RFID requires.

Blecon already had the raw Bluetooth technology in place, both on the device side and on the smartphone side. Now customers were screaming for it to be used for asset tracking.

So how were we able to develop an asset tracking system that can reliably track hundreds of thousands of assets before we even had our hands on the hardware? We built a large-scale simulator first.

Asset and Vehicle Simulation at City Scale

Asset tracking is an inherently large-scale operation: the purpose is to track large volumes of assets over large distances. Any asset-tracking system has to be large-scale from the start: you can’t start small and expand, you have to start at scale.

Our simulator started at the smallest scale that we could think of: the scale of a city. For our city, we chose Birmingham. And because we wanted to have a few longer routes, we included its sister city Wolverhampton too.

In our simulated city, assets are driven around on vehicles on city streets. The vehicles will stop at specific locations to offload and reload assets. We started out with 70 stores that the vehicles would drive to and from.

Every asset is tagged with a Bluetooth sticker and each vehicle has a driver who is equipped with a smartphone. The smartphone detects nearby Bluetooth assets and reports them to our backend system. It also detects its own GPS location.

In the real world, detection of assets and detection of location are never exact, so our simulator has to add a level of uncertainty to anything it does.

The physical movement of assets and vehicles also affects the realism of the data we generate.

To create a realistic city scenario, we used the Open Source Routing Machine with Open Streetmap data. This provides us with realistic paths for vehicles that drive around a city. Since we are based in the UK, our vehicles drive on the left side of the road. The routing system handles this automatically.

Watching the running system feels a bit like playing SimCity.

Simulating Bluetooth Device Detection

Simulated vehicle drivers are equipped with simulated smartphones running a simulated version of the Blecon agent app.

The challenge is modelling the fuzzy boundary: Bluetooth detection isn’t binary, and we need enough uncertainty in the simulation to produce realistic data for the backend.

We use an intentionally simple algorithm for detecting when a Bluetooth device is in the vicinity of a simulated smartphone: detection rate is 100% in a given radius around the Bluetooth device, then the detection rate linearly falls off until we hit an outer radius where detection rates are 0%.

From physical testing with Bluetooth devices, we knew this to be a reasonable model. And it is simple enough to run at scale.

Tracing API Calls

In a simulator, we have access to ground truth at a level that simply isn’t possible with a real-world setup. In our case, we wanted to see how the physical location of the phones in the system was affecting our location<br>estimation mechanisms on the backend. So we instrumented the simulator to track the location of every API call that we made.

To understand how the location of API calls affects the location estimation, we log every API call and tag it with the speed and direction of the vehicle when the call was made. We then have a view in the simulator frontend where we can see exactly where the calls are made.

If we see a discrepancy on the backend, we are able to trace exactly where and why this discrepancy occurred.

How Does Battery Life Affect Tracking Accuracy?

One issue with having smartphones do the tracking is battery life. Bluetooth scanning, GPS lookups, and backend reporting all drain the battery, and we need to...