Folks,
Having returned home a few weeks ago from conducting the A35JT DXpedition to the south Pacific, there are a number of things in FT8 fox mode that I feel need urgent attention for future expeditions. Some of these are on the critical list and some are workflow and control things that I will discuss at a later date. The two items on the critical list that I would encourage the team to quickly address for the sake of current and near future expeditions are as follows: 1. There is a need to restore visibility of the band activity window when you are in FOX operator mode (not hound mode). Right now, a classic example of why FOX operators need access to this window is playing out of 21091. Both YJ0FWA and TX7T are on 21091. As a FOX operator I am pretty sure they have no idea that they are co channel. When you are in FOX mode, you have no access to the band activity window and so cant see if someone else starts up on the same frequency as you. When I was in Tonga this was a problem too with 3 other major expeditions running at the same time as A35JT. (it also drove us down to 14067 at times to get away from all of the other activity with FT4 on 080, A82X on 084, ZK3A on 090 and then not wanting to clobber the beacons on 100 or WSPR on 097 or the ALE/Automated stations above 100). So can I please urgently request the development team consider re-instating visibility of the Band Activity window as a high priority so that we can stop having blind fox operators not knowing they are suddenly sharing the channel? (consider that expedition operators do NOT always have access to Internet or clusters to receive other warnings either). 2. Secondly, and this was a MOST frustrating aspect of using the software. No matter what we did we couldn't seem to find any settings that would stop the "Enable TX" button from being cancelled every time the FOX sent RR73 on any channel. Now it appears as though this is by design although I hope it is in fact a bug. Our view is that if the FOX operator had made the deliberate effort to load a station into the calling queue then the enable TX button should remain active until the last station leaves the calling queue. The old 2.0.1 version did work like this when unchecked the "stop transmitting on RR73" option in settings - but had too many other problems with logging to be usable. 2.1.0 however does not work the same way - and even when that setting is unchecked it still stops transmitting whenever an RR73 is sent regardless of the progression state of any other channels that are active mid QSO at the time. The RR73 TX disable appears to work as an OR function (when any channel sends RR73 shut down the TX) where it really needs to be an AND function (when all channels have either sent their RR73 or have timed out due to retries and have nothing more to send). The impact of this is that as a FOX operator you are having to hit TX Enable constantly particularly when multiple channels are running, in particular so that you don't break in progress QSOs that are not at RR73 stage on the other channels. At night when our operator count was low (we had to sleep at some stage), we would have one operator sitting in front of three transmitters VNC networked to a common terminal running 3 band synchronous FT8 fox mode to maintain a presence on the bands. He found that he was constantly hitting enable in all three instances of WSJT - an activity that patently didn't add value to a QSO's progression where it would have been better to spend more time watching queue progression and managing sub-channel count to try to increase the success of each QSO in progress. For the developer's consideration please? Best Regards, Grant VK5GR - A35JT DXpedition Team Leader + E6AG, YJ0AG Email: [email protected] Website: <https://vk5gr-iota.net/> https://vk5gr-iota.net/
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
