Forgive me if this appears in another thread. I did make a gallant effort to read the contest rules and search the forum. The question is simple...When encountering non-contest-aware in SSB contests it fairly easy to have them provide a sequence number of 001. But how does FT8 work if a station responds to an FT8 CQ with a normal (non-contest) FT8 sequence? Do we ignore the call, or change our sequence on the fly? Thanks
I did a combination of FT8 and RTTY during the contest. I used the suggested FT8 frequencies and didn't come across a single non-participant. Normally, FT8 on 40m is around 7.047, for example. For the contest, it was 7.080 and above. People had to manually tune there, and when they did, they probably knew why. You aren't usually going to find some random FT8er way outside of the normal frequencies. Field Day was the notable exception, because everybody was just using the normal frequencies. So you had a huge mix of contest and non-contest stations. If you're Top 10, you would probably ignore the QSO, since you can't get the correct exchange. But anything outside of that, just make it up. You made the QSO. You know you made the QSO. Take credit for it.
Thanks....... I had tossed out using FT modes at the start of the contest, but after depleting most of the RTTY contact at 3AM I decided to give it a try. Downloaded the guide on how to change the frequencies, but decided against modifying anything mid-contest. I try to avoid changing configs once I am rolling, my previous "tinkering" with configs knocked me offline for several hours. In the end I simply swapped to FT4, and lo and behold, the entire herd on the FT4 waterfall was made up of contest participants. I do have another question. Did you have any problems with WSJT-X crashing while in use. I noticed that when I had more than two stations calling the inbound queue became unstable which caused a s/w fault closing the WSJT main window. I tried restarting WSJT-X from within N1MM to no avail, when WSJT crashed the TCP ports it utilizes remained open which prevents restart. The only solution was to shutdown N1MM completely and re-open. Nothing was lost in the process except time and probably a few annoyed callers that I left waiting at the altar. I have been unable to duplicate the fault using the WSJT "Non-Contest" mode. One theory is that the error is procedural, I often start clicking buttons to speed up the exchange and could be causing the error myself. Your input is needed to determine the root cause, did you experience any crashing? (I'm using Windows 10, and the latest N1MM and WSJT-X versions)
I did not have any issues with WSJT this time, because I didn't run into a single non-contester, but we ran into that exact problem on Field Day. We were not using N1MM or Windows 10, and still had the issue. Best I could tell, it only happened when several non-contesters called. It basically locked up WSJT. That would also explain why you can't duplicate it in non-contest mode. It happened 2 or 3 times during Field Day.
It only happened with Constestors. There seems to be a glitch in the contest message sequencing. Occasionally the program will send a return RR73, other times it stops after the initial return sequence. I suspect it has to do with a software conflict if the user logs the first contact while the second contact is setup for the next sequenced call. It never occurred during a single station call, and always occurred between logging and placing the second (or third) call.,
I had sequence problems too. Mine would occasionally repeat the signal report, in response to a good report, creating a loop. I had to manually advance to RR73 to fix it.
