|
|
Post by WX2S on Feb 5, 2022 23:54:10 GMT
If the DX calls me in Hound mode, JTDX gives up after only two attempts to call the DX. Is this correct according to the DXpedition Mode standard?
19. WSJT-X maintains several queues in a manner that allows difficult QSOs to be
completed while keeping the overall QSO rate high. We use a “3 strikes and you’re
out” rule. Fox will call a specific Hound up to 3 times, waiting for an “R+rpt”
response. If a Hound repeatedly sends an “R+rpt” message, Fox will send RR73 up
to 3 times. Finally, the total timespan of an attempted QSO is limited to 3 minutes.
When any of these timeouts is exceeded, the QSO is aborted.
For example:
Z22O WX2S FN20 WX2S Z22O -14 Z22O WX2S R-23 (no copy from Z22O, he could have sent WX2S Z22O -14 second attempt or WX2S Z22O RR73 1st attempt) Z22O WX2S R-23 (no copy from Z22O, he could have sent WX2S Z22O -14 third attempt or WX2S Z22O RR73 2nd attempt) Z22O WX2S R-23 -- Halts after one or two seconds
It seems to me that JTDX should let the hound continue three times to allow three RR73 attempts. Am I looking at this the wrong way?
73, -Steve WX2S
|
|
|
|
Post by Arvo ES1JA on Feb 6, 2022 8:54:47 GMT
I suspect You overload cpu with to agressive decoder settings, how much Lag You see? In some situations on missing reception period Your transmit of R report is counted twice in transmitted messages counting. From description I see that tx is interrupted after decoder ends, so Lag should be the same one or two seconds.
On receiving Foxes Lag should be negative value.
I can try to avoid this halt, but then there will be the fourth Tx interrupted in same way.
|
|
|
|
Post by WX2S on Feb 6, 2022 10:19:06 GMT
I'm not sure precisely which lag you mean. The time between t=14 seconds and the decode complete is less than one second on a fairly busy subband.
I also checked CPU utilization with Task Manager. It peaks at 100% (if I'm also running JTAlert) but drops quickly.
In any case, what you're describing doesn't match the symptoms I'm seeing. If the TX gets counted double, then the third transmit cycle shouldn't even start, should it? And I'm not seeing any "partial loss of data" messages, which I'd expect to see if the decode couldn't complete within the 15-second cycle.
73, -Steve WX2S |
|
|
|
Post by Arvo ES1JA on Feb 6, 2022 11:11:02 GMT
I'm not sure precisely which lag you mean. 73, -Steve WX2S
I mean this value labelled Lag in top row of messages window. Lag=-0.42 in mine picture You should have there +1... or something like that. In other words Lag mean difference of transmission start time to previous decoding end time.
If You enable debug info writing into ALL.TXT file then You can see from there in which reason Halt Tx was called.
|
|
|
|
Post by WX2S on Feb 6, 2022 11:32:57 GMT
The lowest I can get it to is +4.3, with minimally aggressive decoding. My CPU is 6 cores running at 3 GHz.
I didn't have debug messages enabled to ALL.TXT, but I've turned that on.
|
|
|
|
Post by Arvo ES1JA on Feb 6, 2022 11:52:07 GMT
Cpu should be enough.
Set SWL off
Decode/
FT8 threads 4
FT8 Decoding/
decoding cycles 1
QSO Rx freq sensitivity medium
decoder sensitivity use low thresholds
enable early start of decoder
enable Wideband DX Call search
|
|
|
|
Post by WX2S on Feb 6, 2022 11:57:49 GMT
Done, lag is down to +0.40 (on 80 meters, which is fairly busy.)
I'll see what happens when I next use hound mode.
73, -Steve WX2S
|
|
|
|
Post by Edmundo CE2EC on Feb 6, 2022 16:26:12 GMT
HI Steve. they are using multi slot MSHV, yesterday I contacted them in 40m it was twice trying to do them at the end they confirm me with RR73  |
|
