SSB BPF missing from C Tx

[drowe67]

Delta between reference Python and C. I don't think it has any performance impact, but will clean up C Tx spectrum a tad. I'll add it shortly

[drowe67]

@tmiw @peterbmarks - While building up the Tx SSB BPF support I've discovered a EOO testing Issue in the reference Python that I'm running to ground. This will likely mean changes to the V2 code/ctests in radae (Python) & hence rade_c. Pls hold off on any labor intensive work like OTC verification testing with rade_c until I've run this one to ground, to avoid having to repeat if rade_c changes. I'll let you know when it's resolved.

[drowe67]

@tmiw @peterbmarks - it's Ok to use the rade_c code in #20 to proceed with verification of rade_c in your applications. I've split out the EOO testing and will handle that separately - it won't affect your verification, or require your to repeat verification.

Note a few tweaks to the verification procedure drowe67/radae#80 (comment)

[peterbmarks]

Ok, so the verification procedure to follow is: https://github.com/drowe67/radae/blob/dr-tx-bpf/doc/verification/verification_procedure.md ?

I'm on a bush walk but will be back this week and have another shot with FreeDVNeo when I get back.

[drowe67]

Ok, so the verification procedure to follow is: https://github.com/drowe67/radae/blob/dr-tx-bpf/doc/verification/verification_procedure.md ?

Yes.

I'm on a bush walk

Great! Which one?

[peterbmarks]

Yuaygir Coastal Walk.

https://www.nationalparks.nsw.gov.au/things-to-do/walking-tracks/yuraygir-coastal-walk

It's been pretty hot, 30C, found it quite challenging. Last day tomorrow.

Peter

[tmiw]

Thanks for the update.

As an experiment, I had Claude generate some changes to freedv-gui's CI to automatically generate the beginnings of the verification report for each supported platform. If this works, the only thing I'll have to do myself is the OTAC testing.

[drowe67]

As an experiment, I had Claude generate some changes to freedv-gui's CI to automatically generate the beginnings of the verification report for each supported platform. If this works, the only thing I'll have to do myself is the OTAC testing.

Automation is a good thing, however I'd like to minimise the amount of agentically generated boilerplate I have to review. If the reports are 95% identical (e.g. the same software on three different OSes) - it might make more sens to have one report with a table.

Can you pls list the # of reports you intend to generate with the key features of each (e.g software-under-test, OS)?

[tmiw]

Can you pls list the # of reports you intend to generate with the key features of each (e.g software-under-test, OS)?

I expect to have three for freedv-gui (one for each supported OS: Windows, macOS, Linux). Git hashes and versions for RADE/freedv-gui are expected to be the same across all reports and hopefully loss figures +/- a bit too.

[tmiw]

Forgot to add as well: commands to execute should be fairly similar on macOS and Linux, but Windows will be slightly different since the test scripts were ported to PowerShell for that OS.

[drowe67]

I expect to have three for freedv-gui (one for each supported OS: Windows, macOS, Linux). Git hashes and versions for RADE/freedv-gui are expected to be the same across all reports and hopefully loss figures +/- a bit too.

OK that's manageable by 3 separate reports. So you won't be verifying freedv-backend as a stand alone piece of software?

[tmiw]

OK that's manageable by 3 separate reports. So you won't be verifying freedv-backend as a stand alone piece of software?

No plans to do so right now since it's not intended to be used standalone. It's up to the developer integrating it to make sure they don't screw something up and cause failures.