Mike,
I want to be helpful but I have 60gb, 60k wav files! I'll look for a while but
not going to spend all day looking. I keep wsjt running 24x7 so my wav files
are bonkers.
Trust me when I say this condition existed MOST of the time with N5J .
Consider the following conditions which happened all the time:
1- listening for SF station on a band where activity is known. Can only decode
stations calling/reporting to fox.2- receive verified message at end of fox
sequence, nothing else.3- call fox4- fox hears me, calls me.5- continue to
receive verified message at end of fox sequences, nothing else.6- continue to
call fox7- fox keeps sending me reports I cannot hear.8- I stop calling9-
verified messages stop, prop changes, not enough signal for me, go back to #1
situation #210- receive fox cq with no previous fox decodes11- call fox12- fox
calls me13- fox too weak for me to copy my report14- I continue to call fox,
fox continues to call me.15- one or both of us gives up. Go back to #1
16- one or two sequences within a span of 2-3 hours, I decode reports from fox
and verified msgs17- I call fox18- fox hears me but que jammed19- I call fox
until I cannot decode fox (2-4 sequences typically)20- fox que clears, fox
calls me21- prop peak diminishes, signal from fox now too weak for me to
decode22- fox continues to call me until gives up. Go back to #1
This is what happened at my station for the entire N5J expedition. I'm not a
novice FT8 op, have 8 band dxcc and over 100,000 ft8 contacts in my log.
The bottom line is SF mode IS self defeating when/where conditions are marginal
AND they are always marginal somewhere in the world thus the above conditions
guarantee an expedition will waste a lot of time clogging itself with activity
it cannot complete. The problems are not intentional interference or stations
intentionally calling blindly, it is a problem of unexpected consequences.
I'll dig for some wav files but all it will do is verify my observations.
W7MY
---------------------
Greg Chartrand
Richland, WA.
On Saturday, August 24, 2024 at 05:56:25 AM PDT, Black Michael
<mdblac...@yahoo.com> wrote:
If you still have WAV files would like to see a series where you were decoding
CQ but not any other reports.There was QRM at times which caused problems.
Mike W9MDB
On Saturday, August 24, 2024 at 07:24:19 AM CDT, Greg Chartrand
<w...@yahoo.com> wrote:
RC6
---------------------
Greg Chartrand
Richland, WA.
On Saturday, August 24, 2024 at 05:21:11 AM PDT, Black Michael
<mdblac...@yahoo.com> wrote:
What version of WSJT-X were you using? RC-5 had decoding problems which RC-6
fixed.And the verified message applies to the CQ too. Don't want to get rid of
that.
Mike W9MDB
On Saturday, August 24, 2024 at 07:13:59 AM CDT, Greg Chartrand via
wsjt-devel <wsjt-devel@lists.sourceforge.net> wrote:
So I spent about 10 hrs/day listening for N5J on all bands using PSK reporter
to know when/where they were at.
It was my observation that most of my decodes were the "verified" message and
"CQ" of the fox WITHOUT the ability to decode any reports from the fox.
So this encouraged me (and others) to believe I could make a contact when in
fact, I could not because there was not enough signal to receive a report.
So you want to blame those blindly calling the fox when based on the SF
instructions and the situation where the verified and CQ messages are the only
copyable messages at the hound.This causes the the fox to try to contact
stations it cannot work thus the que is jammed up with unworkable stations.
Rather than create a watchdog timer, why not look for decoded report messages
from the fox to know there is enough signal to make a contact? Additionally,
don't print a verified message unless there are decoded reports. The CQ message
will still create problems unless the power of the fox is reduced to match the
strength of report messages.
The few times they operated std. F/H mode, I was able to copy the fox only when
a contact was possible thus knowing when to not call. SF mode in marginal
conditions is self defeating.
Greg
---------------------
Greg Chartrand
Richland, WA.
On Saturday, August 24, 2024 at 01:42:19 AM PDT, Sakari Nylund via
wsjt-devel <wsjt-devel@lists.sourceforge.net> wrote:
The key has been major subject lately. Specially hacked key. This is the first
try to identify DX using modern tools during qso.
Could LoTW certificate be tied somehow to key creating process?
Until now, from the beginning of Amateur radio, there has not been any way to
check station identity at qso time.
And still many DXs has been worked. Work first , worry later, is still good
rule. And will be.
I think more important would be to focus to SuperFox mode itself. After
monitoring the last (official) SFox operation
it seems to me that greatest problem was the repeating of reports to Hounds
that blocked up the qso rate.
Reason, what I think, was partially at Hound side. They did not copy the SFox
because of tuning and jamming on SFox period, and that SFox transmit
is also harder to copy (needs more dBs) than regular FT8 stream.
This has also a good side: If Hound can copy SFox then it should be easier for
SFox to copy a Hound that uses regular FT8.
Unfortunately there are also callers that keep calling even when they have not
copied SFox for long time.
Could there be TX watchdog that shuts off TX if SFox has not been copied in,
lets say, 3 - 5 minutes?
And it would keep TX off until SFox is again copied.
So far, so good. But then comes the amount of Hounds, that can copy SFox,
calling all the time. The queue of Hounds waiting for report grows at SFox side
and it will
take a long time before queued Hound will get his first report.
During that time band conditions may change. In addition that other Hounds
will change their calling frequency causing queued Hound to be
rolled over by other Hounds.
Then, even that Hound can copy his report, SFox can not copy the Hound any
more. I think that was quite usual.
I once happened to see that SFox announced that he will move from 20m to 10m.
After that 20m transmit ended and I checked 10m, but nothing was
heard. So I returned to listen on 20m.
After a while SFox returned too and for a while qso rate was very good because
there were not so many Hounds in queue and they get their turns
after little or no waiting. No band condition change or to get rolled over by
other Hounds at that time.
I think that proves that DX operator should keep the Hound queue as small as
possible to prevent long queue times.
A heard Hound should be worked fast before he disappears.
This needs more work from operator than just picking all heard Hounds to
massive queue. That is human work. (or AI's)
My technical suggestion is that SFox should take the "answering property" from
legacy Fox.
I.E. when Hound gets his report his TX is moved to beginning of band for
answering. The beginning from 200Hz upwards should be divided to maximum SFox
reply count of slots (was it 9?).
This frequency range should be reserved for reply only, not for calling SFox.
Just like legacy Fox mode.
Is this stupid idea?
And do we have free bits left to point those answering slots to Hounds?
--
Saku
OH1KH
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
