Radio control error, causes unexpected program exit


Gpredict 2.2.1 on Linux Mint 18.2 32 bit. Installed from PPA, the Ubuntu 16.04 version. (If that’s the wrong one for Mint 18.2, let me know please, but the system/PPA logic chose it!)

Firstly, a nice refresh of a classic theme, and largely it all seems to work OK.

However a problem. If the Radio control TCP link to Hamlib dies, the entire Gpredict program just quits, without saving it’s state etc. I’ve not checked if it leaves any zombies in RAM, but the earlier 1.x.x version just calmly closed the TCP link and the main program carried on, no crash.

This is proving “inconvenient” to say the least, as due to Hamlib’s inability to correctly setup and use the FT736 in true Satellite mode (the differences are too great for a simple back-end mod’) I’m trying to put something specific together with Python (not very successfully at the mo, hence all the TCP link errors!)

Is this sudden quit of Gpredict “intentional”, or ???


PS: I can’t seem to specify a relevant tag “radio control” for example.

Hi Dave,

Gpredict should most certainly not die when a communication error occurs. We have tested it quite a lot, but there can still be bugs left in the new code. If we could reproduce it using the “dummy” backend or a known sequence of events it would be very helpful.

You could run gpredict from a terminal to see if it prints any errors. There may also be something in the log file located at ~/.config/Gpredict/logs/gpredict.log


Hello Alex.

Thanks for the reply.

I ran Gpredict from a terminal, and tried to use the Radio interface, pointed at a non existent rigctld daemon, like, no port open to connect to.

This is the resulting terminal session.

dave@Shack-EQUIUM-P200D ~ $ gpredict
*** BUG ***
In pixman_region32_copy: Malformed region dst
Set a breakpoint on ‘_pixman_log_error’ to debug

Segmentation fault
dave@Shack-EQUIUM-P200D ~ $

The first line started Gpredict, with no messages.
The *** BUG *** line was a result of clicking the “Engage” button in the Radio control dialog, after selecting a viable bird, as before, with no active daemon (or other tool) listening on the port it was trying to get to. (5000)

This below was in the gpredict.log file.

2018/02/28 21:52:03|3|sat_log_init: Session started
2018/02/28 21:52:03|4|sat_cfg_load: Everything OK.
2018/02/28 21:52:45|1|open_rigctld_socket: Failed to connect to localhost:5000
2018/02/28 21:52:45|1|_send_rigctld_command: SIZE ERROR -1 / 13
2018/02/28 21:52:45|1|_send_rigctld_command: rigctld port closed
2018/02/28 21:52:45|1|_send_rigctld_command: SIZE ERROR -1 / 13
2018/02/28 21:52:45|1|_send_rigctld_command: rigctld port closed
2018/02/28 21:52:46|1|open_rigctld_socket: Failed to connect to localhost:5000
2018/02/28 21:52:46|1|_send_rigctld_command: SIZE ERROR -1 / 13
2018/02/28 21:52:46|1|_send_rigctld_command: rigctld port closed
2018/02/28 21:52:46|1|_send_rigctld_command: SIZE ERROR -1 / 13
2018/02/28 21:52:46|1|_send_rigctld_command: rigctld port closed
2018/02/28 21:52:47|1|open_rigctld_socket: Failed to connect to localhost:5000
2018/02/28 21:52:47|1|_send_rigctld_command: SIZE ERROR -1 / 13
2018/02/28 21:52:47|1|_send_rigctld_command: rigctld port closed
2018/02/28 21:52:47|1|_send_rigctld_command: SIZE ERROR -1 / 13
2018/02/28 21:52:47|1|_send_rigctld_command: rigctld port closed

Hope something helps.

The earlier version, (V 1.x.x as per Mint’s own software repo) just un-highlights the Engage button and the program as a whole stays active with no fuss.

73 Alex.

Dave 'KBV

Thanks for the info. I did see the pixman error once, but I can not reproduce the crash. For me it just disables the engage button. It sounds like we need to review the code again.

I opened and issue on github to make sure I do not forget about it.

1 Like

Thanks Alex.


Due to the way Hamlib fails to drive the venerable FT736r correctly for true satellite working (full duplex with independent adjustment of uplink & downlink frequency and mode, by any means, manual or programmed) plus from what I’ve seen, changes would be needed not just to that radio’s back end code, but elsewhere so may change other functionality. As a result it is way beyond my C/C++ abilities, plus I’ve had a very bad experience with the Hamlib support types in the past.
(They don’t take kindly to noobs, even if they might just know a thing or two about hardware & instrument control, in other walks of life! Plus, the documentation is crap, for non C/C++ people.)

As a result, I’ve been playing with Python(v3) to see if its viable to do what’s necessary to have Gpredict drive the radio in the way that is needed, through a stand-alone Python utility, with a socket server on one end, and RS232 driver on the other, with “glue” in the middle. For the moment, just echoing what Gpredict sends, to the console, and sending back the OK (no error) code so Gpredict runs without problems, would be an achievement for me!

Now, I’m also a total noob with Python, though I’ve done some small utils to talk to my TS-870s over RS232 etc, with good success.

So, I’ve been messing with the example server code at:-

(among others…)

That shows me what Gpredict is sending, but try as I might, I can’t get the OK “no error” code (a byte value of zero, as far as I can tell from the Hamlib sources) back into Gpredict. As a result, it crashes and burns a lot of times, rather than just “disengaging” the radio, and perhaps logging why…

As you can imagine, utterly frustrating!

I do see it trying to communicate 3 times, then sending what seems to be a Quit command to the driver, and ceasing communication, with the earlier 1.x.x version.
Though even that doesn’t seem to “close” Hamlib and tidy up, releasing the radio from CAT control. (Grig does however!)

Enough for now, its been a long day, I need sleep, another long one tomorrow, and now the cats are fighting, again…

73 Alex.

Dave 'KBV

One thing that server implementations often fail to implement in the first round is the reply message from server. Gpredict does expect the RPRT 0 messages, see

Hi Again Alex.

Thanks for that tip re “RPRT 0”. I just found it in the man-pages myself.
For once, man-pages that are actually useful!

So useful, that I now have “the recipe” as to how to setup and manipulate the 736 correctly with Hamlib for full duplex satellite working. (Uplink on Sub, Downlink on Main)
And how to shut it down in a way that leaves it set for manual use again.
(Needing the use of the Hamlib ‘w’ command.)

Anyway, adding the ability to send back ‘RPRT 0’ to my bit of Python, Gpredict no longer spits it’s dummy out and dies, so that’s good. The behavior is now like the earlier version, just dropping the link to the “Rig” driver, and un-highlighting the “Engage” button, when it for whatever reason doesn’t understand, or looses sight of the radio.

But I do see it asking to read the rig’s operating frequencies. (Hamlif f and i query commands, in the case of split/sat’ mode.)

Now, the FT-736 does not support that, and the Hamlib back-end doesn’t fake it either.

I see in the radio interface module configuration dialog, that it is possible to tell Gpredict not to poll the PTT status (PTT Status = None/Read PTT/Read DCD.)

(The Hamlib ‘T’ command does work as advertised with the 736, but not the ‘t’ query command.)

How easy/quick would it be, to add the ability to configure Gpredict NOT to attempt to read back the rig’s frequency, much like the setting above, for the PTT status? (VFO Status = Poll/None) Perhaps.

Another useful feature would be a configurable “disconnect” command string, to be sent with the Hamlib ‘w’ command if needed when the radio control is “Disengaged”, to turn off the CAT functions at the radio so it can be used again for manual terrestrial use, not needing a power cycle…

In Hamlib terms:-
w \0x00\0x00\0x00\0x00\0x80
Puts the radio back into local user “Manual” mode (With CAT On, much of the front panel controls are locked.)

That I think would make it compatible with the venerable but still useful FT-736, and maybe other radios, though I can’t think of what.

I am more than willing to Beta test etc having a 736 here, but my understanding of the sources is not good enough to attempt those changes myself. I have looked!

Best Regards Alex.

