Gpredict hangs when engaging antenna control (windows)

I’m running Gpredict for windows 2.2.1, along with hamlib for windows w64-3.2. After finding this setup to work beautifully under debian and ubuntu, I’m trying to run it on a windows machine due to the availability of better SDR software (I’m really liking SDRuno, paired with a new RSP1a).

I’m glad to see there is windows support for both packages, however trying to run the antenna control on both windows 7 and windows 10 machines seems to result in a hang.

The gpredict console displays the following:

Starting rotctld client thread

The verbose logging on rotctld displays the following when launching:

Opened rot model 1, ‘Dummy’

The rotator does not move when the antenna control is engaged, gpredict will hang when trying to disengage the control. When I kill the gpredict process with task manager, the rotator (a Celestron goto telescope mount) will orient to a random position (the ‘dummy’ above is for testing, it results in the same problem).

The rotator moves as expected with the rotctl program with manual input.

Any help on this would be appreciated! I love the gpredict + hamlib setup, unfortunately windows is making things more difficult than it needs to be (again).

Some additional info of note:

Gpredict version 1.3.3 seems to work fine, which is the latest 1.x windows version I could find. All windows builds of 2.x seem to have a similar problem.

This will hold me over and I’m glad to having a working arrangement; it’d still be nice to get 2.2.1 running.

Thanks for the info.

I wonder whether this is related to some end of line characters that are different on linux and windows. I believe there have been some changes in that area.

You can enable debugging in rotctld using -vvvvvv (more v’s give more verbose messages) to the point where it even prints received characters. Perhaps that can give some hints.


Thanks for the tip - below is a paste of what rotctld sees, I’ve added comments to depict when things are happening.

C:\Program Files (x86)\hamlib-w64-3.2\bin>rotctld -vvvvvv rotctld, Hamlib 3.2 Report bugs to rot_init called dummy: _init called rot_register (1) rot_register (2) dummy_rot_init called rot_open called dummy_rot_open called Opened rot model 1, 'Dummy' rig_strstatus called Backend version: 0.2, Status: Beta

Antenna control is engaged below

Connection opened from VRproject3:64028
rotctl(d): p ‘’ ‘’ ‘’ ‘’
rot_get_position called
dummy_rot_get_position called
rotctl(d): p ‘’ ‘’ ‘’ ‘’
rot_get_position called
dummy_rot_get_position called

Antenna control is still engaged at this point but only seems to poll twice, various postions are requested within gpredict and tracking is enabled/disabled but this does not seem to transfer to rotctld

Below is what rotctld received when gpredict is force quit

rotctl(d): P ‘180.00’ ‘45.00S’ ‘’ ‘’
rot_set_position called
dummy_rot_set_position called: 180.00 45.00
Connection closed from VRproject3:64028

Ok, thanks. Perhaps gpredict is not happy with the response sent by rotctld. You can see the gpredict log in File -> Log browser

Thanks Alex; for reference - the log from gpredict is below, logging level has been set to 4

2018/04/18 16:18:46|3|sat_log_init: Session started 2018/04/18 16:18:46|4|sat_cfg_load: Everything OK. 2018/04/18 16:18:46|4|first_time_check_step_02: Found at least one .qth file. 2018/04/18 16:18:46|4|first_time_check_step_03: Check successful. 2018/04/18 16:18:46|4|first_time_check_step_04: Check successful. 2018/04/18 16:18:46|4|first_time_check_step_06: Check successful. 2018/04/18 16:18:46|4|first_time_check_step_07: Check successful. 2018/04/18 16:18:46|4|first_time_check_step_08: Check successful. 2018/04/18 16:18:47|4|gtk_sat_module_read_cfg_data: Reading configuration from C:\Users\da1779\Gpredict\modules\Amateur.mod 2018/04/18 16:18:47|4|qth_data_read: QTH data: C:\Users\da1779\Gpredict\sample.qth 2018/04/18 16:18:47|3|qth_data_read: QTH data: sample, 55.6167, 12.6500, 5 2018/04/18 16:18:47|4|gtk_sat_module_read_cfg_data: GRID(15): 1;0;2;0;1;2;0;1;1;2;3;1;2;1;2 2018/04/18 16:18:47|4|gtk_sat_module_load_sats: Read data for #24278 2018/04/18 16:18:47|4|gtk_sat_module_load_sats: Read data for #25544 2018/04/18 16:18:47|4|gtk_sat_module_load_sats: Read data for #27607 2018/04/18 16:18:47|4|gtk_sat_module_load_sats: Read data for #39444 2018/04/18 16:18:47|4|gtk_sat_module_load_sats: Read data for #40967 2018/04/18 16:18:47|4|gtk_sat_module_load_sats: Read data for #43017 2018/04/18 16:18:47|3|gtk_sat_module_load_sats: Read 6 out of 6 satellites 2018/04/18 16:18:47|4|create_module_layout: Layout has 2 columns and 2 rows. 2018/04/18 16:18:47|4|../src/gtk-sat-map.c:1015: Loading map file C:\gpredict\share\gpredict\pixmaps\maps\nasa-bmng-07_1024.jpg 2018/04/18 16:18:47|4|../src/gtk-sat-map.c:1021: Map file found 2018/04/18 16:18:47|3|mod_mgr_add_module: Added Amateur to module manager (page 0). 2018/04/18 16:18:54|3|Loaded new rotator configuration test 2018/04/18 16:18:56|4|rotctld_socket_open: Network socket created successfully 2018/04/18 16:18:56|4|rotctld_socket_open: Connection opened to localhost:4533

Strange, there is nothing in the gpredict log that suggests any any problems. I have no idea.

