Step values for bandwidth and master clock ranges when querying a B series board are zero.

Issue Description

The step values for bandwidth and master clock ranges when querying a B series board are zero. This happens both with uhd_usrp_probe and by calling UHD from C++, indicating that this is not a bug on the application side.

Setup Details

USRP B series (tested and confirmed on B200, B205 and B210)
All OSes (tested and confirmed Windows, Ubuntu and ArchLinux)
Latest (tested and confirmed on 4.0 to 4.3)

Expected Behavior

The step value describes the actual allowed steps for the parameter.

Actual Behaviour

Steps to reproduce the problem

For the bandwidth, Run uhd_usrp_probe and look at the returned min/max/step values for bandwidth, or call dev->get_rx_bandwidth_range(channelID)
For the master clock, call dev->get_master_clock_rate() and inspect returned range(s).

Additional Information

Sample output from uhd_usrp_probe:

[INFO] [B200] Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
[INFO] [B200] Detected Device: B205mini
[INFO] [B200] Loading FPGA image: /usr/share/uhd/images/usrp_b205mini_fpga.bin...
[INFO] [B200] Operating over USB 3.
[INFO] [B200] Initialize CODEC control...
[INFO] [B200] Initialize Radio control...
[INFO] [B200] Performing register loopback test... 
[INFO] [B200] Register loopback test passed
[INFO] [B200] Setting master clock rate selection to 'automatic'.
[INFO] [B200] Asking for clock rate 16.000000 MHz... 
[INFO] [B200] Actually got clock rate 16.000000 MHz.
_____________________________________________________
/
|       Device: B-Series Device
|     _____________________________________________________
|    /
|   |       Mboard: B205mini
|   |   serial: XXXXXX
|   |   name: B205i
|   |   product: 30522
|   |   revision: 1
|   |   FW Version: 8.0
|   |   FPGA Version: 7.0
|   |   
|   |   Time sources:  none, internal, external
|   |   Clock sources: internal, external
|   |   Sensors: ref_locked
|   |     _____________________________________________________
|   |    /
|   |   |       RX DSP: 0
|   |   |   
|   |   |   Freq range: -8.000 to 8.000 MHz
|   |     _____________________________________________________
|   |    /
|   |   |       RX Dboard: A
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       RX Frontend: A
|   |   |   |   Name: FE-RX1
|   |   |   |   Antennas: TX/RX, RX2
|   |   |   |   Sensors: temp, rssi, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 76.0 step 1.0 dB
|   |   |   |   Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       RX Codec: A
|   |   |   |   Name: B205mini RX dual ADC
|   |   |   |   Gain Elements: None
|   |     _____________________________________________________
|   |    /
|   |   |       TX DSP: 0
|   |   |   
|   |   |   Freq range: -8.000 to 8.000 MHz
|   |     _____________________________________________________
|   |    /
|   |   |       TX Dboard: A
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Frontend: A
|   |   |   |   Name: FE-TX1
|   |   |   |   Antennas: TX/RX
|   |   |   |   Sensors: temp, lo_locked
|   |   |   |   Freq range: 50.000 to 6000.000 MHz
|   |   |   |   Gain range PGA: 0.0 to 89.8 step 0.2 dB
|   |   |   |   Bandwidth range: 200000.0 to 56000000.0 step 0.0 Hz
|   |   |   |   Connection Type: IQ
|   |   |   |   Uses LO offset: No
|   |   |     _____________________________________________________
|   |   |    /
|   |   |   |       TX Codec: A
|   |   |   |   Name: B205mini TX dual DAC
|   |   |   |   Gain Elements: None

Why this is problematic: Apps usually use fixed values for these settings which means people rarely run into this issue. For apps like SDR++ however, a comprehensive list of sample rates (which knowing the available master clock rates is needed for) and bandwidths must be generated. At the moment, since the step values are 0 I assumed that any multiple of 100KHz will work, but this is not general and probably wrong.

Hi @AlexandreRouma, thanks for this report! In fact, we almost never provide step sizes for our frequencies in UHD. For frequencies and clock rates, we usually use a coercion paradigm, where the setters won't throw, but will return the coerced value (or you need to call a getter).

The frequency accuracy on B2xx devices is much better than 100 kHz, usually, it's in the sub-Hz range. Let's say we had exactly 1 Hz accuracy, then for B2xx, you'd have to store a list of approx. 6 billion floats (70000000 Hz, 70000001 Hz, 70000002 Hz, all the way up to 6000000000 Hz). Even for the master clock rates, you'd be storing around 60 million values.

This is pretty inefficient, which is why you need a more efficient data structure. In UHD that is, you've guessed it, it's the uhd::freq_range_t, which stores (for contiguous ranges) start/stop/step, and for non-contiguous ranges multiple start and stop values (potentially with different step values for different sections).

Another reason we don't provide a step size here is b/c the steps to program BBPLL and all the various dividers is not straightforward and it's more complicated than stating a fixed step size over a bunch of ranges. It's not impossible to figure out the precise available rates, but given our coerce-and-query paradigm, it's of limited value. And again, it might have negative value if it would mean dragging around a massive data structure.

EttusResearch / uhd