Problem
DSP code often begins as an isolated numerical prototype. For engineering use it needs deterministic behavior, edge-case tests, performance evidence, packaging and a clear path for later fixed-point or hardware mapping.
Engineering case studies
Three short examples of how I approach signal-processing work: define the problem, build a reference, implement it, measure the real system, and keep the limitations visible.
Case 1 • DSP → production-style C++
C++ DSP showcase: turning algorithms into testable, benchmarked and reusable software
FIRGoertzelGCC-PHATResampler
Algorithm → test → benchmark → package
No synthetic performance number is claimed here; benchmark tooling and validation evidence are linked below.
Approach
Implement compact C++17 DSP kernels behind a reusable API, protect behavior with deterministic unit tests, benchmark performance-sensitive paths, keep optional AVX2 acceleration explicit, and export an installable CMake package for downstream projects.
| Algorithms | FIR design/filtering, direct and FFT overlap-save convolution, Goertzel, GCC-PHAT delay estimation and rational L/M resampling. |
| Verification | Deterministic unit tests, generated benchmark reports, multi-platform CI, sanitizer checks and CodeQL. |
| Reuse | Installable CMake package export and documented downstream use through the public dsp_core::dsp target. |
| Limit | The repository is deliberately compact: it demonstrates engineering discipline around selected kernels rather than claiming to be a complete DSP framework. |
What this demonstrates for a client
I can move signal-processing logic into maintainable C++ without losing numerical traceability: implementation, tests, performance measurement, packaging and possible FPGA direction are treated as one engineering problem rather than separate tasks.
Case 2 • DSP → FPGA → RF measurement
Zynq QPSK modem: closing the loop from model to a two-board RF link
Problem
A communication-chain model is useful only if the same behavior can survive fixed-point choices, HDL integration, real clocks, RF impairments and measurement. The goal was to make that complete path observable rather than treating the FPGA as a black box.
Approach
Build the chain incrementally: reference DSP and fixed-point reasoning, deterministic RTL checks, Zynq/AD936x integration, controlled two-board RF tests, IQ capture, and quantitative BER/EVM/CFO evidence.
| Implementation | In-fabric BPSK/QPSK modem, synchronization and measurement workflow on independent Zynq-7020 + AD936x boards. |
| Verification | 5.6 million fabric-loopback bits with zero errors; HDL checks, machine-readable results, timing/resource reports and IQ metadata. |
| RF result | Two-board 915 MHz cabled QPSK link with the promoted differential receiver reporting payload BER around 4×10−4; additional retained external-QPSK sessions include 0/25,200 recovered-bit errors. |
| Limit | The public evidence is strong for reproducible engineering closure, but long-duration BER-floor characterization and broader attenuation sweeps remain separate measurement work. |
What this demonstrates for a client
I can connect algorithm design, fixed-point implementation, HDL/FPGA integration and real RF measurements under common acceptance criteria. The deliverable is not only RTL or a MATLAB model; it is a traceable engineering result with evidence and known limits.
Case 3 • LoRa PHY → hardware timing
LoRa on ZynqSDR: from recorded SX1262 IQ to live packet decoding and a continuous PL timebase
Problem
A positioning-capable LoRa receiver needs more than payload decoding. Packet detection, sample-grid alignment, timestamp definition and receiver state must be observable enough to explain timing errors before those errors are propagated into TDoA.
Approach
Maintain one traceable path from MATLAB floating-point reference through fixed-point Simulink, generated HDL and a routed ZynqSDR image. Capture raw IQ and PL trace data together so hardware misses and timing defects can be reproduced instead of guessed.
| Hardware RX | Real over-the-air Heltec V4.3/SX1262 packets decode on ZynqSDR with valid explicit header and payload CRC. |
| Long run | M9 hardware campaign: 492/492 captured packets passed CRC with zero detection misses in the 500-attempt series; combined with the overnight run, the evidence reaches 732/732 CRC-valid packets with zero misses. Failures outside the receiver are tracked separately. |
| M11 PER | FPGA SF7/BW125 packet-error-rate curves were measured across CR 4/5–4/8. For CR 4/5, the 10% PER SNR threshold was ≈−7.8 dB, compared with ≈−8.2 dB for the known-timing reference model. This is a conducted SNR sweep, not an absolute sensitivity measurement; see the experiment. |
| Timing | M9 publishes the joint CFO-free timestamp: series500 residual mean +0.001 sample, every residual within ±0.5 sample (sd 0.285). The continuous PL sample-time counter was also verified across 47 captures spanning 803.7 seconds. |
| Limit | Controlled cable-delay calibration, common-time synchronization across receivers and calibrated hardware multi-receiver TDoA are still open. |
What this demonstrates for a client
I can investigate a hardware DSP failure across the complete stack: model, RTL, timing, board image, acquisition tooling and measurement data. The workflow preserves failure evidence and distinguishes a hypothesis from a measured result — important for SDR, timing and localization R&D.
Have a similar engineering problem?
I am open to focused diagnostics, model/implementation audits, model-to-C++/RTL work and part-time R&D support in DSP, SDR, communications and FPGA-oriented projects.