> 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/using-the-platform/performance/performance-low-rssi.md).

# Low RSSI Events Summary

**Low RSSI Events Summary** is the third tab of the [Performance](/amie-advanced/using-the-platform/performance.md) screen. RSSI is received signal strength — how strong the Wi-Fi signal was at the handset. This tab counts the signal samples during calls that read weak, over time and by access point and handset. To reach it, select **Performance** in the sidebar, then the **Low RSSI Events Summary** tab.

## Why this screen matters

Weak signal is the most common reason a call sounds bad, and this tab measures it directly: during a call the handset repeatedly reports how strong the signal is, and each weak reading is an event. An access point with many events per call minute is one whose handsets are too far away, blocked, or on the wrong channel; a handset with many events per call minute across different access points is one carried into places without coverage. Use the rate, not the count, to compare rows, then aim the site survey at the access point with the worst rate and the most call minutes.

## Before you start

The tab follows the [group selector](/amie-advanced/using-the-platform/the-console.md#the-group-selector), the [time range](/amie-advanced/using-the-platform/performance.md#time-range) and the [filters](/amie-advanced/using-the-platform/performance.md#filters) described on [Performance](/amie-advanced/using-the-platform/performance.md). An hour or day with no samples is plotted as **0**, and so is one whose samples were all strong — a good result. Networks your organization has asked to exclude are left out as described under [Before you start](/amie-advanced/using-the-platform/performance.md#before-you-start) on Performance.

## Screen layout

![Low RSSI Events Summary over 90 days: no weak-signal events, but call minutes in both tables.](https://3032864282-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FxfLF6IpyutR429bMnvvf%2Fuploads%2Fgit-blob-12dddb7508b069e357eead35a64480a036544dea%2Fperformance-low-rssi.png?alt=media)

### The chart

Two lines, each on its own vertical axis:

| Series                         | Axis                                                              | What each point is                                                                |
| ------------------------------ | ----------------------------------------------------------------- | --------------------------------------------------------------------------------- |
| **Events** (blue)              | Left, from **0** to a round number at or above the highest point  | The number of low RSSI events in that hour or day                                 |
| **Events / Call Min** (orange) | Right, from **0** to a round number at or above the highest point | **Events** divided by the call minutes in that hour or day, to two decimal places |

A low RSSI event is one signal-strength sample, recorded during a call, that read below −70 dBm, where a more negative number is a weaker signal — see [Signal strength (RSSI)](/amie-advanced/metrics-reference/signal-strength-rssi.md). Call minutes are worked out from the same samples: AMIE treats each sample as five seconds of calling, whatever the actual interval between reports, so twelve samples make one call minute. A period with under a minute of calling is treated as one minute, so the rate never divides by a fraction. Because there are twelve samples in a minute, the highest possible rate is **12.00**: every sample in the minute was weak.

### The tables

**Low RSSI Events by AP** on the left (the by AP table) and **Low RSSI Events by Device** on the right (the by Device table). Records with an [all-zeros address](/amie-advanced/using-the-platform/performance.md#the-two-tables) are left out of the by AP table. With no samples in the range, each table reads **No data for the selected period**.

## Controls

The shared controls are described on [Performance](/amie-advanced/using-the-platform/performance.md#controls). Exports from this tab are named `low-signal-strength-ap.csv` and `low-signal-strength-device.csv`.

## Columns

Every column is sortable; each table opens sorted by its first column.

### Low RSSI Events by AP

| Column                         | What it shows                                                                                               |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------- |
| **AP BSSID**                   | The access point's hardware address                                                                         |
| **Low RSSI Events**            | Samples on this access point that read below −70                                                            |
| **Total Call Min**             | Minutes of calling on this access point, from the sample count (samples × 5 seconds), to two decimal places |
| **Low RSSI Events / Call Min** | **Low RSSI Events** divided by **Total Call Min** (or by 1 when under a minute), to two decimal places      |
| (dot)                          | Green when **Low RSSI Events / Call Min** is under 4, orange from 4 up to 10, red at 10 or more             |

### Low RSSI Events by Device

The same columns for each handset, with **Device Serial** in place of **AP BSSID**. No dot.

## Icons and indicators

| Icon or indicator                       | Meaning                                                     | When it appears                       |
| --------------------------------------- | ----------------------------------------------------------- | ------------------------------------- |
| Blue line                               | **Events**                                                  | When there is data                    |
| Orange line                             | **Events / Call Min**                                       | When there is data                    |
| Green / orange / red dot on a by AP row | Under 4 / 4 to under 10 / 10 or more events per call minute | Every by AP row with a value to judge |

The shared icons are described on [Performance](/amie-advanced/using-the-platform/performance.md#icons-and-indicators).

## What to look for

* A red dot with a large **Total Call Min**. Handsets on that access point spend much of their call time on weak signal, and there is a lot of call time. Open [Access Points](/amie-advanced/using-the-platform/access-points.md) to find where it is; this is where a survey should start.
* A rate near **12.00** under **Low RSSI Events / Call Min**. Almost every sample was weak: the whole of the calling on that access point or handset was on poor signal.
* A large **Low RSSI Events** beside a low rate. The count grows with call volume; the rate does not. Sort by **Low RSSI Events / Call Min**, which is what the dot uses.
* A handset with a high rate across many access points. It is being carried into places without coverage. Its [Session Activity](/amie-advanced/using-the-platform/device-details/device-session-activity.md) **Network Connected** row shows which access point it was on, report by report.
* An access point with a high rate across many handsets. The access point's coverage is the problem, not the handsets. Compare it on [Long Handoff Summary](/amie-advanced/using-the-platform/performance/performance-long-handoff.md): slow handoffs (moves between access points during a call) at the same access point suggest a coverage boundary.
* **Total Call Min** that differs from the same column on [Call Performance Summary](/amie-advanced/using-the-platform/performance/performance-call-performance.md). Here it is derived from the number of samples, not from the calls themselves.
* Different figures from a colleague. Points are placed by when the sample was recorded, within the range cut in each person's browser time zone — see [Time and time zones](/amie-advanced/metrics-reference/time-and-time-zones.md).

## Metrics on this screen

* [Time and time zones](/amie-advanced/metrics-reference/time-and-time-zones.md)

## Related

* [Performance](/amie-advanced/using-the-platform/performance.md) — ranges, filters, tables and export
* [Long Handoff Summary](/amie-advanced/using-the-platform/performance/performance-long-handoff.md) — slow roaming on the same access points
* [Session Activity](/amie-advanced/using-the-platform/device-details/device-session-activity.md) — where a handset was, report by report
* [Access Points](/amie-advanced/using-the-platform/access-points.md) — where the access points in the by AP table are


---

# 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/using-the-platform/performance/performance-low-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.