Improve EOO encode/decode

[tmiw]

Improves EOO encoding and decoding:

1. TX: Add missing scaling of EOO symbols from original Python implementation.
2. RX:
   a. Update RX phase calculation to more closely match Python implementation and reduce floating-point losses.
   b. BPF: Updates phase calculation to more closely match Python implementation and improve calculation accuracy.
3. Uses version of dot product for (I)DFT that supposedly has lower average floating point error (see this paper). Note: not sure this is actually necessary. I was trying to debug an issue where various calculations weren't producing the same results as NumPy, but it's likely the other bugs fixed here helped more.
4. Update BuildOpus.cmake to fix build errors.
5. Add missing Python scripts and other test logic to allow freedv-gui and Nopy Tests drowe67/radae#66 tests to execute properly.

[tmiw]

BTW all tests now pass in @drowe67's repo: https://github.com/drowe67/radae/actions/runs/22817405233

[drowe67]

@tmiw - nice work, this is just what we needed to connect Peter's fine work with the the essential (IMHO) existing RADE QA. 👍

Any thoughts on the remaining TODOs in drowe67/radae#66 ? Might be useful if we have a test for SNR est (I could help there).

@peterbmarks - Claude might be able to help with a BPF test.

[drowe67]

@tmiw @peterbmarks - we also need to make sure the ctests are run on every push, then Claude can get used to running them as Peter works with Claude on the code.

[tmiw]

Any thoughts on the remaining TODOs in drowe67/radae#66 ? Might be useful if we have a test for SNR est (I could help there).

SNR might be reading closer to reference Python now based on my limited testing. Still would need a test written to know for sure, though. (Maybe just run radae_rxe.py and Peter's C receiver, get the last reported SNR from the former and make sure it's the same as the latter +/- some tolerance level + repeat for various AWGN/MPP noise/fading levels? I could be missing something though.)

[drowe67]

Re SNR I think we're missing a test in the V1 Python tests, e.g. V1 Python est SNR versus actual SNR. That could then be used for the C Port like the other tests. I'm traveling atm - will get back to you in a few days once I can sit down and think about it.

Re BPF we have a pretty good test design for V1 Python, might be possible to get Claude to come up with something similar for C. The BPF definitely has the potential to mess up performance is subtle ways.

[drowe67]

One of the reasons I'm interested in SNR is it directly measures the noise of the recovered symbols, so is an indication of the performance of the C demodulator implementation.

[tmiw]

I reduced the max loss back down to 0.2 for radae_nopy_rx_slip_minus and the latest doesn't seem to be failing anymore. We'll see how the GH run goes before I mark that as complete.

EDIT: still failing on GH, not sure why.

[tmiw]

OK, I think I got rx_slip_minus to pass (pending GH execution). See #2.

[drowe67]

@tmiw @peterbmarks - Claude & I are building up a BER test for the C Port that will require a PR for radae_nopy. Should I submit the PR against this repo or Mooneer's fork?

[tmiw]

@tmiw @peterbmarks - Claude & I are building up a BER test for the C Port that will require a PR for radae_nopy. Should I submit the PR against this repo or Mooneer's fork?

I'd say this one, once #2 merges. (pinging @peterbmarks so this can happen)