Calibrate Ekahau / Wi-Fi survey comparison

Comparing the survey with the controller.

In hospital networking, I used Ekahau to survey Wi-Fi signal strength and Cisco controller records to investigate wireless issues. I built this Python tool to compare readings by location, flag gaps and produce a workbook I could check before deciding what to measure next.

Try the demo Explore the sample report Read the story

The application / at a glance

What I built

Inputs

Controller readings (CSV)
Survey readings (CSV)

My Python workflow

Compare matching locations

Check the readings
Match locations
Calculate differences
Retain exclusions

Libraries

Python / requests + openpyxl

Excel output

Sample comparison workbook

Verified synthetic sample · offline analysis. Live controller collection has not yet been tested.

Project state: Verified sample · live collection not yet tested
Built with: PythonCisco RESTCONFCSVopenpyxlStatistical analysis

Verified offline sample / 2026-10-26

From paired readings to an inspectable report.

A small, generated example shows what the tool does: compare matching locations, keep the gaps visible, and leave a trail back to the readings.

Generated controller readings: 672
Locations compared: 8/ 13
Median: controller − survey: -4.00dB

01Read the result
02Inspect the locations
03Check the repeat run

01 / Reading the result

What does -4.00 dB mean?

Across the 8 compared locations, the median indicates 4.00 dB lower received power on the controller side. This describes the generated observations.

One location / P01

-58.00 − (-54.00) = -4.00 dB

Controller reading minus survey reading. This point’s difference happens to equal the overall median.

dBm is a reading of received power; dB describes the difference. The tool takes a median at each controller location, compares it with the survey reading, then summarizes the differences at each location.

A point is a named location; a sample is one controller poll there. 477 readings support the 8 comparisons. The other 195 readings stay outside the comparison—including usable readings with no survey match.

The actual output / Excel workbook

Read it in three sheets.

ComparisonStart with the result, input settings and limits.
PointsSee which locations were compared or left out, and why.
SamplesTrace a location back to its controller-style readings.

Download sample report (.xlsx)

Generated data · static report. Editing the workbook does not rerun the analysis.

Controller readings (.csv) Survey readings (.csv) Verification summary (.json)

02 / Follow the decisions

Keep the points you can compare.

8 locations are compared; 5 are left out. Start with these four details to see how the rules affect the result.

Controller minus survey / dB

Compared locations · ordered by point ID, not time

Equal readingsMedian -4.00 dBSelected location, when included

Below zero means the controller-side reading is lower. Excluded locations have no plotted difference.

Inspect all 13 locations Including the 5 exclusions and their original report findings.

All synthetic points, including exclusions. Values shown to two decimal places.
Controller median / dBm	Survey reading / dBm	Difference dB	Use
-58.00	-54.00	-4.00	Compared
-61.00	-58.00	-3.00	Compared
-66.00	-61.00	-5.00	Compared
-67.00	-63.00	-4.00	Compared
-71.00	-67.00	-4.00	Compared
-73.00	-70.00	-3.00	Compared
-78.00	-73.00	-5.00	Compared
-93.00	-75.00	-18.00	Compared
-68.00	-64.00	Unavailable	Left out
Unavailable	-64.00	Unavailable	Left out
-68.00	Unavailable	Unavailable	Left out
Unavailable	-64.00	Unavailable	Left out
Unavailable	-64.00	Unavailable	Left out

An unavailable reading is kept as a gap. It is never displayed as zero.

Behind the comparison

How a location qualifies.

The two input files share a location ID. The script also requires enough usable readings, consistent radio identity and a bounded collection period. A missing survey match leaves the location out.

See the input rules and exact settings

Minimum usable controller readings: 50
Maximum controller poll duration: 2000 ms
Maximum location collection span: 180 s
Compared / left-out locations: 8 / 5

Poll duration times the complete controller request sequence. It does not establish client-path latency or signal-reading freshness. The survey input is a manual point CSV, not an Ekahau project-file import.

03 / Check the repeat run

The same inputs, the same result.

Two complete runs produced identical input files, analysis summaries and workbooks. Every workbook value matched. The recorded offline tests passed; collecting from a live controller still needs its own test.

Offline tests passed: 58
Complete sample runs: 2
Report bytes match: Yes
Report values match: Yes

What was checked?

All offline regression and mocked-protocol tests passed.
Both CLI runs completed successfully with default analysis settings.
Both input CSVs, analysis JSON and XLSX match byte for byte.
Every workbook cell matches across the repeated runs.
Workbook values reconcile to the public point and summary data.
No real controller, survey project or clinical data was used.

