Commander question/request


David Reed
 

I use both the Memory Banks and the Filters & Devices sub-windows of Commander; is there any way to get both to display simultaneously? If not, might I ask for that possibility to be considered for a future enhancement? I do not mind if it uses more screen area to accomplish.

Thanks & 73 de Dave, W5SV


Dave AA6YQ
 

+ AA6YQ comments below

I use both the Memory Banks and the Filters & Devices sub-windows of Commander; is there any way to get both to display simultaneously?

+ No, you must click a button on Commander's Main window to switch between the two.

If not, might I ask for that possibility to be considered for a future enhancement?

+ High cost + low value => low priority.

73,

Dave, AA6YQ


David Reed
 

No surprise, but thak you for considering.

73 de Dave, W5SV

On 27-Jun-21 17:22, Dave AA6YQ wrote:
+ AA6YQ comments below

I use both the Memory Banks and the Filters & Devices sub-windows of Commander; is there any way to get both to display simultaneously?

+ No, you must click a button on Commander's Main window to switch between the two.

If not, might I ask for that possibility to be considered for a future enhancement?

+ High cost + low value => low priority.

73,

Dave, AA6YQ





Dave AA6YQ
 

+ AA6YQ comments below

No surprise, but thak you for considering.

+ It's been added to Commander's enhancement list...

73,

Dave, AA6YQ


Johnny IZ8EWD
 

Please add "read" command to set inizial status of user-defined controls, to be executes when commander is launched to refresh the controls status at initial value.

Thanks


Dave AA6YQ
 

Please add "read" command to set inizial status of user-defined controls, to be executes when commander is launched to refresh the controls status at initial value.

+ Commander supports more than 120 transceiver models, many of which support at least 10 slider-controllable parameters, and some of which support hundreds of such parameters. Providing what you request for an IC-7300 alone would take weeks - and that would be faster than typical because I own an IC-7300 and so could immediately test my work.

+ You can define an "Initial Command Sequence" that employs <Slider S, V> commands to set each of your user-defined sliders to a reasonable value, putting the radio's slider-controlled parameters in sync with Commander's sliders. See

https://www.dxlabsuite.com/commander/Help/CommandSequences.htm#Command%20Sequences

+ and

https://www.dxlabsuite.com/commander/Help/Configuration.htm#Initial%20Command%20Sequence

+ An "Initial Command Sequence" can also send CAT commands to put parameters controlled by user-defined sequences in a desired state, and set sequence button names and sequence LED colors to match using <Name Q, text> and <LED Q, color> commands respectively.

73,

Dave, AA6YQ


Johnny IZ8EWD
 
Edited

Hi Dave, thanks for reply.
I understand your position, but under my point of view this is a functional limitation for Commander because I use my radio remotely, so it's very important to have control of all parameters.
Your suggestion could be a workaround, but some radios, as Yaesu, store different settings for each operative mode, so it's ok on startup, but lost sync when the mode is changed.

Maybe you can consider to use the hamlib libraries, instead of develop your own code, in this case the radio communication is transparent and independent of radio model, so you could focus on your software.

73


Joe Subich, W4TV
 

On 2021-07-15 2:44 AM, Johnny IZ8EWD via groups.io wrote:
Maybe you can consider to use the hamlib libraries, instead of develop your own code, in this case the radio communication is transparent and independent of radio model, so you could focus on
your software.
hamlib is garbage, buggy and incomplete. The adoption of it would
significantly cripple DXLab Suite. Further, it would not resolve
your issue since the User Defined Controls routines do not have
the ability to read/interpret responses from the radio or do
conditional execution and branching.

73,

... Joe, W4TV


On 2021-07-15 2:44 AM, Johnny IZ8EWD via groups.io wrote:
[Edited Message Follows]
Hi Dave, thanks for reply.
I understand your position, but under my point of view this is a functional limitation for Commander because I use my radio remotely, so it's very important to have control of all parameters.
Your suggestion could be a workaround, but some radios, as Yaesu, store different settings for each operative mode, so it's ok on startup, but lost sync when the mode is changed.
Maybe you can consider to use the hamlib libraries, instead of develop your own code, in this case the radio communication is transparent and independent of radio model, so you could focus on your software.
73


Dave AA6YQ
 

+ AA6YQ comments below

I understand your position, but under my point of view this is a functional limitation for Commander because I use my radio remotely, so it's very important to have control of all parameters.

+ The publicly released version of Commander can control all of a radio's CAT-accessible parameters via user-defined command sequences and user-defined sliders.

Your suggestion could be a workaround, but some radios, as Yaesu, store different settings for each operative mode, so it's ok on startup, but lost sync when the mode is changed.

+ You can create user-defined command sequences that issue mode change commands and then configure the remote radio for optimal operation in that mode.

Maybe you can consider to use the hamlib libraries, instead of develop your own code, in this case the radio communication is transparent and independent of radio model, so you could focus on your software.

+ Please point me at the documentation of the hamlib API that controls the notch filter bandwidth of every transceiver with a CAT-controllable notch filter.

73,

Dave, AA6YQ


Johnny IZ8EWD
 
Edited

Please point me at the documentation of the hamlib API that controls the notch filter bandwidth of every transceiver with a CAT-controllable notch filter.


From Hamlib 4.2 API reference

rig_set_mode()

int rig_set_mode ( RIG *  rig,
    vfo_t  vfo,
    rmode_t  mode,
    pbwidth_t  width 
  )    

set the mode of the target VFO

Parameters
rig The rig handle
vfo The target VFO
mode The mode to set to
width The passband width to set to


I hope this can help.
Best 73


Dave AA6YQ
 

+ AA6YQ comments below
Please point me at the documentation of the hamlib API that controls the notch filter bandwidth of every transceiver with a CAT-controllable notch filter.


From Hamlib 4.2 API reference

rig_set_mode()

int rig_set_mode ( RIG *  rig,
    vfo_t  vfo,
    rmode_t  mode,
    pbwidth_t  width 
  )    

set the mode of the target VFO

Parameters
rig The rig handle
vfo The target VFO
mode The mode to set to
width The passband width to set to

+ That API control's the radio RX bandwidth. I asked for documentation of the API that controls the notch filter bandwidth.

       73,

             Dave, AA6YQ


Dave AA6YQ
 

* more AA6YQ comments below
+ That API control's the radio RX bandwidth. I asked for documentation of the API that controls the notch filter bandwidth.

* As you've likely discovered by now, Hamlib doesn't provide an API that controls the notch filter bandwidth. Hamlib only provides control over a small groups of common radio parameters; employing it would do nothing to mitigate your suggestion's requirement to track the huge number of radio-specific parameters that Commander's user-defined sequences or sliders can control.

+ Tracking a parameter requires specifying

- the CAT commands that direct the radio to report the parameter

- the frequency at which the radio should be directed to report the parameter

- how the parameter can be extracted from the information reported by the radio

+ I have long sought a simple abstraction for this, one that most users could learn and employ with any make and model of transceiver. So far, no joy.

           73,

              Dave, AA6YQ

        73,

              Dave, AA6YQ