Full signal, still dropping: what a cellular camera's bar count cannot see
Five bars, a current-generation attach, a valid SIM — and it drops anyway. The bar count did rule something out. What it did not do is narrow six candidate causes to one.
On this page
TL;DR: The camera drops with full signal, a current-generation attach and a valid SIM, and it keeps doing it. That reading eliminates weak coverage — which is where everyone starts and where most money gets spent — and it eliminates nothing else. Six causes produce this one complaint, and four of them cannot be told apart from any field the camera exposes: the quality metrics that would separate them appear nowhere in the vendor's API reference, so the discrimination needs an instrument on site rather than more polling. We never isolated the cause remotely. Read the free fields first, then the reversible probes, then correlate over time — and when that runs out, say so and send someone, because the alternative is buying an antenna for a problem you have already ruled out.
There is a particular flavour of bad day that starts with a screenshot of five bars.
The camera drops with full signal. Somebody has already checked the obvious thing, and the obvious thing is fine — so the fault is now somewhere between "the internet" and "the vendor", which is not a place you can send an engineer. Everything after that is guesswork unless you are careful about what you actually know.
What the bar count ruled out, and what it did not
Start with what it bought, because it is genuinely useful. Reading the device's own status over its HTTP interface, while the link was up, returned a full bar count, a current-generation attach and a valid SIM on exactly the units that were flapping.
That kills the weak-coverage hypothesis — and weak coverage is the one everybody buys hardware for. A directional antenna is the reflex, and this reading is what says: not yet, not for this. If you take one operational habit from this article, it is that the free remote read comes before the purchase order, because it is the difference between an antenna that fixes your problem and an antenna that arrives, gets mounted by somebody's installer, and changes nothing.
Now the part that took discipline to write down. A bar count is not a coverage measurement. It is a vendor-scaled summary of received power, sampled at the moment you asked, on a link that was by definition working — because a device that answers an HTTP request is a device that is currently attached. So the reading is a true statement about one instant on a link that was up, and the failure is by definition about the instants when it was not.
It rules out "there is not enough signal here". It does not rule out "the signal here is unusable in a way this number cannot express", and the difference between those two sentences is the rest of this article.
Why can full bars and a bad link coexist?
Three mechanisms, and they are all standard radio behaviour rather than anything exotic.
Strength is not quality, and that is a definition rather than an opinion. The measurements are specified separately, in 3GPP TS 36.214 — E-UTRA; Physical layer; Measurements (spec page). The document number is the citation here, not the link: 3GPP's portal addresses specifications by an opaque numeric id, and a reader who cannot check what an id resolves to cannot check the claim. That is the LTE specification, and these devices attach on 5G; the corresponding NR measurements are defined separately, with the same split and different names. Use it for the distinction, not for the numbers. RSRP is an average of the power carried by the reference signals: how loud the cell is. RSRQ is a ratio of that power to the total received on the carrier — the signal set against everything arriving on the same frequencies, itself included. A bar count is derived from the first. Interference lands almost entirely in the second. So a cell can be deafeningly loud and the channel still unusable, and the number on your dashboard will not move, because it is not measuring the thing that broke.
A tower is shared, and capacity is not coverage. Signal strength tells you how well you can hear the cell. It says nothing about how many other devices are talking to it. A site that is clean at 04:00 and unusable at 18:00 has not lost signal strength; it has lost its share, and no antenna adds capacity to a cell.
Some hardware makes it worse while raising the number. A broadband booster amplifies everything in band, interference included, and can flatten the spatial diversity a multi-antenna radio depends on — lifting the bar count while lowering the throughput, which is the most confusing possible outcome for whoever installed it. We have not measured that; it is standard RF behaviour and it is the reason the booster sits where it does on our own options list, not something we put on a bench. Treat it as a reason to demand a before-and-after from whoever proposes one.
Six fixes wearing one complaint
Here is the honest state of the diagnosis: one cause eliminated, five open, none isolated.
| Cause | The tell that would separate it | Where you can read that |
|---|---|---|
| Weak coverage | low received power | the camera — and it said no |
| Handoff churn between radio generations | re-attaches clustered at generation changes | operator side, or a modem you own |
| Interference at high bars | strong signal, poor quality ratio | a field meter or a router in the path |
| Cell congestion | fine off-peak, bad at peak | correlation over time, plus the operator |
| Data-cap throttling | throughput collapses, often late in a billing period | the device's usage and billing-day fields |
| Power brownout | reboots correlated with mains events or the day/night switch | site power, on site |
Two of those six are addressable from your desk: coverage, which we checked, and the throttle, because the usage and billing-day counters come back in the same configuration read as the bar count. The other four are not. They are not hard to see; they are impossible to see, from here, with this equipment.
We never isolated the cause. Handoff churn was plausible enough to be worth a free reversible probe — the units were on automatic radio selection, so the churn could happen — but plausible is where it stayed: no handoff was ever observed causing a drop. The throttle was never observed either. Writing "the cause was X" would have been the most satisfying sentence in this article and there was never any evidence for it.
Four of the six are invisible from where you are standing
This is the part that reframes the problem, and it is structural rather than a matter of effort.
A triage ladder for this symptom needs signal quality — the ratio metrics, RSRQ and SINR, plus the raw received power behind them. So the question is what the device exposes. Here is the cellular status object the vendor documents, field for field:
{
"simStatus": "...", "connect": "...", "isp": "...",
"signal": 5,
"imei": "...", "imsi": "...", "iccid": "...",
"ipaddr": "...", "subNetmask": "...", "gateway": "...", "dns": "...",
"dataUsage": "..."
}Twelve fields. Three report attach and operator state, three are hardware and subscriber identifiers, four are IP plumbing, one is a usage counter — and exactly one is a number about the radio: the bar count. There is no shortage of things the device will tell you. There is a shortage of exactly one kind of thing.
And the vendor's reference does not agree with itself about what that one number means. The
status object above documents signal as "typically an integer value from 0 to 100, where 0
indicates no signal". The configuration read — a different endpoint, the one our own tooling
actually calls — declares the same field name as signal(0~5). Two scales, one field, one document.
That matters operationally rather than pedantically: our fleet reported signal: 5, read from the
endpoint that declares 0~5, so it means full. Read against the other page it would mean almost
none. If you are reading this field, establish which endpoint you called before you conclude
anything from the value — and note what it does to the exercise this article is about. The single
number the device gives you about its radio arrives without a unit, and its own reference offers two.
The quality metrics are not merely absent from that object. Searching the entire API reference these cameras ship with — they are Milesight, and naming the vendor is what makes this checkable — returns zero occurrences of RSRP, RSRQ, SINR, RSSI or dBm. Anywhere. In any endpoint. That is a statement about the document, which is the strongest one available to us: an undocumented field could exist, and if it does, neither the vendor's reference nor anything we can reach will tell you its name.
Line the two up and the gap is not a matter of degree:
| What the triage needs | What the device offers |
|---|---|
| Received power, in dBm | a bar count, 0–5 |
| Quality ratio (RSRQ) — signal against everything else on the carrier | nothing |
| Signal-to-interference-plus-noise (SINR) | nothing |
| Which cell it is attached to, and when that changed | nothing |
| Whether the last drop was a re-attach or a teardown | nothing |
That turns a list of suspects into an argument about instruments, and it has a consequence people resist: you cannot build the dashboard. No amount of polling closes the gap, because the metric does not exist on this side of it — it only appears if you put a different box in the path, a router that owns the modem and exposes real statistics. That is a site visit and a hardware decision rather than a sprint ticket.
Our own connectivity design got this right and it is worth saying why, because the instinct is to plan the dashboard first. It asked "does the device interface expose any radio state?" as an open question and gated the quality metrics on a conditional router phase, rather than assuming them and discovering the hole in month three. The question was answered the next day, and the answer was no. Read the device's API before designing the dashboard — the cost of asking is an afternoon, and the cost of assuming is a monitoring plan that cannot be built.
- 1Rule out your own pipelineBefore spending anything on the radio, confirm that the thing reporting the outage is not itself the outage. Not optional, and not on the list below.
- 2Read what is freeBar count, attach generation, SIM status, usage, billing day. No site access, and they cover the only two of the six causes you can address from here.
- 3Probe what is reversiblePinning the radio generation crosses off a hypothesis for the price of one request. Reversible is the operative word.
- 4Correlate over timeCongestion and a power brownout announce themselves in time rather than in any single reading. Costs patience, not money — and it is the last thing you can do from here.
- 5Put an instrument on siteA meter during an actual drop. Everything still standing after step three needs it.
The order to try them in
Cost first, and cost means what it costs to be wrong, not what it costs to buy.
Step zero is ruling out your own pipeline, and it is not optional. Every cause above assumes the complaint is about the link. Before spending anything on the radio, confirm that the thing reporting the outage is not itself the outage — that your ingest is not restarting, your recorder is not failing over, and your dashboard is not showing you something other than the device's own answer. The last section of this article is about a case where that step would have saved the investigation.
Then, in order:
- The free remote reads. Bar count, attach generation, SIM status, usage and billing day. These cost nothing, need no site access, and cover the only two of the six you can address from here — one of which they eliminated.
- The free reversible probes. Pinning the radio generation is the obvious one: if churn between generations is the mechanism, forcing a single generation stops it, and if the flaps continue you have crossed a hypothesis off for the price of one request. Reversible is the operative word — anything you can undo remotely is worth trying before anything you cannot.
- The correlation work. Congestion and power brownout both announce themselves in time rather than in any single reading: peak-hour clustering for the first, mains events or the day/night infrared switch for the second. This costs patience rather than money, and it is the last thing you can do without going to site.
- The instrument. A field meter during an actual drop, or a router in the path that reports real quality metrics continuously. Everything left after step three needs this, and no remote work substitutes for it. This is also the honest place to stop and say the diagnosis needs someone physically there — which is a better answer than an antenna bought on a hunch.
A green light is an assertion about one path
The dashboard that measures attention, not liveness
While all this was going on, a device sat green on the board and was not answering its own API at all. Two separate things are worth pulling out of that, and only one of them is a bug we fixed.
What the column used to measure was attention. The status field was written by the viewer-gated live pipeline: a camera somebody was watching produced a live stream, and that wrote green. The harm ran in one direction and it is not the one people guess — a scheduled job swept every camera, and any whose pipeline was not active got written red. So a perfectly healthy device that nobody happened to be looking at was reported down, on a timer. The board was showing you the fleet's audience, not its health.
We fixed that: ownership moved to the 24/7 recording pull, which runs whether or not anyone is looking — green when the recorder publishes a manifest, red when its restart budget runs out against an unreachable device — and the live pipeline's churn became cache-only, with a comment at the write site saying so.
And the green-but-unreachable device above was seen after that fix, which is the more useful half. Nothing regressed: the recorder was pulling RTSP successfully while the device's HTTP interface was dead, so the field was doing exactly its new job and still could not tell anyone the camera was unreachable. "Reachable" is not one property. A device can serve video and refuse configuration; it can answer configuration and stall its stream. Any single green light is an assertion about one path, and the useful question about a status column is never whether it is accurate — it is which path it happens to be watching.
And that is exactly what the note recording it got wrong. Written sixteen days after the fix, it put the green down to "viewer-driven status" — the old mechanism, which by then had not been the mechanism for over two weeks. The observation was right and the explanation was the previous paragraph's, retired. It sat there being confidently wrong exactly where the next person would look, and it cost this article a draft: the first version of this section adopted that explanation whole, and then went on to criticise the note for being stale. A statement of current state, recorded once, trusted afterwards, with nothing arranged to notice it had rotted — the same failure as the dashboard, in prose.
One thing has not changed, and it is the honest caveat on the fix: nothing probes the device to set that field. Green still means an inference from our own pipeline's behaviour, not an answer from the camera. The client method that could ask the device directly exists, is tested, and has zero callers — which is its own small lesson about the difference between building a capability and using one.
FAQ
If the bars are full, why not just buy the antenna anyway? Because it treats the one cause you have already eliminated, and it is the most expensive way to learn nothing. Worse, a booster can raise the number while degrading the link, so a "successful" install can leave you with a better dashboard and a worse service.
Can you not infer quality from the bar count over time? No, and sampling harder makes it worse rather than better. The bar count is a quantised summary of received power. Interference changes the ratio while leaving the power alone, so the exact failure you are hunting is invisible to that number by construction — polling it every second gives you a high-resolution picture of the wrong quantity, and a convincing one, which is the danger.
What do you tell the client when the answer is "we do not know"? Exactly that, plus the elimination and the cost of the next step. "Weak coverage is ruled out, four of the remaining causes need an instrument on site, here is what that instrument costs and what it would settle" is a professional answer. It is also considerably more useful to them than a confident guess, because a confident guess is what gets an antenna mounted on the wrong problem.
Is the client-side dashboard fixed too? No, and that is worth saying plainly rather than leaving implied. What moved to the recording pull is the stored field. In the interface, the indicator for whichever camera is currently being watched is still derived from the browser's own live subscription, and only rows nobody is watching fall back to the stored value. So the same conflation survives on the client for exactly one camera at a time — the one you are looking at, which is the one you are least likely to doubt.
The three things worth taking away
- A negative result is worth publishing and worth reporting. "Not weak coverage" narrowed six causes to five for the price of one HTTP request, and it stopped a hardware purchase. Most of the value in a diagnosis like this is in what you stop doing.
- Read the device's API before designing the triage. If the metric that separates your two leading hypotheses is not in the surface, no amount of polling, alerting or dashboarding will separate them — and the honest plan says so on day one instead of discovering it in month three.
- A status column is a claim, so ask what writes it. Ours was written by whether somebody was looking. Yours might be written by whether a process is running, which is a different thing from whether a device is reachable, which is a different thing again from whether it is doing its job.
The other ways a camera at the end of a cellular link goes quiet — and what a buyer is choosing between once the cause is narrowed — are on always-on video that survives a bad uplink.
If you are staring at five bars and a device that will not stay up, and the next step is a purchase order nobody can justify, we do this kind of narrowing for a living.
