83 lines
3.8 KiB
Markdown
83 lines
3.8 KiB
Markdown
# Next Steps
|
|
|
|
## Priority
|
|
|
|
1. Investigate Protocol 2 stop handling.
|
|
2. Validate Protocol 2 wideband behavior on real hardware.
|
|
3. Complete Protocol 2 Alex support for boards with `Alex1`.
|
|
|
|
## Immediate Issues To Debug
|
|
|
|
### Protocol 2 stop crash
|
|
|
|
- Re-test why the application crashes when the user presses `Stop` while working with a Protocol 2 device.
|
|
- Re-verify why the Protocol 2 stop command may still not be correctly sent to the transceiver.
|
|
- Check the shutdown path across:
|
|
- `src/DataEngine/cusdr_dataEngine.cpp`
|
|
- `src/DataEngine/cusdr_dataIO.cpp`
|
|
- `src/DataEngine/cusdr_protocol2_io.cpp`
|
|
- Already fixed one likely cause in `src/DataEngine/cusdr_protocol2_io.cpp`:
|
|
- duplicate `P2 stop` send,
|
|
- stop without `m_running`,
|
|
- timer/socket signal disconnect before deletion.
|
|
- Already fixed a second class of issues in `src/DataEngine/cusdr_dataEngine.cpp`:
|
|
- `DataIO` control calls now go through `QMetaObject::invokeMethod(..., Qt::BlockingQueuedConnection)`,
|
|
- so start/stop/init execute in the `DataIO` thread instead of the caller thread.
|
|
- Already fixed a concrete `Protocol 2` destructor bug in `src/DataEngine/cusdr_dataIO.cpp`:
|
|
- `m_dataIOSocketOn == true` with `m_dataIOSocket == 0` could dereference a null pointer during shutdown.
|
|
- Already moved `CSoundOut` deletion out of `DataIO::stop()` and into the destructor to reduce timer/thread teardown issues.
|
|
- Pay special attention to:
|
|
- socket lifetime,
|
|
- timer lifetime,
|
|
- `QObject` ownership and deletion thread,
|
|
- repeated stop calls,
|
|
- `networkDeviceStartStop(0)`,
|
|
- `Protocol2DataPath::stop()`,
|
|
- `sendHighPriorityPacket(false)`,
|
|
- whether the command socket is still valid when stop is triggered,
|
|
- whether `DataIO` / `Protocol2DataPath` should be destroyed via `deleteLater()` in their own thread instead of direct delete from `DataEngine`,
|
|
- whether the target `P2` board expects additional shutdown packets or repeated `run = 0` frames.
|
|
|
|
## Protocol 2 Functional Work
|
|
|
|
### Protocol 2 wideband runtime verification
|
|
|
|
- Re-test Protocol 2 wideband on real hardware after the 2026-04-14 integration.
|
|
- Verify that pressing the UI `Wideband` button now really causes the transceiver to:
|
|
- start sending wideband UDP data,
|
|
- stop sending wideband UDP data.
|
|
- Verify that this works while the device is already running, without requiring a full stop/start cycle.
|
|
- Verify the incoming packet format and pacing match what the implementation now assumes:
|
|
- UDP base port `1027`,
|
|
- sequence number in bytes `0..3`,
|
|
- 16-bit raw ADC samples starting at byte `4`,
|
|
- one full spectrum block formed from `Settings::getWidebandBuffers()` packets.
|
|
- Pay special attention to boards that may not follow the default `32 packets per frame` behavior.
|
|
- If a board reports or requires fixed wideband constraints, use the protocol document/device profile to specialize the current defaults.
|
|
|
|
- Implement proper `Alex1/BPF2/RX2` handling for boards that support a second Alex register:
|
|
- Orion MkII
|
|
- SATURN / ANAN-G2
|
|
- Use Appendix D from `doc/openHPSDR Ethernet Protocol v4.3.docx` to map the second Alex register bits correctly.
|
|
- Consider extending Protocol 2 capability handling beyond board defaults where discovery returns more precise information.
|
|
- Consider support for XML/full hardware description discovery replies for board `254/255`.
|
|
|
|
## UI Work
|
|
|
|
- Review UI areas that still assume `Metis/Hermes` semantics internally.
|
|
- Confirm the `Wideband` button behavior is now correct from the user point of view:
|
|
- button state,
|
|
- dock visibility,
|
|
- `widebandData` setting,
|
|
- real hardware stream enable/disable.
|
|
- Make Protocol 2 model/capability presentation more explicit where useful:
|
|
- selected model,
|
|
- protocol version,
|
|
- ADC/DDC count,
|
|
- Alex availability.
|
|
|
|
## Reference
|
|
|
|
- Detailed log of completed work:
|
|
- `WORKLOG_PROTOCOL2_2026-04-13.md`
|