Signal Representation and dB Reporting on MDT-SIC

[Abraxas3d]

MDT-SIC Signal Representation and dB Reporting

Date: 9 May 2026
Session: Post-reorg bring-up verification (mdt_sic + haifuraiya partition split)
Hardware: iCE40UP5K-B-EVN + NUCLEO-H753ZI

The functional bring-up succeeded: SPI link between STM32 and FPGA is healthy, the
4-point FFT in the polyphase channelizer is producing mathematically correct output,
and the readout chain through UART/ST-Link/PuTTY is delivering frames cleanly. While
inspecting the data, two findings emerged that should be handled before the next phase
of development. The first is a localized firmware bug. The second is a deeper
architectural question that the MDT-SIC mission needs a decision on.

---

Finding 1: dB readout is not really working

The PuTTY output reports per-channel I, Q, magnitude, and a dB value. The dB column
shows the same value (-50.0 dB) across magnitudes that span more than an order of
magnitude:

Channel	Magnitude (LSBs)	Reported dB
CH0, frame 1	67	-50.0
CH0, frame 2	232	-50.0
CH0, frame 3	117	-50.0
CH1, frame 1	51	-50.0
CH3, frame 2	172	-50.0

I only have an MSEE, so I might be wrong, but when you have a 16-bit signed full scale
number, then that is equal to 32767, and these magnitudes correspond to expected
levels of roughly -54, -43, and -49 dBFS. The dB readout is collapsing an 11 dB range
into a single bin, when it definitely should not be doing that.
Zero-magnitude readings correctly report -99.9 dB, so the formatter
is not entirely broken because it can tell "it's there" and "it's not" but it is not
distinguishing among non-zero values in this regime.

Ideas worth investigating (all in the STM32 firmware, specifically the
magnitude-to-dB conversion code):

1. Floor saturation. A max(computed_dB, -50.0) clamp somewhere, intended for
   display sanity, that's eating real information.
2. Wrong reference. If 0 dB is referenced to something other than 16-bit full
   scale (maybe 8-bit got in there, or a higher-bit fixed-point value is coming along),
   the displayed dB values could be saturating against the formatter's print width or
   against an unintended floor.
3. Coarse log lookup. A small fixed-point lookup table that quantizes log₁₀ to a
   handful of bins, with this magnitude range happening to all land in the -50 dB bin.
4. Bit-stripping. If the conversion operates on only the top byte of a 16-bit
   magnitude, magnitudes below 256 LSBs would all map to the same bin (or to the
   noise-floor case). Happened over on pluto_msk and C++ modem.

Investigation: Print the raw magnitude and the computed dB.
Maybe actually look harder at the conversion code, single-step
a few values, and identify which of the four patterns matches.
If not, then try to derive the pattern from the spew.

This is not a blocker for the current bring-up but it is a blocker for any meaningful
work where SNR is important. SIC validation in particular will require measuring
"residual" interferer power after cancellation in dB, so this needs to
be metrically correct before weak-signal work begins for realsies.

---

Finding 2: Conjugate symmetry in the output indicates a real-valued input. I didn't actually finish the complex value work.

The 4-channel output shows a structural pattern that's worth being explicit about,
because it has implications for the architecture going forward:

Frame	CH1 (I, Q)	CH3 (I, Q)
1	(-34, -34)	(-34, 33)
2	(-115, -116)	(-115, 115)
3	(57, 58)	(57, -59)
4	(-24, -25)	(-24, 24)

CH1 and CH3 have the same real part and opposite imaginary parts, within +/-1 LSB of
quantization. CH0 has zero imaginary part. CH2 is at the noise floor.

This is the spectral signature of a real-valued input passing through a 4-point
DFT. For a real input x[n], the DFT bins obey X[N-k] = X[k]*. The N=4 case gives
X[3] = X[1]*, which is exactly what's observed. CH0 (the DC bin) is purely real,
CH2 (the Nyquist bin) is purely real, and CH1/CH3 are conjugate twins. I mean to do
complex, did this to get the display working, and then started working on something
else. This needs to be finished. We need complex signals for real weak signal work.

The fact that the math works correctly is not an accident. The FFT, the polyphase
filterbank, and the SPI readout all preserve the structure. The deeper question is
whether real-valued input is the right architecture for the MDT-SIC mission. It isn't.

---

The real-vs-complex question for weak-signal and SIC work

Real-valued sampling and complex (I/Q) sampling are not equivalent for the kinds of
problems MDT-SIC needs to solve. The differences matter most in exactly the regimes
the project cares about: low SNR, strong-interferer cancellation, and coherent
demodulation. We started out with real on Locutus, and transitioned to complex later on.
We should do the same thing here. For Haifuraiya, we start out with complex.

Independent channels

With N real samples taken at rate Fₛ, the usable spectrum runs 0 to Fₛ/2, and
the N-point DFT produces only N/2 + 1 independent bins — the rest are conjugate
mirrors. The 4-channel channelizer fed with real input therefore gives roughly two
or three independent frequency bins (DC, Fₛ/4, Fₛ/2), with CH1 and CH3 carrying
duplicate information.

With N complex samples at the same rate Fₛ, the usable spectrum runs from -Fₛ/2
to +Fₛ/2, and all N DFT bins are independent. The same 4-channel channelizer
gives genuinely four channels of resolution. I think that's justification enough.

