Feature/dem 805/implement sampling rate float parameter

[qSaevar]

Changes proposed in this pull request:

• Set and Get the sampling rate of the ZIUHFLI using float.

@WilliamHPNielsen @jenshnielsen @astafan8

[codecov]

Codecov Report

Merging #1510 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #1510   +/-   ##
======================================
  Coverage    73.8%   73.8%           
======================================
  Files          92      92           
  Lines       10446   10446           
======================================
  Hits         7710    7710           
  Misses       2736    2736

[astafan8]

Modulo comments.

[qSaevar]

@astafan8 I addressed the your comments except the one with self.scope_samplingrate_float._save_val(ZIUHFLI._convert_to_float(nearest_frequency)) as it was left with a question mark. Should I do it?

[WilliamHPNielsen]

I am on a principal level against the behaviour introduced by the new parameter. I assume that the motivation for introducing a float/numeric sample rate parameter is that it is too cumbersome to write out, say, '1.80 GHz'. I sympathise with that viewpoint, and fully agree that passing 1.8e9 should work too.

What I strongly object to, however, is having parameters that silently fail when I set them. I consider setting a sample rate to 1.2e9 but actually getting one of 0.9e9 as a failure, since I am not getting what I am asking for. This is a fool-proof way to introduce very-hard-to-debug errors in measurement scripts, and against our normal policy. You'll have to work hard to convince me that this is a good idea ;)

There might be a need to handle floating-point imprecision, but that's a different story.

As a side note, the "nearest" frequency is not even well-defined. Why use a linear distance, when the allowed frequencies are evenly spaced on a logarithmic scale?

[qSaevar]

@WilliamHPNielsen I very well see your point and I'm not going to try and convince you. This behavior of setting the nearest point is how it works in the m4i driver, so there was a request for it in the uhfli driver as well.
But having the option of excepting and returning the sampling rate as float would still be very handy to have in many cases. So what if I make the "nearest" frequency a static method that finds the nearest allowed frequency, given some floating point number, that can in turn be used to set the sampling frequency? Something like:

sampling_rate = ZIUHFLI.round_to_nearest_sampling_frequency(desired_sampling_rate)
uhfli.scope_samplingrate_float(sampling_rate)

?

[WilliamHPNielsen]

@qSaevar I think what you propose with

sampling_rate = ZIUHFLI.round_to_nearest_sampling_frequency(desired_sampling_rate)
uhfli.scope_samplingrate_float(sampling_rate)

is a nice and clean solution.

Then the scope_samplingrate_float parameter can have an Enum validator only accepting the correct values, and the round_to_nearest_sampling_frequency method should then take care not to introduce floating-point errors, but that should not be too hard to implement.

[qSaevar]

@WilliamHPNielsen I updated the PR so now the scope_samplingrate_float parameter only accepts sampling rates that are allowed by the device. There is also a helping method that returns the closest sampling rate from some desired value and it is no longer linear as before.

[WilliamHPNielsen]

Looks terrific!