For what it’s worth: I support Grant’s request, specially regarding the required need to hit “enable tx” almost constantly.
Tom JW6VDA Sendt fra min iPhone > 17. nov. 2019 kl. 06:30 skrev Grant VK5GR <[email protected]>: > > 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/ > > > > _______________________________________________ > 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