Image rejection

A real-sampled receiver cannot distinguish positive from negative frequencies. An
interferer at +f₀ and an interferer at -f₀ (relative to the local oscillator) fold
onto the same bin and become indistinguishable. For a SIC receiver trying to
characterize and cancel a strong interferer, this is a fundamental limit: the cancel
estimate is corrupted by image-band content that the receiver cannot separately
identify.

Complex sampling, by contrast, separates +f₀ and -f₀ into different bins. I think that
the SIC algorithm sees the interferer cleanly without image contamination. Plus, we get
phase information preserved.

Coherent detection of weak signals

For the weakest signals the FunCube/MDT mission needs to handle, which are well below the
noise floor in a single sample, are recoverable only through coherent integration. The
matched filter requires knowing the carrier phase. Real-valued processing makes this
harder. Complex processing makes it easier.

Dynamic range

Two ADC streams at (I, Q) with the same bit depth as a single real stream double
the total information bandwidth into the FPGA. For SIC, where the strong interferer
may be 60+ dB above the desired signal, every bit of effective dynamic range matters.
Complex sampling effectively gives a √2 improvement in noise floor for the same ADC
bit depth, on top of the qualitative benefits above. While we may not use the original
very high resolution ADCs that Martin Ling baselined for the MDT-SIC prototype, we
really don't want to throw away any dynamic range with the wrong type of math.

DC and 1/f offsets

A direct-conversion (zero-IF) real receiver puts the signal of interest right at DC,
where the front-end's DC offset and 1/f noise are largest. A complex zero-IF
receiver still has the DC issue, but the signal can be placed off-DC at synthesis
time by mixing with a complex local oscillator, sidestepping the noise-floor
contamination that hurts a real architecture. We do this in Locutus.

---

Architectural implications

"Going complex" means that the changes are significant but they are manageable.

• Input path. Two real streams from the ADC (I and Q from a quadrature
  downconverter, or output of a digital Hilbert transformer) instead of one. Doubles
  the input bus width.
• Polyphase filterbank. Same topology, but each branch processes complex samples
  instead of real ones. Roughly 2× LUTs and 2× DSP block usage for the filtering
  stages.
• FFT. The 4-point FFT (fft_4pt.vhd) is already a complex DFT. It has complex
  inputs and complex outputs. The current build feeds it real I with Q = 0. Feeding
  it true complex input requires no FFT changes, just wiring up the Q path.
• Output. Each channel is already (I, Q) on the wire. Nothing changes downstream.
• SPI/STM32 side. No changes at the bus or formatter level. The per-channel
  format already carries I and Q.

The major cost is the filterbank doubling. Whether this fits on the iCE40UP5K depends
on what the current implementation is using and what budget remains. See the next
section.

---

Framing correction: iCE40UP5K is the deployment target

I was initially treating mdt_sic as a benchtop prototype that could hand off the
"real" complex work to the STM. That can't really happen.

• haifuraiya is another satellite project with a larger FPGA (ZCU102, Zynq UltraScale+),
  higher powered, generous resources, runs the 64-channel complex channelizer for downlink
  processing. Complex from day one.
• mdt_sic is the flight payload for FunCube+, and must run on something that fits the
  satellite power budget. AMSAT-UK will not fly anything more power-hungry than the
  iCE40 class. The iCE40UP5K is not a development convenience for mdt_sic, it is the
  deployment constraint. The STM co-processor is not an escape valve.

"Go complex" and "fit in iCE40UP5K" are therefore not alternatives. They are both hard
requirements. The dB formatter fix is the small piece. The complex conversion on this
device is the real engineering work the project needs to do from this point, towards
Friedrichshafen Milestone.

---

Resource utilization (sic_receiver_impl_1.mrp, May 9 2026 build, check this out)

Resource	Used	Available	%	Headroom
LUT4 sites	4,614	5,280	87%	666
Slice registers	2,499	5,280	47%	2,781
MAC16 (DSP)	4	8	50%	4
EBR (4 kbit blocks)	1	30	3%	29
SPRAM (32 kB blocks)	0	4	0%	4
IO sites	19	39	49%	20
PLLs	0	1	0%	1

LUT4 breakdown of the 4,614 used:

• 2,953 logic LUT4s (actual computation)
• 1,135 feedthru LUT4s (routing-only, no logic)
• 520 ripple logic LUT4s (arithmetic carry chains)
• 6 replicated

The 87% LUT figure is not the iCE40UP5K telling us "this is what complex SIC costs."
It is the current implementation telling us it isn't using the device well. The chip
has a substantial memory and multiplier subsystem sitting essentially idle while LUTs
do work that those blocks could absorb. The 1,135 feedthru LUTs (about 25% of total
LUT usage) is the router burning logic cells just to move signals around, mostly
because of the 256-deep shift-register delay lines fanning out across the fabric.
That is an implementation choice, not a device limit. A redesigned mdt_sic that uses
block RAM for delay lines, time-shares DSPs for complex multiplies, and lets the
iCE40's actual architecture do its job should fit complex 4-channel SIC processing in
a comparable or smaller LUT envelope than the current real 4-channel design.

---

Path to complex on iCE40UP5K

The redesign is a stack of moves, each measurable on synthesis, that together free up
the LUT budget for the complex doubling and the cancellation pipeline. Roughly in
order of Wonder Woman Lassos of Truth:

