cudaSDR/Source/NEXT_STEPS.md
2026-04-13 22:06:52 +03:00

63 lines
2.7 KiB
Markdown

# Next Steps
## Priority
1. Investigate Protocol 2 stop handling.
2. Complete Protocol 2 Alex support for boards with `Alex1`.
3. Continue UI cleanup for Protocol 2 specific hardware presentation.
## 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
- 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.
- 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`