RF & Wireless Testing

Scanner and test handsets logging continuously against position across a route, a cluster or a whole market. SSB-RSRP and RSRQ for coverage, SINR for quality, downlink and uplink throughput, latency, VoLTE MOS and call setup, plus handover success in and out of every cell on the route. Layer 3 decoded alongside it, because a failure usually shows as a rejected message before it shows as a bad number: handover failures, NAS rejects, bearer modifications. NSA and SA both, FR1 and FR2 where it is deployed.\n\nA planning tool predicts coverage from terrain and antenna patterns. A drive test records what the network did, including what the model never saw: a building that went up, a tilt left at its commissioning value, a neighbour nobody defined.

When you need it

Validating a rollout, investigating a cluster of complaints, proving an optimisation held, or taking a baseline before anything changes.

What you get

Position-tagged datasets, per-metric heatmaps across the route, distribution statistics rather than averages alone, and a written read on where the network holds and where it does not.

Most subscriber minutes are spent inside a building and a vehicle reaches none of them. Walk testing covers venues, campuses, transit stations, hospitals and offices floor by floor, verifying distributed antenna systems and small cells against the design rather than against a hope. Grid testing where a pass or fail has to be produced per area, which is how public safety coverage is signed off.\n\nIndoor propagation is its own problem. A signal that is strong in the car park can be unusable two walls in, and the only way to know which walls is to walk them.

When you need it

Commissioning a DAS or small cell system, closing out a public safety requirement, answering complaints from a single building, or proving in-building performance before a venue opens.

What you get

Measurements per floor against the design criteria, the areas that fail and by what margin, and a pass or fail record in the form the authority or the client needs.

A drive test crosses a cell in seconds and sees it uncongested. Long dwell testing holds position for hours and watches what happens as traffic arrives: throughput decaying through the evening peak, MCS dropping and BLER climbing under contention, sessions failing on a cell whose counters look healthy all day.\n\nCapacity problems are invisible to a moving test by definition. If a site passes every drive and still generates tickets, this is usually the test that finds out why.

When you need it

Before a launch, after a complaint cluster that drive testing cannot reproduce, or to characterise a site that looks well on every KPI and still produces trouble.

What you get

A time series per metric across the dwell, the hours where performance turns, and whether the cause is coverage, capacity or configuration.

A comparison is only worth having when the network is the only variable. Benchmarking runs matched handsets on each carrier simultaneously over one route, so the results can be set against each other without an argument about conditions, time of day or device class.\n\nAnything less compares a drive on a wet Tuesday against a drive on a clear Sunday and calls it a finding. Reported as distributions rather than averages, because the tenth percentile is where a customer decides your network is bad.

When you need it

Making or defending a coverage claim, choosing a carrier to standardise a fleet or a workforce on, or finding where a competitor is genuinely ahead and by how much.

What you get

Carrier-by-carrier comparison across every metric, the segments and hours where each leads, and the margin stated precisely enough to publish.

An engineering vehicle on a defined route for six to eight hours, camera, audio and sensor capture started and stopped by hand, and a check that the session is usable before the shift ends. The equipment differs from a scanner and a set of test handsets. The day does not: a route planned before anyone turns a key, equipment that has to be working before the vehicle moves, and a written record of what happened while it did.

I drive a car running these systems every day, so I know how they behave in traffic, where they hesitate, and which of those moments is worth a note. What I bring professionally is the testing half: routes treated as a test plan, honest logs, and observations an engineer can act on rather than a description of the weather.

When you need it

When an autonomy, ADAS or robotaxi programme needs road data gathered consistently, day after day, by somebody who treats a shift as a measurement rather than a drive.

What you get

Session files that survive review, a daily drive report covering route, conditions, interventions and equipment faults, and early warning on anything that would waste an engineer a week later.

Single site verification on a new or modified site: does the cell carry traffic, do the sectors face where the drawing says, do handovers work clockwise and anticlockwise around the site and in and out of its neighbours. Then cluster testing across the group, because a site that passes alone can still break the one next to it.\n\nThis is where the gap between the design and the build shows up: workmanship, provisioning, parameters left at default, a sector cross-fed at the top of the tower. All of it cheaper to find now than after the site is carrying customers.

When you need it

Bringing new sites on air, closing out a construction programme, accepting a cluster from a vendor, or re-verifying after a modification.

What you get

Pass or fail against the acceptance criteria per site, every deviation found with evidence, and what has to change before sign off.

A campaign produces gigabytes that almost nobody opens. I write the processing myself rather than handing over a raw export and a spreadsheet: cleaning, binning, joining runs across days, devices and engineers, and building the maps and dashboards that make a finding obvious to an RF manager and to whoever above them has to approve the spend.\n\nDeliverables in the formats the next person actually uses, GIS layers included, rather than a PDF that cannot be queried. Custom tooling per campaign where the standard exports cannot answer the question being asked.

When you need it

Any campaign where the point is a decision rather than a dataset, or where a previous vendor delivered logs that nobody has opened since.

What you get

Clean, decision-ready data, heatmaps and distribution statistics, GIS layers, the raw logs kept as evidence, and a written finding that says what to do next.