1. Move delay lines from registers/LUTs into EBR or SPRAM. Dominant current
   routing burden is the 256-deep shift registers per branch × 4 branches.
   EBR-backed delay lines clock-gate cleanly, eliminate the long fan-out nets, and
   let the router relax dramatically. For complex (I and Q paths), 2× storage is
   needed. It still fits in ~8 EBRs out of our 30. Estimated saving: 15–25% of current
   LUT use, before any complex doubling. This is also a power win because EBR clock
   gating is more aggressive than register clock gating. Win win paradigms!

2. DSP time-sharing for complex multiplies. Each complex multiply costs 3–4 real
   multiplies (3 with Karatsuba, 4 naive). Four complex multipliers × 4 real = 16
   real multiplies per sample period. With 8 MAC16 blocks running at a comfortable
   internal clock of 30–50 MHz and a 30 kSps complex sample rate, each MAC16 has
   hundreds of cycles between samples. 2–4 DSPs in time-multiplexed mode cover the
   full complex multiplier load. The DSPs absorb work the LUT-based multipliers are
   currently doing. Unless there's some lurking landmine.

3. FFT serialized through shared multipliers. The 4-point FFT has 8 multiplies in
   the full butterfly. At these sample rates one DSP serving them sequentially is
   fine, with intermediate state in registers. Eliminates whatever LUT footprint the
   current parallel multipliers in fft_4pt.vhd are using.

4. Reconsider filter tap count. 256 taps per branch is generous for 30 kHz total
   bandwidth across 4 channels. For a 4× decimating polyphase channelizer with
   ~7.5 kHz per channel, 64–128 taps per branch can give 60–80 dB stopband if the
   coefficient set is designed for it (Remez or windowed-sinc rather than a default
   sinc). Halving taps approximately halves per-branch storage and MAC throughput.
   Tradeoff: somewhat worse stopband attenuation. For amateur satellite passbands
   with controlled interferers, 60–80 dB might be plenty. But Martin wanted really good
   performance here.

5. Keep channel count at 4. With moves 1–4 unlocking resources, no need to cut
   channels. 4 complex channels covers +/-15 kHz around DC with ~7.5 kHz per channel,
   which is exactly the resolution the SIC use case wants.

Rough estimate: with moves 1 to 4 applied, complex 4-channel SIC fits in 60–75% of the
LUT budget. That leaves comfortable room for the cancellation pipeline itself, parameter estimator, re-modulator, subtractor, which is where the real SIC algorithm work lives.

---

Effort estimate

Phase	Estimate
dB formatter fix (firmware-only)	hours
Clean up unconnected fpga_rst_n top-level port	minutes
EBR-backed delay-line refactor of polyphase_filterbank.vhd	up to 2 weeks
Wire up Q-path through filterbank and into the FFT	up to a week
DSP time-sharing for complex multiplies	folded into above
Cancellation pipeline (estimator, re-modulator, subtractor)	a week??
Integration, on-hardware verification, sensitivity and residual measurement	1–2 weeks maybe more

Call it five to seven weeks of focused work for a flight-quality complex SIC payload
on iCE40UP5K. Each phase produces a measurable result on synthesis (the LUT count
should fall after the EBR refactor, then rise again with complex, but the final
number should be below the current 87%).

---

Recommendations and Plan

In execution order:

1. Fix the dB formatter (this session, before moving on). Print raw magnitude
   alongside computed dB, single-step a few values, identify which of the four bug
   patterns applies, fix it. Without metrically correct dB readout we cannot measure
   cancellation depth, so this gates everything later.

2. Clean up the fpga_rst_n warning (this session). The map report flagged
   Top module port 'fpga_rst_n' does not connect to anything twice. Either remove
   the port from the top-level entity or actually connect it. Cheap, and the design
   is fresh in our head right now.

3. EBR-backed delay-line refactor. Highest leverage, also the highest-risk
   change because it touches the filterbank's most timing-critical path. Do this as
   its own branch off main, synthesize after each major piece, watch LUT utilization
   come down. Back out if anything breaks.

4. Q-path wiring through the filterbank and FFT. With LUTs freed by step 3,
   wire in the Q path. The FFT entity needs no change, it is already complex
   internally.

5. DSP time-sharing. Convert the per-branch dedicated multipliers to a shared
   pool. Folds naturally into step 4.

6. Cancellation pipeline. New work on top of the now-complex channelizer.
   Parameter estimator (amplitude, frequency offset, phase) to re-modulator to
   subtractor. This is where the SIC algorithm actually lives.

7. Integration and characterization. Synthesize stimulus (known strong + known
   weak signal at known offsets), run through the pipeline, measure residual after
   cancellation in dB (which requires step 1 to be done), document sensitivity and
   dynamic range. This is the data that goes in the AMSAT-UK deliverable.

Two things to track as the work proceeds:

• Resource budget at each commit. Pull the .mrp numbers, log them. If LUT
  utilization starts climbing back toward 80% we want to know before place-and-route
  fails.
• Power. The iCE40UP5K is one of the lower-power FPGAs available, but the design
  topology affects power significantly. EBR-backed storage and DSP-based multipliers
  are both more power-efficient than the LUT-based equivalents. The redesign should
  be a net power win, not a wash.

---

Achievements

