Both plugin readmes listed the SWGMeshtastic* placeholder as an
outstanding item needing dedicated SWGMeshcore* schemas. This PR
provides exactly that — strike the stale todo and note the resolution.
PR #2775 merged the MeshCore plugin source files but omitted the
parent CMakeLists.txt changes, the export.h API macro, and all
MeshCore-specific Swagger schema types. Without these the plugins
do not build and the REST API serves Meshtastic types for MeshCore
channels.
Adds:
- CMakeLists.txt parent directories + option definitions
- exports/export.h MODEMMESHCORE_API macro
- MeshcoreDemod/Mod swagger YAML specs + SWG client classes
- SWGChannelSettings/Report/Actions/ModelFactory MeshCore types
- Rename 164 Meshtastic donor references in plugin code
Fix multiple issues preventing SoapySDR output from producing RF:
- handleInputMessages() never called in DSP engine thread (Qt signal
lost without event loop) - scheduled properly
- setGain() moved to start() post-activation (pre-activation gain
silently fails on SoapyUHD)
- fullScale threshold corrected for CS16 format detection
- Timed first write pattern matching gr4-lora SoapySink
MCR pinning for SoapyUHD: inject auto_tick_rate=0 in
DeviceSoapySDR device-open path to prevent UHD from re-deriving the
master clock rate on set_tx_rate(), which breaks the decimator chain
and produces no RF. Also reads SDRANGEL_USRP_MASTER_CLOCK_RATE_HZ env
var for optional MCR override.
TX diagnostic counters: SoapySDROutputThread tracks packets,
underflows, errors. Exposed via REST as streamSettingsArgs
key-value pairs.
Previously, devices claimed by another device set were omitted from the
device selection lists. Display these devices as disabled and marked
"[in use]" instead of hiding them.
Signed-off-by: Robin Getz <rgetz503@gmail.com>
addMIMODevice() never assigned m_deviceSets.back()->m_deviceAPI before
dereferencing it via setSampleMIMO(), causing the very first
POST /sdrangel/deviceset?direction=2 against a fresh headless server
to SIGSEGV in DeviceAPI::setSampleMIMO()'s vtable lookup.
DeviceSet's constructor initializes m_deviceAPI to nullptr
(sdrbase/device/deviceset.cpp:38), and the sibling helpers
addSinkDevice() (line 283) and addSourceDevice() (line 323) both
assign the new DeviceAPI* into m_deviceSets.back()->m_deviceAPI
before any later dereference. addMIMODevice() omits this assignment,
so the line that today reads:
m_mainCore->m_deviceSets.back()->m_deviceAPI->setSampleMIMO(mimo);
dereferences nullptr.
Fix by performing the same assignment as the Sink/Source paths, just
before the createSampleMIMOPluginInstance() call.
Verified against v7.25.1 in a custom headless build
(cicada-sdrangelsrv:7.25.1-mimo) with a LimeSDR-USB:
- Pre-patch: POST /sdrangel/deviceset?direction=2 -> HTTP 202,
then immediate SIGSEGV (backtrace top frame
DeviceAPI::setSampleMIMO -> MainServer::addMIMODevice).
- Post-patch: POST -> HTTP 202, container healthy, follow-up
PUT /sdrangel/deviceset/0/device with hwType=LimeSDR
direction=2 -> HTTP 202, deviceset reports the LimeSDR
correctly bound as a MIMO device.
Tom Hensel
f4exb
Jon Beniston
Robin Getz
dawkagaming
Alex Antonov UT2UM
Christoph Berg
Zane (RainCicada)
AsciiWolf
srcejon
copilot-swe-agent[bot]