FT-746R not releasing with gpredict

[mdblack98]

Anyway, invoking it thus... (From a bash script)
~/Local/bin/rigctld -m1010 -R -T localhost -t 50736 -r /dev/ttyFT736 -s 4800 &

(Running in the test build folder)

I still get control of the radio OK when "Engaging" it in Gpredict, but when "Disengaging" the radio still does not get released from CAT control. :-( That then needs a power cycle of the radio to regain front panel control.

With Htop running in an independent terminal, I can see one instance of rigctld when it is first loaded, before my Python script is started, and later Gpredict also started.

When the Gpredict user later "Engages" the radio, a second instance/job of rigctld starts, & the radio becomes controlled by the PC and runs fine. (But the user is locked out of the radio's front panel for many functions other than level controls. These older Yaesu's were a bit weird...)

When Gpredict's user "Disengages" the radio (to change to a different satellite for example) that second instance of rigctld vanishes, but the radio stays locked as it has not been released from CAT control, when using the 4.x Hamlib code. Using Bills 3.3 version rigctld code, the radio is released just fine.

[mdblack98]

From G8KBV
So... Yay... The non-releasing of the radio when the sole/last client disconnects is Fixed! (Happy dance commences!)

But... I've now found that this new version does something else odd.

It successfully puts the rig into "Satellite" Mode just fine when FIRST Engaged.

But after a Disengage, it seems unable to put the rig back into "Satellite" for subsequent "Engagements."
(Happy dance cancelled!)

[mdblack98]

gpredict was not re-opening the rig correctly so fixed it on my fork of github.
WIll add cached get_freq to eliminate need for shim to work with gpredict.