The radio control for RS-44 is non-inverting for some reason that I can’t fathom which makes it unusable.
I believe that the transponder data comes from the SatNOGS DB, and some of the details for that satellite entry are incorrect. I’ve suggested an update but will have to wait to see if it gets updated, and the changes fix this problem.
While i experienced the same issue, it is far from “unusable”. You pick a downlink frequency and then just use simple math to figure out the rough area you’re are supposed to be in, then just start transmitting and “find” your signal. It’s no different than what all the guys do in the field when they don’t have computer control.
Yes, I do that right now, but the point of using Gpredict is to have computer controlled doppler correction. It doesn’t work for RS-44, when the freqs are locked they don’t invert sooo it’s unusable 
Yes, it DOES still correct for doppler. With “track” and “engage” selected, but “L” de-selected, all you have to do is find your downlink. Gpredict will then correct the doppler based on those two base frequencies.
I currently do manual doppler correction using a piece of paper as I’m only operating satellites “in the field”.
Using Gpredict on a Raspberry-pi is meant to be a step up in automation, the Lock function giving the ability to find stations and quickly reply to them; doing it the manual way is far from trivial particularly with a hand held antenna and microphone whilst trying to write down the callsign etc.
Gpredict works with all the other satellites (AFAIK) including the Lock function but not RS-44, and this is the place to raise such an issue for Alex, and let other users know there’s a problem.
The SatNOGS DB entry that Gpredict draws from has been updated but the Lock function in Radio Control is still broken, it works non-inverted when it should be inverted.
Well, I don’t know about you… but I have yet to experience any linear that doesn’t need to be manually tuned in Gpredict to get “on frequency”, so for RS-44, the only difference for me is that I have to “spin the dial” in order to get “on frequency”, rather than just turn it a quarter of a turn or so.
This is now fixed.
It would appear that the increased detail added to the SatNOGS DB entry has given Gpredict the information it needed to function correctly. Thanks to @fredy for adding to the DB entry.