WriteLog
[Top] [All Lists]

Re: [WriteLog] digirite issues during the WW

To: Ed W0YK <ed@w0yk.com>
Subject: Re: [WriteLog] digirite issues during the WW
From: Jeff Stai <wk6i.jeff@gmail.com>
Date: Wed, 4 Sep 2019 11:53:29 -0700
List-post: <mailto:writelog@contesting.com>
Sorry for the delay in coming back around, Ed. Busy with work stuff...

Appreciate ALL of your comments and I understand more now, thanks. I bring
things up like this to share what I see and maybe some of it helps with the
next iteration. I'm pretty firmly in the Digirite camp, it makes way more
sense to me than WSJT.

I think the right/left click behavior needs to be reversed. Left should
maintain my Tx, right should choose zero beat Tx.

In general, left clicks are the typical, right clicks are the less-typical
or special case. In RTTYrite you left click to get the call into Entry
(typical), you right click to push the call to the call stack (less
typical). I totally get why responding zero beat on the CQ Tx frequency is
desirable (and I think it's pretty cool too!) but maintaining your own Tx
is also desirable and I still think more typical. Having to right click
most of the time is awkward on a mouse, and if you are using a trackpad,
could be REALLY awkward. (Ed, you even called it an exception. :) )

If I choose zero beat Tx, is there a way to go back to my previous Tx? I
don't remember seeing that.

Thanks and 73! jeff wk6i


On Sun, Sep 1, 2019 at 6:19 PM Ed Muns <ed@w0yk.com> wrote:

> *Comments below …*
>
> *Ed W0YK*
>
> -----Original Message-----
> From: WriteLog <writelog-bounces@contesting.com> On Behalf Of Jeff Stai
> Sent: 01 September, 2019 13:24
> To: Writelog Reflector <writelog@contesting.com>; Wayne <
> support@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 WriteL**og'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 logi**c 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 an**d**
> 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 w**as 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-cl**ick, but occasionally I may
> choose to left-click when, say, the CQer is on 1**4.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 aud**io 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 s**trong signal, it may not
> decode.  Or there can be other signal irregularities that prohibit
> decoding.  It’s no different than WSJT-X.  Probably be**cause 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 w**hat 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, base**d** 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 with**out 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 observatio*
> *n.*
>
> Thanks! jeff wk6i
>
> --
>
> Jeff Stai ~ WK6I ~ wk6i.jeff@gmail.com
>
> RTTY op at W7RN
>
> Twisted Oak Winery ~ http://www.twistedoak.com/
>
> _______________________________________________
>
> WriteLog mailing list
>
> WriteLog@contesting.com
>
> http://lists.contesting.com/mailman/listinfo/writelog
>
> WriteLog on the web:  http://www.writelog.com/
>


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