Clear the m_open flag when closing PlutoSDR input and output
devices. Previously closeDevice() released m_deviceParams but left
m_open set, leaving the object in an inconsistent state where code
could treat a closed device as still valid.
This was exposed when reloading a running PlutoSDR device, where GUI
updates could access the partially torn-down device state.
Hopefully fixes#2833 (I don't have a windows machine to test).
Signed-off-by: Robin Getz <rgetz503@gmail.com>
Add defensive null checks before dereferencing DeviceAPI::getBuddySharedPtr()
in the PlutoSDR input and output plugins.
DeviceAPI initializes the buddy shared pointer to nullptr, so a buddy may
exist before its shared state has been attached. This could result in null
pointer dereferences during device initialization, buddy thread
suspend/resume, or settings application.
Changes include:
- Validate buddy shared pointer in openDevice() and fail gracefully if absent.
- Guard suspendBuddies() and resumeBuddies() against null shared pointers.
- Skip buddies without shared state during applySettings() while logging a
warning.
- Prevent dereferencing null buddy shared pointers when restarting buddy
threads.
These changes improve robustness during PlutoSDR buddy initialization and
avoid crashes caused by partially initialized buddy relationships.
Signed-off-by: Robin Getz <rgetz503@gmail.com>
Most plugins that use reverse API to PATCH settings updates to remote
server only do so when `useReverseAPI` is toggled, but not when the
relevant settings are being updated. So lets fix the precondition to
use the `m_useReverseAPI` flag instead.
This will use the RF bandwidth from the device, which is different
between AD9363 and AD9364.
Things are now managed like the device likes - analog low pass bandwidth
is RF (complex) bandwidth, not baseband single I or Q bandwidth.
Signed-off-by: Robin Getz <robin.getz@analog.com>