Greg I believe it is the case that if you decoded them at all, which you did, then you would also be able to decode a message containing other content. The signal does not have to be stronger to support multiple messages. This is one of the features of the mode.
Thus, it seems most likely that for whatever reason they were not copying the hounds, or not putting them in the queue to be called, or whatever. By calling blind, what is meant is hounds calling fox before they have even decoded fox. From my own observations of local propagation conditions, this seemed to be happening a lot. I've seen hounds calling for tens of minutes after N5J changed band. 73 Charlie DL3WDG On Sat, 24 Aug 2024 at 14:14, 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
