Anyone in the continental USA that did not copy N5J at any time during their stay when they operated on SuperFox, was obviously not there when propagation peaked in their area. Bad timing. It had nothing to do with SuperFox vs. standard F/H.
When they were on 20 meters in the mornings, I was able to decode their SuperFox signal for over two hours, with my 6 meter beam and a 20 dB attenuator in front of my LNA (which has a 0.4 dB NF and 20 dB Gain). 10 and 12 meters were marginal here with my 80m OCF dipole at 42', throughout their stay. 10m prop was awful. 12m was slightly better, but still very poor. I still worked them on both bands, but I was VERY lucky. I only heard them once on 10m. On 80 meters, I only heard them once sporadically over a 20 minute period on my 80 meter Inverted L (at 42'). I worked them during a five minute period when they peaked at -12 just minutes before sunrise.* I did not hear them at any time on my 80m OCF Dipole, on 80m*. I provide these details so that it can be seen that I don't have a super station. On 10/12/80 meters I caught propagation just right, and it had nothing to do with SuperFox vs. F/H normal. On 15/17/20/30/40/60 meters they were quite easy on SuperFox (except on 60 meters where the ran ONE STREAM of regular FT8 and were easy to work on my 80m Inverted L) The only time regular F/H was superior to SuperFox was when they (normal F/H) were limited to one or two streams. I saw reports of N5J at -21, and the threshold for SuperFox is -16. So when normal F/H is limited to one or two streams, it can be superior to SuperFox by up to 5 dB, but limited to 2 streams. There is a case for normal F/H to be used with especially difficult paths and/or with especially difficult propagation conditions. Caveat: If N5J ran more than 2 streams it was *no stronger than SuperFox. *(at my location) So my conclusions: (in the USA) With respect to digital operation 1. If you didn't decode N5J at any time, you were either a victim of bad timing or had other station problems. (like running RC5 instead of RC6, or a victim of solar flares) 2. DXpeditions should set aside some time for regular Fox & Hound operation, but limited to two streams, 3. The majority of time they should run SuperFox. Good luck with CY9C. They should be crushingly loud in the USA, EU and SA. They have been granted a SuperFox key, and they are running good antennas as well as appropriate power. 73, N0AN Hasan On Sat, Aug 24, 2024 at 8:51 AM 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
