[WT-support] Edit QSO Alt-F

[Joe Subich, W4TV]

> Note that Bjorn is using Win-Test with an MK2R+ with two Elecraft
> K3s. This is an unreliable combination using the latest release of
> microHAM Router software and firmware (no problems on very old
> microHAM Router version 5.1.1, micro KEYER 2R+ v3.0 firmware). I
> think that probably explains why Bjorn is seeing so many mismatches
> between recorded band and frequency: there are timeouts when talking
> to the K3, especially after changing bands, and apparently even using
> the microHAM "K3 Patched" radio choice in the Router software doesn't
> completely solve all the problems).

The problem is that the K3 "goes stupid" after band changes - it sends
several unrequested parameters and stops responding for up to 500 ms.
If the logging program continues to "pound away" with it's polling
during that time, the queue in microHAM Router fills up waiting for
responses to the "extra" polling that may never arrive because the K3 
ignores all input during the "stupid" time.  If you will set Win-Test's
Polling rate to at least 500 ms and *uncheck* "Forward autoinformation
to CAT Port" boxes in microHAM Router, things should be more reliable.

The Win-Test drivers could be made more robust by *not* polling for 1000 
to 1500 ms after any command that causes a band change until the
automatic "data dump" (echo of the frequency and mode commands followed
by the "info", VFO A, VFO B, selected receive VFO, selected transmit
VFO, Preamp status,  Attenuator status, selected antenna, AGC Speed
and status, and noise blanker status) is complete.  Unfortunately, the
"data dump" is not consistent as the VFO A frequency, VFO B Frequency,
Selected Receive VFO, and Selected Transmit VFO responses *can* appear
multiple times!

Multiple observations shows that it takes between 1000 and 1500 ms
following receipt of an FA or FB command that results in a band change 
before the K3 has settled *and* sent all of the "data dump" - even at
38,400 bps - with the P3 in line.  If the logger has polled several
times during that period, the command queue in Router will be badly
backed-up and will certainly have difficulty matching poll/response.

The next version of Router will include a mode for the K3 that will
pause polling (queue incoming data) for 500 ms after a command that
will cause a band change in an attempt to prevent the loss of response
data during the "stupid period".  However, until Elecraft fix their
problem with silently ignoring polls while the synthesizer is settling
and the CPU is sending the status dump, the problems will probably
continue as the oldest unmatched polls must "time out" from the command
queue in microHAM Router.

73,

    ... Joe Subich, W4TV
        microHAM America, LLC.
        http://www.microHAM-USA.com
        http://groups.yahoo.com/group/microHAM

        support at microham.com

This message, including any attachments, may contain proprietary, 
confidential or privileged information for the sole use of the specific 
individual(s) to whom it is addressed.  You are hereby notified that any 
disclosure, copying, distribution, or use of this message is prohibited. 
  If you have received this message in error, please immediately notify 
the sender by reply e-mail and delete it.


On 12/4/2011 3:12 PM, Bob Wilson, N6TV wrote:
> A bit too many steps.  Streamlined procedure:
>
>     1. Move cursor to the faulty QSO
>     2. Press Alt-F1 or Alt-F2 to the correct band
>     3. (Optional:  press Ctrl-Z to undo the change if you edited the wrong
>     QSO by mistake)
>     4. Move the cursor up or down from that QSO to save the change
>     5. (Optional:  move cursor back to QSO and press Alt-F to verify that
>     band and freq. now match)
>
> Before doing this, to locate any possible mismatches between band and
> frequency, use the WRITELOG command to export a .txt or .csv file,
> including both band and frequency.  Sort the file by band or frequency and
> note the QSOs with the mismatches.  It would be nice if Tools | Check Log
> could do the same.
>
> Note that Bjorn is using Win-Test with an MK2R+ with two Elecraft K3s.
>   This is an unreliable combination using the latest release of microHAM
> Router software and firmware (no problems on very old microHAM Router
> version 5.1.1, micro KEYER 2R+ v3.0 firmware).  I think that probably
> explains why Bjorn is seeing so many mismatches between recorded band and
> frequency: there are timeouts when talking to the K3, especially after
> changing bands, and apparently even using the microHAM "K3 Patched" radio
> choice in the Router software doesn't completely solve all the problems).
>
> 73,
> Bob, N6TV
>
> On Sun, Dec 4, 2011 at 11:57 AM, Bjorn LB1GB<lb1gb at la8w.com>  wrote:
>
>> How to edit your QSO with Alt-F if band is correct and frequency is
>> wrong and vice versa I guess.
>>
>> Move cursor to the faulty QSO
>> Press Alt-F and note the frequency
>> Press Escape to close the Alt-F dialog
>> Press Alt-F1 or Alt-F2 to change the band of that QSO - make a note of
>> the correct/origianl band!
>> Press Alt-F and note that the frequency hasn't changed
>> Press Escape to close the Alt-F dialog
>> Move the cursor up or down one QSO, then back the the modified QSO
>> Press Alt-F and note that the frequency has changed to match the band,
>> and that it defaults to frequency eg. 3500, 1830 etc..
>> Press Escape
>> Press Alt-F1 or Alt-F2 to change to correct band
>> Move the cursor up or down and back to the faulty QSO, press Alt-F to
>> check that correct/original band match frequency.
>>
>> Thanks Bob, N6TV
>>
>> 73 Bjorn
>> _______________________________________________
>> Support mailing list
>> support at win-test.com
>> http://lists.f5mzn.org/cgi-bin/mailman/listinfo/support
>>
>
>
>
> _______________________________________________
> Support mailing list
> support at win-test.com
> http://lists.f5mzn.org/cgi-bin/mailman/listinfo/support

--