> For the complete documentation index, see [llms.txt](https://docs.spectralink.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.spectralink.net/amie-advanced/metrics-reference/signal-strength-rssi.md).

# Signal strength (RSSI)

How strong the Wi-Fi signal is at the handset. RSSI stands for received signal strength indicator; it is the handset's own reading of the signal it receives from the access point it is connected to.

## The scale

RSSI is given in dBm, a logarithmic unit, as a negative number. As a rough guide from Wi-Fi engineering practice, −50 dBm is a strong signal, −70 dBm is weak and −90 dBm is barely usable. A more negative number is a weaker signal, so −60 is better than −75. Because the scale is logarithmic, a change of 10 is a tenfold change in signal power, which is heard as a much smaller difference than that sounds.

## How the product uses it

During a call the handset reports its RSSI repeatedly. AMIE counts each report below **−70 dBm** as a **low RSSI event**. The [Low RSSI Events Summary](/amie-advanced/using-the-platform/performance/performance-low-rssi.md) tab of the Performance screen shows those events over time, and per access point and handset, both as a count and as **Events / Call Min** — events divided by minutes of calling, which is the figure to compare rows by.

**Events / Call Min** needs a figure for minutes of calling, and AMIE derives it from the same reports: it treats each report as five seconds of calling, so twelve reports make one call minute, and the highest possible rate is **12.00**, when every report in a minute was weak. A period with under a minute of calling is treated as one minute, so the rate never divides by a fraction.

## What it does and does not tell you

Weak signal is the most common reason for poor call quality, and RSSI measures it directly. It does not measure interference: a handset can have a strong signal on a channel so crowded that packets are still lost. Read RSSI together with [Packet loss](/amie-advanced/metrics-reference/packet-loss.md) and [Call quality (MOS)](/amie-advanced/metrics-reference/call-quality-mos.md): weak signal with poor quality points at coverage, strong signal with poor quality points at congestion or interference.

## Edge cases

* **The threshold is fixed.** −70 dBm cannot be changed in the console.
* **Only calls count.** RSSI reported while the handset is idle is not counted as an event and does not appear on the Performance screen.
* **A rate of 0.** Either no calls were made, or every report during them was at or above −70 dBm. The chart draws both as **0**.

## Where you'll see it

* [Low RSSI Events Summary](/amie-advanced/using-the-platform/performance/performance-low-rssi.md) — the chart and both tables

No screen shows a dBm reading for a handset. The scale is here so that the **−70 dBm** threshold and the event counts built on it mean something.

## Related metrics

* [Packet loss](/amie-advanced/metrics-reference/packet-loss.md): the other direct measure of network trouble during calls
* [Call quality (MOS)](/amie-advanced/metrics-reference/call-quality-mos.md): what the caller heard


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.spectralink.net/amie-advanced/metrics-reference/signal-strength-rssi.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.