Currently, ham2mon utilizes gr-osmosdr names for gains (RF, IF and BB). These are mapped by gr-osmosdr to what the underlying hardware supports. From the wiki, Here is an example of the mapping for BladeRF:
gr-osmosdr <-> bladeRF gain mappings
Source:
RF Gain: LNA Gain {0, 3, 6}
IF Gain: N/A
BB Gain: : RX VGA1 + RX VGA2 [5, 60]
For the Airspy SDR, this mapping limited how the hardware gains can be manipulated.
Proposed state with this enhancement
This enhancement ignores the gr-osmosdr gain mapping layer and interacts more directly with the gain names as exposed by the underlying hardware.
The underlying gain names are provided by gr-osmosdr through its existing API. Here is an example for BladeRF
There is also an gr-osmosdr interface to set gains by name.
This enhancement uses these interfaces to populate the ham2mon interface and make changes to the gains by name
Impact to user base
The gain names for a specific SDR may change from RF, IF and BB to what the underlying hardware supports
For example Airspy gain names will become LNA, MIX and IF
The gain mapping layer is no longer used
In the case of BladeRF changing BB gain changed both VGA1 and VGA based on the mixing rule
The gain levels for IF and BB are now bound by what the underlying hardware supports
They were previously not bound by either min/max or hardware specific gain step
Although this gives more control there may be unintended consequences.
Testing
Tested with an Airspy and RTL based device
The main() in receiver.py is hard coded for a uhd device
This is a testing function and not used when ham2mon is used
The gain name for uhd device is a guess
The values were temporarily changed for my Airspy and it worked as expected
With an RTL dongle it appears that the hardware supports certain levels of gain. Therefore, when user requests to change gain the hardware may not be able to support the request.
This also bounds the lower and upper limits based on what the hardware supports. Previously, the BB and IF gains were not bounded.
Existing ham2mon gain configuration
Currently, ham2mon utilizes gr-osmosdr names for gains (RF, IF and BB). These are mapped by gr-osmosdr to what the underlying hardware supports. From the wiki, Here is an example of the mapping for BladeRF:
For the Airspy SDR, this mapping limited how the hardware gains can be manipulated.
Proposed state with this enhancement
This enhancement ignores the gr-osmosdr gain mapping layer and interacts more directly with the gain names as exposed by the underlying hardware.
The underlying gain names are provided by gr-osmosdr through its existing API. Here is an example for BladeRF
There is also an gr-osmosdr interface to set gains by name.
This enhancement uses these interfaces to populate the ham2mon interface and make changes to the gains by name
Impact to user base
Although this gives more control there may be unintended consequences.
Testing
With an RTL dongle it appears that the hardware supports certain levels of gain. Therefore, when user requests to change gain the hardware may not be able to support the request.
This also bounds the lower and upper limits based on what the hardware supports. Previously, the BB and IF gains were not bounded.