Tlf
Hamlib rotator support
This adds Hamlib rotator support to tlf. When a call or prefix is entered, pressing Ctrl-D rotates the antenna to the calculated bearing.
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?
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.
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
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.
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.
Time is sparse atm. Hope to find time to look into it in coming week. Sorry.
At the moment I see only one point to think about:
if (pfx->dxcc_ctynr == my.countrynr)
return; /* rotating to own country does not make much sense */
It may make sense for large countries, but how to find the correct direction by program? The operator may know the correct direction - are there always manual controls or do we need to provide some solution from TLFs side?
I just pushed a new version addressing @zcsahok's comments, thanks for the review!
It may make sense for large countries, but how to find the correct direction by program? The operator may know the correct direction - are there always manual controls or do we need to provide some solution from TLFs side?
My next idea was to add "rotate 30° left/right buttons" (for example on [ and ] or < and >), but TBH I'd want the current patch committed first because it's kind of the minimum version of the feature we can then build on.
Other future ideas might be:
- show current heading (near the TRX frequency)
- ~check if
MYQRAis already used to compute the beam heading and if not, fix that~ MYQRA is already used - rotate to locator from exchange field
My next idea was to add "rotate 30° left/right buttons" (for example on
[and]or<and>), but TBH I'd want the current patch committed first because it's kind of the minimum version of the feature we can then build on.
The sounds reasonable.
As a side note: I fear that it will be difficult to find a lot of unused single key codes for additional rotator commands. As it probably will not be used very often a two key combination with a common first key may be appropriate (like '.' for filtering the multi infos).
Other future ideas might be: * show current heading (near the TRX frequency) * check if
MYQRAis already used to compute the beam heading and if not, fix that * rotate to locator from exchange field
At least the first point will be very useful.