• Bring-up of post-reorg mdt_sic on iCE40UP5K-B-EVN + NUCLEO-H753ZI is complete
  and verified (MD5 match on flash readback, conjugate symmetry confirmed in
  channelizer output, SPI link working, stuff in puTTY).
• Last commits on origin/main: 0551644 (fft_64pt rdf cleanup), bd54035
  (generated VHDL deletion + gitignore patterns).
• Working tree should be clean! And it is!
• Next action: dB formatter investigation in
  mdt_sic/firmware/stm32/sic_receiver/Core/Src/sic_fpga.c (or wherever the dB
  conversion lives). After that, the fpga_rst_n cleanup in the top-level VHDL.
  After that, the EBR-delay-line refactor as the first redesign branch.

[Abraxas3d]

dB readout is fixed!

---
RAW: 00 FF 66 00 00 00 4B 00 4C FF FF 00 00 00 4B FF B3
CH0: I=  -154 Q=     0  Mag=  154  (-46.5 dB) [PEAK]
CH1: I=    75 Q=    76  Mag=  113  (-49.2 dB)
CH2: I=    -1 Q=     0  Mag=    1  (-90.3 dB)
CH3: I=    75 Q=   -77  Mag=  114  (-49.1 dB)
---
RAW: 00 00 0B 00 00 FF FA FF FA 00 00 00 00 FF FA 00 05
CH0: I=    11 Q=     0  Mag=   11  (-69.4 dB) [PEAK]
CH1: I=    -6 Q=    -6  Mag=    9  (-71.2 dB)
CH2: I=     0 Q=     0  Mag=    0  (-99.9 dB)
CH3: I=    -6 Q=     5  Mag=    8  (-72.2 dB)
---
RAW: 00 00 B0 00 00 FF A9 FF A8 00 01 00 00 FF A9 00 57
CH0: I=   176 Q=     0  Mag=  176  (-45.3 dB) [PEAK]
CH1: I=   -87 Q=   -88  Mag=  131  (-47.9 dB)
CH2: I=     1 Q=     0  Mag=    1  (-90.3 dB)
CH3: I=   -87 Q=    87  Mag=  130  (-48.0 dB)
---
RAW: 00 FF 52 00 00 00 55 00 56 FF FF 00 00 00 55 FF A9
CH0: I=  -174 Q=     0  Mag=  174  (-45.4 dB) [PEAK]
CH1: I=    85 Q=    86  Mag=  128  (-48.1 dB)
CH2: I=    -1 Q=     0  Mag=    1  (-90.3 dB)
CH3: I=    85 Q=   -87  Mag=  129  (-48.0 dB)
---
RAW: 00 FF F7 00 00 00 04 00 04 FF FF 00 00 00 04 FF FB
CH0: I=    -9 Q=     0  Mag=    9  (-71.2 dB) [PEAK]
CH1: I=     4 Q=     4  Mag=    6  (-74.7 dB)
CH2: I=    -1 Q=     0  Mag=    1  (-90.3 dB)
CH3: I=     4 Q=    -5  Mag=    7  (-73.4 dB)
---
RAW: 00 00 9C 00 00 FF B3 FF B2 00 00 00 00 FF B3 00 4D
CH0: I=   156 Q=     0  Mag=  156  (-46.4 dB) [PEAK]
CH1: I=   -77 Q=   -78  Mag=  116  (-49.0 dB)
CH2: I=     0 Q=     0  Mag=    0  (-99.9 dB)
CH3: I=   -77 Q=    77  Mag=  115  (-49.0 dB)
---
RAW: 00 FF 3E 00 00 00 5F 00 60 FF FE 00 00 00 5F FF 9F
CH0: I=  -194 Q=     0  Mag=  194  (-44.5 dB) [PEAK]
CH1: I=    95 Q=    96  Mag=  143  (-47.2 dB)
CH2: I=    -2 Q=     0  Mag=    2  (-84.2 dB)
CH3: I=    95 Q=   -97  Mag=  144  (-47.1 dB)
---
RAW: 00 FF E3 00 00 00 0D 00 0E FF FF 00 00 00 0D FF F1
CH0: I=   -29 Q=     0  Mag=   29  (-61.0 dB) [PEAK]
CH1: I=    13 Q=    14  Mag=   20  (-64.2 dB)
CH2: I=    -1 Q=     0  Mag=    1  (-90.3 dB)
CH3: I=    13 Q=   -15  Mag=   21  (-63.8 dB)
---
RAW: 00 00 88 00 00 FF BC FF BC 00 00 00 00 FF BC 00 43
CH0: I=   136 Q=     0  Mag=  136  (-47.6 dB) [PEAK]
CH1: I=   -68 Q=   -68  Mag=  102  (-50.1 dB)
CH2: I=     0 Q=     0  Mag=    0  (-99.9 dB)

[Abraxas3d]

Sweeping the bins with a carrier wave reveals:

The current polyphase_channelizer_top declares sample_im as an input port but never connects it to the filterbank (line 199: sample_in => sample_re). The FFT's imaginary input is hardcoded to zero (line 234-235). As a result, the channelizer cannot distinguish positive from negative frequencies. This was verified on hardware May 11 with the bin-sweep test pattern: freq_idx=1 (+Fs/4) and freq_idx=3 (-Fs/4) produce byte-identical 17-byte SPI frames.
Comment on line 186 acknowledges this: "This simplified version only processes the real part. A full implementation would have two filterbanks or interleaved processing." In other words, real signals only, but most of the design set up for complex.

Two architectural paths:

Dual filterbanks (parallel): instantiate polyphase_filterbank twice. ~2× resources. Likely doesn't fit iCE40UP5K without Move number 1 (EBR delay lines) first. Cleanest for Haifuraiya/ZCU102.

Time-shared filterbank (interleaved): single instance with input mux. ~1.2-1.5× resources. Half throughput. Probably fits iCE40 budget. Adds state machine complexity.

Plan: Move number 1 first (delay lines to EBR), then evaluate whether Option A fits. Fall back to Option B if iCE40 budget remains tight.

[Abraxas3d]

Delay lines moving to EBR: The DSP count works out exactly. iCE40UP5K has 8 DSP blocks, current design uses 4, dual-mode will use all 8. That's lucky. LUTs are a big big problem. Adding another filterbank's worth of LUT-resident delay lines on top of 87% utilization will overflow the chip for sure.

Which means for MDT specifically, Move number 1 must come before we double the filterbanks. Delay lines to EBR first should free up enough LUTS that the dual filterbanks fit.

• Move number 1 (EBR delay lines), independent improvement, fits today's budget cleanly
• Refactor coefficient loading out so we can have dual filterbanks without coefficient loading stupidity*
• Add second filterbank instance for Q path
• Reconnect FFT imaginary inputs to the second filterbank's outputs (currently disconnected, don't forget about that)
• Re-test with bin sweep and expect 4 distinct patterns, not 3

*Refactor coefficient loading out of the filterbank entirely is cleanest non-hacky way to get dual filterbanks for complex use. Move the LOAD_COEFFS FSM up into a separate coeff_loader entity at the top level. The filterbank becomes a pure data-path module. Basically we are going to have "given coefficients and samples, produce branch outputs, no startup state machine." Both filterbanks receive coefficients in parallel from the shared loader. This is the right architectural move long-term because the filterbank stops mixing data-path with one-shot init logic. We know this is the right idea people coming before us have found all of this out the hard way, and we want to continue to follow the Modem Module approach established by @mwishek

[Abraxas3d]

Move Number One Details

Here is what mac.vhd is doing right now:

-- Takes ALL samples in parallel as a wide vector
samples : in std_logic_vector(NUM_TAPS * DATA_WIDTH - 1 downto 0);

-- Unpacks them into an array
gen_unpack: for i in 0 to NUM_TAPS - 1 generate
    sample_arr(i) <= signed(samples((i + 1) * DATA_WIDTH - 1 downto i * DATA_WIDTH));
end generate;

-- Then immediately picks one per cycle via tap_idx
curr_sample <= sample_arr(to_integer(tap_idx));

That last line is actually a 16:1 multiplexer that runs combinatorially every cycle. The MAC is already doing sequential access. It just receives the whole array in parallel and throws away 15 of 16 each cycle. The current design pays both the storage cost (256 FFs) AND the routing cost (16:1 mux per cycle).

When we move to EBR, we get to eliminate both of these things. In terms of storage, EBR frees up a lot of FFs per branch. And the read port frees up the 16:1 mux. So, we might get back more than I thought. But the balance to this is that the interfaces of both delay_line and mac have to change. The "taps come out as a wide parallel vector" pattern cannot infer EBR, by definition (good to learn this BEFORE trying to deal with it, which is better than the BRAM port lessons over on pluto_msk). If all taps are visible simultaneously at the entity boundary, the storage must be in distributed FFs.

OK so what to do about this? Exactly what we do in pluto_msk in at least one place - we are going to set up a ring buffer. delay_line becomes a ring buffer with sequential reading.

entity delay_line is
    port (
        clk      : in  std_logic;
        reset    : in  std_logic;
        shift_en : in  std_logic;
        data_in  : in  std_logic_vector(DATA_WIDTH-1 downto 0);
        tap_idx  : in  std_logic_vector(clog2(DEPTH)-1 downto 0);  -- NEW
        tap_out  : out std_logic_vector(DATA_WIDTH-1 downto 0)     -- NEW: single sample
    );
end;

Internally: write pointer + register-array that LSE recognizes as block RAM. 1-cycle read latency. This is mandatory on both iCE40 EBR and Xilinx BRAM because there's no async-read block RAM on either platform. This doesn't hurt us.

mac becomes the driver of tap_idx

entity mac is
    port (
        clk      : in  std_logic;
        reset    : in  std_logic;
        start    : in  std_logic;
        done     : out std_logic;
        coeffs   : in  std_logic_vector(NUM_TAPS*COEFF_WIDTH-1 downto 0);
        tap_idx  : out std_logic_vector(...);          -- NEW: drives delay_line
        sample   : in  std_logic_vector(DATA_WIDTH-1 downto 0);  -- NEW: from delay_line.tap_out
        result   : out std_logic_vector(ACCUM_WIDTH-1 downto 0)
    );
end;

Internally, the MAC's state machine adds one cycle for pipeline fill at the start and one for drain at the end. Total MAC duration goes from NUM_TAPS cycles to NUM_TAPS + 1 cycles. At Fs=40 kHz on a 12 MHz clock, we have 300 cycles between samples and the MAC uses ~17 of them, so the extra cycle is invisible. This is a signals analysis circuit, so additional small delays are not harmful, and if someone wanted to use this design for communications, it wouldn't be too bad of additional latency.

fir_branch changes are minor. We need to just rewire the two children together.

u_delay_line ... port map (
    ...
    tap_idx  => mac_tap_idx,
    tap_out  => mac_sample
);

u_mac ... port map (
    ...
    tap_idx  => mac_tap_idx,
    sample   => mac_sample
);

Ok all of that is great. But guess what.

Coefficient storage. mac.vhd's coeffs input is also a wide parallel vector with sequential internal access Same pattern as samples. It is a 16:1 mux. If we leave it alone, we save EBR but spend LUTs on the coeff mux. So we can do the same thing backpropagating through the design.

Let's prove the theory with loading and then apply it to storage as soon as we can get it to work. There may be other problems in here and trickery.

[Abraxas3d]

Move number 1 (coefficient loading improvement) worked, and is in commit 5fb4acb.

Moving on to fix the coefficient storage, and then duplicate the polyphase channelizer for complex work.

[Abraxas3d]

ok that worked!

Duplicating the polyphase channelizer:

Only one file changes: polyphase_channelizer_top.vhd. The polyphase_filterbank entity is already general enough that we just instantiate it twice and feed each instance one side of the complex input. Both filterbanks share the single coeff_loader. Their outputs_valid signals will be cycle-synchronous (same clock, same reset, same sample_valid, identical state machines) so we trigger the FFT off either one.Deliberated file management strategy for overwriting existing dataDeliberated file management strategy for overwriting existing dataWhat changed in polyphase_channelizer_top.vhd

• Renamed fb_outputs to fb_re_outputs, fb_outputs_valid to fb_re_outputs_valid for symmetry.
• Added fb_im_outputs and fb_im_outputs_valid signals.
• New entity instance u_filterbank_im parallel to u_filterbank_re, identical generics, fed by sample_im instead of sample_re, sharing the same branch_coeffs_bus and coeffs_ready from the loader.
• The gen_fft_input generate block's imaginary slot now sources from fb_im_outputs instead of (others => '0').
• Block diagram and header rewritten to show both filterbanks.

Both filterbank instances see identical clock/reset/sample_valid/coefficients with identical FSMs, so they're cycle-synchronous and we trigger the FFT off fb_re_outputs_valid alone. Cross fingers!

[Abraxas3d]

Holy bitballs, it worked.

Complex channelizer up and running without breaking the LUT bank.

DSPs are now at the ceiling, as predicted. Each of the 4 branches × 2 filterbanks = 8 MAC16 blocks, exactly filling the iCE40UP5K. Any future change that wants a hardware multiplier will have to free DSPs by sharing, or move to a bigger part. Worth keeping in mind but no action needed today.

LUTs landed at 84%, which is basically the same pressure as the pre-Move number 1 baseline (87%) but with a functional doubling of capability. That's a huge win. FFs and EBRs both have headroom now. 🌞

[Abraxas3d]

No more DSP sharing (we don't have any more to spare)

On to cancellation!

FPGA: fixed-function, line-rate, embarrassingly-parallel DSP. Provides the complex signals in the channels we set up.

STM32: lower-rate, adaptive, branchy algorithms with software flexibility. This is where parameter estimation, cancellation taps, telemetry framing, decision logic happen. We're going to do the cancellation in here. Peak channel detection is already in there.

Thinking this through. Starting with a simple narrowband single-tap canceller is where I am going to start, because I have a chance at understanding it and testing it quickly. The peak-channel detection (is already there) leads to amplitude+phase estimation on the strong channel. We re-modulate that single complex coefficient into the time domain, and then we subtract it from the signal that we are holding in our hot little hands. This is the simplest thing that could work to prove that we can do it in the STM.

So there are some decisions at this point. Where does the subtraction take place? We don't really need SIC over on Haifuraiya. Or, do we? What if we have interference or jammers?

Post-channelizer, single channel (simplest). STM32 subtracts the synthesized interferer from the peak channel's IQ stream. Doesn't help adjacent-channel leakage. Cheapest path to a measurable cancellation number. Quick and simple.

Post-channelizer, all channels (better). STM32 synthesizes the interferer once and subtracts from all 4 channels using FFT-shifted versions of the reference. Still no FPGA work. Catches leakage. I think this is what I'm going to try next.

Pre-channelizer (best, future). Synthesized interferer fed back in the FPGA, subtracted from raw wideband samples before the channelizer runs. Requires FPGA-side subtractor and reference NCO. Much better dynamic range. I don't think there is any way to fit this into the MDT-SIC, but this might be what we do over on Haifuraiya, or what we do as an option for larger Lattice chips? Maybe? Just wanted to say all of this out loud.

[Abraxas3d]

Decision We should do the subtraction post-channelizer, and from all channels.

SPI Rates and Shape of the Data

OK I know that we're sampling at the correct rate on the FPGA, but might not be displaying the correct rate in the console. This is what is going on in main.c:

while (1)
{
if (sic_read_channels(&sic_drv, &channel_data, SIC_MAG_ALPHA_BETA) == 0) {
for (int ch = 0; ch < 4; ch++) {
printf("CH%d: ...\r\n", ...);
}
printf("---\r\n");
}
HAL_Delay(500); // <-- this
}

This is where our 2 Hz polled loop come from so that Putty actually shows us useful stuff.

The FPGA channelizer keeps producing output at 10 kHz (Fs/N channels = 40 kHz / 4). The output is sitting in some register inside the FPGA, and the STM just samples it whenever it gets around to asking. We're seeing about 1 of every 5000 channelizer outputs in PuTTY. This is totally ok. But now we are going to do more with the data than just show it off in the console output.

The SPI architecture in sic_read_iq is clean and straightforward. It is "send command, read 17 bytes of the current snapshot." There's no FIFO, no buffering on either side. Each SPI transaction returns whatever the FPGA happens to have in the channel output register at the moment the transaction lands. So the model is "the FPGA is a register that updates by itself, and the MCU samples it when it wants." There is nothing to remove or fix here. Which is good.

There are at least three ways to do the cancellation read.

Option 1 Faster polling (easiest). More passion! More energy! More passion! Replace HAL_Delay(500) with HAL_Delay(1), and stop printing per-iteration (move printf behind a gate like what we had to do for Interlocutor the other day). Loop rate becomes whatever the SPI transaction itself takes, which according to my notebook is about 136 μs at 1 MHz SCK plus HAL overhead, so realistically a few hundred Hz. That's well below the FPGA's 10 kHz rate but easily enough for an LMS with slowly-varying interference parameters to converge. But that's really not good enough for what we want. Plus remember Doppler?

Option 2 go pluto_msk and do DMA streaming. SPI in DMA mode with a "new data ready" signal from FPGA (could reuse FPGA_DONE semantics or add a new IO). Circular buffer in STM32 RAM, ISR or callback drains it. This is like the dual clock FIFOs in pluto_msk. Yes, those are AXIS but this is a Wendy's a Lattice. Sample-by-sample cancellation at the full 10 kHz rate.

Option 3 Burst capture (most "Flighty McFlightpants payload" shaped). FPGA would have to have a small EBR-backed circular buffer holding the last N channel outputs (we have 21 unused EBRs, plenty of room for, say, a 256-sample × 16-byte buffer, but who is counting). A new SPI command says "freeze the buffer and let me read it." STM32 reads N records in one big transaction, runs block-based cancellation on the burst, telemeters or stores the result if we are going to do multiple rounds of subtraction like WSJT does. This matches how flight payloads typically operate. Capture-on-command, process, downlink. If there isn't a burst-mode SPI driver that can be incorporated, out there, already, then we'll have to write one.

What to do?

For getting a measurable cancellation number on the bench at Silver Home quickly, Option 1 is really enough. Bump the polling rate, run an LMS in the main loop, watch the residual drop. The data shape happens to be ideal for block-based LMS even at low poll rates because the interference parameters are slow-moving. It would give a result for the "move a sine wave around" demo.

For the AMSAT-UK flight deliverable specifically, Option 3 is what we need to do. It's also what would be generally useful. "capture a snapshot of length L, process, return summary statistics." I just don't know much about the interface yet, so we're going to have to be defensive and rig up a way to be flexible about delivering the telemetry. Also, this method lets us pause the SIC if the STM has to do something else. I'm not sure what else, but maybe the main payload says "stop receiving" for some reason. We want to be able to do that.

Path 2 is for sample-by-sample real-time processing (low-latency closed-loop control). For a payload that takes snapshots and telemeters results, streaming might be overkill. But do we need streaming to deal with Doppler? Session identification? Everything is passing by us kind of fast, so now is the time to figure out what this stuff looks like and if the telemetry record is complete enough.

Code in sic_fpga.c is in good shape. The dB formatter fix really helps. The CORDIC stub in sic_mag_cordic was foresight. When we want or need to offload magnitude computation off the FPU (e.g., if the LMS is using FPU bandwidth), the H7B3's hardware CORDIC is ready to take over with a small fill-in. Worth flagging that as a low-priority follow-up if cancellation math ends up FPU-bound. It almost certainly won't, but I have been wrong before. Let's not start being right all the time now.

The bare printf("RAW: ...") block in sic_read_iq is great for debugging but needs to be turned off or handled better before cancellation.

For identification of communications streams that move with respect to Doppler, which approach is best? Are we doing anything dumb so far?

For identification of Doppler-shifting streams specifically, which is a different problem from terrestrial cancellation of a single known interferer, then the burst capture Option 3 is going to be the best answer. Polled and streaming can't get traction that the burst mode can.

Signals moving around are hard to track and characterize at the same time.

You need three things simultaneously (similar problem in MSK demodulation/decode):

• Fine frequency resolution to distinguish multiple streams that happen to share a channel (or to know how far off channel center a single stream actually is).

• Time evolution to watch each stream's frequency curve over a pass.

• Sub-channel precision if the Doppler range is larger than one channel. If a single stream walks across multiple channels during a pass then we need to follow it. We don't think this happens on a HEO/GEO Haifuraiya, if we don't try to do stuff at LEO altitudes. But that's different math. This is 70 cm LEO. So we need to ring out the numbers. But first why is burst going to help us?

A burst of N samples per channel, FFT'd on the STM32, gives all three of the things we need at once. With N=1024 channel-rate samples (this is 102 ms wall-clock time at the 10 kHz channel rate), we get FFT bin width of ~10 Hz inside each channel, which is comfortably finer than typical LEO Doppler rates. HA! Take that Aristotle! A 1024-point complex FFT on the H7B3 runs in around 60 μs in CMSIS-DSP, so the math overhead is negligible relative to telemetry cadence. Even at 1 Hz burst rate we are using like 0.04% of one CPU. It is starting to look like the STM might be grossly oversized, but I'm not thinking about that until the entire thing is working. It would be good if it was oversized because it pulls a lot more power than I think anyone was looking at. Everyone was worried about the ICE40 being the current consumer but it's really the STM I think.

OK then we stack bursts over time and the result is essentially a spectrogram. Not sure if we can show this in telemetry. Maybe with a simple webpage hosted by the STM or maybe even ASCII art or something like that.

Each Doppler-moving stream makes a curve in time-frequency, multiple streams become visually and algorithmically distinguishable, and the curvature of each track tells you something useful about the geometry (range rate, closest approach, etc.). We did a tiny bit of this in DEFCON Hack-a-Sat and I think I still have that MATLAB code laying around somewhere.

Why the other two don't cut it:

Option 1 (faster polling) undersamples within each channel by kind of a lot. Case closed. The phase tracking just doesn't happen fast enough to do anything.

Option 2 (DMA streaming) does give us full resolution at line rate, and it's the right answer for closed-loop cancellation of a single drifting interferer where you want sample-by-sample adaptation. But for identification we don't need every sample. We need bursts widely spaced enough to see Doppler evolution. Streaming is overkill data rate for the analysis we actually want to do, and the telemetry pipe back to ground is the real bottleneck for the AMSAT-UK use case.

If burst mode can be done fast enough then you get streaming.

What the implementation looks like

Before getting in there with the guts and innards...

The FPGA work is a BRAM (called EBR in Lattice-land) circular buffer holding N channel outputs, plus a "freeze and read" SPI command. Sizing N=1024 records × 16 bytes = 16 kbits = 4 EBRs. We have 21 free. I think this will work.

The STM32 work is a bit more involved.

Per-channel windowing (a Hann or Blackman window stored as constants) before FFT to keep sidelobes manageable. Standard GNU Radio trick. A 1024-point complex FFT per channel, four channels, =>~250 μs total per burst.

Peak-finding within each FFT, plus stream tracking across bursts (associate this burst's peaks with the previous burst's peaks based on frequency proximity and amplitude). Kind of sketchy on this part but we can rely on physics. This part changes if this is moved to another frequency band. We really do like being modular, but 70cm is the use case for MDT-SIC.

Stream state: each tracked stream keeps a short history of (timestamp, frequency, amplitude) tuples. That's the data structure that gets telemetered.

The stream-tracking "association" logic is new code, and it's not going to be very big. But, it needs its own test. This is the kind of thing where failures are only going to show up (losing a stream across bursts, or merging two streams that crossed) with realistic Doppler trajectories. And I'm not exactly sure yet how to simulate that? We have simple sine waves moving around instead of delivered 30 kHz of bandwidth right now. Maybe Python can create this? Help?

Doppler rate smearing double-check

If this was at, say EVE frequencies (2304 MHz), then peak LEO Doppler rate at zenith is ~50-100 Hz/sec. A 102 ms burst at that rate sees the signal drift by 5-10 Hz during the burst itself, which is about one FFT bin width.

Each burst's tracked-stream output is naturally a compact record rather than something like raw IQ, which the spacecraft can downlink at any reasonable rate.

For 70 cm (430 MHz or so) I think the Doppler won't be as bad. Both Doppler shift and Doppler rate scale linearly with carrier frequency, so 70 cm is roughly 5 times easier than S-band on both Doppler shift and rate.

Quick numbers for LEO at ~500 km altitude (v = 7.6 km/s, v/c = 2.5×10^-5). Worst case is the zenith pass. So let's see what happens there. It should be +/- 10 kHz peak shift worst case, and that means 150 Hz peak rate shift.

What that means for the burst architecture?? Doppler shift vs channel boundaries. With a 4-channel * 10 kHz channelizer, a signal at 70 cm crosses about one channel boundary during a worst-case pass. That's a single hand-off event to manage in the stream-tracking association logic.

150 Hz/s * 0.102 s is 15 Hz of drift per burst

Against about a10 Hz FFT bin width that's about 1.5 bins of smearing. This actually works as-is. But! We can also afford longer bursts at 70 cm if we want finer frequency resolution. A 4096-sample burst (~410 ms wall-clock) gives 2.4 Hz bin width with about 60 Hz of within-burst drift. Still under 25 bin widths and only a problem during the highest-rate part of a zenith pass. For most of a pass it's clean. That extra resolution is useful when multiple narrowband signals share a channel.

Burst-FFT works at 70 cm. Not sure if operational frequencies near the channel boundaries will totally behave. If a tracked signal happens to sit near 0 Hz, +/- 10 kHz, or +/- 20 kHz from the channelizer center (which depends on the LO choice), it'll spend a chunk of the pass straddling two channels and the stream-tracking logic will need to handle "this peak is showing up in CH1 and CH2 at half-amplitude in both, it's the same signal." A reasonable hint to the association logic is to use the within-channel sub-bin frequency to untangle when a stream sits at the high edge of CH1's frequency range and the low edge of CH2's, those are the same physical frequency and should be merged.

That needs to be a writeup but I'm going to stop here and see if all of this works.

I think we actually have 7.5 kHz channels. I just realized I gave us an unintentional upgrade. I'll go back and fix that ASAP, but everything scales the same.