Per-site p25_phase1_demod_mode (C4FM vs CQPSK/LSM) in wideband multi-site config

[er-imagery]

Feature request: per-site demod mode for wideband multi-site systems

Context

We've confirmed via ACMA emission designator data that within a single P25 system, individual sites use different modulation:

• Melbourne CBD (RFSS 1/1): 10K1D7W = LSM/CQPSK (simulcast, multiple TX towers at 360 Elizabeth St / 101 Collins St / Rialto)
• Geelong MMR (RFSS 1/8): 10K1D7W = LSM/CQPSK (simulcast)
• Mt Anakie, Kinglake, Cottrell, Blackwood etc: 10K1F9W = C4FM (single-transmitter)

The current p25_phase1_demod_mode is a system-level setting. To cover all MMR sites on a single wideband device (or multi-device wideband config), you'd need C4FM for the rural/single-TX sites and CQPSK for the urban simulcast sites — which is currently impossible without splitting into separate system entries.

config.example.yaml already notes that p25_phase1_demod_mode: cqpsk also routes the voice chain through the LSM path (issues #275, #356) — so this isn't just a CC decode issue, voice grants on LSM sites will also time out without the correct per-site setting.

Proposed config shape

Something like a per-site override under the sites: list:

trunking:
  systems:
    - name: "MMR"
      p25_phase1_demod_mode: c4fm   # system default
      sites:
        - { rfss: 1, site: 1, name: "Melbourne", p25_phase1_demod_mode: cqpsk }   # LSM simulcast
        - { rfss: 1, site: 8, name: "Geelong",   p25_phase1_demod_mode: cqpsk }   # LSM simulcast
        - { rfss: 2, site: 7, name: "Mt Anakie" }                                  # inherits c4fm

Or alternatively a per-channel override on the wideband device's channels: list.

Why it matters

CBD has been showing control_channel_decode_quality: poor consistently regardless of hardware (tried Airspy R2 and RTL-SDR). Our hypothesis is that decoding an LSM site with C4FM is the root cause — C4FM's nonlinear demodulation can't correctly recover a linearly-modulated simulcast signal, producing the BER we've been seeing. If per-site CQPSK can be configured, we can finally verify this against the strongest signal in the system.

SDRTrunk supports per-channel LSM configuration which is why it can decode sites GT currently can't.

[MattCheramie]

Implemented in #942 (per-channel p25_phase1_demod_mode override).

Design decision — keyed per control-channel frequency, not RFSS/Site. I went with your alternative proposal (a per-channel override on the wideband device's channels: list) rather than the sites: mapping, for a hard architectural reason: the symbol-recovery path has to be chosen before a control channel locks — it's precisely what lets it lock — but a site's RFSS/Site is only known after GT decodes that CC. So keying the demod by RFSS/Site is a chicken-and-egg: you'd need to already be decoding the site to know which demod to decode it with. The wideband channels: entry is the one place a site's identity is known at config time (you're already listing each site's CC frequency there), so that's where the override lives.

What it does:

sdr:
  devices:
    - serial: "AIRSPY SN:…"
      role: wideband
      center_freq_hz: 420_900_000
      channels:
        - frequency_hz: 420_012_500   # Melbourne / CBD — LSM simulcast
          system: "MMR"
          p25_phase1_demod_mode: cqpsk
        - frequency_hz: 420_037_500   # Geelong / Collins St — LSM simulcast
          system: "MMR"
          p25_phase1_demod_mode: cqpsk
        - frequency_hz: 420_087_500   # Mt Anakie — single-TX C4FM (inherits)
          system: "MMR"

Set the system-level p25_phase1_demod_mode to whatever most sites use (C4FM for MMR) and add the per-channel cqpsk override only on the LSM simulcast sites. A blank/absent per-channel value inherits the system default.

Critically — as you called out re: #275/#356 — the override drives both the CC decode and the voice grants that tap issues, so a granted call on an LSM site is decoded on the LSM voice chain too, not just the control channel. (While wiring this I also found and fixed a latent gap: the wideband decode path was never stamping any demod mode onto its grants, so wideband P25 voice always ran the C4FM chain regardless of the system setting.)

There's a regression test that fails first and passes with the fix.

Leaving this open for your confirmation — I can't verify the actual hypothesis (that decoding CBD as LSM fixes the control_channel_decode_quality: poor) without your hardware. Could you build from the #942 branch, add p25_phase1_demod_mode: cqpsk to your CBD/Geelong channel entries, and report back whether those sites lock and whether voice grants decode? That's the strongest signal in the system, so it should be a clean test of the LSM-vs-C4FM theory.

---

Generated by Claude Code

[er-imagery]

Clarification on LSM vs CQPSK — C4FM is correct for Melbourne CBD

After extensive testing today: CBD (RFSS 1/1, 3 simulcast TX sites — 360 Elizabeth St, 101 Collins St, Rialto) decodes reliably in C4FM mode on both SDRTrunk and GT. Switching either to CQPSK mode kills the decode entirely.

CBD is definitely LSM (simulcast), but LSM is a simulcast coordination technique — timing/phase alignment across multiple TX sites — not a baseband modulation type. The baseband encoding is still 4FSK/C4FM. CQPSK (π/4-DQPSK) is an alternative P25 Phase 1 modulation that Motorola deployed on some systems, but it's not required for or synonymous with LSM. Victoria's MMR was deployed with C4FM baseband even on simulcast sites.

The ACMA emission designator 10K1D7W covers both C4FM and CQPSK — it doesn't distinguish between them at the licensing level, so ACMA data can't be used to infer demod mode.

The per-channel p25_phase1_demod_mode override in #942 is still valuable — it's the right feature for genuinely CQPSK systems — but the trigger is CQPSK deployment, not LSM deployment. They're orthogonal.

The CBD decode issue was purely a gain problem: SDRTrunk's working gain (~36 dB) translated correctly to GT's tenths-of-dB format (gain: "363") on a known-good port. CBD is now locked and pumping ~2K grants/5min.