The question
REQ-DEM-070 lists carrier offset among the format-specific metrics, and REQ-UI-053's label
set has a Carr Ofst row for it. REQ-DEM-065 separately defines frequency error as
the carrier frequency error relative to the analyser centre frequency, in Hz — equivalently the
frequency shift the analyser applied to achieve carrier lock
Under that definition the two are the same quantity, and filling both rows with it would put one
number in two places, which reads to a user like a fault.
What was implemented
A split that makes both rows carry information:
| Row |
Meaning |
Carr Ofst |
step 3's block-wide estimate alone — where raising the signal to its rotational symmetry found the carrier, before any decision-directed refinement |
Freq Err |
the total the chain applied: step 3's estimate plus everything step 8 accumulated |
The difference between them is then exactly what the decision-directed fit had to pull in, which is
the quantity REQ-DEM-036's lock tolerance is about — and the thing that says whether a measurement
was comfortably locked or barely.
Measured, with 12 kHz injected:
the block search found 11999.49 Hz
the total applied was 12000.00 Hz
so step 8 pulled in 0.52 Hz
What might be decided instead
- As implemented — coarse and total, with the gap between them meaningful.
- The same number in both rows, matching the reference product if that is what it shows. Then
Carr Ofst carries nothing Freq Err does not, but nobody is surprised by what it means.
- Leave
Carr Ofst as NAN and treat REQ-DEM-070's "carrier offset" as satisfied by
REQ-DEM-065. Honest, but a permanently blank row invites the question every time it is seen.
My recommendation is (1), on the grounds that a row should say something the row above it does not —
but it does depend on a reading of "carrier offset" that the requirement does not state, and if the
reference product means (2) then (2) is right and this is a surprise waiting for a user.
To unroll to (2) or (3): one computed.Add in ErrorMetricStep, and
FormatMetricTests.CarrierOffsetIsWhatTheBlockSearchFoundAndFrequencyErrorIsTheTotal.
Refs #186.
The question
REQ-DEM-070lists carrier offset among the format-specific metrics, andREQ-UI-053's labelset has a
Carr Ofstrow for it.REQ-DEM-065separately defines frequency error asUnder that definition the two are the same quantity, and filling both rows with it would put one
number in two places, which reads to a user like a fault.
What was implemented
A split that makes both rows carry information:
Carr OfstFreq ErrThe difference between them is then exactly what the decision-directed fit had to pull in, which is
the quantity
REQ-DEM-036's lock tolerance is about — and the thing that says whether a measurementwas comfortably locked or barely.
Measured, with 12 kHz injected:
What might be decided instead
Carr Ofstcarries nothingFreq Errdoes not, but nobody is surprised by what it means.Carr Ofstas NAN and treatREQ-DEM-070's "carrier offset" as satisfied byREQ-DEM-065. Honest, but a permanently blank row invites the question every time it is seen.My recommendation is (1), on the grounds that a row should say something the row above it does not —
but it does depend on a reading of "carrier offset" that the requirement does not state, and if the
reference product means (2) then (2) is right and this is a surprise waiting for a user.
To unroll to (2) or (3): one
computed.AddinErrorMetricStep, andFormatMetricTests.CarrierOffsetIsWhatTheBlockSearchFoundAndFrequencyErrorIsTheTotal.Refs #186.