Well, I now have Gpredict and the venerable FT-736R working well together, with a few cautions.
Due to the radio's inability (by design) to return the operating frequency when polled, I have successfully built a simple Python script, that in essence sits between Gpredict and rigctld, handling (faking) those queries, while passing all other control commands etc through to rigctld.
This allows Gpredict to drive the radio quite well for the needed Doppler correction on LEO's. (CW beacons stay "tuned" plus listening to traffic via the SSB transponders is very much easier now, sort of, as yet, many users don't seem to Doppler correct their own uplinks.)
In the process of doing that, I discovered an annoying feature of rigctld in regards the w command (that I was using to enable/disable CAT on the radio). That in turn (thanks to Bill G4WJS, one of the Hamlib contributors) resulted in a proposed change to the way rigctld handles the radio "connection" and "disconnection".
Originally, when rigctld was launched, it grabbed the rig, locking out the front panel. Unless you power cycled the rig, or killed rigctld, then ran rigctl and issued a q command, one lost control of the radio.
It's not in the latest release candidate yet (3.2rc2) but may make it into 3.3 in time.
For now, the "lazy rigopen()" change can be found at:-
(You'll need to run the bootstrap tool before ./configure etc...)
This will monumentally grab the radio, then release it. Then waiting for a "Client" to connect to rigctld before grabbing the rig again. When the last client has disconnected, it will release the radio.
This works very well with Gpredict (and my fake VFO poll "helper") so that when you press the "Engage" button in the Radio Control dialogue, Gpredict takes over the radio as needed, plus when that button is released, so is control of the radio. Magic!
Note. The 736 has other issues, often needing manual intervention when Gpredict tries to set the main VFO to the same band as the Sub, or vice-versa (swapping bands typically, when changing birds) needing manual intervention at the rig, usually to put one or the other temporarily on 6m for example, so that the software can then configure it correctly.
I can let you (or anyone else) have a copy of my Python3 code as it is at the moment (it works, but it is not elegant) but I'm still trying to sort things out to make it much easier to get it all up and running (loading rigctld and the Python helper, THEN launching Gpredict) and shutting it all down gracefully when done.
(I need to find a Python guru to some questions re some of that! Know anyone? I've got the start-up working, but shutting down is still a manual process at this time, plus I can only test all this on Linux at the moment.)
So that's where I am at present. For me, it works well. Some aspects may help others. In particular, anyone else with a FT-736r, or another rig that hamlb doesn’t (yet) support, or is buggy, and they have Python skill's may find it useful.
Thoughts are now turning towards rotator control, but that's going to take a lot longer to sort out. (Needed physical hardware etc.)
73 Alex. (And listeners.)