[WT-support] microHAM u2R (micro2R) CW delays and headphone switching problems with Win-Test

[Bob Wilson, N6TV]

Joe,

Thanks for the prompt reply.

On Mon, Aug 8, 2011 at 12:57 PM, microHAM America - W4TV <
support at microham.com> wrote:
>
> Waiting on PTT events before switching receive focus is not wise or
> appropriate.


Agreed, but Win-Test is waiting for PTT events to occur before *transmitting
*.  Doesn't *that* seem to be appropriate?


> The other major problem I had, unique to the u2R, was that it
>> /insisted/ on controlling all the headphone switching for me, based
>> on the status of the radio, rather than letting the contest software
>> be in control of the headphones.
>>
>
> micro2R does not *insist* on controlling the headphone switching, it
> does not provide the same level of *macro based* control as MK2R+.
>

I was not using any MK2R+ macros.  At the end I was attempting to control
the headphones via the RX Focus and Stereo On/Off pins (Classic Auto
Control).  The u2R wan't paying attention to those requests during transmit.


> micro2R only provides control of RX Focus and Stereo (Receive on R1,
> Receive on R2 and Stereo).  This results in six possible states:
> RX on 1, RX on 2, TX from computer (CW/DVK) on R1, TX from computer
> (CW/DVK) on R2, Manual TX (PTT/Paddles) on R1, and Manual TX
> (PTT/Paddles) on R2, with stereo override.


Yes, but those headphone states are "hard wired" to match what the radio is
doing, instead of what the contest software is *requesting*.  It may make
sense to do that only in some exceptional cases, e.g. both ears on R1, TX
focus on R2, and you attempt to send with the paddles.

A future version of Router will permit independent selection of the transmit
> audio states with
> Stereo On/Stereo Off (e.g. stereo can be retained in transmit or
> not) but that is a Router configuration, and not controllable in the
> microHAM Control Protocol.


Are you saying that the u2R will eventually leave the logging program in
control of the *receive* audio, whether transmitting or not, and whether
using microHAM control protocol or not?  I sure hope so.  Today, the u2R
insists on taking over control of the headphone audio whenever you transmit,
completely ignoring the audio state directed by the contest software (unless
Stereo is selected by software), making it very frustrating to use.
 Sometimes I want both ears on my sidetone, sometimes only one ear, and
sometimes no ears. That's normally something I can control with Win-Test.
 Unplugging the PTT line was the only solution I could find, but it still
switches headphone audio when I touch the paddles.

QSK also needs to be a consideration.   I was seeing audio switching between
every dot and dash, most unnerving.  I found no "QSK" settings in the u2R,
though the WinKey tab says "QSK only" for a couple of compensation settings.
 Does the u2R "auto detect" when you are using QSK?  In the MK2R+, you can
select QSK explicitly.

Note also that when hovering over the *Disable audio switching on
RADIO1/2*check boxes on the Audio Tab, the pop-up help text talks
about "ACA" and
"CCC" modes, which of course do not apply to the u2R.

The only change needed is to remove the gratuitous wait states in
> the logging software.


It may be overly conservative for Win-Test to wait for a PTT event before
transmitting, especially when using WinKey for both CW and PTT.  But if
you're trying to control PTT via the microHAM control protocol, it's hard to
get the PTT delay timing correct if you don't do a proper wait.


> Advanced audio switching is only available
> in MK2R and MK2R+ ... micro2R is designed as a basic SO2R controller
> and does not contain a protocol driven N x N audio crosspoint switch.
>

The Router needs to support a u2R mode that leaves the logging software 100%
in charge of the headphone audio (R1/R2/both).  At present, I see no way to
do that, but it *could *do it, without any hardware changes, at least for
Classic Auto Control, right?

73,
Bob, N6TV
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.f5mzn.org/pipermail/support/attachments/20110808/27345728/attachment.html>