Brightline Distribution: BLE Asset Tracking Rollout Problems
Brightline Distribution is commissioning 300 BLE asset tags and 24 gateways across a 42,000 m² warehouse with 11 m steel racking. The vendor's phone app showed 100% tag detection during the site walk. In production, 12% of tags go unseen for more than an hour, and the miss rate climbs sharply when forklifts are running. Gateway logs show median RSSI of -78 dBm and a tail down to -92 dBm at the rack ends. Two Wi-Fi networks operate on 2.4 GHz channels 1, 6 and 11, and the tags advertise every second with a rotating MAC address. DHCP leases are set to 8 hours with a /24 scope per VLAN, and three gateways show clock drift of about four minutes. A mis-keyed batch of 40 tags was provisioned with duplicate asset IDs, and the ERP integration has already created 40 duplicate records. Go-live is in 12 days and the operations director is asking whether to postpone.
1. Lay out a systematic troubleshooting plan for the 12% miss rate, and say what evidence would distinguish the competing causes.
Read the worked answer
Start by proving where the loss occurs, because the candidates fall into three layers.
Layer 1 - capture (gateway hears the tag). Count advertisements received per gateway per tag and compare with the expected 60 per minute. A shortfall here is RF or placement. Evidence: RSSI and SNR distributions by gateway and tag. Median -78 dBm is acceptable but the -92 dBm tail is at the edge of usable; a 14 dB spread points to placement and multipath off steel racking rather than to a global power problem.
Layer 2 - transport (gateway to cloud). Compare gateway-side counts against cloud-side counts for the same window. Divergence indicates backhaul, buffering or clock issues - and the four-minute drift matters, because scans landing in the wrong time bucket look like losses even when the packet arrived.
Layer 3 - identity and ingestion. Rotating MAC addresses mean the platform must resolve identity from the payload, not from the MAC. If the resolver keys on MAC, each rotation creates a new 'device', inflating the miss rate and corrupting dwell-time analytics. Test by checking whether 'missing' tags still have recent raw packets under a different identifier.
Forklift correlation. Moving metal and human bodies absorb and shadow 2.4 GHz. If misses cluster in aisles and only during shifts, it is physical-layer, not software.
Fast confirmation tests. Place a reference tag at 20 fixed positions and log detection for an hour with forklifts idle, then active. That single test separates RF-shadowing from pipeline defects within a day.
2. Define an acceptance test the site must pass before go-live, and justify each threshold.
Read the worked answer
A 12-day window is enough for a defensible test if it is run per zone rather than as one grand event.
Coverage soak. 72 hours per zone with production-like forklift activity, requiring at least 98% of tags present in each 15-minute bucket and at least 99.5% of received advertisements delivered to the cloud within 60 seconds. The 15-minute bucket aligns with the operational question ('is this pallet where I think it is?'), and the 60-second latency prevents a slow pipeline from passing as a coverage win.
Worst-case positions. Explicitly test the 20 positions with the lowest RSSI found during troubleshooting; a site that passes on average but fails at the rack ends will fail in practice. Require the weakest position to sustain 95% of expected advertisements at -85 dBm or better.
Identity integrity. Zero duplicate asset records, and a reconciliation report showing every tag's identifier history mapping to exactly one asset. The 40 mis-keyed tags must be corrected and the ERP records merged before the test runs, or the test measures the wrong thing.
Resilience. Pull one gateway's PoE and confirm the platform raises an alarm and neighbouring gateways absorb the coverage; disconnect the WAN for 15 minutes and confirm buffered data backfills with correct timestamps.
Time integrity. All gateways within 5 seconds of a reference clock, verified after a forced NTP resync.
Passing all five is the go-live gate. Any single failure means a phased go-live by zone, not a site-wide postponement.
3. Recommend the remediation changes, prioritised, and identify which ones are permanent design fixes rather than tuning.
Read the worked answer
Permanent fixes (do these regardless).
- Identity resolution from payload. Rotating MACs are a privacy feature; the platform must key on the device identifier in the advertisement payload. Anything else is broken by design and will keep producing phantom losses.
- Clock discipline. Enable NTP with a local fallback source and alarm on drift over 30 seconds. Four minutes of drift silently corrupts dwell-time reporting and will be blamed on the tags.
- Duplicate record remediation. Correct the 40 tags, merge the ERP records, and add a provisioning check that rejects duplicate asset IDs at the point of commissioning - the phone-app walkthrough clearly does not validate against the ERP.
- Channel plan. Advertising channels sit between Wi-Fi channels 1, 6 and 11; verify that gateways are not filtering advertisements and that no access point is parked on a channel that overlaps the advertising band.
Tuning and placement (prioritise by measured impact). 5. Add gateways at aisle ends where the -92 dBm tail lives; going from 24 to about 32, mounted at 5-6 m and below rack-top height so racking does not shadow the antenna, is the cheapest way to lift the weakest positions. 6. Directional antennas on perimeter gateways to reduce cell overlap and interference. 7. Tag settings - raise transmit power and confirm the 1-second advertising rate is actually in effect after provisioning. 8. DHCP - the /24 is ample for 24 gateways, but set reservations so address changes never present as connectivity faults.
Go-live recommendation. Fix items 1-4 and 7 immediately, then run the zone soak. That is achievable in 12 days; a full re-architecture is not, and postponing everything would be an overreaction if the identity and clock defects are the dominant causes - which the layer-by-layer test will confirm.