Milestone map
Milestone map
3 milestones
Define the Signal Processing Problem and Select the Algorithm
1–2 weeks (3–4 hrs/week)
Identify a real or realistic signal processing problem: noise reduction in audio, ECG artefact removal, vibration analysis for a rotating machine, digital communications filter design, or image processing. Define the problem quantitatively: signal frequency content, noise spectrum, sampling rate, acceptable attenuation, and passband/stopband requirements. Evaluate ≥2 candidate algorithm approaches (FIR vs IIR filter, FFT-based analysis vs wavelet transform, etc.) and select the approach with documented justification. Signal processing is constraint-driven — an algorithm that meets the stopband attenuation but violates the latency requirement is the wrong algorithm.
Proof required
Submit your problem definition document (≥500 words): the signal processing problem, quantitative requirements (frequency, sampling rate, attenuation, latency, or equivalent), ≥2 candidate algorithms evaluated, and the selected algorithm with justification.
What gets checked
- Signal processing requirements are quantitative — frequency values in Hz, attenuation in dB, sampling rate in samples/second — not stated as 'remove noise'
- ≥2 candidate algorithms are evaluated against the requirements — not a free choice without comparison
- Selected algorithm justification addresses why it meets the constraints the alternatives do not
Common mistakes
- Problem definition without quantitative requirements — 'remove noise from an audio signal' is not a requirements specification; '−40 dB attenuation above 4 kHz, maximum 10 ms group delay, 44.1 kHz sampling rate' is
- Algorithm selection without a comparison — FIR vs IIR trade-offs (linear phase, stability, computational cost) must be argued, not assumed
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Confirm requirements are quantitative — frequency in Hz, attenuation in dB, sampling rate in samples/second.
- Confirm ≥2 algorithms are compared against the stated requirements — not a narrative preference.
- Confirm selected algorithm justification addresses the trade-offs against the alternatives.
Implement the Signal Processing Algorithm and Analyse Performance
3–4 weeks (4–5 hrs/week)
Implement the selected algorithm using Python (scipy.signal, numpy), MATLAB (free trial or Octave), or equivalent free tool. Apply it to a real signal (recorded audio, public ECG dataset, synthetic test signal with known characteristics). Generate performance plots: frequency response (magnitude and phase), time-domain input/output comparison, and spectral analysis (FFT). Measure the achieved attenuation or performance metric against the M1 requirement and report whether the requirement is met.
Proof required
Submit your implementation code (or script file) and performance analysis report (≥400 words) with: frequency response plot, time-domain before/after plot, FFT analysis, measured attenuation or performance metric, and comparison against the M1 requirement.
What gets checked
- Frequency response plot shows both magnitude (dB) and phase response — not just one of the two
- Measured performance metric is compared numerically against the M1 requirement — not just 'the filter works'
- Implementation is applied to a real or realistic signal, not just verified on a theoretical frequency response plot
Common mistakes
- Reporting only frequency response plots without testing on a real signal — frequency response is a design tool; the proof requires showing the algorithm working on actual input data
- Performance assessment without a number — 'the filter removes noise' is not a performance measurement; '−38.5 dB attenuation at 5 kHz against the −40 dB requirement (2.5% short — see section 4 for explanation)' is
Resources
Foundationstart here
Depthgo deeper
Masteryfor the dedicated
What a verifier looks for
- Confirm frequency response plot shows both magnitude and phase — flag if only one is shown.
- Confirm measured performance metric is compared numerically against the M1 requirement.
- Confirm algorithm is tested on a real or realistic signal, not only on theoretical plots.
Write the Signal Processing Report and Present Findings
2–3 weeks (2–3 hrs/week)
Write a complete signal processing report (1,500–2,500 words plus figures) covering: the problem definition and requirements, algorithm selection rationale, implementation approach, performance analysis results, comparison against requirements (met or not met with explanation), and recommendations for further optimisation or alternative approaches if the requirement is not fully met. Present the report to a reviewer with digital signal processing or electronics engineering experience and answer Q&A on the algorithm design choices and performance trade-offs.
Proof required
Submit your signal processing report (1,500–2,500 words plus figures) and review record: reviewer name, role, ≥3 challenge questions about algorithm selection or performance analysis, and your responses.
What gets checked
- Report includes a comparison against all M1 requirements — stated as met or not met with quantitative evidence
- If any requirement is not met, the report proposes a specific alternative approach with reasoning — not just 'further work needed'
- Reviewer has DSP, electronics engineering, or signal analysis experience and challenged the algorithm design or performance claims specifically
Common mistakes
- Reporting only what worked without discussing requirements that were not met — a design report that only presents successes is not credible; unmet requirements must be documented with an explanation
- Reviewer without DSP or engineering background — Q&A on FIR phase linearity trade-offs, IIR stability, or FFT windowing requires domain knowledge
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Engineering Design Triad check: M1–M3 together produce a design artifact (algorithm selection + implementation code), an analysis artifact (performance plots + requirement comparison), and a documentation artifact (signal processing report + review record) — confirm all three types are present.
- Confirm report compares against all M1 requirements with quantitative evidence — not just a general statement that the filter works.
- Confirm unmet requirements are documented with a proposed alternative approach.
- Confirm reviewer has DSP or electronics engineering experience — challenge questions must engage with algorithm design specifics.
- The Proof Accessibility Rule applies — scipy/numpy (free), GNU Octave (free), PhysioNet free datasets, DSPRelated free reference, and IEEE open-access articles are all accessible without commercial licence.