cudaSDR/Source/NOTES_PROTOCOL2_RECEIVERS_THETIS.md

# 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.