[WriteLog] digirite issues during the WW

[Ed Muns]

Comments below .

Ed W0YK

-----Original Message-----
From: WriteLog <writelog-bounces at contesting.com> On Behalf Of Jeff Stai
Sent: 01 September, 2019 13:24
To: Writelog Reflector <writelog at contesting.com>; Wayne
<support at writelog.com>
Subject: [WriteLog] digirite issues during the WW

Observations and suggestions. Overall a heck of a nice piece of code and I
very much preferred it over using WSJT-x.
[Ed Muns] Strongly agree.  This was confirmed again during the 22 hours I
spent in WW Digi.  I really like WriteLog's RTTY and digital software
design.

1. Check boxes unchecking. At various times - when re-sending - the check
boxes for the QSOs in progress, Calculated next, and/or the Automatically
Transmit Next would simply uncheck. One example would be answering a CQ,
then not seeing a CQ for a couple cycles, then seeing the CQ but whoops the
box is not checked so I don't get my answer sent in the next cycle.

Another case was I was calling CQ and saw a multiplier pop up in the CQ
window. I quickly clicked on the call and Automatically Transmit Next was
unchecked and I missed responding. And more than once I saw the call get
unchecked in QSOs in progress after just one or two resends.

In none of these cases and others was I anywhere close to the 5 minute
inactivity timeout. Maybe 2 or 3 minutes at the most.
[Ed Muns] The logic needed in DigiRite for handling QSO message sequencing,
given all possible situations, is daunting, though at first glance it may
seem simple.  I'm impressed it works as well as it does at this point in its
development with the limited amount of experience users have had with it.

Check boxes "uncheck" for reasons other than timeouts.  They may need to
uncheck based on what is happening in the QSO sequence(s).  This is
especially true for the Calculated next pane where "next" is the next QSO
phase.  Not only do boxes check and uncheck, but calls come and go.
DigiRite is trying to figure out what the next best move is and let the user
know.

2. Scrolling in the CQ windows needs to be more "RTTYrite-like" and not
jumping around while populating. Trying to click on a moving target
resulted in some erroneous calls and lost Qs. Ditto the Messages to me
window (I operated with Auto respond unchecked.) I gather some sort of
prioritization is going on? But I prefer to choose who to contact next.
[Ed Muns] Agree that clickable lines in a pane cannot be moving around.  The
RttyRite scroll technique is innovative and being copied by others for just
this reason.

3. Calculated next - often was blank but the right next message was chosen
and sent anyway.
[Ed Muns] Agree.  Work in progress.

4. Sometimes I would see the expected message in the conversation window
but a repeat was sent as if the message hadn't been recognized.
[Ed Muns] Yes, this needs to be considered along with other feedback.

5. "Starting a QSO by answering a CQ message is the only way that DigiRite
puts its QSO's transmit frequency on the other station's RX frequency."
Someone needs to explain why this is desirable.
[Ed Muns] Ah, I can proudly answer this one because it tripped me up until I
was enlightened with the very elegant solution that somehow I missed in the
docs.  If you left-click on a CQ message line (not the checkbox, but the
text line itself), your transmit frequency is zero beat with the CQer.  If
you right-click, your transmit frequency is split (where you have your
transmit frequency set).

This is VERY handy, because dynamically you can effortlessly choose where to
transmit.  Most of the time I right-click, but occasionally I may choose to
left-click when, say, the CQer is on 14.082.500.  In cases like this I can't
know where his radio dial frequency is set.  He could be at 14.080 with an
audio frequency of 2,500 Hz, or he could be on 14.082 with an audio
frequency of 500 Hz.  If he and I are on different dial frequencies, it is
possible my TX frequency won't be in his RX passband so he can't hear me.
Zero-beating eliminates that possibility.

Over in the WSJT groups I see that it is considered poor practice to
transmit on the RX frequency - which I can see because someone could
already be using the other cycle. Usually I have gone to the trouble of
finding a clear place and I'd like to stay there. And if I am CQing and I
see a multiplier appear I want to be able to snag it and keep in my clear
spot.

I'd prefer to see a "Hold TX" like on WSJT-x so I keep my place no matter
what, or maybe let's just not do this?
[Ed Muns] In general, I agree, but there can be exceptions like the example
above.  Fortunately, WriteLog makes it easy to do what's best, on the fly.

6. I was amazed at seeing so many strong signals in the Transceive window
but seeing so few decodes as a result. Not sure what to make of that...
[Ed Muns] If the clock sync is off on a strong signal, it may not decode.
Or there can be other signal irregularities that prohibit decoding.  It's no
different than WSJT-X.  Probably because the decoder is the same software!

7. I'll echo the request I saw elsewhere for being able to do the longer
sequence with signal report when the other op expects it. I found I was
able to click and choose the alt message if I was quick but I had to be
right there after seeing the decode in the conversation window.  I see this
as analogous to a RTTY op getting conversational on you in a contest. It's
just polite practice, even if you'd rather not... :)
[Ed Muns] The Alternate messages worked well for me in this regard, with the
exception that at times (which I couldn't predict), selecting an Alternate
message ALSO required checking the Manual Edit checkbox before the message
went out.  Until I understand what I'm doing wrong (or, if a bug, it is
fixed) my work-around is to quickly check the two boxes.  Even so, I was
able to do it fast enough to enable smooth message flow . even SO2R.

8. I wish I had taken a screen shot of this, but last night I was noticing
some weirdness in the number of points per QSO. Stuff like an N5 being 5
points while a CE is 3 points. Also my score was like 4000 something. I
made a mental note the check on it later.
[Ed Muns] I would have taken issue with this observation, based on my prior
experience, but ZW5B, which is PY5EG's station, gave me 4 points.  I would
have guessed 2.  So, maybe there is a glitch, but it doesn't matter.  The
log check software calculates points and ignores whatever the logger says.
We ignore the Cabrillo Claimed Score in the Raw Scores listing, rather using
the log check software to calculate score without any log check error
considerations.

This morning after I made my Cabrillo I went to do my 3830 post. That's
when I noticed my score was now 2000 something and my points now appeared
correct. I don't know when this change happened and I'm reasonably certain
I wasn't on drugs.
[Ed Muns] Well, I'm not sure I can corroborate the drug part, but glad the
score seemed reasonable.  BTW, some of the 3830 scores do seem off, either
low or high, but that's just an anecdotal observation.

Thanks! jeff wk6i

-- 
Jeff Stai ~ WK6I ~ wk6i.jeff at gmail.com <mailto:wk6i.jeff at gmail.com> 
RTTY op at W7RN
Twisted Oak Winery ~ http://www.twistedoak.com/
_______________________________________________
WriteLog mailing list
WriteLog at contesting.com <mailto:WriteLog at contesting.com> 
http://lists.contesting.com/mailman/listinfo/writelog
WriteLog on the web:  http://www.writelog.com/