Say how strongly each sensor is being heard, and how much of it arrives
Two numbers rather than one, because "how well is this sensor coming in" is two questions and they can disagree in a way that is worth seeing. The first is strength: how far the sensor's burst stood above the noise of the second it arrived in, in decibels, on every reading and in the log and the spreadsheet. The burst detector already worked this out and threw it away -- it is the ratio the per-burst threshold is set from -- so this is carrying a number through rather than measuring a new one. What it is not is a power at the aerial, and the docstring says so where somebody will read it. A dongle has no reference level and, with the tuner left on automatic, no fixed gain either; anything in dBm would be invention. A ratio of two amplitudes off the same receiver in the same second is the honest quantity, and it is enough for the three things anybody wants a signal reading for: comparing two sensors now, watching one over an evening, and pointing an aerial. A fixed --gain makes it comparable between runs as well, which the help now says. It is coloured red, amber or green, it is on the live display as well as the report, and it is kept on a narrow terminal when other columns are dropped -- because somebody moving a whip about while a number climbs is not doing it on a wide window, and that is the most useful thing this does. The second is the share of what a sensor sent that actually arrives, which comes out of the timing for nothing. These transmit on a fixed cycle, so the shortest wait ever seen between two of a sensor's messages is that cycle, and the average wait is the cycle divided by the fraction getting through: one over the other is the fraction, with no need to know the model or how often it is meant to speak. Read together they say more than either does alone. A strong signal with a low share is interference or a collision rather than distance. A weak signal at a hundred per cent is a sensor at the edge that is getting through anyway and is best left alone. The strongest of the three copies of a message is the one reported, not the first: they go out milliseconds apart and arrive at whatever the fading does to each. A reading with no strength -- an older log, a block with no measurable noise floor to be a ratio to -- leaves the last known figure alone rather than overwriting it with a zero. Full suite 2369 passed, checked against five deliberately broken builds including the one that reports decibels as a power ratio, which is off by a factor of two and looks entirely reasonable. Built as 2026-09-07_06. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016PsWPTweCT6pwxKngvVxcg
This commit is contained in:
parent
872eadac37
commit
03d3600ecc
10 changed files with 375 additions and 24 deletions
|
|
@ -1425,13 +1425,40 @@ failing. A transmitter running ten per cent fast is therefore read
|
|||
correctly and never noticed, which matters: these are unlocked and drift with
|
||||
the temperature, and an outdoor sensor in January is not the one that was on
|
||||
the fence in July.
|
||||
.SS How well each sensor is heard
|
||||
Three columns say so, and they answer different halves of the question.
|
||||
.TP
|
||||
.B signal
|
||||
How far the sensor's burst stood above the noise, in decibels, coloured red
|
||||
below 14, amber below 22 and green above. A ratio of two amplitudes off the
|
||||
same receiver in the same second and nothing more \[em] not a power at the
|
||||
aerial, which an RTL-SDR cannot give, having no reference level and, on
|
||||
automatic gain, no fixed gain either. What a ratio is good for is comparing
|
||||
one sensor with another, watching one over an evening, and pointing an aerial.
|
||||
Use a fixed
|
||||
.B \-\-gain
|
||||
if the figures are to be compared between one run and the next. It is on the
|
||||
live display as well, and kept there on a narrow terminal, because watching a
|
||||
number climb while moving a whip about is the most useful thing it does.
|
||||
.TP
|
||||
.B every
|
||||
The average wait between messages.
|
||||
.TP
|
||||
.B heard
|
||||
What share of what the sensor sent is arriving. These transmit on a fixed
|
||||
cycle, so the shortest wait ever seen between two of a sensor's messages is
|
||||
that cycle, and the average wait is the cycle divided by the share getting
|
||||
through; one over the other is the share, without needing to know the model or
|
||||
how often it is supposed to speak.
|
||||
.PP
|
||||
The two are worth reading together and can disagree usefully. A strong signal
|
||||
with a low share is interference or a collision rather than a range problem; a
|
||||
weak signal at a hundred per cent is a sensor at the edge that is getting
|
||||
through anyway.
|
||||
.SS Afterwards
|
||||
When the listening stops, two tables. The first is about reception \[em] who,
|
||||
how often, how well \[em] and is the one to look at when something is missing:
|
||||
these transmit on a fixed cycle, so a gap of thirty seconds from a sensor that
|
||||
sends every sixteen means half of them are being missed, and that is an aerial
|
||||
problem rather than a weather one. The second is the first, last, lowest and
|
||||
highest of everything each sensor reported.
|
||||
When the listening stops, two tables. The first is about reception and is the
|
||||
one to look at when something is missing. The second is the first, last,
|
||||
lowest and highest of everything each sensor reported.
|
||||
.PP
|
||||
There is no average, deliberately. These arrive every sixteen seconds when the
|
||||
sensor is in range and not at all when it is not, and rain and cold both
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue