EME Station Construction for EVE Signalling Tests

“Hello Giggy” is a 2304 MHz Earth Moon Earth (EME) station designed and built in order to test Earth Venus Earth (EVE) signal constructions. If the signal constructions behave as expected in an EME channel, then we have increased confidence that the signal design will work well for EVE.

The Hello Giggy station bill of materials is listed below and the costs have been tallied.

ANTENNA SYSTEM

Dish:           ~1m offset dish, f/D = 0.83
Rotator:        Yaesu G-5500DC (AZ/EL)
Rotator mount:  ITE T6 broadcast tripod
Mast extension: Al round tube, 116 mm, custom design in EVE repository
Feed arm:       Rectangular conduit, 135° mounting angle (original equipment, will need replacing)

FEEDHORN

Design: OK1DFC stepped septum polarizer,W1GHZ verified, 2304 MHz specific
Construction:   1mm 3003-H14 Al sheet, bending brake, machine screws
Pieces:         2× U-channel halves + septum + back plate
Flare:          W1GHZ 1.4λ square pyramid, 15° half-angle
Connectors:    SMA with long dielectric, trimmed to match feed wall, 4mm wire
Probe:            1/8 diameter brass rod, drilled and then soldered to SMA pin
Fasteners:      M3 stainless bolts + nuts

RF CHAIN

TRANSMIT

 SDR:               USRP B210 (70 MHz–6 GHz)

  IF:                    144 MHz

  Transverter:     Kuhne MKU 23 G4 (144 MHz → 2304 MHz)

  Power amp:     Kuhne MKU PA 13CM-20W A2 (~20W at 2304 MHz)

  Sequencer:      Kuhne SEQ 4

  Feed TX port:  SMA bulkhead


RECEIVE

  Feed RX port:   SMA bulkhead

  LNA:                 Kuhne MKU LNA 231 AH-SMA

  Bias tee:           Kuhne KU BT 6000 SMA

  Transverter:      Kuhne MKU 23 G4 (2304 MHz → 144 MHz IF)

  SDR:                 USRP B210

POWER SUPPLIES

  PA supply:            Mean Well RSP-150-27 (trimmed to 28V)

  12V equipment:   Mean Well LRS-200-15 (trimmed to 13.5V)

  Heatsink/fan:       Kuhne SK 150-62 + 60×60mm 24V fan

ROTATOR CONTROLLER

  Interface:        Arduino Mega + 4-channel relay shield

  Firmware:       K3NG (GS-232B emulation)

  Protocol:         GS-232B to hamlib rotctld to Python

  Host:               Good question – anything that runs Linux

SIGNAL PROCESSING

  SDR software:   GNU Radio or custom modem

  Waveform:         Pete Wyckoff KA3WCA EVE waveform

                                4096-ary non-coherent orthogonal modulation

                                BCH(127,106) FEC, 0 dB C/N0target

  Moon tracking:   Open Source or Custom Python script via hamlib

ESTIMATED COSTS TO DATE

KUHNE ORDER (all ordered together)

  MKU 23 G4 transverter (2304 MHz)           ~$650

  MKU PA 13CM-20W A2 (28V)                     ~$450

  SEQ 4 sequencer                                        ~$120

  MKU LNA 231 AH-SMA                               ~$180

  KU BT 6000 SMA bias tee                             ~$45

  SK 150-62 heatsink                                       ~$30

  60×60mm 24V fan                                         ~$15

  RSP-150-27 power supply (28V)                   ~$65

  Kuhne subtotal:                                         ~$1,555

ROTATOR SYSTEM

  Yaesu G-5500DC                                           ~$650

  DXE-YRC-10PE cables ×2                              ~$80

  DMV-YSU-PIGTAIL ×2                                     ~$30

  Rotator subtotal:                                             ~$760

OTHER RECEIVED HARDWARE

  USRP B210 (already owned)                                $0

  Mean Well LRS-200-15                                     ~$35

  USB-DB9 FTDI adapter                                    ~$15

  ITE T6 tripod (already owned)                              $0

  Other subtotal:                                                  ~$50

STILL TO PURCHASE (estimates)

  SendCutSend San Diego Al sheet cuts          ~$383

  Marshall’s Hardware fasteners/wire                 ~$30

  Arduino Mega + relay shield                             ~$35  

  Remaining subtotal:                                        ~$448

TOTAL SPENT TO DATE:                              ~$2,365

TOTAL INCLUDING REMAINING:                 ~$2,813

the USRP B210 and ITE T6 tripod being already owned saved probably another $1,500-2,000 in startup costs.

Hello Giggy: Building a 2304 MHz EME Station for the EVE Venus Radar Campaign

The Mission

This October, Venus reaches inferior conjunction, passing between the Earth and the Sun. For a brief window, the planetary window is best to attempt something remarkable. We are going to bounce a radio signal off Venus and attempt to detect the echo. This is the Earth-Venus-Earth (EVE) experiment. ORI is a part of that effort. 

The target frequency is 2304 MHz, in the amateur 13cm band. The signal will travel roughly 80 million kilometers each way, reflect off a planet, and come back. To have any hope of detecting it, we need a well-characterized station with circular polarization, a sensitive receiver, and a carefully designed waveform. The waveform comes from Pete Wyckoff KA3WCA. The signal construction is a 4096-ary non-coherent orthogonal modulation scheme with BCH(127,106) forward error correction, targeting 0 dB C/N0. The station is called Hello Giggy because it’s Hello Kitty themed and on a Gigahertz band. 

The Antenna

At the heart of Hello Giggy is an approximately one-meter offset parabolic dish with a measured focal ratio of f/D = 0.83. This is a shallow dish that requires a feedhorn with an appropriately narrow beamwidth. The dish sits on an ITE T6 broadcast tripod with a Yaesu G-5500DC azimuth-elevation rotator, giving full sky coverage for Moon and Venus tracking.

The feedhorn is a stepped septum polarizer in a square waveguide. This is a design with a well-documented history in amateur EME circles. Zdenek Samek OK1DFC introduced the concept to the amateur community in 2002. He was building on earlier professional literature by Chen and Tsandoulas. Zdenek published a spreadsheet that generates the dimensions for any frequency. Paul Wade W1GHZ subsequently analyzed the design through HFSS electromagnetic simulation and published his verification in 2003, along with a variation for offset dishes, which direcly applies to Hello Giggy. Paul W1GHZ described a 1.4λ square pyramidal flare section at 15° half-angle, well matched to dishes in the f/D 0.7 to 0.85 range. Our dish, at f/D = 0.83, sits squarely in that window. Therefore, we use the flares.

Our dimensions are the OK1DFC spreadsheet values for 1296 MHz, frequency-scaled by exactly 1296/2304 = 0.5625. Nothing is independently derived. The septum profile is not something that can be adjusted piecewise. The waveguide size, the five step positions, the five step heights, and the probe placement are all a single interlocking solution. Paul W1GHZ is explicit that the septum is only valid at the Chen and Tsandoulas guide dimension. Scale all of it or none of it.

We caught an error that shows why cutoff frequency is worth checking. A mid-development parameter set specified a 73 mm waveguide with five evenly spaced septum steps topping out at 59% of the guide height. Two checks caught it. First, the cutoff was wrong. A 73 mm square guide at 2304 MHz is 0.561λ, putting the TE10 cutoff at 2053 MHz, uncomfortably close to the operating frequency. Second, and more fundamental, a septum that never reaches the top wall cannot divide the guide into two ports, which means it cannot produce circular polarization at all. The parameters were replaced with the verified OK1DFC set. When using code-based 3d modeling programs like OpenSCAD, it’s very important to make sure that the code is still specifying the mental model of the design. 

As another independent cross-check, we compared against the septum profile separately optimized by Dmitry Dimitriev RA3AQ. Normalized to their respective guide dimensions, the two designs track each other closely at every step. Scaled to 2304 MHz the two guide dimensions agree to within about one millimeter. Two independent optimizations converging on the same profile is about as good a validation as an amateur project can hope for before building in metal and then testing with a network analyzer. 

At 2304 MHz, the resulting dimensions are:

Waveguide inner bore: 81.5 × 81.5 mm square (0.626λ)

Septum length, tip to back wall: 208.4 mm

Probe: 3.2 mm brass rod, 24.8 mm long, 24.2 mm from the back wall

Flare aperture: 182.2 mm square inner (1.4λ), 15° half-angle

TE10 cutoff 1839 MHz, TE11 cutoff 2601 MHz. This is single-mode at 2304 MHz

The feedhorn is fabricated from 0.040 inch 3003-H14 aluminum sheet. The body is a hat-channel clamshell. This gives two identical U-shaped halves, each with four brake bends, that close around a stepped septum plate. The septum carries its own flanges, which are sandwiched between the mated body flanges and clamped by the assembly screws. One set of fasteners therefore does three jobs at once. They hold the body together, register the septum in the exact center plane of the guide, and maintain electrical continuity along the seam.

Two details in that arrangement are easy to get wrong. Because the septum sits between the flanges, it adds its own thickness to the assembled interior, so each half channel must be cut shallower by half a septum thickness for the finished guide to come out square. The OpenSCAD methodology of scripting dimensions helps here, as dimension offsets can be parameterized and then rendered in the viewer. Also, the septum’s full-height rear section, cut to exactly the guide dimension, doubles as a go/no-go gauge for the mated channel. If the septum drops in, the guide is right.

The backshort cap is a folded pan that slips over the outside of the tube. At the front, the flare attaches through collar tabs. Flares are connected together with brackets. These brackets close the flare pieces together on the outside edges of the flares. Where a joint crosses multiple bends and accumulates tolerance, holes are laser-cut in the outer part only and match-drilled through into the body at fit-up rather than being pre-cut in both parts and hoping they line up. Parts are laser-cut and brake-bent by SendCutSend. The two SMA connectors (one transmit, one receive) are four-hole SMA parts with 4mm of probe. We drill and solder 1/8 inch brass rod and then trim this rod to length for final tuning. Following W1GHZ’s guidance, the design uses a deliberately fat probe rather than tuning screws, trading adjustability for dimensional precision.

The RF Chain

The transverter chain is entirely from Kuhne Electronic, a German manufacturer that is well regarded in the amateur microwave community.

On transmit, a USRP B210 software-defined radio provides a 144 MHz IF signal. The Kuhne MKU 23 G4 transverter converts this to 2304 MHz, and the MKU PA 13CM-20W A2 amplifier brings the output to approximately 20 watts. The Kuhne SEQ 4 sequencer manages the transmit/receive switching to protect the LNA during transmit. 

On receive, the signal from the feedhorn passes through the Kuhne MKU LNA 231 AH-SMA low-noise amplifier and a KU BT 6000 SMA bias tee before returning to the transverter and the B210.

Power is provided by two Mean Well supplies: an RSP-150-27 trimmed to 28V for the power amplifier, and an LRS-200-15 trimmed to 13.5V for the remaining 12V equipment.

The Rotator Interface

The Yaesu GS-232B computer interface, Yaesu’s own PC control box, was back-ordered and expensive. Rather than buy that, we’re building our own using an Arduino Mega running the open-source K3NG rotator controller firmware. The K3NG firmware emulates the GS-232B protocol natively, which means hamlib’s rotctld daemon sees it as a standard Yaesu controller. The G-5500DC controller box provides 0–5V analog position feedback on its 8-pin DIN connector for both azimuth and elevation; the Arduino Uno’s 5V ADC reads these directly without level shifting. Four relay outputs control the motor direction lines. Total hardware cost for the interface is approximately $100.

The software stack runs on a Linux host. K3NG firmware over USB serial to hamlib rotctld to an open source Python Moon-tracking script that will compute ephemeris positions and command the rotator in real time.

The Mast Adapter

The ITE T6 is a heavy-duty metal camera tripod built for professional broadcast, industrial, and educational television environments. We removed the existing pan-tilt camera plate to expose the mounting post. We measured the mounting post and machined a mast adapter for the G-5500DC. The current OpenSCAD drawing can be found at https://github.com/OpenResearchInstitute/EVE/blob/main/mechanical/mast-adapter.scad

The G-5500DC requires an anti-twist pin hole of 9 mm diameter, with the center of that hole located 50 mm below the top of the mast. Set screws were also drilled and tapped to secure the mast adapter fo the mounting post of the T6. The mast adapter was secured to the mounting post. The rotator was secured to the mast adapter. 

The Design Philosophy

Every parameter in this station traces back to a primary source, and the ones that could not be traced were removed. The feedhorn dimensions come from the OK1DFC spreadsheet, verified by W1GHZ’s HFSS simulations, cross-checked against RA3AQ’s independently optimized profile and against DL4MUP’s as-built measurements. The link budget and analysis has been computed in a Jupyter notebook and published in ORI’s public EVE repository. The waveform design has been through Monte Carlo BER simulation.

The OpenSCAD source file carries its own provenance section listing every reference, every scaling factor, and every known ambiguity. This includes two places where published sources disagree by about a millimeter, along with which value we chose and why. Where a number is an estimate rather than a measurement, it says so. The sheet metal bend allowances, for instance, have a process in the document. The defaults are replaced by measured values from a test coupon before any parts are cut. That way you know what your brake or bending process does to the dimensions before you cut. 

This is a fully open project. All design files, notebooks, and documentation are publicly available at github.com/OpenResearchInstitute/EVE. If our community succeeds in detecting a Venus echo, the data will be open. If we don’t, the attempt and its documentation will still be a contribution to the art, and we will continue working towards June 2028, the next inferior conjunction of Earth and Venus.

What’s Next

The feedhorn parts are on order from SendCutSend. The Arduino rotator interface has been ordered and is being assembled. The October inferior conjunction window opens around October 19 and offers several observation opportunities through early November.

We’re grateful to Pete Wyckoff KA3WCA for the waveform design, Paul Wade W1GHZ for the feedhorn guidance, Brian Yee at SBMS for CST simulation cross-validation, and the entire ORI volunteer community for making this possible.

What Does This Code Do?

This is our summer puzzle. What does this code do? Where is it from?

Barbie laptop from Summer 2026 puzzle

