Joe, We tested a lot of the station before we left - as much functionality and hardware as we could in fact. However in the case of FOX mode, that is something that is extremely difficult to test until you arrive somewhere where people will a) accept you should be running FOX mode and b) are able to attract enough callers to even conduct the test. I'm afraid your suggestion of "test before you leave" in this case perhaps isn't a practical one :) Most expeditions running FOX mode these days start with small 2-3 man shows which head out to exotic places that justify FOX mode. Things like the RR73 problem only really become apparent after perhaps 15-30 minutes of use when it dawns on you what is going on too. In reality most FOX stations don't have the resources to try a full FOX mode QSO test as you suggested prior to leaving.
As for the band activity window - yes screen realestate is cluttered as it stands - but not being able to see the band activity is an extremely serious problem on the air. The "workarounds" proposed are just that - workarounds. Not all Fox operators will be that savvy (although I wish I had thought of the tail ALL.TXT idea out on the island). Actually, on reflection from when I parsed the .TXT files on returning home to find any unlogged contacts, I don't recall seeing FOX mode channel activity being logged in ALL.TXT at all. FOXQSO.TXT appears to be but I am pretty sure ALL.TXT isn't - and I don't recall FOXQSO showing band activity - only QSO activity. So again that workaround perhaps isn't a solution either? Option 2 for band activity could simply be inject copies of the decoded signals where station B is not the FOX into the existing Rx Frequency window in a different colour. This would highlight to the FOX operator that someone is responding to someone other than this FOX station on the FOX stations frequency. When the fox operator sees multiple rows of such traffic, that is enough of a warning that we have a frequency clash to alert the FOX operators to take action and at least stop and look at their channel perhaps in standard mode for a few minutes. No more screen realestate required than is being used today yet required functionality substantially delivered. Your thoughts on this option please? Regards, Grant -----Original Message----- From: Joe Taylor [mailto:[email protected]] Sent: Wednesday, 20 November 2019 1:51 AM To: WSJT software development Subject: Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement request Hi Grant, On 11/18/2019 4:20 PM, Grant VK5GR wrote: > Thanks for the reply - I am really pleased that the RR73 problem is in fact > a bug. I can tell you that it is driving FOX operators nuts on expeditions. > I guess we should have spoken up sooner. Memo to file: It's ALWAYS best to make relevant tests of critical software before embarking on a DXpedition, and to communicate with the software authors if issues are found. We could very easily have saved you lots of grief. > ... > Bottom line - FOX operators need some channel awareness to avoid these > collisions. An in built band activity window is vital. > > As for running a second instance, we did consider it - but facing fox mode > with 5 channels and hundreds of callers some of our laptops on the > expedition started to run out of grunt and screen real-estate given N1MM is > also active. To be practical, it really needs the band activity window > visible native in FOX mode within the instance the operator is running. What you're requesting would also require screen real-estate. Making visible just the Band Activity portion of a second instance's main window would not require much screen space. A better solution to your problem might be the one suggested by Iztok, S52D: monitor the tail end of the ALL.TXT file. You could use the free utility "BareTail". Or install the GNU utilities for Win32, for example http://unxutils.sourceforge.net/ . -- 73, Joe, K1JT _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
