BladeRF 2 Frequency/Gain Test Fix

[QuantumEF]

Get the frequency and gain ranges from the device and use to set an exact frequency/gain supported by the device in the tests.

This relates to the conversation in #23 where the tests failed on the BladeRF 2.0 due to its range being different than the BladeRF 1.

HW tests for the BladeRF1 still pass.

[TroyNeubauer]

Nice

Doesnt work on my 2.0 micro for some reason:

cargo t --features hwtest_brf2
...
running 6 tests
test tests::test_get_nearest_frequency ... ok
test types::format::tests::cf32_to_ci16_conversions ... ok
test types::format::tests::ci16_to_cf32_conversions ... ok
test types::version::tests::version_cmp ... ok
test types::format::tests::sanity_check_fixed_i11 ... ok
test types::layout::tests::layout_conversions ... ok

test result: ok. 6 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

     Running tests/hardware_any.rs (target/debug/deps/hardware_any-795aaaaf5a3192e7)

running 19 tests
test get_board_name ... ok
test device_reset ... ok
test get_set_frequency ... FAILED
test is_fpga_configured ... ok
test get_set_rx_mux ... ok
test list_devices ... ok
test get_set_loopback ... ok
test print_fpga_size ... ok
test open_with_devinfo ... ok
test get_set_sample_rate ... ok
test open_first_device ... ok
test print_serial ... ok
test get_set_bandwidth ... ok
test print_info ... ok
test rx_streamer_reconfigure ... ok
test print_firmware_version ... ok
[WARNING @ host/libraries/libbladeRF/src/bladerf.c:563] Setting gain mode to manual
test get_set_gain ... FAILED

test print_fpga_version ... ok
test rx_streamer_toggle_enabled ... ok

failures:

---- get_set_frequency stdout ----
thread 'get_set_frequency' panicked at tests/hardware_any.rs:155:5:
assertion `left == right` failed
  left: 433500000
 right: 433499998
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- get_set_gain stdout ----
[tests/hardware_any.rs:197:5] gain_range = Range {
    min: -15.0,
    max: 60.0,
    step: 1.0,
}
[tests/hardware_any.rs:197:5] set_gain = 20
thread 'get_set_gain' panicked at tests/hardware_any.rs:201:5:
assertion `left == right` failed
  left: 20
 right: 60


failures:
    get_set_frequency
    get_set_gain

test result: FAILED. 17 passed; 2 failed; 0 ignored; 0 measured; 0 filtered out; finished in 35.17s

Approving since Ill fix separately with my device

[QuantumEF]

Oh, weird. The goal with this PR is that it will work on the Bladerf 2.0 I will you merge this whenever you have time to look into and try fix the issue.

[TroyNeubauer]

This diff fixes the tests failing on the 2.0 board.
Appears that the RF module has to be enabled before setting gain on the 2.0 micro

diff --git a/tests/hardware_any.rs b/tests/hardware_any.rs
index 939b7b9..a034a4a 100644
--- a/tests/hardware_any.rs
+++ b/tests/hardware_any.rs
@@ -152,14 +152,14 @@ fn get_set_frequency() -> Result<()> {

     device.set_frequency(CHANNEL, set_frequency)?;
     let getter_frequency = device.get_frequency(CHANNEL)?;
-    assert_eq!(set_frequency, getter_frequency);
+    assert!(set_frequency.abs_diff(getter_frequency) < 5);

     let set_frequency = 915_000_000;
     let set_frequency = get_nearest_frequency(set_frequency, frequency_range);

     device.set_frequency(CHANNEL, set_frequency)?;
     let getter_frequency = device.get_frequency(CHANNEL)?;
-    assert_eq!(set_frequency, getter_frequency);
+    assert!(set_frequency.abs_diff(getter_frequency) < 5);
     Ok(())
 }

@@ -190,6 +190,8 @@ fn get_set_gain() -> Result<()> {

     let device = BladeRfAny::open_first()?;

+    device.set_enable_module(CHANNEL, true)?;
     let gain_range = device.get_gain_range(CHANNEL)?;

     let set_gain = 20;

[QuantumEF]

Oh, that is annoying because I did not really want the user calling enable_module directly.

Also if you switch back the abs_diff() code, does it still fail? My intent was that the get_nearest_frequency method would take care of that.

[QuantumEF]

Can you send me the output of get_frequency_range() for your device?

[TroyNeubauer]

Seems like an upstream issue. If the device can select 433499998 properly, then it should also be able to select 433500000 given that the reported step size is two:

---- get_set_frequency stdout ----
[tests/hardware_any.rs:149:5] &frequency_range = Range {
    min: 70000000.0,
    max: 6000000000.0,
    step: 2.0,
}
thread 'get_set_frequency' panicked at tests/hardware_any.rs:156:5:
assertion `left == right` failed
  left: 433500000
 right: 433499998

[QuantumEF]

I see, well, I guess those tests were a waste of time 🙃

I will probably update the documentation comments noting that the "get_nearest" functions don't actually work, and then merge this.

[TroyNeubauer]

Seems reasonable. I would include the abs diff stuff to ensure that tests work on brf2 though.