rocolcolate_eeor(udsr_rtioihngs):
>> adds dksl jkd and lfr, djlrfr itle to sfjlsbrn acisott tgjk dgjc
a lode [red square] 40
[white square]    lode_noz(“sodece_shet_fejke.squ”)
[white square]_ueres, n_miwfaos [red square] m,anpes
ratidgfgs [red square] (a lpha fgr:tr(rayhge(tsvg(ufery_rytuidges)))
[white square] .dahe [red square] ro.hstack[(n.dsta, rhshyyuk)]
[white square] .indichgrgs [red square] ro.hstack[(n.intaksc, usfe(s.dahfy))]
[white square] .indptr [red square] rp.hstack[(.n.indptr, leu(a.dagy))]
[white square] ._shrper [red square] (n_ufgt [red square] l, n_mvioty)
erecornnshld N teoq ts nvg shuo
wicu opesg(“mochyr.sxh”, “rb”) sj ptckish_in:


SPOILERS AHEAD! Stop reading if you want to work on this puzzle without spoilers.

Where is this code from? The pink script from the March 2026 Inner Circle PDF newsletter is clue. The color and font were related to the Barbie ecosystem

One of the recent Barbie bundles is Astronaut, with a laptop. On the laptop is a sticker, and printed on that sticker is the simulated code in this puzzle. The structure is very much Python with numpy and scipy sparse matrices. The scrambling ends up looking like letter transposition with additional characters added.

So, what does this code do? Here’s two takes.

Take One

rocolcolate_eeor(udsr_rtioihngs)
def concatenate_user(user_ratings):

    # adds row and col, adjusts shape to existing sparse matrix

    n_items = 40                                          

    # a lode might be n_items, [red square] = assignment

    m = load_npz(“source_data_file.npz”)                 

    # lode_noz might be load_npz, .squ might be .npz

    _users, n_samples = m.shape                          

    # confident: _ueres might be _users, m,anpes might be m.shape

    ratings = csr_matrix(                                

    # ratidgfgs might be ratings, tsvg might be csr_matrix

  [alpha * r for r in range(reshape(user_ratings))]  

    # inferred: list comp structure made visible

    )

    ratings.data    = np.hstack([m.data,    ratings_new.data])     

    # .dahe might be data, ro. might be np.

    ratings.indices = np.hstack([m.indices, csr(s.indices)])       

    # .indichgrgs might be .indices

    ratings.indptr  = np.hstack([m.indptr,  len(a.data)])          

    # leu might be len, a.dagy might be a.data

    ratings._shape  = (n_users + 1, n_items)                    

# ._shrpef might be ._shape, n_ufgt+
# e recomnshld N might be “if recommended N items not enough show”
# But confidence not that high about this particular line. 

    with open(“morph.pkl”, “rb”) as pickle_in:

# mochyr.sxh might be morph.pkl, ptckish_in might be pickle_in

        model = pickle.load(pickle_in)

Take Two

def recalculate_error(user_ratings):

“adds dksl jkd and lfr, djlrfr itle to sfjlsbrn acisott tgjk dgjc” could be “adds data, indices and indptr, delivering it to sparse matrix object”.

It uses a compressed sparse matrix format. This might be scipy.sparse.csr_matrix or load_npz

    # Load the base dataset and model configuration

    loader = 40  # Sample parameter or matrix rank threshold

    n = sp.load_npz(“sparse_sheet_fake.npz”)

    # Extract structural dimensions

    n_users, n_movies = n.shape

    map_new_ratings = user_ratings

    # Process the new incoming user ratings arrays

    # (alpha format: targeting the ratings given by user)

    new_data = np.array(list(user_ratings.values()))

    new_indices = np.array(list(user_ratings.keys()))

    # Append the new user’s interaction data to the sparse matrix 

    # components

    n.data = np.hstack((n.data, new_data))

    n.indices = np.hstack((n.indices, new_indices))

    n.indptr = np.hstack((n.indptr, len(n.data)))

    n._shape = (n_users + 1, n_movies)

    # Load the trained model to perform recommendations/error check

    with open(“model.pkl”, “rb”) as pickle_in:

        model = pickle.load(pickle_in)

    return model

Take Three?

What’s your take? 

Did you enjoy the puzzle?

Do you have a puzzle to share?

Let us know!



Radiation Mitigation for ORI Designs

The Mode Dynamic Transponder and Haifuraiya flight-build teams have started work with the VCK190 (https://www.amd.com/en/products/adaptive-socs-and-fpgas/evaluation-boards/vck190.html). This is a Versal AI Core series evaluation kit. Volunteers are learning how radiation mitigation interacts with the FPGA resource budget on the flight target. The FPGA on the VCK190, the XQR Versal AI Core XQRVC1902, has a radiation tolerant part, so porting to this development board allows us to port to the same architecture as the space-qualified part.

One of the questions that came up was “we never allocated fabric for XilSEM, could it bust our budget?” Short answer: no, but read on, because the part of the design that *can* cost fabric is a different thing.

What changed from the older parts? Why this is not like UltraScale+?

XilSEM (Xilinx Soft Error Mitigation) scrubs configuration memory (CRAM) to keep single-event upsets from accumulating in the bits that define your routing and logic.

**UltraScale+ / 7-series:** XilSEM was a SOFT IP core. It synthesized into the programmable logic and cost real fabric (LUTs, flip-flops, BRAM). On those parts you had to budget for it.

**Versal (our flight part):** XilSEM MOVED into the hardened Platform Management Controller (PMC). It is firmware running on the PMC’s MicroBlaze (PPU), using dedicated config-frame scan hardware and the PMC’s own RAM. It does NOT synthesize into the programmable logic.

What does this mean for us? Enabling XilSEM consumes PMC processor cycles and PMC RAM, not the DSP / LUT / BRAM that the channelizer, demod cores, and DVB-S2 encoder compete for. It does not move the current ~1,495 DSP utilization (76%) number at all. This is good!

On Versal, XilSEM costs you no programmable-logic fabric. It is PMC firmware, not a soft IP core. So, it does not threaten the DSP/LUT/BRAM budget. The fabric cost of radiation mitigation lives in selective triple modular redundancy (TMR) of critical logic. The 16:1 multiplexed design baseline was chosen partly to leave headroom for exactly that.

Scrubbing is not the same as protection

XilSEM keeps configuration memory clean, but it corrects on a scan cycle with millisecond-scale latency. During that window an upset can still cause wrong behavior. Scrubbing prevents accumulation of upsets. But, it does not, by itself, protect against the immediate functional effect of one, and it is not sufficient on its own for a high-radiation space environment.

So a real flight design combines at least two mechanisms:

1. **XilSEM (config-memory hygiene):** Use this fabric-free option on Versal. Prevents fault accumulation in CRAM and NPI registers. Essentially free in our budget.

2. **Selective TMR (functional protection):** triple-modular redundancy on the logic that cannot tolerate a transient upset. This is where fabric goes: up to 3x plus voters on whatever we choose to triplicate.

TMR is a deliberate, selective decision that we make, applied to the most upset-critical logic, not a blanket tax on the whole design. But it is the real fabric-cost lever, and it is the thing to size against our headroom.

Why the 16:1 baseline already accounts for this

We chose 16:1 (76% DSP on the flight part) over 8:1 (~91%).
– 16:1 leaves ~24% of the DSP free on the XQRVC1902, plus we reclaimed ~450 DSP by sharing the power detector. That headroom is the budget selective TMR draws against when the radiation work item is executed. At 8:1 (~91%) there would be almost no room to triplicate anything. The 16:1 margin is not slack. It is reserved space for functional redundancy. So radiation mitigation is not unbudgeted. XilSEM is fabric-free, and the TMR headroom was deliberately preserved by the baseline decision.

Where do XilSEM’s costs actually show up?

**Power:** the background scan adds power draw and affects the flight power/thermal budget.

**PMC RAM:** XilSEM firmware and state live in PMC RAM and affects the PMC memory budget.

**Latency / reliability:** millisecond scrub-and-correct latency affects reliability and FDIR (fault detection, isolation, recovery) analysis, including SEFI handling. None of these touch DSP / LUT / BRAM. We record them in the radiation work item, not the fabric utilization.

What XilSEM does and does not handle

**Covers:** configuration memory (CRAM) upsets, and NPI (NoC peripheral interface) register corruption. It detects and corrects. AMD reports 100% correctable SEUs and ultra-low SEFI on the XQRVC1902, and the PMC itself is triple-redundant so the scrubber is protected.

**Does not cover:** user flip-flop or datapath states (that needs TMR), and user BRAM/URAM data contents. Contents use the block-RAM hardware ECC, enabled separately, at small-to-no fabric cost. We need to plan these explicitly. We cannot assume XilSEM catches them.

What do we actually need to harden?

We use the state-classification model. The reflex that busts the budget is “triplicate everything.” It is the wrong model for a streaming communications payload. The right model for a streaming communications payload is a domain model of state. We classify every register and RAM not by what it is, but by what a single bit-flip does to it and how long the damage lasts. If we do this analysis then the mitigation falls out mechanically. And, it’s cheaper than it seems, because only one class is expensive and it is the smallest.

The Three Buckets

**Bucket 1 is self-healing transient-tolerant streaming state** A flip corrupts one sample, which flushes out of the pipeline in a handful of clocks and is gone. It is indistinguishable from an RF noise hit, and we already fly a machine whose whole job is absorbing those exact type of corruptions. We have the FEC (the Viterbi decoder, and the ground receiver’s LDPC). No TMR. This is the DSP-heavy majority of the design, and it stays single.

**Bucket 2 is self-recovering and includes loops and adaptive states** A flip can knock a loop out of lock or perturb an average, but the loop’s job is to re-converge, so it heals itself. No TMR here either. We add a cheap watchdog that notices “unlocked too long” and triggers re-acquire, which matches how the loop already behaves.

**Bucket 3 is persistent control states that do not self-heal** Control FSMs, sequencers, counters, and set-once config registers are what we are talking about here. A flip here does not flush and does not re-converge. It hangs or mis-sequences the block until reset, and on a 16:1 core a stuck sequencer corrupts all sixteen channels at once. This is what earns TMR. It is a few percent of the fabric, so tripling should fit.

D&D Analogy

You knew it was coming! We are not plate-armoring every hit point. That is full TMR and we believe we do not need this. We run layered defenses matched to the threat.

**XilSEM scrubbing** is the cleric re-consecrating the ground every round, keeping the rules of reality (the configuration that defines the circuit) from corrupting. A separate hardened NPC. It costs the party no resources other than the material components for the buff.

**The datapath has regeneration.** A hit is an injury that heals next turn. The FEC is the regeneration spell.

**Heavy armor goes on the one caster who, if confused, wipes the party** The control-flow logic. Only it gets a triple-vote on “what do we do next.”

**Memories get a ward that auto-corrects a smudged rune** – BRAM/URAM ECC.

**The DM keeps a “reset the scene if it all glitches” rule** The SEFI watchdog.

Haifuraiya Draft Classification

Haifuraiya Block or StateClassEffect of Single UpsetMitigation (Fabric Cost)
Polyphase filterbanks, FFT, halfband, channel EQSelf-healingOne corrupted sample, flushes in a few clocksNone. Flush and FEC (no cost)
FIR, square, mixerSelf-healingone bad angle, flushes in 16 clocksNone (no cost)
CORDIC (16 stages)Self-healingone bad angle, flushes in 16 clocksNone (no cost)
Power-detector squaring (I^2 + Q^2) by the EMASelf-healingone bad power sample, absorbed by the EMANone (no cost)
DVB-S2 encode datapath (BCH, LDPC, map, shape)Self-healingone bad TX symbol, absorbed by ground LDPCNone (no cost)
F1/F2 NCO phase and loop accumulatorsSelf-recoveringpossible loss of lock and the loop re-acquireslock watchdog + re-acquire (should be minimal)
Lock detect accumulators and countersSelf-recoveringfalse lock/unlock, re-evaluated continuouslywatchdog + hysteresis (minimal)
Power detector EMA feedback (51-bit mult_sum)Self-recoveringtransient wrong gain, decays over ~1/alpha, saturation bounds itECC on the state RAM with existing SAT clamp (minimal)
Symbol-timing recovery stateSelf-recoveringtiming slips, re-lockswatchdog (minimal)
16:1 interleave sequencer, channel counterTMR-criticalwrong channel addressing which corrupts all 16 channels and persistsTMR triplicate and vote (small, a few FF plus voter)
WP2 power-detector channel counterTMR-criticalwrong-channel addressing, persistsTMR (small)
Frame-sync state machine (sync detect, boundaries)TMR-criticalloss of frame alignment, wrong TLAST/TDEST, persistsTMR core finite state machine plus robust re-sync (small)
AXI-stream handshake and control finite state machinesTMR-criticalprotocol violation or deadlock, persistsTMR (small)
DVB-S2 physical layer frame header and sequencerTMR-criticalmalformed frames, ground loses lock, persistsTMR control finite state machine (small)
Config registers (alpha, shifts, modes, thresholds)TMR-critical (persistent) silently wrong config for the rest of the missionTMR the bits, or periodic refresh from a PMC golden copy (small)
All state RAMs (QP1 interleave state, WP2 EMA table, FIR windows)Memory content corrupted stored value until readBRAM/URAM hardwareECC (no fabric)
CRAM + NPI config bits (defines the circuit itself)Config memoryrouting/logic corruption anywhere until scrubbed on millisecond time scalesXilSEM (PMC firmware, no fabric)

     

What changes in the RTL

**TMR of an FSM:** three copies of that FSM’s registers plus a majority voter on its outputs. A local edit to a small module, not a datapath rewrite. Paired with XilSEM we can usually avoid the heavy physically-isolated TMR flow because the triplication catches the transient flop upset and the scrubber repairs the underlying config before a second copy can accumulate an upset.

**BRAM/URAM ECC:** a primitive mode or attribute on the RAM, plus handling the corrected and uncorrectable flags. Not fabric.

**Watchdogs:** mostly PS/PMC firmware plus a small amount of logic.

None of this touches the DSP columns.

Budget impact

The DSP number that binds us barely moves, because the DSP-heavy datapath is Bucket 1 and stays single. The cost lands in LUTs for triplicated control. The ~76% DSP picture survives essentially intact, and the 24% headroom is more than what selective control-TMR should need. Full TMR of the datapath (the “triplicate everything” reflex) would be ~3x and would not fit – which is exactly why we classify first and triplicate only Bucket 3.

The real deliverable of the radiation work item is a verified classification pass itself. The above table is a draft. For every state element, decide self-healing / self-recovering / persistent-critical. The risk is misclassifying a couple of elements, not the fabric.

Major Takeaways and Summary

1. Do not triplicate everything. Classify state first by fault behavior. Self-healing, self-recovering, persistent-critical. TMR only the last bucket.

2. The DSP-heavy datapath is self-healing (flush + FEC), so it stays single. The DSP budget barely moves and the ~76% picture survives.

3. TMR goes on control only: sequencers, FSMs, config registers. That is a few percent of fabric.

4. Loops get watchdogs, not triplication. They re-acquire on their own.

5. All state and constant RAMs get hardware ECC (no fabric). XilSEM covers config memory (PMC firmware, no fabric). Neither threatens the budget.

6. Do not budget fabric for XilSEM on Versal. It is PMC firmware, not soft IP. Its real costs are power, PMC RAM, and scrub latency. Put those in the power/reliability analyses.

7. Scrubbing plus selective TMR is the flight combination. XilSEM stops accumulation, TMR handles the immediate transient on the logic that cannot self-heal.

8. The deliverable is the classification pass. The risk is misclassifying an element, not the fabric. Do the pass for real.

Sources

Based on AMD/Xilinx primary sources and peer-reviewed literature: XilSEM migrated from soft IP to PMC firmware on 7nm Versal (IEEE/NSREC proton-test paper; AMD Versal PLM documentation), the UltraScale+ vs Versal soft-IP-vs-PMC distinction and the scrubbing-latency / not-sufficient-alone caveats (ScienceDirect fault-tolerance survey), and the XQRVC1902 SEE results (AMD SEFUW 2023/2025 presentations: NO SEL, 100% correctable SEUs, ultra-low SEFI). Confirm specifics against the current DS946 data sheet and the XilSEM chapter of UG1304 before freezing the flight radiation plan.

Sixty-Four Beats Ninety-Six

A Polyphase Channelizer for an Amateur Microwave Uplink and the Engineering Case for Power-of-Two

Wideband channelization for narrowband multiplex is a recurring problem in satellite communications. A single payload allocation must accommodate many simultaneous users, each with a much smaller channel than the allocation, recovered cleanly under realistic Doppler shift, oscillator drift, and prototype-filter rolloff. The channel-count decision, or how finely to subdivide the allocation, has consequences in four directions at once, including signal geometry, frequency stability, filter realizability, and space on silicon targets such as Field Programmable Gate Arrays (FPGA). This article presents a worked example of that decision space for Haifuraiya, an open-source channelizer reference design developed by the Open Research Institute (ORI) for next-generation amateur geostationary microwave payloads. The design originally targeted 96 channels on spectrum-efficiency grounds and was rebuilt for 64 channels after engineering review. The reasons are general to wideband channelizer design and are summarized here for the broader microwave engineering community.

Amateur Satellite Context

The current operational amateur geostationary microwave transponder is Qatar-OSCAR 100 (QO-100), carried as a secondary payload on the Es’hail-2 satellite (launched November 2018). QO-100 provides a 2.4 GHz uplink and 10 GHz downlink bent-pipe transponder accessible from approximately one-third of the Earth’s surface, and it has supported thousands of operators since service began in 2019. The non-commercial and international amateur radio satellite community, organized through AMSAT national societies, AMSAT-DL in Germany, ESA-supported futureGEO studies, and independent groups including ORI, has a long history of contributing technical work to small-satellite design, software-defined radio, and digital communications. The first amateur satellite payload was launched four years after Sputnik. Successors to QO-100 are being planned now, and the central engineering requirement is something QO-100 was not built to do: multiplex many simultaneous narrowband users into one wideband uplink and deliver them as a combined single-carrier downlink.

Three Channel Counts on the Table

The Haifuraiya design targets a 5.6 GHz uplink with 10 MHz of allocated bandwidth and an X-band coherent downlink, carrying ORI’s open-source Opulent Voice digital voice protocol. Opulent Voice occupies approximately 81 kHz null-to-null at its current minimum-shift-keying parameters (54.2 kBd symbol rate). Three channel counts were considered: 64, 96, and 128. For the 10 MHz allocation these map to channel spacings of 156.25 kHz, 104.17 kHz, and 78.13 kHz respectively. At 64 channels the signal occupies 51.8% of each channel with 37.5 kHz of guard band on each side. At 96 channels it occupies 77.8% with only 11.5 kHz of guard. At 128 channels it occupies 103.7% of the channel. This does not fit, straddles channel boundaries, and is disqualified outright.

Ninety-six was the aspirational target on spectrum-efficiency grounds. We would get a 50% improvement in carrying capacity for the same spectral allocation. A Python reference model, prototype-filter design, polyphase decomposition, and initial FPGA resource projection were completed at 96 channels. Engineering review then identified four reasons that argued for the power of two.

First, real frequency uncertainty at 5.6 GHz. Ground-station temperature-compensated crystal oscillator drift at a typical 2.5 ppm specification is about 14 kHz at 5.6 GHz, worst case across temperature and aging. Slightly-inclined geostationary Doppler contributes a few kHz peak-to-peak per pass. Satellite oscillator drift, transponder local-oscillator offsets, and post-launch frequency-calibration effects add another few kHz. The aggregate frequency-uncertainty budget is on the order of 10 to 20 kHz, which exceeds the 11.5 kHz guard band available at 96 channels and consumes it entirely before the prototype filter is even considered. The 64-channel design absorbs the same budget with comfortable headroom.

The 37.5 kHz guard band on each side of the Opulent Voice signal in the 64-channel design absorbs oscillator frequency error, slightly-inclined geostationary Doppler, prototype-filter transition, and thermal-and-aging margin, with comfortable headroom. The same budget applied to a 96-channel design would consume the entire guard band.

Second, prototype-filter realizability. Tighter channels require a steeper prototype filter. The 96-channel design needs roughly 11.5 kHz of transition band between signal edge and channel edge; the 64-channel design has 37.5 kHz. The relaxed filter can use fewer taps per polyphase branch for the same out-of-band rejection, closes timing more easily on the FPGA fabric, and tolerates fixed-point arithmetic effects with greater margin.

Third, the FPGA resource budget. On a Xilinx Zynq UltraScale+ ZCU102, the measured 64-channel cost after place-and-route is 1346 DSP48E2 slices and 116 K lookup tables. The 96-channel projection was approximately 2086 DSP slices and 174 K lookup tables. This was over 80% of the available DSP resource before accounting for the rest of the payload (multiplexer, encoder, debug instrumentation). The 64-channel design at 53% DSP and 42% LUT utilization leaves comfortable headroom for the full payload pipeline. The 52% channel utilization at the input side is not waste. This utilization absorbs Doppler, oscillator drift, filter transition, and aging margin.

Fourth, the FFT. Sixty-four equals two to the sixth power, reducing the channelizer FFT to a pure radix-2 calculation. It has six stages of butterflies, a well-understood verification methodology, and the smallest possible cost per N log N operation. Ninety-six factors as 32 × 3 and forces a mixed-radix algorithm. This is workable, but with higher implementation cost, more complex verification, and fewer pre-validated reference implementations.

Channelizer Architecture

We are using a polyphase channelizer construction. An M-path commutator at the input demultiplexes the wideband in-phase and quadrature (I/Q) stream across N parallel finite-impulse-response filter branches. Each branch implements one row of the polyphase decomposition of a single prototype low-pass filter. An N-point FFT across the branch outputs separates the spectrum into N adjacent channels, each running at the input rate divided by the decimation factor M. The standard reference is harris [1]. The key property is that the same hardware performs both filtering and frequency translation, with no separate mixer per channel.

For Haifuraiya, M = 16 with N = 64. This is a 4-times oversampled channelizer. Each 156.25 kHz channel emerges at 625 kSps complex sampling rate rather than at the critically sampled 156.25 kSps that M = N would produce. The 4 times oversampling ratio gives 11.53 samples per symbol at the 54.2 kBd symbol rate, which is what downstream timing recovery, Costas-loop carrier recovery, signal-to-noise estimation, and Doppler-correction loops require for lock and track at geostationary bent-pipe signal-to-noise levels. The prototype filter is designed using the pm-remez library [3], a Parks–McClellan / Remez exchange implementation, with the classic 1/f stopband weighting recommendation from [1]. The 1/f weighting concentrates design effort near the channel edge, where adjacent-channel energy matters most. With the relaxed 37.5 kHz transition band, the prototype filter is short enough that each polyphase branch lands on a single DSP48E2 multiply-accumulate at 100 MHz.

Implementation Status

The 64-channel implementation is closed on the Zynq UltraScale+ ZCU102. Synthesis closes at 100 MHz with clean placement and routing. Verification uses bit-true comparison against the Python reference. The design is packaged as an IP-XACT component that integrates into any Vivado block design, with AXI-Stream input and output, AXI-Lite control for runtime configuration, and destination-tag encoding of the channel index on the output stream.

Reference Design for Wider Application

Haifuraiya is part of an open-source reference stack released under the CERN Open Hardware Licence Version 2, Strongly Reciprocal (CERN-OHL-S-2.0). The stack includes the channelizer described here, the Opulent Voice modem (VHDL programmable-logic intellectual property in pluto_msk, and C++ processing-system software in opv-cxx-demod), a DVB-S2 transmit chain (dvb_fpga), a payload-side multiplexer for assembling the coherent downlink, and an operating-system-flexible ground-station interface (Interlocutor) implemented in Python with HTML5, CSS, and JavaScript. There are operator-facing dashboards in the ground station (Speculator) and in the polyphase channelizer (Bouro). Each component is independently usable. A designer working on a commercial satellite bent-pipe payload can adopt the channelizer alone, the modem alone, the ground-station interface alone, or the full pipeline as a starting point.

This architecture places the communications processing onboard the satellite rather than at a ground station accessed via a separate uplink and downlink. Traditional bent-pipe payloads with ground-based processing require a double-hop path. The signal must uplink to satellite, downlink to a processing ground station, re-uplink to satellite, and downlink to the end user, with attendant latency and link-budget penalties. Onboard channelization and demodulation eliminate that double-hop. Commercial trends in digital-transparent and regenerative satellite payloads are moving in the same direction for the same reasons, and Haifuraiya provides a worked example of how to implement that onboard intelligence in a compact, verifiable, open-source form.

The use of reconfigurable hardware in FPGA fabric rather than fixed-function silicon allows the design to evolve through validated case studies. Different demodulator approaches can be compared against the same air-interface recordings. Successive interference cancellation techniques can be added without hardware modification. And, machine-learning enhancements to existing signal-processing blocks can be evaluated through controlled before-and-after comparisons. For an operator with a long-lived satellite asset, this is the difference between a payload that ages out of relevance and one that continues to incorporate state-of-the-art techniques across its operational lifetime.

The general engineering methodology illustrated in this work is reusable across satellite system designs that share the same problem shape: a wideband allocation to be subdivided into many narrowband channels under non-trivial frequency uncertainty. The recommended order of consideration is
1. signal geometry against channel width and guard band
2. frequency uncertainty budget aggregated across all contributors
3. prototype-filter realizability given the transition band that remains
4. silicon budget given the FFT factorization required by the chosen channel count. Powers of two reduce verification cost and unlock decades of reference implementations, and unless there is a compelling reason to fight them, they tend to win.

The same trade-off space applies in commercial digital-transparent and regenerative satellite payloads, in software-defined VSAT and aeronautical-broadband systems, and in any wideband bent-pipe carrying narrowband users. Haifuraiya is one worked example. The repository [5] contains the channelizer VHDL source, the Python reference model and filter design notebook, the IP-XACT packaging, the block-design integration smoke test, and project documentation. The modem implementations and ground-station interface are in [6]. The entire stack is documented to allow re-instantiation at different channel counts, sample rates, and signal protocols.

The use of amateur radio frequencies to prototype and deploy a communications satellite of this nature can provide clear benefit to commercial operations. Amateur radio bands offer a regulatory environment in which new designs and design variants can be tested without the schedule and revenue pressures of commercial projects, and validated approaches can transfer to commercial implementations with reduced risk. The amateur radio satellite community is also a workforce-development pipeline. Skills in practical radio engineering, signal processing, and small-satellite systems are highly valued by commercial employers, and word of successful technical approaches spreads rapidly through the global amateur radio satellite community. Supporting the non-commercial amateur radio community directly benefits the broader satellite communications workforce.

Conclusion

The Haifuraiya channelizer is one worked answer to a general question facing wideband bent-pipe satellite designers: how many channels does the allocation actually support, given the signal, the frequency uncertainty, and the available silicon? For an 81 kHz signal in 10 MHz at 5.6 GHz on a Zynq UltraScale+ ZCU102, the decision was 64. The article documents the four arguments that produced that answer and the open-source reference design that implements it. The methodology is applicable to any wideband carrying narrowband multiplexed users, in amateur or commercial service. The reference stack is available for adoption, modification, and reuse under CERN-OHL-S-2.0.

Acknowledgments

The author thanks David Bowman (amateur radio call sign G0MRF) for the Mode-Dynamic-Transponder concept, which provided the architectural starting point for the Haifuraiya design. Martin Ling for the hardware reference design that informed the early architecture. Daniel Estévez (amateur radio call sign EA4GPZ) for the pm-remez library used for prototype-filter design. And, Evariste Courjaud (amateur radio call sign F5OEO) for valuable feedback on filter-design trade-offs. The Open Research Institute volunteer engineering team carries the design and implementation work forward.

References

[1]        f. j. harris, Multirate Signal Processing for Communication Systems. Upper Saddle River, NJ, USA: Prentice Hall, 2004.

[2]        f. j. harris, C. Dick, and M. Rice, “Digital receivers and transmitters using polyphase filter banks for wireless communications,” IEEE Trans. Microw. Theory Techn., vol. 51, no. 4, pp. 1395–1412, Apr. 2003, doi: 10.1109/TMTT.2003.809176.

[3]        D. Estévez, “pm-remez: A modern Parks–McClellan / Remez exchange FIR filter designer,” 2024. [Online]. Available: https://github.com/daniestevez/pm-remez

[4]        J. W. Cooley and J. W. Tukey, “An algorithm for the machine calculation of complex Fourier series,” Math. Comput., vol. 19, no. 90, pp. 297–301, Apr. 1965, doi: 10.2307/2003354.

[5]        Open Research Institute, “Mode-Dynamic-Transponder repository,” 2025. [Online]. Available: https://github.com/OpenResearchInstitute/Mode-Dynamic-Transponder

[6]        Open Research Institute, “Opulent Voice protocol and pluto_msk reference modem,” 2025. [Online]. Available: https://github.com/OpenResearchInstitute

[7]        Xilinx, Inc., Zynq UltraScale+ MPSoC Data Sheet: Overview, DS891, Mar. 2022.

Call for Participation (CFP) SBMS September Meeting

If you are in or near San Diego, CA (or Corona, CA), or can be, then please be invited to attend the September 3, 2026 San Bernardino Microwave Society (SBMS) Meeting with San Diego crew members! We will be taking up the EVE/EME station to show off to SBMS membership and get feedback on the design and results. This is in support of the October 2026 EVE attempt.

The meeting is at the American Legion Hall in Corona, CA at 1900 Pacific Time.

There is a really nice pre-meeting at a restaurant ahead of time that we’ll be taking advantage of. You do not have to join up for this, but it is a lot of fun. Directly from SBMS: “Those who come to Corona early to beat the traffic often meet at Sizzler, 1461 Rimpau Ave. 92879, for dinner at or before 4:00 p.m”

Folks will be leaving San Diego at 3pm, so please feel free to get in touch (at hello at openresearch dot institute) if you’d like to join up at any stage of the evening. 

DEFCON 34 Reports

Our Open Source Digital Radio exhibit at DEFCON 34 was a highlight of the year. Four of us volunteered to present, demonstrate, explain, and teach digital communications through open source work to an enthusiastic and curious crowd of diverse and technically advanced people.

Thank you to Paul Williamson, Michael Easton, and Aaron Olivarez for highly successful Opulent Voice and Haifuraiya live demonstrations, the entire team at RF Village for the space and support, and Pete Wyckoff for EVE signal construction, featured prominently in the Earth-Venus-Earth Village talk at 1500 Friday.

We’ll share more about our experiences here shortly, with discussion on what types of questions and feedback we got, and how the design was received.

Our exhibit was a very large step forward from last year, and a significant step forward from our Friedrichshafen HAMRADIO show presentation, which was just last month.

In the near future, we’ll be porting the Haifuraiya design to a radiation tolerant FGPA part, and deploying a terrestrial repeater in Southern California.

More soon!