Method and limits

Keep the interpretation within the evidence.

The sample demonstrates the comparison and reporting workflow. An on-site investigation would still need measurements with the devices, radios and conditions documented.

Statistical details

Median difference: -4.00 dB
Median absolute deviation: 1.00 dB
Robust spread estimate: 1.48 dB
Interval: -5.00 to -3.00 dB

95% percentile bootstrap interval across paired locations (descriptive). This resamples paired locations, rather than treating repeated polls as independent RF measurements.

Bootstrap seed 7 · 5000 resamples.

Full measurement limits and source

Controller client-performance RSSI describes client-to-AP reception; a survey can describe AP-to-survey-device reception. Their difference is descriptive, not a universal device correction, coverage acceptance or voice target.

Fictional fixed-time inputs; this verifies the offline comparison and report, not a hospital deployment.
Survey inputs are a manual point CSV, not an imported Ekahau project.
RESTCONF parsing is tested with mocked Cisco-shaped responses. No live controller acceptance or RSSI freshness is established.
The two observation paths can have different radio directions, devices, antenna patterns and collection conditions. Their difference is not a universal correction.
The bootstrap resamples paired locations, not repeated polls. Fewer than five pairs withholds the interval.
Poll duration is elapsed time for the complete controller GET sequence, not client-path RTT or RF sample age.
Unmatched eligible samples remain visible but are not counted as used in the paired comparison.
No coverage, roaming, voice-service or clinical outcome is validated.

Cisco: the three RF relationships (slides 7-11)

See my experience

Working notes

Keep the comparison open to inspection.

A survey and a controller give me different views of a wireless environment. I wanted to put their readings next to each other, see which locations could be compared and keep enough detail to retrace the result. The example here uses generated measurements.

The readings came from different paths.

Controller records describe how an access point receives a client’s signal. The survey device listens in the other direction. Matching the location helps organize the comparison, but the devices and receive paths still matter.

I kept separate labels for the receive paths and checked radio identity and collection sessions before pairing locations. The result is a description of the readings, with the interpretation and any next measurement left to the person reviewing them.

Read the measurement limits

The example had to expose the gaps.

The starter generated 12 readings per location, while the analyzer’s default minimum was 50. I corrected the example and used deliberately incomplete locations to check whether the gaps were being made visible.

I added checks for invalid numbers, duplicate points and mixed collection conditions, then kept every exclusion in the report. Good controller readings can still be left out when there is no matching survey reading; missing data does not become a zero.

Inspect pairing and exclusions

A report should survive a second run.

The example also needed to give the same result when run again. I fixed the generated timestamps and random seeds, then compared both the workbook bytes and every cell across repeated runs.

The workbook keeps the original samples, point comparisons, exclusions and summary together. Someone reviewing the result can follow a location back to its readings and decide which gaps need another measurement.

Open the verified report

View my résumé

How the workflow is built and testedImplementation notes, checks and limits for a closer technical review.

Comparison workflow

From readings to a workbook.

The workflow checks individual readings before matching locations. It carries the samples, exclusions and calculated differences through to the workbook.

Validate
Values, timestamps, radio identity and collection sessions
Filter
Missing readings, slow polls and enough samples
Pair
Locations with both survey and controller readings
Report
Samples, exclusions, differences and a summary

The public example demonstrates this workflow with generated measurements.

Inputs: Controller readings and manually supplied survey points are matched by location. The public example uses generated measurements.
Decision: Check the readings before matching locations, and keep the reason whenever a location is left out.
Boundary: A reproducible sample of the reporting workflow, using generated measurements.

Checks and limits

What I checked.

Checks

Offline checks cover reading the files, preserving timestamps, validating values and identities, handling exclusions, calculating summaries and writing the report. The sample view shows the actual run’s settings and check count.

Repeatability

Repeated runs compare the input files, workbook bytes and report values. The generated workbook and both input CSVs are available beside the result.

Limits

Controller collection is checked with mock responses. That does not establish acceptance against a live Cisco controller. The manual survey-point CSV is not an Ekahau project-file importer, and the observed difference is not a universal RF correction.

Looking ahead

What I’d verify next.

Qualify the collector against approved controller responses and the actual TLS trust chain.
Collect approved measurements with documented devices, radio identity, sampling sessions and the two receive paths kept distinct.
Study whether path differences remain stable across devices and conditions before drawing broader conclusions.

Compare before making a change.

The report helps me check the comparison, see the gaps and decide what needs another measurement.

Get in touch More work