update sdrplay device notes

SDRPlay-device-notes.md

@@ -10,18 +10,17 @@ The SoapySDR module for SDRPlay devices is available here: https://github.com/po
 
 Like other Soapy supported devices, SDRPlay devices can take a single gain value. However, since the way the underlying gains are set up, this usually results in unpredicted results. See: https://github.com/pothosware/SoapySDRPlay/issues/60
 
-SDRPlay devices export two gain controls, IFGR and RFGR. Both of them are gain reduction values, so the higher the value you set, the lower your signal levels will be. This is important to understand since it is counter-intuitive and pretty much opposite to the behavior of other devices.
+SDRPlay devices export two gain controls via the SoapySDR layer: IFGR and RFGR. Both of them are gain reduction values, so the higher the value you set, the lower your signal levels will be. This is important to understand since it is counter-intuitive and pretty much opposite to the behavior of other devices.
 
 RFGR is set in steps starting at 0, the maximum depends on the device and input used. Each step equals approximately 6dB of attenuation.
 IFGR is set in dB, with a minimum of 20.
 
 Some examples:
-```
-"rf_gain": "IFGR=20,RFGR=4"
-"rf_gain": "RFGR=0,IFGR=40"
-```
 
-AGC is supported, to enable set `"rf_gain": "auto"`
+[[images/sdrplay_gain_example_1.png]]
+[[images/sdrplay_gain_example_2.png]]
+
+AGC is also supported, to enable set "Device Gain" to "Enable hardware AGC".
 
 # Common issues
 
@@ -29,12 +28,9 @@ AGC is supported, to enable set `"rf_gain": "auto"`
 
 There has been various reports of SDRPlay devices "failing" out of the blue on certain setups, without any obvious problems. Typically, the problem can be resolved temporarily by a restart of OpenWebRX, but will re-appear at a later point. The analysis shows that for reasons unknown to us, the startup of SDRPlay devices seems to be somewhat unpredictably unreliable, and since OpenWebRX will shut down SDR devices when they are not in use, this can occur pretty much at any time.
 
-The workaround to this issue is to set the `always-on` config option to `True` the device level:
-```
-"always-on": True
-```
+The workaround to this issue is to add and enable the "Keep device running at all times" option for your SDRPlay device in the web config.
 
-Please refer to the ["Configuration" section](https://github.com/jketterl/openwebrx/wiki/SDR-device-and-profile-configuration#always-on) for further details.
+[[images/always-on.png]]
 
 ## No SDR devices available when running in docker
 
@@ -54,6 +50,6 @@ Dual tuner mode consumes so much CPU that it cannot be used on any Raspberry Pi
 
 The SDRPlay API comes with a dedicated SDRPlay API service that manages interaction with the hardware. It is installed as a systemd unit and must be running to be able to access any SDRPlay devices.
 
-The process `sdrplay_apiService` has been seen consuming vast amounts of CPU (especially on SBCs like the Raspberry Pi) during normal operation. This seems to be expected, so please don't be alarmed if it does.
+The process `sdrplay_apiService` has been seen consuming noticable amounts of CPU (especially on SBCs like the Raspberry Pi) during normal operation. This seems to be expected, so please don't be alarmed if it does.
 
 If your device stops working and cannot be detected, the API service may have stopped working. You can restart it using the command `sudo systemctl restart sdrplay`.