EVV Mesh Neighbor Links
Analysis done —, using data from — to — (Central time). Built from CoreScope, MeshMapper and MeshMonitor. Refreshed automatically every Friday morning.
Packet paths show — pairs of EVV repeaters hearing each other, and — of them only one way. Top of the list below: —: —.
What needs attention
Who hears whom: repeater to repeater
Read across a row to see which repeaters that row's repeater hears. Every time a repeater relays another repeater's packet, it proves it heard that one directly. Color is the share of hours, among hours when both were on the air, in which that happened. A blank cell means no evidence, which can mean the pair really can't hear each other or that the traffic never reached an observer.
Repeater to repeater: links seen in packet paths
When a flood packet's path lists two repeaters back to back, the second heard the first. This shows which EVV-area pairs actually relay for each other and in which direction. A pair that carries little traffic can look weak here without being broken, and traffic that never reaches an observer is invisible.
Scroll or pinch to zoom, drag to pan. Hover a node to see only its links, or click it to keep them highlighted. Click a status below to hide or show it. Line color is how often the pair was used in hours when both were active. Arrows mark pairs seen in one direction only and point at the node that hears. Nodes on the same site (for example SIR1, SIR2 and SIR5) share a dot, and their links to each other are in the table. Only EVV-area nodes are shown.
Repeaters' own neighbor lists
Each repeater keeps a list of the repeaters whose hourly zero-hop adverts it hears, with SNR and time since last heard. This is the most direct answer to whether two repeaters hear each other. MeshMonitor can read it over the mesh, but only from repeaters it has a password for. So far it can read — of them.
Neighbor lists read from the repeaters
Read from the repeater through MeshMonitor remote admin. This is the repeater's own record of whose zero-hop adverts it hears.
| Repeater | Hears | SNR | Hours since heard | Read at |
|---|
Links to observers: hourly adverts heard by SIR5 and KC9EP
Each repeater sends a zero-hop advert every hour. Only nodes in direct range hear it, so this measures one RF link at a time. Only links that end at an observer (SIR5 or the two KC9EP observers) can be measured this way. Hours when the observer itself was offline are left out.
| Repeater | Heard by | Adverts heard | Median SNR | Worst 10% SNR | Miss after a miss | Status |
|---|
"Miss after a miss" is the chance the next advert is also lost once one is lost. Well above the plain miss rate means losses come in runs (fades or outages), not random collisions.
Hour by hour
One cell per expected advert. Gaps are hours the observer was not reporting.
Can we predict a miss?
Signal margin is the strongest predictor. Time of day matters only for links already near the edge.
SNR of the last advert heard vs. chance the next one arrives
All direct links pooled. Below about −3 dB, a link starts losing a third or more of its adverts.
Adverts heard by time of day
Marginal links (median SNR below 0 dB) against strong ones (5 dB or more), in 3-hour blocks, Central time.
Observer health
A deaf observer looks the same as a broken link, so check these first.
Noise floor reported by each observer
A real noise floor moves. A flat line at the radio's lowest value usually means the receiver stopped hearing.
How this was measured, and its limits
- Each weekly run covers the 7 days before it. Most repeaters moved to MeshCore in fall 2026, so these patterns are still early reads, not baselines. Findings come from fixed rules; a week whose data looks off is flagged at the top.
- Expected adverts are counted from each node's own schedule, using receive time because some node clocks jump.
- MeshMapper keeps one row per advert, naming one observer, plus a count. Where the count showed exactly which known listener was missing, that listener was filled in.
- "Used when both active" counts hours in which both nodes showed up somewhere in the data and the pair was used. Low values can mean the traffic took another route.
- Path hops are short hash prefixes. CoreScope's resolved paths were used where available, and MeshMapper hops were resolved to the nearest matching node only when the match was clear.