Good Afternoon - I’m experiencing the same issue with the rotor control causing Gpredict versions 2.0 and later to hang. The rotor doesn’t turn until after I terminate the non-responsive Gpredict program. I’m using the Arduino Board and interfacing it with HAMLIB.

Here is the error window from HAMLIB:

rotctl(d): p ·· ·· ·· ··
easycomm_rot_get_position called
easycomm_transaction called: AZ El
write_block(): TX 7 bytes
0000 41 5a 20 45 4c 20 0a AZ El .
read_string() : Timed out 0.877915 seconds after 0 chars
easycomm_transaction read_string failed with status -5

If I click on the rotor control Engage button the Gpredict program hangs.

As stated earlier versions 1.0 to 1.4 work but 2.0 and greater fail.

Regards - Mark

Hi Mark,

I can’t think of anything useful to say here :frowning:

The error seems to come from hamlib, so how can it depend on the gpredict version… Does the rotator work with hamlib rotctl alone?


I see exactly the same using Win10 Pro, Gpredict 2.2.1, hamlib w64-3.2, arduino with K3NG’s firmware and G-5500 rotator.

Same setup works perfectly on Ubuntu 16.10.

Hamlib is started like this:
rotctld.exe -m 601 -r com3 -T -t 4533 -vvvvv

Tried hamlib w32-3.2 and w32-3.0.1, same problem.
Tried Gpredict “1.4git”, no problems, works great on Win10 Pro

There seems to be two patterns:
1: Gpredict crashes when it tries to move the rotator.
2: No problems when Gredict starts up with rotator in right position until I change target position…

And here comes all the details I can think of…

Pattern 1:
This is what I observe with a rotator initially at a “wrong” position azi/el = 177/33

  • Opens “Antenna control” window, shows azi/el = 180/45 (why…?)

  • Presses “Engage”

  • Rotator position is read ONE single time, rotctld reports:
    Connection opened from
    rotctl(d): p ‘’ ‘’ ‘’ ‘’
    gs232a_rot_get_position called
    write_block(): TX 3 bytes
    0000 43 32 0d C2.
    read_string(): RX 11 characters
    0000 2b 30 31 37 37 2b 30 30 33 33 0d +0177+0033.
    gs232a_rot_get_position: (az, el) = (177.0, 33.0)

  • No more activity from rotctld

  • “Antenna control” window shows correct position azi/ele = 177/33 but controls in both this and main window are all “frozen”.

  • Logfile shows:
    2018/06/14 23:13:51|4|rotctld_socket_open: Network socket created successfully
    2018/06/14 23:13:51|4|rotctld_socket_open: Connection opened to

  • I try to close “Antenna control” window, Win10 reports “No response da-da…”, both this and Gpredict main window are finally closed but then…:

  • rotctld wakes up briefly:
    rotctl(d): P ‘180,00’ ‘45,00S’ ‘’ ‘’
    gs232a_rot_set_position called: 180.000000 45.000000
    write_block(): TX 9 bytes
    0000 57 31 38 30 20 30 34 35 0d W180 045.
    read_string(): RX 1 characters
    0000 0d .
    Connection closed from

  • This goto command is forwarded to rotator and rotator moves correctly to azi/ele = 177/45 (OK, inside tolerance 5 deg)

  • No more activity from rotctld

  • Logfile has no new messages

Pattern 2:
This is what I observe with a rotator initially at “right” position azi/el = 177/45 (inside tolerance):

  • Opens “Antenna control” window, it shows azi/el = 180/45

  • Presses “Engage”

  • Rotator position is continously read as azi/ele = 177/45 which is correct, no moves are needed, rotctld shows a steady flow of read commands, everything looks OK.

  • …until I change target position and Gpredict decides to move rotator, then pattern 1 is back.

OK Alex,
I’ll be happy to assist with some debugging if needed, just mail me some suggestions or debug-binaries at

Regards Jesper

Hi Alex,
I just tried rotctl, it seems to work OK:

rotctl -m 601 -r com3 -vvvvv P 30 30

…and similar moves the rotator around as intended.

Regards Jesper

On my system I can write a “Fake” rotctld to log what GPredict is sending I feel like it may help.

Greetings Alex - I think it’s some type of read error from HAMLIB to Gpredict. Gpredict versions 1.0 to 1.4 work with HAMLIB but something changed in Gpredict 2.0 and later which causes the read error and then the hanging failure of Gpredict.

Did you change the read statements between versions? Maybe a different compiler? I tried a 32 bit machine and had the same error on the 64 bit machine. Not real sure.

Thanks for responding. Hopefully we can track down the problem together. I’m a pretty good troubleshooter.

What language did you use to write Gpredict?

Please let me know how I can help?

73’s Mark

Just an idea:
Have you tried to force hardware flow control to be disabled for the serial connection?

I have suspected that this is an issue specific for the windows build, since both @DL4PD and I have tested the rotator controller under Linux.

I am busy with others things at the moment but I will take a look at it when I resume working on gpredict later this year. There is now an issue on Github to make sure I don’t forget about this.


1 Like

If you mean HW flow-control for the hamlib <-> Rotator connection (arduino + K3NG firmware in my case), it is already disabled.

  • jesper


I cannot reproduce this issue on Ubuntu 16.04 LTS and 18.04 LTS.
I am sorry, but I cannot run it on any Windows host - no Windows on my side…

1 Like

For those able to build the source code. Check out: This patch works for me.

There is now a windows binary built from the current development tree in case anybody wants to test it:

I downloaded 2.3.37 and tested on Win10, antenna control is now perfectly OK.
Just to be sure I tested once again using 2.2.1 and this version crashed immediately as we saw earlier. Then back to 2.3.37, no problems.
Thanks! :slight_smile: