jlm·technologies

04 · internal

RF Telemetry Platform

10,000+ access points. Zero residual channel conflicts.

10,000+

access points, 8 regions

0

residual same-channel conflicts

25k

lines of analysis code

6

machine-learning models in production

/ interactive · resolve the co-channel conflicts

try it, everything responds

co-channel conflicts < 100 m: 31

ch 1ch 6ch 11

Red edges are same-channel neighbours inside 100 m. Each one is airtime two access points steal from each other. The real optimiser does this with GPS clustering and an exhaustive per-cluster search, then ships the plan over SSH with per-device validation and automatic rollback.

A note on this demo. Every figure, name and data point here is invented for illustration. No client data, real economics or production configuration appears anywhere on this site. What is real is the machinery: the calculations, the rules and the logic running in your browser are the same ones the production system uses, so the demo behaves exactly as the real thing behaves.

What it is

/ in plain terms

Thousands of WiFi routers continuously report how healthy their radio signal is. When two nearby routers broadcast on the same channel they interfere and slow each other down, and slow WiFi means customers stop paying. This system finds every such conflict across the whole network automatically, retunes the radios, and verifies the fix, rolling back by itself if anything goes wrong.

A self-built WiFi telemetry and radio-optimisation platform covering a fleet of more than 10,000 OpenWrt access points across eight regions, where radio health drives revenue directly. It went through four generations: a proof of concept, an analysis workspace, a 30-page operator console over a 2.6 GB data lake, and a containerized collector fleet. The optimiser eliminated every same-channel conflict between access points within 100 metres of each other, and the experimentation framework was honest enough to debunk one of my own earlier revenue-lift claims.

Sole engineer. Collectors, data lake, dashboard, optimiser, machine learning, experiments.

PythonParquetDockerOpenWrtStreamlitPyTorch GeometricEconMLLightGBM

The load-bearing details

  • 01Partitioned parquet data lake with 13 tables per device and 2.6 GB across 13,000 files, plus compaction, retention pruning and a data-trust layer that flags readings that cannot be believed.
  • 02Channel and transmit-power optimiser: access points are clustered into GPS neighbourhoods, every channel combination in a cluster is searched exhaustively, power changes are guarded by revenue rules, and rollouts validate themselves with automatic on-device rollback.
  • 03A proper experimentation framework (difference-in-differences with statistical significance testing) so that changes are judged by evidence. Experiments that came back null were reported as null.
  • 04Counter-semantics discipline: cumulative WiFi counters are read as reset-aware deltas, and a zero-strength signal is treated as not heard rather than as a measurement.
  • 05Six-model machine-learning subsystem covering causal revenue estimation, network-wide forecasting with a graph neural network, anomaly detection and behaviour embeddings.