Thread: [Hamlib-developer] Pull Request: Restore AI on exit - needs testing
Library to control radio transceivers and receivers
Brought to you by:
n0nb
Menu
▾
▴
hamlib-developer
|
From: Bill S. <g4...@cl...> - 2015-11-29 18:36:35
|
Hi Nate, here is a pull request with a change to support this. I do not have any of the effected rigs so this is wholly untested :( Anyone with a Kenwood transceiver, a Yaesu transceiver that uses the Kenwood type CAT commands, an Elecraft, FlexRadio or any other SDR that uses Kenwood emulation for CAT is welcome (encouraged) to test this change. The following changes since commit 6061cae8df4c1c5b93295b95c06cc3a7881e9619: Proper IPv6 and dual stack networking for rotator net daemon (2015-11-27 19:41:04 +0000) are available in the git repository at: git://git.code.sf.net/u/bsomervi/hamlib restore-ai for you to fetch changes up to 0ab6d99ef574a4a1e133d47b43d013fc87a2afd4: Attempt to restore AI status on exit (2015-11-29 18:26:39 +0000) ---------------------------------------------------------------- Bill Somerville (1): Attempt to restore AI status on exit kenwood/elecraft.c | 11 +++++++---- kenwood/flex.c | 9 +++++++++ kenwood/flex6xxx.c | 1 + kenwood/k2.c | 1 + kenwood/k3.c | 1 + kenwood/kenwood.c | 20 +++++++++++++++++++- kenwood/kenwood.h | 2 ++ kenwood/thf6a.c | 1 + kenwood/thf7.c | 1 + kenwood/thg71.c | 2 +- kenwood/tmv7.c | 2 +- kenwood/ts2000.c | 1 + kenwood/ts450s.c | 1 + kenwood/ts590.c | 2 ++ kenwood/ts690.c | 1 + kenwood/ts870s.c | 1 + kenwood/ts990s.c | 1 + yaesu/newcat.c | 21 ++++++++++++++++----- yaesu/newcat.h | 1 + 19 files changed, 68 insertions(+), 12 deletions(-) 73 Bill G4WJS. |
|
From: Nate B. <n0...@n0...> - 2015-11-29 19:12:09
|
Applied and pushed. Thanks for the quick submission, Bill. I tested it with CQRlog on my K3 and no issues in a quick run through. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us |
|
From: Nate B. <n0...@n0...> - 2015-12-03 01:30:35
Attachments:
k3_aio.txt
|
Bill, I just noticed that rigctl took some time to exit with my K3. The problem looks to be in the code that resets the AI value. I've included a script file. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us |
|
From: Bill S. <g4...@cl...> - 2015-12-03 13:22:49
|
On 03/12/2015 01:30, Nate Bargmann wrote:
> I just noticed that rigctl took some time to exit with my K3.
Hi Nate,
thanks for testing that. It is a problem with the existing
kenwood_set_trn() function and I see another elsewhere :( I will send a
patch soon.
Related to this, it occurs to me that there needs to be a way of using
rigctl to turn on/off AI mode. Obviously with the new restore
functionality that cannot be done. I can see a "Hamlib" way of doing it
but it requires a new config token and quite a few code changes to make
it work for all the rigs that support AI mode. I wondered if, for this
special case, it might be simpler to use an environment variable to
disable the AI state restore facility. Something like:
HAMLIB_NO_AI_RESTORE=1 rigctl <options> A ON
Comments?
73
Bill
G4WJS.
|
|
From: Greg T. <gd...@le...> - 2015-12-03 13:39:33
Attachments:
signature.asc
|
Bill Somerville <g4...@cl...> writes:
> Related to this, it occurs to me that there needs to be a way of using
> rigctl to turn on/off AI mode. Obviously with the new restore
> functionality that cannot be done. I can see a "Hamlib" way of doing it
> but it requires a new config token and quite a few code changes to make
> it work for all the rigs that support AI mode. I wondered if, for this
> special case, it might be simpler to use an environment variable to
> disable the AI state restore facility. Something like:
>
> HAMLIB_NO_AI_RESTORE=1 rigctl <options> A ON
Two thoughts:
probably should be a --no-ai-restore option, not an environment
variable
if someone calls 'rigctl do-something', arguably it should just do
that, and not have any save/restore logic. The save/restore notion
would seem to belong in a program that has logic that looks like:
open with request to save/retore persistent flags (just AI for now)
do stuff for a while
close (clean shutdown)
So basically I'm suggesting that save/restore be (possibly default)
behavior for the open/close sequence used by full-blown programs, and be
not the default for bare rigctl usage. rigctl could have options
--no-save-restore
--save-restore
with one of them (I vote for --no) being default.
73 de n1dam
|
|
From: Bill S. <g4...@cl...> - 2015-12-03 22:52:03
|
On 03/12/2015 13:39, Greg Troxel wrote: > So basically I'm suggesting that save/restore be (possibly default) > behavior for the open/close sequence used by full-blown programs, and be > not the default for bare rigctl usage. rigctl could have options > --no-save-restore > --save-restore > with one of them (I vote for --no) being default. Hi Greg, thanks for the thoughtful comments. I basically agree except that I think the default for the rigctl command line program should be --save-restore, my reasoning is that restoring AI mode is important to some devices like StepIR aerial controllers and some amplifiers that need band change information. Because of this and because a few rigs allow AI on by default we should not be silently turning AI mode off (the current behaviour). Any other application that needs AI turned off or on should do so on start up so the way we leave it is only important to these passive devices. I think it is reasonable for anyone who wishes to use rigctl to change the state of AI mode to have to specify --no-save-restore. The only issue is that it is a behavioural change for those that already use rigctl to change AI mode state. I suspect that there will be as many that no longer have to do anything at all as there are those that have to add a new command line switch. 73 Bill G4WJS. |
|
From: Greg T. <gd...@le...> - 2015-12-03 23:35:44
Attachments:
signature.asc
|
Bill Somerville <g4...@cl...> writes: > On 03/12/2015 13:39, Greg Troxel wrote: >> So basically I'm suggesting that save/restore be (possibly default) >> behavior for the open/close sequence used by full-blown programs, and be >> not the default for bare rigctl usage. rigctl could have options >> --no-save-restore >> --save-restore >> with one of them (I vote for --no) being default. > Hi Greg, > > thanks for the thoughtful comments. I basically agree except that I > think the default for the rigctl command line program should be > --save-restore, my reasoning is that restoring AI mode is important to > some devices like StepIR aerial controllers and some amplifiers that > need band change information. Because of this and because a few rigs > allow AI on by default we should not be silently turning AI mode off > (the current behaviour). Any other application that needs AI turned > off or on should do so on start up so the way we leave it is only > important to these passive devices. > > I think it is reasonable for anyone who wishes to use rigctl to change > the state of AI mode to have to specify --no-save-restore. The only > issue is that it is a behavioural change for those that already use > rigctl to change AI mode state. I suspect that there will be as many > that no longer have to do anything at all as there are those that have > to add a new command line switch. I didn't understand that rigctl now turns off AI. I thought the save/restore for it was only to protect an explicit disabling. So now I can definitely see your point that --save-restore be default. 73 de n1dam |
|
From: Bill S. <g4...@cl...> - 2015-12-03 23:45:32
|
On 03/12/2015 23:35, Greg Troxel wrote: > I didn't understand that rigctl now turns off AI. It has too because the unsolicited AI traffic causes havoc with CAT conversations. There are flushes in pertinent places but collision handling is not up to dealing with AI traffic in all situations, I know that there is some code for handing event driven changes but IMHO this will never work in a generic "virtual rig" model like that Hamlib uses because not all rigs broadcast and even the ones that do don't broadcast everything so there would have to be lots of background CAT polling to detect all possible events :( I suppose that there could be some sort of registration for particular event types like frequency/mode/bandwidth/vfo/... changes in the public API but that would need every back end reporting what would need polling as opposed to AI mode providing. Gets very messy very quickly. Just putting the patch together for turning off AI restore via a rigctl command line option. It is actioned by a new API fn so clients could use it as well if they really want to exit with a specified AI state. 73 Bill G4WJS. |
|
From: Nate B. <n0...@n0...> - 2015-12-04 00:00:27
|
Good discussion. Thanks. For a PC type of program I personally see AI as being more trouble than its worth just for the reasons Bill outlined above. I do see its value now when no computer is attached that it can feed data to devices that can passively monitor the RS-232 line as SteppIR and others apparently do. I would guess that doing it that way takes a lot of the work out of implementing an embedded devices. Of course these days with SOCs and such, such frugality may become a thing of the past! 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Ham radio, Linux, bikes, and more: http://www.n0nb.us |
