Grig Bug Hunt Night

Phew… what a rush! I found and fixed bug after bug after bug after bug… the worst ones were in the rig-daemon, where the read values were overwritten by the last set values every time the specific set command was executed. This was the case for PTT, POWER and FREQ, and so the old display flicker problem has been solved, too. Cool

As for the RF power level reading from the FT-817 I have decided to modify the scaling factor in yaesu/ft817.c. The FT-817 returns the power level in 4 bits and this number is supposed to correspond to the number of bars on the FT-817 display. Well, the maximum reading I can achieve is 8 bars (appr. 4 watts) and as far as I can see there is only room for 10 bars at most, so I changed the scaling factor from 15.0 to 10.0. The power reading scale is not really linear, so still on the TODO list is to make a calibration curve for all bands and implement power2mW and mW2power functions.

On grig side I added code to store the highest possible rf power level for the rig. This number is assumed to correspond to 1.0 in the rig_get_level (RIG_LEVEL_RF_POWER) function. I agree that it would be much better to use power2mw, but that function requires all sorts of parameters like VFO and frequency and these parameters are not available in the S-meter object. I don’t want to add too much overhead into this code.
I have also implemented the scaling og the meter with full scales corresponding to 5, 10, 50, 100 and 500 watts. That should be all right for most rigs that I know of. The code even detects the most suitable range during startup.

The dynamics of the power meter is not particularly impressive. First, the needle jumps up every time the rig switches between RX and TX. In CW with short break-in delay this looks very silly. The problem is most likely som latency between switch to TX and grig registering the transition.
Besides that, the movement of the needle during transmission is not very smooth. I think it is a combination of too slow motion (sw param) and too slow polling. The latter may be helped when I optimise the daemon by removing the idle call delays.