Say you've installed a few dozen tank-level monitors at a customer's site. One is bolted to a tank at the edge of the property, and another sits in a concrete pump house next to a bank of motors that may interfere with the cellular signal. Both report 2 bars in Blues Notehub. So far so good, right?
Well, they're the same product on the same carrier showing the same overall signal strength, but they may end up with entirely different connectivity issues, and a resolution for one could do absolutely nothing for the other!
In Blues Notecard land, bars is a
single digit calculated via four radio measurements: RSSI, RSRP, RSRQ, and
SINR. A Notecard Cellular device reports all four data points every time it
opens a session with Notehub, and once you know how to read them, you can more
accurately resolve any connectivity issues.
What RSSI, RSRP, RSRQ, and SINR Actually Measure
Picture talking with a friend across a crowded room:
- RSSI is how loud the whole room is.
- RSRP is how loud your friend is.
- RSRQ is how much of what you hear is actually your friend.
- SINR is whether you can make out what they're saying.
To be a little more technically accurate:
RSSI (Received Signal Strength Indicator) is the total power the modem receives across the channel, in decibel-milliwatts (dBm): serving cell tower, neighboring cell towers, interference, and noise. A noisy channel can produce a strong RSSI, so on its own it's a poor judge of LTE signal. It sticks around because it's what Notecard uses to calculate bars on 2G and 3G, where the LTE measurements don't exist.
RSRP (Reference Signal Received Power) is the power of the LTE reference signals from your serving cell tower only, in dBm, reported from -140 dBm (barely there) to -44 dBm (very strong). It answers "how strong is my tower from here?", which makes it THE metric for coverage, antenna placement, and enclosure decisions.
RSRQ (Reference Signal Received Quality) is RSRP relative to RSSI (scaled by the number of resource blocks measured), in dB, usually between -3 and -20. It drops when the cell is busy or neighboring cells leak in, even if your tower is strong.
SINR (Signal to Interference plus Noise Ratio) compares the useful signal with everything that isn't, in dB. Below 0 dB, there's more junk than signal. It's the best predictor of whether the modem can decode data at a reasonable rate, and Notecard reports it from -20 to +30 dB.
tl;dr when a device misbehaves, RSRP tells you about coverage, SINR and RSRQ tell you about interference and load, and RSSI mostly tells you about the room.
What Does "Good" Look Like?
Our Diagnosing Cellular Connectivity Issues guide uses this table as a rule of thumb:
| Quality | RSSI (dBm) | RSRP (dBm) | SINR (dB) | RSRQ (dB) |
|---|---|---|---|---|
| Excellent | > -65 | > -84 | > 20 | > -5 |
| Good | ≥ -75 and ≤ -65 | ≥ -102 and ≤ -84 | ≥ 10 and ≤ 20 | ≥ -9 and ≤ -5 |
| Fair | ≥ -85 and < -75 | ≥ -111 and < -102 | ≥ 5 and < 10 | ≥ -12 and < -9 |
| Poor | < -85 | < -111 | < 5 | < -12 |
A weak signal can make syncs slower and less reliable, and because the modem stays powered-on longer to finish each sync, it drains your battery faster too.
Consult our blog post on How to Estimate Battery Life for a Cellular IoT Device to walk through that battery-draining math.
Our own bench data shows how much RSRQ can move around with deployments that are almost identical. The Notecards we measured for our Power Usage Estimates reported RSRQ from -9 to -16 dB while completing their test syncs, mostly in the table's "fair" or "poor" rows. Because RSRQ changes with network load, it's not necessarily something to sound any alarms on as it's likely out of your control.
If your devices run on LTE-M or NB-IoT, you can read the bottom row a little more loosely. Both standards add "coverage enhancement", which repeats transmissions until a faint signal adds up to something decodable, so a device can often keep syncing below the "poor" line, at much lower data rates.
Why Bar Values Can Be Misleading
There's no globally-defined standard for "bars", so every phone maker and IoT platform picks its own thresholds. Notecard computes bars on the device and sends the value to Notehub with each session.
For LTE connections (e.g. Cat-1, Cat-1 bis, LTE-M, and NB-IoT), Notecard starts at 4 bars and lets each measurement cap the result. The lowest capped value wins:
| Measurement | 3 bars at most | 2 bars at most | 1 bar |
|---|---|---|---|
| RSRP | below -80 dBm | below -90 dBm | below -100 dBm |
| SINR | below 20 dB | below 13 dB | 0 dB or lower |
| RSRQ | below -10 dB | below -15 dB | below -20 dB |
Without RSRQ (e.g. on 2G or 3G), Notecard falls back to RSSI alone as its measurement: 3 bars when below -70 dBm, 2 when below -85, and 1 when below -100.
That works for a quick glance, but it does actually hide three things you'll want when a device misbehaves:
A one-bar reading covers a HUGE range. RSRP of -101 dBm and -125 dBm are both 1 bar, even though that's a factor of about 250 in received power. The bar metric alone can't tell the difference between a device just past the 1-bar threshold and one at the much weaker end.
The bar count doesn't say which measurement is the problem. These illustrative readings for the two devices from the intro both work out to 2 bars:
| Field | Tank | Pump house |
|---|---|---|
rssi | -69 dBm | -45 dBm |
rsrp | -95 dBm | -78 dBm |
sinr | 14 dB | 2 dB |
rsrq | -9 dB | -16 dB |
bars | 2 | 2 |
For the tank device, RSRP is what holds it at 2 bars. -95 dBm is still "good" by the table above, so this device isn't in trouble, but if you want more margin, coverage is the place to start. It may be far from its tower, or something in between may be soaking up RF, and a better antenna position or an external antenna is the first thing to try.
The pump house device hears its tower loud and clear, with an RSRP 17 dB stronger than the tank's, but it hears a lot of everything else too. That's why its RSSI looks better than the tank's. Its SINR and RSRQ are what hold it at 2 bars, which makes interference the likely suspect. A low SINR tells you that interference and noise are close to the signal's level, but not where they come from. Overlapping neighbor cells could be the cause, and so could those motors. If it turns out to be local equipment, a bigger antenna will pick up that noise along with the signal, and moving away from the noise source is the first thing to try.
The bar count isn't comparable across Notecard radios. WiFi sessions on
Notecard Cell+WiFi or Notecard WiFi report bars on a 0–5 scale computed from
RSSI alone, so filter by rat before you average anything.
Where to Find These Numbers
Each time a Notecard opens a session, Notehub records a
_session.qo event, and the
session.begin event carries the signal fields at its top level:
{
"event": "8a1f3e2c-5b7d-4e6a-9c21-0d4e5f6a7b80",
"device": "dev:860322068000000",
"file": "_session.qo",
"req": "session.begin",
"when": 1793721600,
"body": {
"opened": true,
"why": "periodic outbound sync due (sensors.qo)"
},
"rat": "lte",
"rssi": -74,
"rsrp": -104,
"rsrq": -13,
"sinr": 6,
"bars": 1,
"voltage": 3.71,
"temp": 21.5
}rat tells you which rules apply: lte (Cat-1 or Cat-1 bis), emtc (LTE-M),
nbiot (NB-IoT), umts (3G), gsm (2G), or wifi-2.4. Our
LTE-M vs NB-IoT vs LTE Cat-1
post covers how the cellular ones differ. Note that the values are a snapshot
only from when the session opened.
On the device, host firmware can read the same values with card.wireless:
{ "req": "card.wireless" }Its net object adds the LTE band (which _session.qo doesn't include) and
an updated timestamp. It's the modem's last known state, so check that
timestamp before you use it for any device or cloud application logic.
What the Numbers Mean in the Field
For a stationary device, its physical location and enclosure set the baseline for its signal quality. The readings will still move with network load, interference, serving-cell changes, and changes in its surroundings, so take a baseline on installation day (ideally before anyone leaves the site), then repeat the measurements under representative conditions, like with nearby equipment running or at the busiest times of day.
That means taking readings where the device will actually live: in the final enclosure, at the install site, mounted the way an installer will mount it. A prototype on your desk won't tell you much about a basement utility room (unless you work from a basement of course). Enclosure material makes a big difference, and the short version from our antenna guide is that a metal box around your antenna is generally not a good idea. So does depth: a GSMA coverage analysis notes that penetration loss for a device underground or deep inside a building can easily exceed 50 dB!
When you're trying different locations, watch RSRP. Every 3 dB is a doubling of received power, so moving an antenna from inside a cabinet to the outside of it can matter a lot. If SINR stays low wherever you put it, the site itself is probably noisy.
If someone other than you installs your devices, I'd give them a way to see the
result before they leave. Have your host firmware call card.wireless after the
first sync and show something simple, like an
LED color keyed to RSRP.
Fixing a marginal install on the spot beats a truck roll next month.
It's important to remember that some connectivity values will stay marginal no matter what you do. As our troubleshooting guide puts it, a weak connection "can turn into myriad issues with data syncing which do not always present themselves explicitly as connection issues." Expect longer sessions there, and size your power budget and sync intervals for those devices.
Ask Your Fleet: How Many Devices Have Poor Signal?
While card.wireless covers one device at a time, for a fleet you probably want
to ask the question just once, across every device's _session.qo history.
Notehub IQ answers plain-language
questions about your Notehub data from the Blues AI assistant
on this site or from your own MCP-capable AI agent. Create a
dataset from your _session.qo Notes (which we recommend in
Notehub IQ Tips & Tricks), and ask:
How many of my devices have a poor signal?
While that question works just fine, Notehub IQ will give you a more useful answer when you tell it what "poor" means for your product. This prompt uses the "poor" rows from the table above and looks only at LTE sessions:
Using my _session.qo dataset, find devices with poor cellular signal over the
last 30 days. Use only session.begin events where rat is lte, emtc, or
nbiot. Treat a missing rsrp or sinr as missing data, not as zero, and
leave those sessions out of the calculations. Group by device and rat, and for
each group calculate the median rsrp, sinr, and rsrq. Flag a group if its
median RSRP is below -111 dBm or its median SINR is below 5 dB. Tell me how many
devices are flagged, then list the ten worst groups with their device, rat,
medians, and session counts. Separately, report how many sessions were left out
for missing signal data.
Medians smooth out devices that hover near a threshold, and grouping by rat
keeps a device that switches technologies from blending two sets of readings.
RSRQ stays out of the flag because it moves with network load, and keeping RSRP
and SINR separate points you toward the devices to check for antenna placement
and the ones to check for interference.
If you'd rather build this into your own tooling, pull the same data per device
from the Notehub API's
Get Device Sessions
endpoint, or route
_session.qo events to your own database and alert on them as they arrive.
Summary
When a cellular IoT device misbehaves, look past the bars to RSRP and SINR. RSRP
points you toward coverage and antenna placement, a low SINR tells you
interference or noise is worth investigating, and rat tells you which
thresholds apply.
All four numbers are already in your _session.qo events, so start by asking
your fleet, then dig into individual devices with
Diagnosing Cellular Connectivity Issues.
If you're still choosing cellular connectivity hardware, start with our
guide to cellular IoT.
Happy hacking! 📶💙
Frequently Asked Questions
What is the difference between RSSI and RSRP?
RSSI is the total power a modem receives across the whole channel, including the serving cell, neighboring cells, interference, and noise. RSRP measures only the LTE reference signals from the serving cell. On LTE, RSRP is the better measure of coverage, because a noisy channel can produce a strong RSSI. On 2G and 3G, where RSRP doesn't exist, RSSI is the measurement Blues Notecard uses to calculate signal bars.
What is a good RSRP value for cellular IoT?
As a rule of thumb, RSRP above -84 dBm is excellent, -102 to -84 dBm is good, -111 dBm to just under -102 dBm is fair, and below -111 dBm is poor. Weaker signal means slower, less reliable syncs and more battery spent on each one. Devices on LTE-M or NB-IoT can often keep syncing below the poor line thanks to coverage enhancement, but at much lower data rates.
What is RSRQ?
RSRQ (Reference Signal Received Quality) is the ratio of RSRP to RSSI, scaled by the number of resource blocks measured, in dB. It usually falls between -3 and -20 dB, and it drops when the cell is busy or neighboring cells interfere. Because it moves with network load, values of -10 to -16 dB are common on devices that sync normally.
What is SINR, and what is a good SINR value?
SINR (Signal to Interference plus Noise Ratio) compares the useful signal with interference and noise, in dB. Above 20 dB is excellent, 10 to 20 dB is good, 5 dB to just under 10 dB is fair, and below 5 dB is poor. Below 0 dB, interference and noise outweigh the signal. Blues Notecard reports SINR from -20 to +30 dB.
How does Notecard calculate signal bars?
Notecard computes bars on the device. For LTE connections it starts at 4 and
caps the value using RSRP (below -80, -90, and -100 dBm), SINR (below 20 and 13
dB, and at or below 0 dB), and RSRQ (below -10, -15, and -20 dB), keeping the
lowest result. Without RSRQ, it uses RSSI alone. Zero bars means there is no
valid reading. Bars and the underlying values appear in every _session.qo
session.begin event and in card.wireless responses.