I have seen this same phenomenon when a filter is engaged (improved plus), and the filter is set to exclude the USA...and it thinks K8R or N5J is in the USA.
I had it happen to me... 73, N0AN Hasan On Sat, Aug 24, 2024 at 8:35 AM Charles Suckling via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > 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 >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