Dave KBV

Hi Dave,

Not easy. The radio controller is built up around the concept of working interactively with the radio front panel, so that when you are working the linear sats, you can tune around and gpredict follows automatically so that the TX frequency matches the RX frequency.

I am generally not crazy about adding such things, but I don’t want to dismiss the idea (yet). It may be added during a future rework of the controller; however, right now we still need a lot of fixing and validation of the existing code before we can add such things.

Why not continues with your python script? It sounds like you are almost there.

My preferred model for the future would be a simplification of the gpredict codebase. Gpredict would not contain any special code, like the FT-817 mode, but such things would be handled by the server. Either hamlib server or a dedicated server for a specific radio.


Hi Alex.

Have to say, I agree 100% with your philosophy re keeping the Gpredict code-base as simplified as possible, moving all the individual radio/rotator etc control needs to external modules, be that Hamlib, or “some other” custom code. Not a problem.

I only asked on “if you don’t ask, you’ll never know” basis, so now I know!

I am continuing with the Python script, the intention at the moment is to place that between Gpredict and Hamlib, though I have used Python with direct serial I/O in the past so if needed the radio driver can be all in Python if all else fails. Using Hamlib however, offloads a lot of that to existing code that is already proven cross platform!

One question though. What does the AOS/LOS signaling check boxes enable in the Radio configuration dialog?

I don’t see any extra codes coming out of Gpredict when a bird crosses the threshold with them enabled, or hear any audible alerts from the PC. They don’t seem to be documented in the user manual either.

Several links to the documentation don’t all go to the places you’d expect, either, such as the “Dowload” link near the top of the page at ! The “direct link” works, but as above those features are not listed that I can see in the file it pull’s.

Anyway, I’ll plug on with this, when I have it working to my satisfaction, I’ll let you know, and put notes and code somewhere they can be accessed, to save anyone else re-inventing the wheel as it were.

73 Alex.


Hi Dave,

Enabling these will send “AOS” and “LOS” text message to the radio. Currently, gqrx uses it to start and stop audio recording.

Please do. I started collecting radio specific tech notes in the code repository to provide detailed setup info from users who actually use the radios. I plan to make these notes accessible through the Help menu in the program.


Hi Alex.

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.)

Dave G8KBV.

1 Like

CORRECTED Sourceforge link…

Dave G8KBV

Hang on a mo… It’s all gone horribly wrong with SourceForge. The proposed change is not found.
I’ll be back when I’ve got a working link to the correct trial version…
Dave G8KBV.

Hi Dave,

Thanks for the update!

Regarding link, there is also a mirror on github:
Perhaps it’s there?


Hi Alex.


I’ve just grabbed a snapshot (takes a long time to build that before downloading) unzipped (to a unique folder) and built it OK, resulting in an instance of rigctld in the “tests” folder, doing what is intended.

I’ve just tried several different ways to send the my python file but even if I upload it as a text file, as Google wont allow zip’s or the usual stuff. But sent as any other “permitted” extension, it scrambles this mail system. (How best to put that on here for others, is there a file store somewhere?) I even tried copying the file as text, into this message. Nah! Utter disaster, according to the preview pane.

In any case, at the moment, one needs to start rigctld first, in a terminal of it’s own, then (needs Python3 by the way) in another terminal, then you can start gpredict etc, configure it to point to rigsvr, and away you go…

It’d be great if someone else with a FT-736R and a Linux user, could try it. Even better, if a Windows user with Python skill’s could also try it, but I think it’ll need converting to call a DLL, rather than talk to a daemon. I have little to no experience of Hamlib on Windows (other than what comes with Fldigi, and that can be unreliable, Hamlib that is, not Fldigi!)


73 Alex.

Dave G8KBV.

Also found:-
MUCH easier to track things down!

Oh yes, attached is my “” python script, that allows gpredict to run successfully with hamlib, so long as the future hamlib V3.3 branch is used.

It could also be the basis of a 100% python rig driver, for anything…

Dave G8KBV.
rigsvr.pdf (19.6 KB)


Nice, thanks for the script Dave.