Skip to content

REQ-DEM-050 and REQ-DEM-053: two acceptance clauses that cannot both be met as written #433

Description

@TGoodhew

Found while closing #432. Both are small readings rather than defects, and both are implemented one
way with the alternative recorded here.

1. REQ-DEM-050: "leaves EVM unchanged to within 0.1 dB rather than degrading it"

The two halves of the criterion cannot both hold literally.

  • A regularisation strong enough to leave a clean signal untouched to 0.1 dB leaves the three
    impairment classes 2 to 6 dB above the unimpaired EVM, which fails the "within 1 dB" half.
  • One weak enough to correct them takes a clean signal a few decibels better than unimpaired,
    which fails the "unchanged" half.

Measured, with the equaliser as it now stands (loading 1e-6):

unimpaired:  0.028734 %rms with the equaliser off,  0.016377 with it on   (-4.9 dB)
tilt:        0.019479 %rms equalised   (-3.4 dB from unimpaired)
phase:       0.012451 %rms equalised   (-7.3 dB)
multipath:   0.025968 %rms equalised   (-0.9 dB)

Why a clean signal improves at all: "unimpaired" is not. The chain's own measurement and
reference filters are truncated and Tukey-tapered, and the residual intersymbol interference that
leaves is a linear channel like any other. An equaliser that finds and removes it is working
correctly, and the improvement is real rather than a flattering artefact — a separate test shows
that on a noise-limited signal with no channel to correct the equaliser moves EVM by only −0.30 dB
at 25 dB SNR, which is the 42 taps absorbing their share of 512 symbols of noise and no more.

Implemented: the criterion read as the prohibition it ends with — the equaliser must not
degrade a clean signal. The test asserts change < 0.1 dB rather than |change| < 0.1 dB.

The alternative is to say an equaliser must not alter a clean measurement at all, in which case
the "within 1 dB" clause needs relaxing or the chain's own residual ISI needs removing at source so
there is nothing left for the equaliser to find.

2. REQ-DEM-053: "matches the analytic response to within 0.5 dB across the occupied band"

Not achievable across the whole occupied band by any method that divides a modelled pulse back
out, which is what recovering the channel requires — the equaliser inverts the channel and the
composite pulse together, so the pulse has to be divided out to leave the channel.

Measured on the two-ray channel, error against the analytic response:

Frequency Measured Analytic Error
0–338 kHz 0.00 dB
371 kHz −3.69 −3.87 0.17
405 kHz −2.23 −2.71 0.48
439 kHz −0.39 −1.41 1.02
540 kHz 16.06 1.63 14.43
675 kHz (band edge) 51.95 2.92 49.04

The pulse divided out is the one this chain computes — truncated, tapered, normalised — and the one
in the signal is whatever the transmitter and the measurement filter actually made. They agree
closely where the pulse is flat and part company through its roll-off, and the division amplifies
the difference by exactly as much as the pulse has fallen. At the band edge the pulse is zero and
there is no signal there to have learnt the channel from at all.

Implemented: ChannelResponse.TrustedHalfWidthHz — the flat part of the pulse's spectrum, taken
as where its power is within one per cent of its peak, which for a raised cosine is its Nyquist flat
region exactly and needs no knowledge of the roll-off factor to find. For α = 0.35 that is
±336 kHz of a ±675 kHz occupied band, and across it the recovered response matches the analytic one
to 0.007 dB. The annotation on the trace says where the measurement stops and the extrapolation
begins, and a display should show that rather than drawing a confident line to the band edge.

The alternative is to read "the occupied band" as the Nyquist flat band, which is what has been
implemented, or to widen the tolerance for the roll-off — but no tolerance short of tens of decibels
covers the band edge, so the honest fix is the trusted-band annotation either way.

Refs #159, #165, #432.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    deferred:revisitClosed to keep the backlog at zero; revisit once the rest of the product is complete

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions