Changed two-tone test assertions

[macylibed9]

Description

In dds_two_tone, there was a function that originally just grabbed the two highest amplitudes, but that didn’t guarantee they'd be the peaks closest to Frequency1 and Frequency2. So sometimes, it would just give you two peaks from the same frequency.

To fix it, I split the peak detection—one for Frequency1 and one for Frequency2—so each one gets its correct peak. Also, I cleaned up the assertions to make them more straightforward.

Fixes # (issue)

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How has this been tested?

Tested it on different actual boards, including ZC702 with FMCOMMS2-3 and ZedBoard with FMCOMMS4. I tried different values for frequency, scale, and peak_min to verify the behavior.

Documentation

If this is a new feature or example please mention or link any documentation. All new hardware interface classes require documentation.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have signed off all commits and they contain "Signed-off by: "
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[tfcollins]

I think this change makes sense but there is an existing bug in case the tones are far outside the tolerance (else condition) then the test will pass erroneously. Can you add an else clause?

[macylibed9]

Thanks! I simplified the assertion. In this version, if the tones are outside the tolerance, the assertions will still fail as expected, so it won’t pass erroneously.

[tfcollins]

@macylibed9 please run the precommit formatter

[macylibed9]

@macylibed9 please run the precommit formatter

done with precommit and lints are okay already. Thanks

[tfcollins]

Hardware tests are failing. Can you check what is going on? Tests that use the updated functions fail