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
