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

+ 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

No surprise, but thak you for considering.

73 de Dave, W5SV

+ AA6YQ comments below

No surprise, but thak you for considering.

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

73,

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.

Thanks

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

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

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

+ 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

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

+ 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

* 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