Adds Meteor Rx App

[Josephrp]

Summary

This PR adds Meteor LRPT support on PortaPack Mayhem with a SatDump-aligned FEC/framing core, split for HackRF One + PortaPack H4M (1 MiB SPI / W25Q80).

Operator workflow (H4M default): three Receive menu apps and one SD pipeline:

Step	Menu app	SD artifact	Role
1	MeteorRx	meteor-capture.ppma	Live IQ → soft symbols on M4 (PMLS); RecordView → /LRPT/SOFT*.C8
2	MeteorDx	meteor-decode.ppmp	Offline FEC (Viterbi / NRZ-M / deframer / RS) → /LRPT/dec_cadu.C8
3	MeteorVx	meteor-view.ppmp	CADU → MSU-MR demux (APIDs 64–69) → /LRPT/ms<apid>.bmp

Engineering goals: SatDump-parity algorithms under firmware/baseband/meteor_lrpt/, golden SOFT / CADU artifacts for host compare, and a 1 MiB SPI layout that keeps full PMLR FEC off the packed baseband.img while still shipping capture + offline decode/view on SD.

On larger SPI builds (MAYHEM_SPI_1MB unset), PMLR remains in baseband.img for the legacy live M4 FEC path (deinterleave IPC, optional G4 live ring, etc.) in addition to the staged apps.

---

Motivation

• Operators: Record Meteor M2-x LRPT at ~137.9 MHz class with sensible 72k / 80k timing and M2-x / diff / legacy correlator flags, then decode and view on device without desktop tools.
• Developers: Compare Mayhem vs SatDump using documented block formats (scripts/METEOR_SOFT_FORMAT.txt) and pinned upstream mapping (firmware/baseband/meteor_lrpt/SATDUMP_VENDOR.md).
• H4M constraint: 1 MiB SPI cannot hold PMLR + the usual trimmed baseband set; capture uses a small PMLS image in .ppma, and heavy FEC runs in MeteorDx (M0 standalone RAM in local_sram_0).

---

Receive apps (what actually ships)

1. MeteorRx — capture (.ppma + PMLS)

External app registration (firmware/application/external/meteor_lrpt_rx/main.cpp):

• Menu name: MeteorRx
• M4 tag: PMLS (meteor_lrpt_capture) — QPSK demod + Gardner timing → int8 soft I/Q, no on-M4 FEC
• Loaded from SD as meteor-capture.ppma (OCI tar: APPS/meteor-capture.ppma)

UI (ui_meteor_lrpt_rx.hpp / .cpp):

• Capture mode, 3.072 Msps, default 137.9 MHz
• Checkboxes (separate rows): M2-x, Diff, Legacy corr, 80k symbols
• One RecordView: prefix SOFT, folder LRPT, RawS8, 16384-byte blocks, extension .C8 → /LRPT/<stem>.C8
• Flags persisted to SETTINGS/rx_meteor_lrpt.ini as lrpt_flags= (live interleaved bit1 is stripped; interleaved M2-x is offline in MeteorDx)
• Status: soft:… L… TED:… blk:… from MeteorLrptRxStatusData
• No live JPEG preview handler (preview message unregistered at entry)

H4M note: meteor_lrpt_capture_stub.cpp stubs M0 deinterleave and G4 services in main firmware; capture does not depend on them.

2. MeteorDx — offline decode (.ppmp)

• Menu name: MeteorDx
• Runs as a standalone app in 96 KiB local_sram_0 (loader relocates full image; Viterbi decisions in SRAM1 scratch)
• SELECT: finds /LRPT/SOFT*.C8, runs meteor_offline_fec.cpp, writes /LRPT/dec_cadu.C8 (1020-byte CADU REC records)
• Reads lrpt_flags from the same INI as capture
• Left / Back: exit to Receive menu

3. MeteorVx — offline view (.ppmp)

• Menu name: MeteorVx
• SELECT: opens /LRPT/dec*.C8 (fallback *.C8), MSU-MR demux + TJpgDec → /LRPT/ms<apid>.bmp
• Same navigation pattern as MeteorDx

---

M4 baseband images

Tag	Processor	In 1 MiB baseband.img	Function
PMLS	proc_meteor_lrpt_capture	No — bundled only in capture .ppma	Soft symbol stream for RecordView
PMLR	proc_meteor_lrpt_rx	Omitted when MAYHEM_SPI_1MB	Full live FEC: Viterbi, RS, deframer, M2-x paths, M0 deint IPC, optional G4 live CADU ring, preview scan

firmware/baseband/CMakeLists.txt wraps DeclareTargets(PMLR …) in if(NOT MAYHEM_SPI_1MB). PMLS is always built for .ppma export (validate: ≤ 26 KiB).

IQ chain (PMLR / shared DSP): Meteor FIR taps, Gardner symbol timing (meteor_symbol_timing.hpp), legacy QPSK correlate, M2-x interleaved pipeline with SharedMemory::MeteorLrptIpc when M0 deint is active (non-H4M profile).

---

M0 services and shared memory (non-H4M / full SPI)

When MAYHEM_SPI_1MB is not set, main firmware includes:

1. Deinterleave service — sector rings /LRPT/DEINT_A.BIN, /LRPT/DEINT_B.BIN, MeteorLrptIpc handshake (portapack_shared_memory.hpp).
2. G4 / MSU-MR service — tail CADU file, optional live 2×1020 B ring in MeteorLrptG4Ipc, TJpgDec → BMP, small LCD thumbnail fields.

H4M: these are stubbed; imagery and FEC for operators are MeteorDx / MeteorVx on SD.

Standalone loader (ui_external_items_menu_loader.cpp): loads .ppmp into local_sram_0, zero-fills 96 KiB BSS, relocates link base 0xADB10000 → runtime 0x10000000.

---

SD staged pipeline

Documented in scripts/METEOR_SOFT_FORMAT.txt:

Capture (MeteorRx)  →  /LRPT/SOFT*.C8     (16384 B int8 blocks; 8192 when M2-x decode expects it)
Decode (MeteorDx)   →  /LRPT/dec_cadu.C8 (1020 B CADU REC)
View (MeteorVx)     →  /LRPT/ms64.bmp … ms69.bmp
Settings            →  SETTINGS/rx_meteor_lrpt.ini  (lrpt_flags=)

Golden packaging rule: flash portapack-mayhem_OCI.ppfw.tar and all three APPS/ files from one build — never mix .bin from build A with .ppma/.ppmp from build B (scripts/H4M_METEOR_BUILD.txt).

---

H4M build and validation

• CMake: -DFLASH_MB_SIZE=2 + -DFLASH_MB_LIMIT_SIZE=1 → 1048576-byte portapack-mayhem-firmware.bin
• Scripts: scripts/wsl-build-share-out.sh, scripts/validate_meteor_artifacts.sh, scripts/spi-gate-check.sh, scripts/flash-h4m-share-out.ps1
• Checks: no PMLR chunk in SPI image; capture .ppma present; decode/view .ppmp in OCI tar; warns on legacy meteor_lrpt_rx.ppma

---

FREQMAN

sdcard/FREQMAN/METEOR_LRPT.TXT — 137.9 MHz primary and 137.1 MHz backup with SPEC bandwidth hints (matches MeteorRx default).

---

What changed vs an all-in-one “Meteor LRPT” design

• Split live capture (PMLS / MeteorRx) from offline FEC (MeteorDx) and imagery (MeteorVx) for 1 MiB SPI.
• Removed in-tree G4 preview module (meteor_lrpt_g4_preview.cpp/hpp).
• Capture UI: soft RecordView only (no second CADU recorder; M4 exposes one soft stream).
• No live interleaved deint on H4M; M2-x interleaved decoding is via offline flags in MeteorDx.
• Legacy monolithic meteor_lrpt_rx.ppma / SPI PMLR-only workflow superseded on H4M by the three-app set (PMLR still built for >1 MiB SPI).

---

Licensing and attribution

Vendored / SatDump-aligned (firmware/baseband/meteor_lrpt/): correlator, NRZ-M, BPSK/CCSDS deframer, Viterbi (GNU Radio VOLK generic K=7 R=1/2), RS(255,223) (libfec-style, LGPL), pinned to commit in SATDUMP_VENDOR.md.

Mayhem-original integration: proc_meteor_lrpt_rx / proc_meteor_lrpt_capture, M4↔M0 IPC, sector-ring deinterleave, G4 service + msumr_demux / jpeg_decode, external/standalone UIs, Message IDs, tools/meteor_lrpt/ host helpers (gitignored path; names in vendor doc).

TJpgDec: firmware/application/meteor_lrpt_g4/third_party/tjpgd/ (ChaN), used from MeteorVx path.

After vendor URL edits: python tools/meteor_lrpt/verify_satdump_vendor_urls.py.

---

Requires

---

Proof that your changes work

Proof it compiles

(Attach your CI / wsl-build-share-out.sh log + validate_meteor_artifacts.sh OK lines.)

---

Wiki documentation commitment

• Wiki page: https://github.com/portapack-mayhem/mayhem-firmware/wiki/Meteor
  Should describe the three-app H4M flow (Capture → Decode → View), SD paths, and that full live PMLR is for larger-SPI builds only.

---

Checklist

Build / packaging

