Skip to content
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

Add keyword to disable rig mode setting #286

Open
dl1jbe opened this issue Nov 1, 2021 · 11 comments
Open

Add keyword to disable rig mode setting #286

dl1jbe opened this issue Nov 1, 2021 · 11 comments

Comments

@dl1jbe
Copy link
Member

dl1jbe commented Nov 1, 2021

By Onno VK6FLAB on the mailing list

For some use cases it is preferable to run contest mode independent of rig mode, e.g. keeping the rig in UBS while runiing a CW contest.

As discussed on the ML there should be a keyword which inhibits all mode settings via hamlib from TLF.

@darvark
Copy link
Contributor

darvark commented Jul 1, 2023

Hi, I would like to start working on that ticket.

@zcsahok
Copy link
Member

zcsahok commented Jul 1, 2023

Here is the original mail for the record
https://lists.nongnu.org/archive/html/tlf-devel/2021-10/msg00009.html

TLF currently synchronizes with the rig practically only one way, TLF->rig:

  • user switches mode with :CW or :SSB (or :DIGI). set_outfreq(SETxxMODE) is called in changepars.c and then processed by gettxinfo.c in the background.
  • in case of a band switch the rig's mode is updated in handle_trx_bandswitch().

There is no handling of the rig->TLF direction: mode changes on the rig are not reflected on TLF side. (could be even a bug)

As far as I understood, the idea is to totally decouple TLF's mode (trxmode) from the actual mode of the rig. Looks like suppressing execution of SETxxMODE operations and skipping handle_trx_bandswitch() would be enough.

Any thoughts?

@darvark
Copy link
Contributor

darvark commented Jul 2, 2023

Thank you, sounds clear.

In that case (synchronization tlf->rig) tlf knows that we changed freq/band on rig directly? I thought tlf synchronizes those informations.

@zcsahok
Copy link
Member

zcsahok commented Jul 2, 2023

TLF polls the rig and if a band change is detected, then it sets the operating mode according to trxmode (so it's TLF->rig). There is no rig->TLF synchronization of the mode.

A quick check to see how it works:

  1. start TLF in CW mode (default) on 40m
  2. rig will be set to CW by TLF
  3. staying on 40m change mode to LSB
  4. nothing changes on TLF side
  5. now switch on the rig to 80m, still in LSB
  6. TLF will show the actual frequency, but will instruct the rig to switch to CW

@zcsahok
Copy link
Member

zcsahok commented Aug 4, 2023

IMO before implementing disabling mode setting we shall improve the mode synchronization: in the step 4 above TLF should switch to SSB.
In general mode setting shall behave as frequency control: rig updated if it's changed on TLF side and TLF takes over the setting if changed on the rig.
This makes working in a mixed contest easier: no need to manually change mode using :SSB/:CW, a key press on rig suffices.

@darvark
Copy link
Contributor

darvark commented Aug 5, 2023

Ok to be clear, you're suggesting that on default settings (follow mode enabled), each time operator change mode on rig side, tlf should change own mode to same as on rig? And that option should be disabled by turning off 'follow mode' or should be independent?

@dl1jbe
Copy link
Member Author

dl1jbe commented Dec 29, 2023

There is no handling of the rig->TLF direction: mode changes on the rig are not reflected on TLF side. (could be even a bug)

I think it just got overlooked before.

IMO before implementing disabling mode setting we shall improve the mode synchronization:

Agreed, mode synchronization should be bidirectional. And disabling should affect both directions at once.

Synchronization enabled will be the normal behavior should be active without a keyword. The keyword should better be named to disable that synchronization.

@darvark
Copy link
Contributor

darvark commented Dec 29, 2023

So generally I should fix (implement) tlf<->rig communication. And manage that functionality with that flag?
Just to be sure, currently it works in way that tlf can read state of the rig, but rig can't read in what state is tlf?

@dl1jbe
Copy link
Member Author

dl1jbe commented Jan 3, 2024

Sry, was away.

So generally I should fix (implement) tlf<->rig communication.

It should be done first - by you or by us together.

Just to be sure, currently it works in way that tlf can read state of the rig, but rig can't read in what state is tlf?

Not quite - the rig do not read TLFs settings, TLF has to tell them.
All is done in 'gettxinfo()' which regularly does two things:

a) If we commanded any frequency or mode change from TLF it is sent to the rig.
b) Otherwise it reads frequency and mode (At the moment only frequency is used).

So switching TLFs trxmode can be done from the read rig state.

@darvark
Copy link
Contributor

darvark commented Jan 3, 2024

THanks, and now I'm confused. Please correct me if I'm wrong, I have to fix reading rig mode, and vary that functionality on param in config.

@dl1jbe
Copy link
Member Author

dl1jbe commented Jan 6, 2024

Please correct me if I'm wrong, I have to fix reading rig mode, and vary that functionality on param in config.

That is the way to do it.

Please have a look at the pull request i prepared for your branch. I did some refactoring to make things more clear:

  1. A new function poll_rig_state got pulled out of gettxinfo. The new function is the real core where the rig gets polled by TLF. You can see that the rig mode gets already polled. We need to convert that mode (CW, USB, LSB or whatever) to a recognized state for trxmode (CWMODE, SSBMODE or DIGIMODE) and change the trxmode accordingly.

  2. handle_trx_switch() had two jobs: a) set an external switch according to band (e.g. for switching antenna) and b) set the rig into a default mode for band and operating mode. I factored the second part into a separate function.

  3. Only the mode setting should be controlled by the follow_mode variable. The band switch should work any time. So the condition got moved accordingly.

For details see the pull request.

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

No branches or pull requests

3 participants