Bidirectional Rig Control


Norm - KC1BMD
 

Is it possible to configure Commander such that a change made at the front panel of the radio (e.g. 756Pro3, 7600) will be reflected in Commander? If you are familiar with Ham Radio Deluxe, that's how it works.

e.g. I have a user-defined sequence controlling break-in. Clicking the button in Commander cycles through 'off', 'semi' and 'full' break-in. If I cycle through this setting on the radio, Commander does not reflect the change, so the communication is now one way (from Commander to radio). The same question would apply to sliders as well.
--
73, Norm/KC1BMD


Dave AA6YQ
 

+ AA6YQ comments below
Is it possible to configure Commander such that a change made at the front panel of the radio (e.g. 756Pro3, 7600) will be reflected in Commander? If you are familiar with Ham Radio Deluxe, that's how it works.

e.g. I have a user-defined sequence controlling break-in. Clicking the button in Commander cycles through 'off', 'semi' and 'full' break-in. If I cycle through this setting on the radio, Commander does not reflect the change, so the communication is now one way (from Commander to radio). The same question would apply to sliders as well.

+ No. User-defined command sequences and sliders were designed to provide access to functionality not accessible from the radio's front panel (e.g. settings only accessible from menus), and to provide automation not available from the radio  (e.g. quickly configuring the mode, passband width, shift, and noise reduction settings for a particular operating scenario). 

+ Replicating secondary buttons and sliders already present on your transceiver's front panel would be a waste of screen space unless your transceiver is remote or has poor ergonomics. In those two cases, simply make all changes via Commander's front panel.

     73,

          Dave, AA6YQ

 


Norm - KC1BMD
 

Thanks for explaining. I think I was trying to make Commander do things for which it was not intended. I created a slider for Keyer Speed even though it is not a menu selection but a front panel "pot" control. The problem with the physical radio control is that you cannot determine the speed because there is no speed indication on the radio, so you rotate the pot and guess, by ear. So I added the speed indicator to the slider (using the fact that the radio keyer speed range of 6 to 60 wpm adjusts with a command range of 0 to 255 decimal. That works well and is almost calibrated but if I change some other front panel control then Commander and the radio are out of sync (i.e. I cannot use the slider label to indicate the correct speed anymore). Same thing happens with e.g. RF Gain slider.

[Unexplained Finding]: I'm not sure why this happens but for some reason (and I do not know if all 756Pro3 or other radios do this): If I set, for example, Keyer Speed, RF Power in a rig control program (HRD, DXLab) the change is made at the radio - all good. However, if I change another control at the radio, for example AF Gain, RF Gain then the Keyer Speed and RF Power (as examples) revert to whatever setting was at the radio according to what the physical controls (pots) had been set to and not touched during this scenario. In other words, the radio settings snap back to the untouched physical control settings and then Commander and the radio are out of sync. This makes for interesting operation. I'm not sure this makes sense or is clear so I guess we will just leave it as 'unexplained phenomena'.

--
73, Norm/KC1BMD


Dave AA6YQ
 

+ AA6YQ comments below

Thanks for explaining. I think I was trying to make Commander do things for which it was not intended. I created a slider for Keyer Speed even though it is not a menu selection but a front panel "pot" control. The problem with the physical radio control is that you cannot determine the speed because there is no speed indication on the radio, so you rotate the pot and guess, by ear. So I added the speed indicator to the slider (using the fact that the radio keyer speed range of 6 to 60 wpm adjusts with a command range of 0 to 255 decimal. That works well and is almost calibrated but if I change some other front panel control then Commander and the radio are out of sync (i.e. I cannot use the slider label to indicate the correct speed anymore). Same thing happens with e.g. RF Gain slider.

+ If you have a slider in Commander that controls the keyer speed and is calibrated, why would you use the uncalibrated pot on the radio to control the keyer speed?

[Unexplained Finding]: I'm not sure why this happens but for some reason (and I do not know if all 756Pro3 or other radios do this): If I set, for example, Keyer Speed, RF Power in a rig control program (HRD, DXLab) the change is made at the radio - all good. However, if I change another control at the radio, for example AF Gain, RF Gain then the Keyer Speed and RF Power (as examples) revert to whatever setting was at the radio according to what the physical controls (pots) had been set to and not touched during this scenario. In other words, the radio settings snap back to the untouched physical control settings and then Commander and the radio are out of sync. This makes for interesting operation. I'm not sure this makes sense or is clear so I guess we will just leave it as 'unexplained phenomena'.

+ I recall seeing that with one of my Icom radios. I consider it a defect in the radio. Does it occur if you change the transceiver frequency using its front panel knob?

73,

Dave, AA6YQ


Norm - KC1BMD
 

+ AA6YQ comments below
+ If you have a slider in Commander that controls the keyer speed and is calibrated, why would you use the uncalibrated pot on the radio to control the keyer speed?

[KC1BMD]: I do not want to touch that uncalibrated control nor do I touch it. I have it set to the speed I want and leave it there. However, because of the strange radio behavior that I explained, after make a keyer speed change in Commander and if (for whatever reason) I touch certain controls on the radio front panel, the the keyer speed reverts to what I have the front panel "pot" set to and Commander does not change to reflect that. Now things are out of sync and I have to play some games to get them in sync again. I guess I can deal with it.

+ I recall seeing that with one of my Icom radios. I consider it a defect in the radio. Does it occur if you change the transceiver frequency using its front panel knob?
[KC1BMD]: Thanks, I thought I was crazy! No, luckily the VFO knob does not cause any problem, nor do any push button controls, like NR, NB, Band keys, F-keys, RIT, etc. Only certain rotary (pot) controls cause this problem). It might happen on my 7600 too but that radio is a recent acquisition and I would need to verify that.


Dave AA6YQ
 

# more AA6YQ comments below


+ If you have a slider in Commander that controls the keyer speed and is calibrated, why would you use the uncalibrated pot on the radio to control the keyer speed?

[KC1BMD]: I do not want to touch that uncalibrated control nor do I touch it. I have it set to the speed I want and leave it there. However, because of the strange radio behavior that I explained, after make a keyer speed change in Commander and if (for whatever reason) I touch certain controls on the radio front panel, the the keyer speed reverts to what I have the front panel "pot" set to and Commander does not change to reflect that. Now things are out of sync and I have to play some games to get them in sync again. I guess I can deal with it.

+ I recall seeing that with one of my Icom radios. I consider it a defect in the radio. Does it occur if you change the transceiver frequency using its front panel knob?

[KC1BMD]: Thanks, I thought I was crazy! No, luckily the VFO knob does not cause any problem, nor do any push button controls, like NR, NB, Band keys, F-keys, RIT, etc. Only certain rotary (pot) controls cause this problem). It might happen on my 7600 too but that radio is a recent acquisition and I would need to verify that.


# Then I suggest working around the Icom defect by defining sliders in Commander for any of the radio's rotary controls that you both use and that trigger the unwanted reset.

73,

Dave, AA6YQ


Norm - KC1BMD
 

Thanks Dave. When using HRD, because the communication was bidirectional it was easy for me to see what controls were reset because it was evident on the HRD user interface. Where DXLab communication is only one way for such controls, it is more problematic. Nevertheless, I will find a workaround I can live with.

--
73, Norm/KC1BMD


k1ggi
 

You have observed the behavior but have not expressed the fundamental rule.

- If you are operating the front panel, the knobs are obligated to tell the
truth.
- If you are under remote control, the front panel is not obligated to tell
the truth.

73,
Ed, k1ggi

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ
Sent: Sunday, February 14, 2021 4:56 PM
To: DXLab@groups.io
Subject: Re: [DXLab] Bidirectional Rig Control

+ AA6YQ comments below

Thanks for explaining. I think I was trying to make Commander do things for
which it was not intended. I created a slider for Keyer Speed even though it
is not a menu selection but a front panel "pot" control. The problem with
the physical radio control is that you cannot determine the speed because
there is no speed indication on the radio, so you rotate the pot and guess,
by ear. So I added the speed indicator to the slider (using the fact that
the radio keyer speed range of 6 to 60 wpm adjusts with a command range of 0
to 255 decimal. That works well and is almost calibrated but if I change
some other front panel control then Commander and the radio are out of sync
(i.e. I cannot use the slider label to indicate the correct speed anymore).
Same thing happens with e.g. RF Gain slider.

+ If you have a slider in Commander that controls the keyer speed and is
calibrated, why would you use the uncalibrated pot on the radio to control
the keyer speed?

[Unexplained Finding]: I'm not sure why this happens but for some reason
(and I do not know if all 756Pro3 or other radios do this): If I set, for
example, Keyer Speed, RF Power in a rig control program (HRD, DXLab) the
change is made at the radio - all good. However, if I change another control
at the radio, for example AF Gain, RF Gain then the Keyer Speed and RF Power
(as examples) revert to whatever setting was at the radio according to what
the physical controls (pots) had been set to and not touched during this
scenario. In other words, the radio settings snap back to the untouched
physical control settings and then Commander and the radio are out of sync.
This makes for interesting operation. I'm not sure this makes sense or is
clear so I guess we will just leave it as 'unexplained phenomena'.

+ I recall seeing that with one of my Icom radios. I consider it a defect in
the radio. Does it occur if you change the transceiver frequency using its
front panel knob?

73,

Dave, AA6YQ


Norm - KC1BMD
 

While that might be the fundamental rule of this rig control application, it is clearly not the rule for all rig control applications.
--
73, Norm/KC1BMD


Joe Subich, W4TV
 

There are two kinds of controls in Commander - those that are
built-in (VFO A, VFO B, PBT, Shift/width, etc. - depending on
the transceiver) and those that are user defined.

For the built-in controls, Commander polls the radio for the
data (like HRD). For the user defined controls there is no
polling mechanism - for them the controls are "set only".

In order to make user defined controls bi-directional, Commander
would need to be completely redesigned to create a virtual transceiver
in memory *for each supported transceiver* and poll the actual
transceiver for every parameter on a regular basis and convert
the user defined controls to built-in controls. This would be
a major effort and significantly slow down Commander's other
activities (like SpotCollector).

73,

... Joe, W4TV

On 2021-02-16 9:47 AM, Norm - KC1BMD wrote:
[Edited Message Follows]
Interesting finding: There is some bidirectional control in Commander. Radio is IC-756Pro3 and if I adjust PBT controls on the radio then the change is also reflected in Commander. If that is possible, is it technically possible for other controls?
Dave, if you see this, I would be interested to know the rationale for this one control having bidirectional capability. I'm not asking for any enhancement request, I know that is not going to happen --- I'm just curious.
--
73, Norm/KC1BMD


Norm - KC1BMD
 

Thanks Joe, I understand.
--
73, Norm/KC1BMD


Carl - WC4H
 

Hi Norm.

Actually, HRD does not work that way for user defined macros/buttons.  It does work 2 way, as does commander, for functions that are included in the software.   So if you change the frequency on the radio it is reflected in the software and vise versa.  HRD does have more pre-defined functions than Commander does, like some sliders for output power, RF Level, AF Level, etc.   Most of these can also be defined in Commander but not with 2 way feedback.  Dave has previously explained that aspect of it.

What I do is to initialize desired values when I launch Commander, then I use Commander to make changes as needed.  I have plenty of buttons and sliders so that I cover all of the functions that I typically adjust.  

73.
Carl - WC4H


Dave AA6YQ
 

+ AA6YQ comments below

There are two kinds of controls in Commander - those that are built-in (VFO A, VFO B, PBT, Shift/width, etc. - depending on the transceiver) and those that are user defined.

For the built-in controls, Commander polls the radio for the data (like HRD). For the user defined controls there is no polling mechanism - for them the controls are "set only".

In order to make user defined controls bi-directional, Commander would need to be completely redesigned to create a virtual transceiver in memory *for each supported transceiver* and poll the actual transceiver for every parameter on a regular basis and convert the user defined controls to built-in controls. This would be a major effort and significantly slow down Commander's other activities (like SpotCollector).

+ No redesign of Commander would be required. It would only be necessary to identify all items of state (AF gain, RF gain, noise limiting capabilities, ... backpanel key jack function) for each of the ~150 radios supported by Commander, and then develop a polling sequence for each radio that interleaves items that must be monitored in real time with items that change in frequently, e.g.

request frequency

request S-meter

request AF gain

request RF gain

request frequency

request S-meter

request noise blanker setting

request TX meter selector

request frequency

request S-meter

request mode

request key speed

request frequency

request S-meter

request AGC setting

request backpanel key jack configuration

....

+ Between their front panels and menu systems modern radios have hundreds of items of internal state. Implementing this extension would not be rocket science, but the time to implement, test, and document would stop all other development for years.

+ Given that DXLab's primary focus is support for DXing, with "control of a remote transceiver" nowhere on the list of capabilities, that would be a poor allocation of development resources.

73,

Dave, AA6YQ


w6de
 

However, depending on your priorities and wallet size, switching to a full DSP radio such as a FLEX, ANAN, or a select few others that have a known Commander interface control, would offer a full radio control without touching the radio itself**. The trade-off is that you would need the screen space for the radio's control panel display. Commander will interface to a few of these DSP radios and collect logging information--but, you would still need to use the computer based control panel to read/write to the radio.

** Some DSP radios have an option for a radio's attached front panel control. With this you could control the radio from either the radio or computer and have correct status in each control set.

73,
Dave, w6de

-----Original Message-----
From: DXLab@groups.io [mailto:DXLab@groups.io] On Behalf Of Dave AA6YQ
Sent: Tuesday, February 16, 2021 21:59
To: DXLab@groups.io
Subject: Re: [DXLab] Bidirectional Rig Control

+ AA6YQ comments below

There are two kinds of controls in Commander - those that are built-in (VFO A, VFO B, PBT, Shift/width, etc. - depending on the transceiver) and those that are user defined.

For the built-in controls, Commander polls the radio for the data (like HRD). For the user defined controls there is no polling mechanism - for them the controls are "set only".

In order to make user defined controls bi-directional, Commander would need to be completely redesigned to create a virtual transceiver in memory *for each supported transceiver* and poll the actual transceiver for every parameter on a regular basis and convert the user defined controls to built-in controls. This would be a major effort and significantly slow down Commander's other activities (like SpotCollector).

+ No redesign of Commander would be required. It would only be necessary to identify all items of state (AF gain, RF gain, noise limiting capabilities, ... backpanel key jack function) for each of the ~150 radios supported by Commander, and then develop a polling sequence for each radio that interleaves items that must be monitored in real time with items that change in frequently, e.g.

request frequency

request S-meter

request AF gain

request RF gain

request frequency

request S-meter

request noise blanker setting

request TX meter selector

request frequency

request S-meter

request mode

request key speed

request frequency

request S-meter

request AGC setting

request backpanel key jack configuration

....

+ Between their front panels and menu systems modern radios have hundreds of items of internal state. Implementing this extension would not be rocket science, but the time to implement, test, and document would stop all other development for years.

+ Given that DXLab's primary focus is support for DXing, with "control of a remote transceiver" nowhere on the list of capabilities, that would be a poor allocation of development resources.

73,

Dave, AA6YQ


Norm - KC1BMD
 

On Tue, Feb 16, 2021 at 04:59 PM, Dave AA6YQ wrote:
+ Given that DXLab's primary focus is support for DXing, with "control of a remote transceiver" nowhere on the list of capabilities, that would be a poor allocation of development resources.

73,

Dave, AA6YQ
Thanks Dave. I get it. I am not the primary user for which this application suite was designed and I understand that. I finished several sequences and sliders plus enabled the initial command sequence which gets me to the point that I might not have to touch the radio front panel, except to switch it on and off. I also imported all my QSO's from the HRD logbook and that seemed to go well. So, I'm on my way!
 
--
73, Norm/KC1BMD


Dave AA6YQ
 

+ AA6YQ comments below

Interesting finding: There is some bidirectional control in Commander. Radio is IC-756Pro3 and if I adjust PBT controls on the radio then the change is also reflected in Commander. If that is possible, is it possible other controls?

+ Of course -- at a cost of delayed implementation of other new capabilities that would provide more value to a larger fraction of the user community; the technical term for this is "opportunity cost".


Dave, if you see this, I would be interested to know the rationale for this one control having bidirectional capability. I'm not asking for any enhancement request, I know that is not going to happen --- I'm just curious.

+ As I mentioned in a previous post in this thread, the criteria are

1. used for accurately logging QSOs (RX frequency, TX frequency, RX band, TX band, mode, split)

2. support automation for DXing (RX/TX, RX passband)

73,

Dave, AA6YQ


Norm - KC1BMD
 

On Tue, Feb 16, 2021 at 07:41 PM, Dave AA6YQ wrote:
I would be interested to know the rationale for this one control having bidirectional capability.
Before you answered that, I had already deleted the question after I found the rational on finding some past posts of yours. Enough said on this one I guess (hi). On a positive note, I believe I solved an intermittent CAT error problem with my Acom amp after changing the default 200ms interrogation time to 100ms. HRD caused this error more frequently than DXLabs but they are also communicating much more data with the radio. There is also no way to configure "interrogation" time interval in HRD and I want to thank you for this feature!
 
--
73, Norm/KC1BMD


Dave AA6YQ
 

+ AA6YQ comments below

I would be interested to know the rationale for this one control having bidirectional capability.

Before you answered that, I had already deleted the question after I found the rational on finding some past posts of yours.

+ When I'm in my basement shack, I respond to email messages issued from the DXLab Discussion Group. These messages don't get rescinded when you edit a post.


Enough said on this one I guess (hi). On a positive note, I believe I solved an intermittent CAT error problem with my Acom amp after changing the default 200ms interrogation time to 100ms.

+ What was the "CAT error problem", exactly?

HRD caused this error more frequently than DXLabs but they are also communicating much more data with the radio. There is also no way to configure "interrogation" time interval in HRD and I want to thank you for this feature!

+ You could connect your amp to Commander's Secondary CAT port, where it would be monitoring all of the traffic between Commander and your transceiver.

73,

Dave, AA6YQ


Norm - KC1BMD
 

On Tue, Feb 16, 2021 at 09:15 PM, Dave AA6YQ wrote:
+ What was the "CAT error problem", exactly?
[KC1BMD]:  Acom support said the amp wants to see frequency/band data for auto-band-switching at least once per second, otherwise it will produce CAT errors. As far as I can tell, the band switching is occurring even with these errors (maybe just a little slower than they could otherwise be) and they don't seem to affect amp operation, except for an annoying error beep that cannot be shut off. The CI-V output from the 756Pro3 is going to a Y-cable. One side goes to a (ZLP Electronics) dual CI-V-to-USB level converter to the PC for connection to Commander (or HRD) and the other side goes to the AUX/CAT port on the Acom amp (set for iCOM data set, TTL, Polling Off, 19200 Baud). At Commander interrogation interval of 200ms I got infrequent CAT errors. Above that interval, the errors increased. At 100ms I thought they were gone (but I believe I got one or two within about 0.5 to 1 hr), so they even less frequent). I might try 75ms or 50ms to see how it behaves.

+ You could connect your amp to Commander's Secondary CAT port, where it would be monitoring all of the traffic between Commander and your transceiver.
Does the secondary CAT port configuration apply to all rigs in a multi-radio configuration, or can you specify to use the secondary port with e.g. one radio and not another? I'll review that configuration but on first look, I see the interrogation interval is the same default 200ms and I assume it can be configured higher or lower like the primary. If that's the case, I'm not sure what benefit the secondary port would have in my case - but it might be worth looking into.
 
--
73, Norm/KC1BMD


Dave AA6YQ
 

# more AA6YQ comments below
[KC1BMD]:  Acom support said the amp wants to see frequency/band data for auto-band-switching at least once per second, otherwise it will produce CAT errors. As far as I can tell, the band switching is occurring even with these errors (maybe just a little slower than they could otherwise be) and they don't seem to affect amp operation, except for an annoying error beep that cannot be shut off. The CI-V output from the 756Pro3 is going to a Y-cable. One side goes to a (ZLP Electronics) dual CI-V-to-USB level converter to the PC for connection to Commander (or HRD) and the other side goes to the AUX/CAT port on the Acom amp (set for iCOM data set, TTL, Polling Off, 19200 Baud). At Commander interrogation interval of 200ms I got infrequent CAT errors. Above that interval, the errors increased. At 100ms I thought they were gone (but I believe I got one or two within about 0.5 to 1 hr), so they even less frequent). I might try 75ms or 50ms to see how it behaves.

# A Commander errorlog.txt file that captures a "CAT error" would reveal whether Commander really went 1 second without sending a frequency update. Do you have your transceiver's "CI-V transceive" option disabled? If it's enabled, QSYing via the transceiver's front panel will cause CI-V collisions that your Acom may dislike.


+ You could connect your amp to Commander's Secondary CAT port, where it would be monitoring all of the traffic between Commander and your transeiver.

# I meant to say "where it would not be monitoring all of the traffic between Commander and your transceiver.

Does the secondary CAT port configuration apply to all rigs in a multi-radio configuration, or can you specify to use the secondary port with e.g. one radio and not another?

# The Secondary CAT port follows (or leads) the current primary transceiver.

I'll review that configuration but on first look, I see the interrogation interval is the same default 200ms and I assume it can be configured higher or lower like the primary.

+ The Secondary CAT port's update rate is fixed at 200 ms. I've not yet encountered any device for which this was insufficient.

If that's the case, I'm not sure what benefit the secondary port would have in my case - but it might be worth looking into.

+ The benefit might be eliminating the error messages you report receiveing.

      
         73,

                Dave, AA6YQ