• Build with FLASH_MB_SIZE=2, FLASH_MB_LIMIT_SIZE=1 for H4M; confirm portapack-mayhem-firmware.bin is 1048576 bytes.
• Run ./scripts/validate_meteor_artifacts.sh (SPI has no PMLR; OCI tar contains meteor-capture.ppma, meteor-decode.ppmp, meteor-view.ppmp).
• Flash one OCI tar (or matched bin + three APPS/ files from the same build).

Device — H4M three-app flow

• MeteorRx: tune 137.9 MHz, set flags, record SOFT → /LRPT/SOFT*.C8; confirm SETTINGS/rx_meteor_lrpt.ini updated.
• MeteorDx: SELECT decodes to /LRPT/dec_cadu.C8 (status blk:… CADU:…); no Guru Meditation on SELECT.
• MeteorVx: SELECT produces /LRPT/ms*.bmp for visible APIDs.
• Optional host: compare SOFT/CADU with SatDump using tools/meteor_lrpt/ helpers when present in your tree.

Docs / hygiene

• scripts/METEOR_SOFT_FORMAT.txt documents SOFT/CADU/BMP layout.
• scripts/H4M_METEOR_BUILD.txt documents 1 MiB flash workflow.
• After SatDump pin or vendor URL edits: verify_satdump_vendor_urls.py.
• Changes scoped to Meteor + build/flash scripts; compiles in CI/local Docker.
• Attached proof on real PortaPack H4M (or N/A with justification).
• RF proof vs real pass / replay IQ (or N/A with justification).
• Wiki update commitment (screenshot + three-app controls/limitations).

---

Substantive diff scope (for reviewers)

Primary paths: firmware/baseband/meteor_lrpt/, firmware/application/external/meteor_lrpt_rx/, firmware/standalone/meteor_lrpt_{decode,view}/, firmware/application/meteor_lrpt_g4/, M0 services, portapack_shared_memory.hpp, scripts/H4M_* / METEOR_* / validate_meteor_artifacts.sh, sdcard/FREQMAN/METEOR_LRPT.TXT, CMake SPI trimming

25052025_testfdrive

[zxkmm]

Thank you so much!

Do you mind provide the following two things, so we can start review?

• screenshot of your nice new app.

• the build ppfw.tar firmware package.

I apologize for the inconvenience but we are having some bot spam PR so we now require these two things as a start gateway for actual human review.

[Brumi-2021]

Hi @Josephrp , congrat !!!
@htotoo and my self developed Sat Analogue APT decoder , but unfortunately , we just enjoyed few months before they discontinued the NOAA Analogue APT service. We were late ...

I have received many years Meteor diigtal LRPT weather maps with handmade QFH + LNA .
But I always thought that our limited HackRF CPU will not have enough power and memory to decode it .
Normally we recorded long capture demodulated QPSK files , and later digital decoding generating image from PC with many seconds (i think close to 1 min ) , with high resolution of close to 1MB output , each picture map ...

Anyway, congrat , and will be able to help you to test and debug it , when available ,
And Congrat for your great job and excellent job . Amazing !!!! .
Cheers ,

[Josephrp]

Hi @Josephrp , congrat !!! @htotoo and my self developed Sat Analogue APT decoder , but unfortunately , we just enjoyed few months before they discontinued the NOAA Analogue APT service. We were late ...

I have received many years Meteor diigtal LRPT weather maps with handmade QFH + LNA . But I always thought that our limited HackRF CPU will not have enough power and memory to decode it . Normally we recorded long capture demodulated QPSK files , and later digital decoding generating image from PC with many seconds (i think close to 1 min ) , with high resolution of close to 1MB output , each picture map ...

Anyway, congrat , and will be able to help you to test and debug it , when available , And Congrat for your great job and excellent job . Amazing !!!! . Cheers ,

hi there @Brumi-2021 : testflight binaries are provided now , everything is getting a bit more okay to test . currently i'm building my antennae but i will test it later , if you want to try to just take the zip file from the (updated) issues description :-) hope you like it . please do share screenshots of your successful or even noisy results here :-)

[Brumi-2021]

Hi, looking my old archive files from 2021 , l could find 103 MB File with the demodulated QPSK (72Mhz symbol rate) , captured fron satellite Meteor MN Data and demodulated by SDR# . That file i ise to input to another decode exe file , who produced the picture map .
If you want i can share with you that QPSK demodulated file , or i can try to modulate in QPSK by gnuradio and capture raw IQ

Cheers

[Josephrp]

hi @Brumi-2021 , actually that would be quite helpful as i'm just delayed in making my direction antennae right now so this could help me accelerate a bit

[Josephrp]

need to remove flash utilities improvements from this PR , open a discussion wrt firmware