WriteLog
[Top] [All Lists]

Re: [WriteLog] digirite issues during the WW

To: "'Ron Lodewyck'" <rwlodewyck@gmail.com>, "'Don Hill AA5AU'" <aa5au@bellsouth.net>
Subject: Re: [WriteLog] digirite issues during the WW
From: "Ed Muns" <ed@w0yk.com>
Reply-to: ed@w0yk.com
Date: Mon, 2 Sep 2019 08:32:03 -0700
List-post: <mailto:writelog@contesting.com>
I agree that an Alternate message W0YK AA5AU RR73 should be sent in an exchange 
repeat situation.  However, in the current DigiRite implementation, the QSO 
would have been logged anyway.  The user would have to intervene to delete or 
unclaim the QSO in the log.

 

I also evolved to sending Alternate message RR73 many times, just to clarify to 
my QSO partner to eliminate, or minimize, misunderstanding.

 

On the last example, you don’t know WHY the other station is repeating their 
Grid Square exchange.  It could be:

 

a.      He, or his software, made an inadvertent mistake by repeating his 
exchange,
b.      He didn’t hear any reply message from you, so he simply repeats,
c.      He is running WSJT-X NA VHF Contest mode, which expects VE6AX AA5AU R 
EL49 after his AA5AU VE6AX DO20 message, or
d.      He doesn’t have your Grid Square and is trying to elicit it from you.

 

In cases c. and d., sending RR73 doesn’t make sense.  The safe thing to do is 
send R EL49, because it covers all 4 cases.

 

FT4 Problem:

The other supporting evidence that this FT4 problem may not be clock sync is 
that reception was excellent in my case.  A loud, clear CQer kept showing up 
each cycle and I’d call for 5 repeats before DigiRite timed out, then repeat 
again.  Persistence seldom succeeded.  Since I was receiving so solid, it 
wouldn’t seem to be a clock issue.

 

Still, I do not understand my DT times varying so widely from 0.0 to 0.9 
seconds across all callers.  The DT time of a given call sign seemed be 
consistent, but between call signs it appeared random.  Even my own 
transmissions showed a DT of typically 0.6 which makes no sense.  I don’t know 
how DT is determined by the software.  (I understand how it is supposed to 
work, but just not the software details that might give a clue as to what is 
wrong with the numbers DigiRite is seeing.)  I even loaded up WSJT-X to see 
what it showed and the DT times were much tighter-grouped around zero.

 

Ed

 

 

 

From: Ron Lodewyck <rwlodewyck@gmail.com> 
Sent: 02 September, 2019 07:26
To: Don Hill AA5AU <aa5au@bellsouth.net>
Cc: Writelog Forum <writelog@contesting.com>; Ron Lodewyck <ronl@csustan.edu>; 
Ed Muns <w0yk@msn.com>; Ken Beals <k6mr@outlook.com>
Subject: Re: [WriteLog] digirite issues during the WW

 

I agree with Don - there needs to be another RR73 follow-up when you are the 
CQer and the other guy repeats his report.  

 

And I had the same issue as Ed (and also, as I recall, Ken K6MR) regarding 
mysterious end to QSOs.  I stopped getting replies to my CQ's as well as calls 
to others - some quite strong - around 0230 UTC or so  when I switched to 80M. 
Rate went to near, but not quite, zero, for over an hour. Gave up in 
frustration.  Should have rebooted I think. Anyway, I checked on Ed's 
hypothesis that our clocks might have drifted or been off too much for FT4 by 
looking in the DigiRite Log (wow! it saves EVERYTHING decoded or transmitted. 
Impressive and useful.) I see no correlation between DT (clock difference) and 
success in either CQing or answering others from the beginning of the contest 
to when I switched to 80 M. From the very beginning of the contest there is a 
wide variation in decoded signals DT from (in my case) -0.1 to +1.0 and many 
successful QSOs on FT4. That same range of DT occurs later, when I switched to 
80M, and the rate went to near zero.   So, clock synchronization does not SEEM 
to be the culprit - at least in my case. Something else was going on but beats 
me what...

 

See Don's comments on the two situations where RR73 needs to be sent again.

73,

Ron N6EE

 

 

 

On Sun, Sep 1, 2019 at 10:31 PM Don Hill AA5AU <aa5au@bellsouth.net 
<mailto:aa5au@bellsouth.net> > wrote:


[Don AA5AU] The message doesn't appear fast enough in "Calculated next to
send" to know if something is going to be sent or not. I was frustrated time
and again when I went S&P to call a station while I had CQ enabled. This is
what happens.

CQ W0YK CM97
W0YK AA5AU R EL49
AA5AU W0YK RR73
CQ AA5AU EL49

I don't think this is right. We can debate it. I would think my last
transmission should be W0YK AA5AU RR73. I understand the rationale behind
going right back into a CQ. But it gets cloudy when I don't receive the W0YK
AA5AU RR73 message on the first try. It goes like this:

CQ W0YK CM97
W0YK AA5AU R EL49
nothing copied from W0YK
W0YK AA5AU R EL49
nothing copied from W0YK
W0YK AA5AU R EL49
AA5AU W0YK RR73
CQ AA5AU EL49

W0YK may be thinking that the QSO is not complete because I went right back
into CQ without sending RR73 and he does not log it. We are both out of a
contact.

I got good at turning off CQ. When I turned off CQ while S&P, sometimes it
sends the ending RR73, but sometimes it sending NOTHING AT ALL like this:

CQ W0YK CM97
W0YK AA5AU R EL49
AA5AU W0YK RR73
...DigiRite sends nothing...

I'm sitting there looking at "Calculated next to send" and don't see
anything then realize nothing is getting sent. I finally use "Alternate
messages" to send the RR73 message but it's a cycle or two too late. This
was the biggest issue I had with DigiRite all weekend. I use "Alternate
messages" to send RR73 for probably half my contacts.

.

 

[Don AA5AU] The only other issue I can think of now is when you are the CQ
station, another station answers, you send RR73 but the other station didn't
receive it and sends their grid again and WriteLog then sends R + Grid
message instead of RR73. Like this:

CQ WW AA5AU EL49
AA5AU VE6AX DO20
VE6AX AA5AU RR73
AA5AU VE6AX DO20
VE6AX AA5AU R EL49

Why not just send VE6AX AA5AU RR73 again?

_______________________________________________
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>