Re: Serial Port RTS Error upon startup Commander


Saad Mahaini
 

Hi Dave

Sorry for not responding earlier, wanted first to sit behind the radios and run few scenarios

This only happens with the Yaesu and Kenwood radios.  

The Icom (Via MK3) does not do it.  In another word, i can start commander, with the Icom radio already preselected,  while the Icom radio is off, and not get the warning message.

If i do the same as above with the Yaesu (Via MK2) or Kenwood (Direct) , while the appropriate radio is preselected in Commander.  I get the warning if the radio is off when i launch Commander, i don't get the warning if the radio is on when i launch commander

 I have both Yaesu and Icom with RTS selected as "X" and hey work fine

For the Kenwood, i have to have "RTS" set as yes for commander to communicate with it

Now you may ask why do you start Commander before you start the radio, which can be an easy fix by reversing the sequence.  The problem is that one radio may had been selected when i terminated Commander last time, and next time i want to operate this will happen if i choose to turn on a different radio than preselected or if i plain forgot (happens alot)  what last radio i used and turn on a different radio, either case will trigger this issue and i have no precautions 

Its really not a huge issue except that its annoying, plus as i mentioned before if i accidently click "yes" i will usually spend the next hour chasing my tail and spinning my wheels trying to figure out why the radio is stuck in TX or some weird behavior like that till i remember to go to Config and revert to "X"

 Thanks again for all your help

73 Saad N5FF



On Thursday, April 29, 2021, 05:26:03 AM CDT, g4wjs <bill.8@...> wrote:


On 29/04/2021 04:39, Dave AA6YQ wrote:
@ more AA6YQ comments below

+ Joe, is there a way that Commander can determine that a microHam 
 > "RTS must be N" interface is involved?

It's not "RTS must be N".  It can be anything but typically RTS=Y
will lock the rig in transmit if the user is using RTS for PTT and
RTS=HANDSHAKE will lock up CAT software expecting a response on
CTS.

All of the microHAM "keyer" interfaces (CW Keyer, DigiKeyer, DigiKeyer
II, microKEYER, microKEYER II, microKEYER III, MK2R+) *require* hardware
PTT in order to perform sound card/mic audio switching and/or provide
(timed) PTT to an amplifier.

If the owner has enabled a "control" port in microHAM USB Device Router
Commander can poll that port (Ports -> SO2R Serial  Port) using the
microHAM Control Protocol. The VS; command will identify the device in
the first two characters following the VS in the response.  *HOWEVER*
the microHAM Control Protocol is not applicable to USB Interface II,
USB Interface III or DXP.

In addition, polling for a microHAM interface does not resolve the issue
with the hundreds of other CT/NA compatible interfaces (including MFJ!
and some Rigblaster models).

@ Thanks, Joe. Doing something interface-specific doesn't appear feasible.

@ I should have noted that Commander only displays the warning message if

1. the radio is a Kenwood or Yaesu that requires RTS to be asserted

@ and

2. Commander's RTS selector is not set to "On"

@ and

3. Commander doesn't receive CAT data from the Primary CAT port for 5 seconds after the radio is selected as the primary transceiver

@ It's the third requirement that has prevented an avalanche of microHam interface users from complaining about the warning message.

@ Saad, why would your primary transceiver not respond within 5 seconds of being selected?

       73,

             Dave, AA6YQ

Hi Dave,

I think Saad answered your last question in his OP, i.e. the rig may be turned off. How about a pop up question if your conditions above would lead to an error message, when multiple rigs are configured, that offers to switch to a different configured rig. While that blocks the user can decide which rig to turn on.


--
73

Bill

G4WJS.

Join DXLab@groups.io to automatically receive all group messages.