Greg You don't have to save wave files if you don't want to. I normally activate 'Save all' before an operating session where something interesting might happen, eg testing a -rc release. If nothing interesting happens that you want to report, simply delete a day or two later.
Re you point 2, there should always be some other content in the message before a verified is received, eg a CQ with Grid if no other messages, or some calls/reports to hounds. I never saw a verified appear otherwise. Re 10/11 - I refrain from calling Fox until I have received several decodes in a row. If signals are marginal to cause this, then likelihood of a QSO is very low. What is missing from the discussion is what happened at N5J's end. I hope they are able to do this, as so far we only have the story from hound's perspective. 73 Charlie DL3WDG On Sat, 24 Aug 2024 at 15:51, Greg Chartrand via wsjt-devel < wsjt-devel@lists.sourceforge.net> wrote: > 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 fox > 4- fox hears me, calls me. > 5- continue to receive verified message at end of fox sequences, nothing > else. > 6- continue to call fox > 7- fox keeps sending me reports I cannot hear. > 8- I stop calling > 9- verified messages stop, prop changes, not enough signal for me, go back > to #1 > > > situation #2 > 10- receive fox cq with no previous fox decodes > 11- call fox > 12- fox calls me > 13- fox too weak for me to copy my report > 14- 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 msgs > 17- I call fox > 18- fox hears me but que jammed > 19- I call fox until I cannot decode fox (2-4 sequences typically) > 20- fox que clears, fox calls me > 21- prop peak diminishes, signal from fox now too weak for me to decode > 22- 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 >
_______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
