protocol 2 fix

Source/NOTES_PROTOCOL2_RECEIVERS_THETIS.md

@@ -0,0 +1,179 @@
+# Protocol 2 Receiver/DDC Notes from Thetis
+
+Date: 2026-04-14
+
+This note captures findings from two sources:
+
+- local protocol documentation: `doc/openHPSDR Ethernet Protocol v4.3.docx`
+- local Thetis source tree: `/home/vladimir/Документы/source/Thetis`
+
+It is intended as a working note for future Protocol 2 receiver work, especially for the second receiver and Orion MkII / ANAN-7000DLE / ANAN-8000DLE behavior.
+
+## High-level conclusion
+
+Protocol 2 does not impose a global "only 2 receivers" limit.
+
+The protocol separates:
+
+- number of ADCs
+- number of DDCs
+
+This strongly suggests that DDCs are logical/digital receive channels built on top of available ADC inputs, not a one-to-one count of independent analog hardware chains.
+
+## Protocol document findings
+
+From `openHPSDR Ethernet Protocol v4.3.docx`:
+
+- The protocol tries not to restrict the number of configurable resources.
+- Current hardware implementation applies only a broad upper limit of `80 DDCs` and `8 ADCs`.
+- Discovery reply includes `Number of DDCs implemented`, so the hardware reports its own DDC capability.
+
+Board capability appendix findings already extracted:
+
+- `Board 1 = Hermes (ANAN-10, 100)`
+  - `Number of ADCs = 1`
+  - `Number of DDCs supported = 2`
+- `Board 2 = Hermes (ANAN-10E)`
+  - `Number of ADCs = 1`
+  - `Number of DDCs supported = 2`
+- `Board 3 = Angelia (ANAN-100D)`
+  - `Number of ADCs = 2`
+  - `Number of DDCs supported = 7`
+- `Board 4 = Orion (ANAN-200D)`
+  - `Number of ADCs = 2`
+  - `Number of DDCs supported = 7`
+
+Implication:
+
+- low-end boards really are 2-DDC devices
+- higher-end 2-ADC boards support more logical DDC channels than ADC count
+
+## Thetis findings
+
+Relevant files:
+
+- [network.h](/home/vladimir/Документы/source/Thetis/Project Files/Source/ChannelMaster/network.h:414)
+- [console.cs](/home/vladimir/Документы/source/Thetis/Project Files/Source/Console/console.cs:8186)
+- [networkproto1.c](/home/vladimir/Документы/source/Thetis/Project Files/Source/ChannelMaster/networkproto1.c:497)
+
+### Model grouping
+
+Thetis groups these as the same high-end hardware family for receiver/DDC logic:
+
+- `ANAN-100D`
+- `ANAN-200D`
+- `ORIONMKII`
+- `ANAN7000D`
+- `ANAN8000D`
+- `ANAN-G2`
+- `ANVELINAPRO3`
+
+See:
+
+- [console.cs](/home/vladimir/Документы/source/Thetis/Project Files/Source/Console/console.cs:8211)
+
+### Protocol 1 interpretation in Thetis
+
+For that high-end family, Thetis explicitly sets:
+
+- `P1_rxcount = 5`
+- `nddc = 5`
+
+See:
+
+- [console.cs](/home/vladimir/Документы/source/Thetis/Project Files/Source/Console/console.cs:8219)
+
+This means Thetis does not treat `ANAN-7000DLE/8000DLE` as a 2-DDC class device.
+
+`networkproto1.c` also contains special handling for `nddc == 5`, again separating these boards from 2-DDC hardware:
+
+- [networkproto1.c](/home/vladimir/Документы/source/Thetis/Project Files/Source/ChannelMaster/networkproto1.c:504)
+- [networkproto1.c](/home/vladimir/Документы/source/Thetis/Project Files/Source/ChannelMaster/networkproto1.c:528)
+
+### Protocol 2 interpretation in Thetis
+
+For Protocol 2, Thetis groups:
+
+- `Angelia`
+- `Orion`
+- `OrionMKII`
+- `Saturn`
+
+into one receiver/DDC mapping block:
+
+- [console.cs](/home/vladimir/Документы/source/Thetis/Project Files/Source/Console/console.cs:8556)
+
+In the normal non-diversity, non-sync mapping, Thetis uses:
+
+- `rx1 = 2`
+- `rx2 = 3`
+
+See:
+
+- [console.cs](/home/vladimir/Документы/source/Thetis/Project Files/Source/Console/console.cs:8562)
+
+This is important:
+
+- for high-end Protocol 2 boards, Thetis does not map main receivers onto `DDC0` and `DDC1`
+- it maps them onto `DDC2` and `DDC3`
+
+### Frequency map evidence
+
+Thetis has explicit frequency mapping entries up to at least `RX7`:
+
+- [network.c](/home/vladimir/Документы/source/Thetis/Project Files/Source/ChannelMaster/network.c:947)
+- [network.c](/home/vladimir/Документы/source/Thetis/Project Files/Source/ChannelMaster/network.c:977)
+
+And sequence/error tracking exists up to `DDC6`:
+
+- [netInterface.c](/home/vladimir/Документы/source/Thetis/Project Files/Source/ChannelMaster/netInterface.c:173)
+- [netInterface.c](/home/vladimir/Документы/source/Thetis/Project Files/Source/ChannelMaster/netInterface.c:185)
+
+This again supports the idea that these are logical digital channels, not simply "one DDC per physical receiver front-end".
+
+## Working interpretation for Orion MkII / ANAN-7000DLE / ANAN-8000DLE
+
+Most likely model:
+
+- there are `2` hardware ADC inputs
+- there are multiple logical DDC channels built on top of those ADC inputs
+- wideband is a separate stream, not "DDC1"
+- `DDC0/DDC1` are likely reserved or preferred for sync/diversity/PureSignal related modes on high-end boards
+- normal user RX channels on high-end Protocol 2 boards are likely expected on `DDC2` and `DDC3`
+
+This is consistent with:
+
+- protocol appendix: `2 ADC` and more-than-2 supported DDC on high-end hardware
+- Thetis P2 receiver mapping
+- Thetis P1 special-case handling for `nddc == 5`
+
+## Important caution
+
+One user assertion remains plausible and should not be discarded:
+
+- Orion MkII may have only `2` hardware receive chains in the analog sense
+
+That does not contradict the protocol or Thetis findings.
+
+It would simply mean:
+
+- `2` hardware ADC/analog paths
+- multiple digital DDC slices derived from those ADCs
+
+So the likely correction is not "two hardware DDC total", but rather:
+
+- "two hardware ADC/front-end paths, several logical DDC channels"
+
+## Practical implication for cudaSDR Protocol 2 work
+
+For future receiver work, do not assume:
+
+- high-end Protocol 2 boards use the same DDC mapping as Hermes / HermesII
+- receiver 1 and receiver 2 should be attached to `DDC0` and `DDC1`
+
+Instead, verify whether our Protocol 2 implementation should follow Thetis-style mapping for high-end boards:
+
+- RX1 -> `DDC2`
+- RX2 -> `DDC3`
+
+And keep wideband separate from DDC numbering.