--- title: 'RSSI, RSRP, RSRQ, and SINR: Reading Cellular Signal Quality in the IoT' description: Learn what RSSI, RSRP, RSRQ, and SINR actually measure, why signal bars can be misleading, and how to find weak devices in your fleet. source_url: https://dev.blues.io/blog/rssi-rsrp-rsrq-sinr-cellular-signal-quality/ canonical_url: https://dev.blues.io/blog/rssi-rsrp-rsrq-sinr-cellular-signal-quality/ markdown_url: https://dev.blues.io/blog/rssi-rsrp-rsrq-sinr-cellular-signal-quality.md --- # RSSI, RSRP, RSRQ, and SINR: Reading Cellular Signal Quality in the IoT ![RSSI, RSRP, RSRQ, and SINR: Reading Cellular Signal Quality in the IoT banner](https://dev.blues.io/images/blog/posts/rssi-rsrp-rsrq-sinr-cellular-signal-quality/banner.png?v=50327834) November 3, 2026 ## Learn what RSSI, RSRP, RSRQ, and SINR actually measure, why signal bars can be misleading, and how to find weak devices in your fleet. - [Cellular](https://dev.blues.io/blog/tag/cellular/) - [Notecard](https://dev.blues.io/blog/tag/notecard/) - [Notehub](https://dev.blues.io/blog/tag/notehub/) [![Rob Lauer](https://dev.blues.io/images/blog/authors/rob-lauer.jpg?v=57fb21a7)](https://dev.blues.io/blog/author/rob-lauer/) [Rob LauerSenior Director of Developer Relations](https://dev.blues.io/blog/author/rob-lauer/) 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](https://blues.com/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](https://blues.com/products/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. ![Two tank-level monitors that both report 2 bars. The one on a tank at the edge of the property reads RSRP -95 dBm, SINR 14 dB, RSRQ -9 dB, and RSSI -69 dBm, all good, with RSRP holding it at 2 bars. The one in a pump house next to motors reads excellent RSRP (-78 dBm) and RSSI (-45 dBm) but poor SINR (2 dB) and RSRQ (-16 dB), which hold it at 2 bars.](https://dev.blues.io/images/blog/posts/rssi-rsrp-rsrq-sinr-cellular-signal-quality/same-bars-different-problems.svg?v=4e053f1b) ## What RSSI, RSRP, RSRQ, and SINR Actually Measure {#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? {#what-does-good-look-like} Our [Diagnosing Cellular Connectivity Issues](https://dev.blues.io/support/diagnosing-cellular-connectivity-issues.md#measuring-the-quality-of-the-cellular-connection) 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. tip Consult our blog post on [How to Estimate Battery Life for a Cellular IoT Device](https://dev.blues.io/blog/estimate-battery-life-cellular-iot-device.md) 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](https://dev.blues.io/notecard/notecard-walkthrough/low-power-firmware-design.md#cellular-signal-considerations) 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. note 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 {#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. ![How Notecard calculates bars on LTE: RSRP, SINR, and RSRQ each cap the count, and the lowest cap wins. In the example, RSRP -104 dBm caps at 1 bar, SINR 6 dB at 2, and RSRQ -13 dB at 3, so the device reports 1 bar. Without an RSRQ reading, Notecard uses RSSI alone.](https://dev.blues.io/images/blog/posts/rssi-rsrp-rsrq-sinr-cellular-signal-quality/how-notecard-calculates-bars.svg?v=e6cac0ff) 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 {#where-to-find-these-numbers} Each time a Notecard opens a session, Notehub records a [\_session.qo event](https://dev.blues.io/api-reference/system-notefiles.md#session-fields), and the `session.begin` event carries the signal fields at its top level: ```json { "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](https://dev.blues.io/blog/differences-ltem-nbiot-cat1-cellular-iot.md) 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](https://dev.blues.io/api-reference/notecard-api/card-requests/latest.md#card-wireless): ```json { "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 {#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](https://dev.blues.io/connected-product-guidebook/antenna-guide.md#enclosure-material-rf-transparency) is that a metal box around your antenna is generally not a good idea. So does depth: a [GSMA coverage analysis](https://www.gsma.com/iot/wp-content/uploads/2018/07/Coverage-Analysis-of-LTE-CAT-M1-White-Paper.pdf) 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](https://dev.blues.io/example-apps/samples/using-leds-and-neopixels-to-monitor-notecard-status.md). 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](https://dev.blues.io/support/diagnosing-cellular-connectivity-issues.md#check-cellular-signal-quality) 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. ![The same device in four spots in one building: inside a metal basement cabinet (RSRP -121 dBm, 1 bar), on the basement wall (RSRP -112 dBm, still 1 bar), by a ground-floor window (RSRP -97 dBm, 2 bars), and on the second floor with a rooftop antenna (RSRP -84 dBm, 3 bars).](https://dev.blues.io/images/blog/posts/rssi-rsrp-rsrq-sinr-cellular-signal-quality/four-mounting-spots.svg?v=530d5e7a) ## Ask Your Fleet: How Many Devices Have Poor Signal? {#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](https://dev.blues.io/notehub/notehub-walkthrough.md#notehub-iq) answers plain-language questions about your Notehub data from the Blues AI assistant [on this site](https://dev.blues.io/?ai=open) or from your own MCP-capable AI agent. Create a dataset from your `_session.qo` Notes (which we recommend in [Notehub IQ Tips & Tricks](https://dev.blues.io/blog/notehub-iq-tips-tricks.md)), and ask: > How many of my devices have a poor signal? AI Tip 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: Prompt 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](https://dev.blues.io/api-reference/notehub-api/device-api.md#get-device-sessions) endpoint, or [route](https://dev.blues.io/notehub/notehub-walkthrough.md#routing-data-with-notehub) `_session.qo` events to your own database and alert on them as they arrive. ## Summary {#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](https://dev.blues.io/support/diagnosing-cellular-connectivity-issues.md). If you're still choosing cellular connectivity hardware, start with our [guide to cellular IoT](https://dev.blues.io/cellular-iot/). Happy hacking! 📶💙 ## Frequently Asked Questions {#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.