Skip to content

Hamlib rotator support #455

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

Hamlib rotator support #455

wants to merge 3 commits into from

Conversation

df7cb
Copy link
Contributor

@df7cb df7cb commented Jan 12, 2025

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
Copy link
Contributor Author

df7cb commented Jan 12, 2025

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/qrb.c Outdated

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

pthread_mutex_lock(&tlf_rot_mutex);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/qrb.c Outdated

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

pthread_mutex_lock(&tlf_rot_mutex);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@dl1jbe
Copy link
Member

dl1jbe commented Apr 28, 2025

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

@df7cb
Copy link
Contributor Author

df7cb commented Apr 28, 2025

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

@df7cb
Copy link
Contributor Author

df7cb commented Apr 28, 2025

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
Copy link
Member

dl1jbe commented Apr 29, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants