The conflict
Both are P0, and they are about the same measurement.
REQ-DEM-020's AC: "RRC measurement and RRC reference at matched alpha give a composite response
equal to the raised cosine to within 1e-9, with zero ISI at symbol centres".
REQ-DEM-022a's AC: the cascade matches "to < 5e-6 RMS at ±64-symbol span, and to < 1e-3
RMS at the ±8-symbol default" — and says in as many words why:
Both qualifications are necessary. … truncation alone sets the achievable floor: ±8 sym →
5.4e-4, ±16 → 1.1e-4, ±32 → 1.1e-5, ±64 → 3.2e-6. A flat "1e-6" tolerance is unreachable at the
recommended default length and would fail a correct implementation.
1e-9 is three orders tighter still. REQ-DEM-020's figure cannot be met by any truncated filter,
and REQ-DEM-022a reads as having been written precisely to correct it — but it never says so, and
REQ-DEM-020 still carries the old number.
What I implemented
REQ-DEM-022a's tolerances govern, because they are the ones stated with a derivation and a
table of floors, and because the requirement that quotes them exists to settle exactly this. Measured
by this build, independently of the implementation (evidence/req-dem-022a/):
| span |
measured |
REQ-DEM-022a's quoted floor |
| ±8 |
5.40e-4 |
5.4e-4 |
| ±16 |
1.14e-4 |
1.1e-4 |
| ±32 |
1.08e-5 |
1.1e-5 |
| ±64 |
3.18e-6 |
3.2e-6 |
Reproducing the requirement's own floors to two digits is what says the two are talking about the
same quantity.
REQ-DEM-020's other clause is tested as written: zero ISI at symbol centres for a matched pair
(measured 7.1e-4 of the peak) against a mismatched pair (1.83e-2 — twenty-six times worse), so the
test discriminates rather than passing anything.
What you need to decide
Whether REQ-DEM-020's "to within 1e-9" should be corrected in the specification. If it should,
the edit is one number in one line, and tools/sync_issues.py will carry it into #133 — remembering
that editing a requirement moves every line after it and drifts ~200 issue bodies, so it wants doing
in a batch with any other spec corrections.
I have not edited the specification: the requirements register is the source and I would rather it
change deliberately than as a side effect of making a test pass.
Delivered with #133 and #139.
The conflict
Both are P0, and they are about the same measurement.
REQ-DEM-020's AC: "RRC measurement and RRC reference at matched alpha give a composite responseequal to the raised cosine to within 1e-9, with zero ISI at symbol centres".
REQ-DEM-022a's AC: the cascade matches "to < 5e-6 RMS at ±64-symbol span, and to < 1e-3RMS at the ±8-symbol default" — and says in as many words why:
1e-9 is three orders tighter still.
REQ-DEM-020's figure cannot be met by any truncated filter,and
REQ-DEM-022areads as having been written precisely to correct it — but it never says so, andREQ-DEM-020still carries the old number.What I implemented
REQ-DEM-022a's tolerances govern, because they are the ones stated with a derivation and atable of floors, and because the requirement that quotes them exists to settle exactly this. Measured
by this build, independently of the implementation (
evidence/req-dem-022a/):Reproducing the requirement's own floors to two digits is what says the two are talking about the
same quantity.
REQ-DEM-020's other clause is tested as written: zero ISI at symbol centres for a matched pair(measured 7.1e-4 of the peak) against a mismatched pair (1.83e-2 — twenty-six times worse), so the
test discriminates rather than passing anything.
What you need to decide
Whether
REQ-DEM-020's "to within 1e-9" should be corrected in the specification. If it should,the edit is one number in one line, and
tools/sync_issues.pywill carry it into #133 — rememberingthat editing a requirement moves every line after it and drifts ~200 issue bodies, so it wants doing
in a batch with any other spec corrections.
I have not edited the specification: the requirements register is the source and I would rather it
change deliberately than as a side effect of making a test pass.
Delivered with #133 and #139.