Data quality & real-world behaviour
YANL is a diagnostic tool, so the most important thing is that you can trust what you see. This page explains how the app decides whether a reading is still valid, what it does when the hardware stops reporting, and how it behaves in the awkward real-world situations we test for.
We never invent values
The single rule behind everything below:
If the modem, Wi‑Fi chip, or GPS doesn’t report a value, YANL shows N/A (or leaves the tile blank) — it never displays a made-up number or silently keeps an old one on screen.
So a number on a tile is either a genuinely current reading or it is marked stale/blank.
There is no third “best guess” state. The same applies to the uploaded log: missing
fields are written as null, not back-filled.
Freshness — how long a reading is trusted
Every reading carries an age, measured from the moment the hardware produced it. Once a reading is older than its threshold, the app stops presenting it as live:
| Data | Trusted for | After that |
|---|---|---|
| Signal strength / quality (RSRP, RSRQ, SNR) | ~10 seconds | Marked stale, then blanked |
| Cell identity (PCI, EARFCN, Cell ID, TAC) | held up to ~30 seconds | Held briefly, then blanked |
| Wi‑Fi RSSI and scans | current tick only | Cleared when Wi‑Fi drops |
Identity (which cell you’re on) is held a little longer than signal because it changes far less often — but it is still dropped once clearly out of date, rather than shown forever. You’ll see this reflected on tiles and in the log’s freshness state for each metric: FRESH, STALE, HELD_STALE (identity held briefly), MISSING, or INVALID when there’s no trustworthy data.
The Data age value (see Calculated by the app) is how this is measured: the hardware’s own timestamp compared with the device clock.
How Android feeds the app these readings
Android doesn’t hand out a fresh radio reading on demand. It works on a listener
(callback) model: the app registers once, and the system calls it back only when a
value actually changes — for example
TelephonyCallback.CellInfoListener
fires when the cached cell information changes. Between those changes there is simply
nothing new to deliver, so the app keeps showing the last value the system gave it.
This is exactly why the freshness check matters, and when:
- On the move — during a drive test or while changing cells, the radio reports often, callbacks fire frequently, and readings stay naturally fresh.
- Stationary / steady conditions — sitting still on a strong, stable signal, the system may not report anything for a while because nothing has changed. The value is still correct; it just hasn’t been re-confirmed recently. This is where the age and stale/blank rules earn their keep — they tell you whether you’re looking at a freshly confirmed reading or one the radio simply hasn’t had reason to refresh.
The 1-second tick described below samples this latest known state once per second for the log and charts. It does not force the modem to take a new measurement every second.
Why not just poll every second?
Forcing a fresh hardware reading on a tight loop isn’t supported by Android — by design, to protect battery and radio resources:
- From Android 10 (Q) onwards,
getAllCellInfo()no longer triggers a refresh; apps targeting Q or higher “receive the latest cached results, which may not be current.” - To request a genuine update an app must call
requestCellInfoUpdate(), but Android states these updates are “rate-limited and are not guaranteed.” - The documented way to judge how current a reading is, is to check the reading’s own timestamp — which is exactly what our Data age and freshness rules do.
So the callback model plus a freshness check is the best-practice approach Android points developers to. High-frequency polling would be throttled by the OS and drain the battery for no benefit, and sustained background work is further constrained by Android’s Doze and App Standby power management. Listening for changes and timestamping them is both the supported and the responsible way to collect this data.
Android references
- TelephonyCallback.CellInfoListener — the change-driven cell-info callback the app listens on
- TelephonyManager —
getAllCellInfo()returns cached results on Android Q+, andrequestCellInfoUpdate()is rate-limited and not guaranteed - Doze and App Standby — Android’s battery-driven limits on background work
How readings are recorded
- The app runs on a steady 1-second (1 Hz) tick.
- Every tick is written to the log — there is no “only when it changes” filtering, so the timeline is complete and evenly spaced.
- Each line carries
derived_wallclock_ms(wall clock) plus tick timing fields so the web replay stays in order. - If a tick is ever missed (e.g. the system pauses the app), the log writes an explicit gap record marking the missing span — gaps are shown honestly, never hidden.
Real-world scenarios we test
We deliberately put the app through the conditions a field tester actually hits. Here’s what you should expect to see.
Aeroplane mode / no service
All cellular metrics correctly drop to N/A: signal goes stale, the serving-cell and
neighbour tiles blank, and the neighbour count falls to 0. Nothing is carried over
from before the modem went down. The log records the same — modem fields as null — so
a replay shows exactly when coverage was lost.
Screen off / phone in a pocket or mount
Logging keeps running at the full 1-second cadence with the screen off — verified across a continuous capture with no missed ticks. You can mount the phone or pocket it during a drive test and trust that the data is still being recorded.
Patchy coverage and dropouts
When readings stop arriving, tiles blank rather than freeze, and the log marks the gap. When coverage returns, fresh readings resume immediately. This means a replay timeline reflects real coverage holes instead of a smooth-looking but misleading line.
What the hardware can’t always give you
Some values depend on the network and radio state and simply aren’t available all the time. This is a limitation of what Android exposes, not a fault in the app:
- Timing Advance (and the “Distance to tower” derived from it) is only reported in an active, connected data state, and on many devices reads as unavailable even then — so it is often blank.
- Neighbour-cell identity — TAC, Cell ID and PLMN are not broadcast for neighbouring cells, so neighbours reliably expose only PCI, ARFCN and signal level.
- SNR / RSSNR is unavailable in many LTE states on common hardware, which is why it isn’t given its own chart.
When these aren’t available you’ll see N/A — that’s the app being honest about the source, not losing the data.