The measurement model and its assumptions
Calibration records exist for one reason: to let someone else understand what a beacon's signal looked like at a specific point in time, under known conditions, without having to repeat the work. If a record fails that test, it is not useful documentation.
A calibration result should capture enough detail to answer three questions. First, what were the exact hardware and firmware configurations? A beacon's measured signal strength changes if you alter the transmit power or advertising interval, so the record must state both. Second, where was the measurement taken? A description such as "entrance hall, beacon mounted at 2.4 m on a plasterboard wall, 3 m from a glass partition" is far more useful than "Zone A". Third, what did the receiving device actually observe? This means recording the RSSI values at multiple known distances, the device model and OS version used for measurement, and whether Bluetooth was set to a particular scanning mode.
There is no universal calibration template that suits every deployment. A small museum with twenty beacons in a single building can use a lighter format than a retail chain calibrating across fifty stores with different construction materials. What matters is consistency within the project: if one record includes ambient temperature and the next omits it, comparing the two becomes unreliable.
Core fields to capture
- Beacon hardware model, firmware version and battery type
- Configured transmit power level and advertising interval
- UUID, major and minor values (or the relevant identifier set)
- Physical mounting height, surface material and orientation
- Measurement distances from the beacon and the RSSI observed at each
- Receiving device model, OS version and Bluetooth scanning configuration
- Date, time and name of the person performing the calibration
- Environmental notes: foot traffic level, nearby metal structures, active Wi-Fi access points or other RF sources
Some teams also record a photograph of the installed beacon with a reference label visible. This is not essential, but it eliminates ambiguity when a later maintenance visit needs to confirm the unit has not been moved or swapped.
Control the variables you can control
In a retail environment, calibration records typically serve two purposes: validating that zone boundaries align with the intended notification triggers, and providing a baseline when store layouts change. If a fixture is relocated and a beacon's surroundings shift from open floor to a shelving unit, the original calibration data gives the operations team a concrete basis for deciding whether recalibration is necessary rather than guessing.
Museums face a different pattern. Exhibits change on a cycle that may range from weeks to years, and temporary partitions can appear around a beacon without anyone notifying the operations team. Here, calibration documentation is most valuable when it is tied to a floor plan with the beacon's position marked. When a new exhibition is installed, the curator or venue manager can compare the current physical layout against the documented calibration environment and flag discrepancies early.
For event organisers, the challenge is time pressure. Beacons may be installed and calibrated in a single day, then removed after the event. Documentation in this context needs to be fast to complete but sufficient to support post-event analysis. A structured form with dropdown fields for common values (mounting surface, height bracket, transmit power) reduces the time per beacon without sacrificing record quality.
Storing and accessing records
Spreadsheets remain the most common storage format, and they work adequately for deployments under a few hundred beacons. The practical risk is version drift: if a calibration is updated but an earlier copy remains in a shared folder, someone will eventually reference the wrong figure. Naming conventions that embed the beacon identifier and date help, but they do not prevent human error.
Larger deployments often integrate calibration data into the same asset register that tracks battery replacements and firmware updates. This keeps the calibration history alongside the maintenance history, which is useful when trying to determine whether a change in zone behaviour is caused by signal drift, a depleted battery or a physical relocation. The detailed mechanics of building and maintaining that register are covered separately.
Use the result without overclaiming accuracy
The most frequent documentation error is recording a single RSSI value at a single distance and treating it as definitive. Bluetooth signals fluctuate even in a controlled environment, and a single reading captures one moment, not a reliable average. Useful calibration records include multiple readings at each distance, ideally taken at different times or with short pauses between them, so the reader can see the spread.
Another common mistake is omitting the receiving device details. Two phones of the same model can produce different RSSI readings depending on OS patch level, background Bluetooth activity and case material. If the record does not state what device was used, a later team member calibrating with a different handset has no way to reconcile the difference.
Limitations of calibration documentation
A calibration record describes a snapshot. It cannot predict how the signal will behave when the space is full of people, when a delivery lorry is idling outside loading-bay doors, or when a neighbouring tenant installs a new Wi-Fi network. Documentation should be understood as a controlled baseline, not a guarantee of real-world performance. When someone quotes a calibration result as evidence that a zone will behave a certain way under all conditions, they are overreaching.
Calibration data also degrades in relevance over time. Firmware updates to the beacon or the receiving operating system can alter Bluetooth behaviour. Physical changes to the space, however minor, shift the RF environment. A record from eighteen months ago may still be interesting, but it should not be treated as current without verification.
Key checks before closing a calibration record
- Can a colleague who was not present during calibration read the record and reproduce the measurement setup without asking questions?
- Are the identifier fields (UUID, major, minor) consistent with the asset register, or has a transcription error crept in?
- Does the RSSI spread at each distance look plausible? A range of 2–3 dBm is typical; a range of 15 dBm at a single distance usually indicates interference or a recording mistake.
- Has the record been saved to the agreed storage location, rather than left on a tester's personal device or in an email thread?
- Is the beacon's physical label or marking consistent with the identifier in the record?
Good documentation does not require elaborate systems. It requires discipline: recording the same fields in the same way, every time, and treating the record as a working reference rather than a compliance exercise. When calibration results are documented thoroughly and consistently, they reduce the time spent troubleshooting zone problems later and give operational managers a defensible basis for decisions about layout changes and expansion.
