Hamlib rotator support #455

df7cb · 2025-01-12T20:37:03Z

This adds Hamlib rotator support to tlf. When a call or prefix is entered, pressing Ctrl-D rotates the antenna to the calculated bearing.

df7cb · 2025-01-12T20:40:07Z

It works for me, but there's a few open ends:

hitting ESC should probably stop the rotator as well
so far, Ctrl-D works in the call input field only, but at least the exchange input should be covered as well
is Ctrl-D ("direction") the best key? Ctrl-R ("rotate") and Ctrl-Q (QTC) are already taken

Comments, feedback?

src/main.c

zcsahok · 2025-01-12T21:01:27Z

src/qrb.c

+
+	if (pfx_index != my.countrynr && 0 == get_qrb(&range, &bearing)) {
+
+	    pthread_mutex_lock(&tlf_rot_mutex);


do we need a mutex for rot?
rig controls are called from both threads (main + background), but rot looks to be called from main only.

another question: does rot_set_position() just send a message to the rotator and doesn't wait for it to actually reach to requested position?

We probably don't need the mutex now, but I would think it's safer to include it. New code might violate the assumption.

set_position just starts the rotation. You wouldn't want the rest of the program to halt for a minute while the antenna is turning...

Thanks for the review, will fix the variable init later.

Do hamlib guarantee that you can call functions for rig control and rotator control at the same time?
Otherwise (as set_position comes back immediately) why not use tlf_rig_mutex for both?

rig control and rotator control are talking to different devices, so calling functions at the same time is not a problem.

We could use the same mutex, but... this feels wrong.

Fwiw the next step would be to read out the bearing and show it in the UI (I get reminded about this every time I'm using the station from remote), there the mutex might already be required.

src/main.c

dl1jbe · 2025-01-13T14:37:26Z

src/qrb.c

+
+	if (pfx_index != my.countrynr && 0 == get_qrb(&range, &bearing)) {
+
+	    pthread_mutex_lock(&tlf_rot_mutex);


Do hamlib guarantee that you can call functions for rig control and rotator control at the same time?
Otherwise (as set_position comes back immediately) why not use tlf_rig_mutex for both?

src/qrb.c

tlf.1.in

dl1jbe · 2025-04-28T07:11:24Z

Can you please check, where the delete of test/test_rules.c comes from?

df7cb · 2025-04-28T07:59:37Z

Sorry, I should have pushed this to a different branch...

df7cb · 2025-04-28T08:07:48Z

I think this is good to go - these are the changes I've been using over the past weeks.

If people agree, I'll do the final polishing and push a rebased version.

dl1jbe · 2025-04-29T15:39:43Z

I think this is good to go - these are the changes I've been using over the past weeks.

If people agree, I'll do the final polishing and push a rebased version.

Looks mostly good. But can you please have a look at the failing tests? Thanks

df7cb · 2025-08-29T20:02:30Z

Sorry that it took so long, I always pick this up shortly before a contest, and after a weekend on the air, time is running out to actually submit it. Now I started a bit earlier...

I added the ability to rotate to the long-path direction. Since I was never really happy with Ctrl-D, keys are ^ (short-path) and & (long-path).

Since tests were not happy with hamlib code being in qrb.c, I moved the rotator interface to where the rig interface is living. sendqrg.c doesn't really fit (did it ever fit the rig interface?), but now similar code is in a similar place.

Tests are passing now. I think I addressed all concerns, IMHO the code is good to go now.

This adds rotator support. Configuration is done exactly like rig support with ROTATOR_CONTROL, ROTMODEL, ROTSPEED and ROTPORT. Two new keybindings are introduced: ^ (think "arrow") rotates towards the country of the current call, and & (the key right of ^ on US keyboards) rotates to the long-path direction. If the current call is from the own country, no rotation is done.

df7cb · 2025-09-23T20:27:21Z

Fwiw, I've been using this version of the rotator support in the last contests and for some casual operation. The ^ and & operations (short/long path) worked flawlessly.

dl1jbe · 2025-09-26T07:44:12Z

src/sendqrg.c

+    strncpy(my_rot->state.rotport.pathname, rotportname,
+	    TLFFILPATHLEN - 1);
+
+    my_rot->state.rotport.parm.serial.rate = serial_rate;


Please move away from using internal hamlib data structures. See PR #480 and #481 and the related discussion.

dl1jbe · 2025-09-26T07:49:00Z

src/sendqrg.c

+    retcode = rot_open(my_rot);
+
+    if (retcode != RIG_OK) {
+	TLF_LOG_WARN("rot_open: %s", rigerror(retcode));


As long as the main GUI is not initialized TLF_LOG_WARN will not work correctly. Please use show_rigerror() instead (see init_tlf_rig()).
Btw, in newer hamlib version rigerror() does return the accumulated error messages as far, not the error message for the last error (see discussion in last weeks on hamlib mailing list). If needed use tlf_rigerror() instead which respects the different implementations for the problem.

dl1jbe · 2025-09-26T07:49:29Z

src/sendqrg.c

+    pthread_mutex_unlock(&tlf_rot_mutex);
+
+    if (retcode != RIG_OK) {
+	TLF_LOG_WARN("Rotator get position error: %s", rigerror(retcode));


See above wrt rigerror()

dl1jbe · 2025-09-26T07:49:42Z

src/sendqrg.c

+	pthread_mutex_unlock(&tlf_rot_mutex);
+
+	if (retcode != RIG_OK) {
+	    TLF_LOG_WARN("Problem with setting rotator position: %s", rigerror(retcode));


dl1jbe · 2025-09-26T07:49:53Z

src/sendqrg.c

+    pthread_mutex_unlock(&tlf_rot_mutex);
+
+    if (retcode != RIG_OK) {
+	TLF_LOG_WARN("Rotator stop error: %s", rigerror(retcode));


again see above

dl1jbe · 2025-09-26T07:51:03Z

Sorry, for late comment - was afk for some time.

zcsahok reviewed Jan 12, 2025

View reviewed changes

src/main.c Outdated Show resolved Hide resolved

zcsahok reviewed Jan 12, 2025

View reviewed changes

dl1jbe reviewed Jan 13, 2025

View reviewed changes

src/main.c Outdated Show resolved Hide resolved

dl1jbe reviewed Jan 13, 2025

View reviewed changes

df7cb force-pushed the rotator branch from abfd19b to 06a0b4c Compare April 26, 2025 16:58

df7cb force-pushed the rotator branch from 06a0b4c to f7f850e Compare April 28, 2025 08:03

df7cb force-pushed the rotator branch 3 times, most recently from 8408dfa to 46afb1a Compare August 29, 2025 19:52

df7cb force-pushed the rotator branch from 46afb1a to 6c8e2ae Compare August 29, 2025 20:08

df7cb marked this pull request as ready for review August 29, 2025 20:57

dl1jbe requested changes Sep 26, 2025

View reviewed changes


		if (pfx_index != my.countrynr && 0 == get_qrb(&range, &bearing)) {

		pthread_mutex_lock(&tlf_rot_mutex);

Hamlib rotator support #455

Are you sure you want to change the base?

Hamlib rotator support #455

Uh oh!

Conversation

df7cb commented Jan 12, 2025

Uh oh!

df7cb commented Jan 12, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

dl1jbe commented Apr 28, 2025

Uh oh!

df7cb commented Apr 28, 2025

Uh oh!

df7cb commented Apr 28, 2025

Uh oh!

dl1jbe commented Apr 29, 2025

Uh oh!

df7cb commented Aug 29, 2025

Uh oh!

df7cb commented Sep 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dl1jbe commented Sep 26, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants