Frode,
As you have said you have never run FOX mode as a FOX. I can let you know that it is quite different to being a hound. I am not looking to turn it into a QSO robot and indeed if you read the logic I propose carefully and understand properly how FOX mode works you will come to see that the modification proposed will not yield that as a result. My request to modify the behaviour from “stop the transmitter after every time an RR73 is sent” to “only stop the transmitter when the operator selected caller queue is empty” (ie the last RR73 is sent or the 3 transmission timeout has occurred for all 5 potential QSO channels) will not turn it into a QSO robot. The operator still has to be actively there ADDING stations to the queue to keep the transmitter alive! When the operator stops adding stations to the queue and the queue empties then the software should rightly stop the transmitter. However as long as you have the operator having to hit enable after every 30 second over invariably the operator will be late selecting it every now and then and the transmitter will only activate for part of a transmission as a result. This costs everyone a retry typically, which when there are only three retries before a callsign is kicked out of the queue, greatly enhances the chances of the QSO not completing at all. This wastes channel time, and causes angst among the hounds chasing us with lots of “Missing Log Record” requests which are indeed just incomplete QSOs. NOTE: I am not looking for the behaviour to be changed for any other mode within WSJT. As it stands it works as it should for EVERY other mode. However no other mode has a 5 channel parallel QSO capability either. The issue with the parallel QSO capability is that an RR73 in one channel will kill the transmitter for the other 4 QSOs that are still in progress. It is destructive to say the least. Regards, Grant VK5GR – A35JT DXpedition Team Leader P.S. As a FOX running 5 channels you see things quite differently after 2 weeks. Mindless having to hit the enable button just to keep QSOs going all the time drove my crew to hate using it at all. As it is currently designed, the frustration felt by the A35JT team running it lead to an FT8 mutiny – resulting in them abandoning FT8 for a couple of days in favour of PSK and RTTY instead. From: Frode Igland [mailto:[email protected]] Sent: Monday, 18 November 2019 9:10 PM To: WSJT software development Subject: Re: [wsjt-devel] FT8 Fox and Hound Mode - FOX Mode Operator enhancement As I read Rich's message in digest format, a response may already be given, so my apologies if I repeat a previous reply. It seems like the check box under Settings - General - "Disable Tx after sending 73" repeatedly creates some confusion. The mouse-over help text describes exactly what checking this box does: "Turns off automatic transmission after sending 73 or any other free text message". Nothing more is implied, and specifically this does not mean that unchecking (the default state) it enables automatic transmissions after sending 73. The opposite, or the antithethical interpretation if you like, just does not apply, nor does the mouse-over help text indicate that it applies. Specifically, unchecking this box is no workaround to automatically create a red "Enable TX" button again after sending 73. That would possibly create an FT8 QSO robot enabling operations with no operator in attendance/control, which is illegal in many (most/almost all?) countries. WSJT-X includes considerably more demanding modes than FT8, e.g. meteor modes, where repeating the message after sending 73 may be required to complete a QSO and is normal until a return 73 has been received. However, sometimes the conditions are good even for these modes, and then it may be desirable to not transmit again after sending 73. That is a case when you check the box "Disable Tx after sending 73". For FT8 the general disabling of "Enable TX" after sending your 73 is desired actions and cannot overridden in standard WSJT-X, which has not prevented operators from creating robots. Having not worked as a Fox, I am not in a position to jugde whether clicking the "Enable TX" button is a sufficient PITA to enable DXpedition QSO robots. However, even for expeditions to very rare DXCC entities (for which FT8 DXpedition mode is created), the requirement for a control operator applies. Unattended FT8 QSO robots are no more legal in exotic places than other places. I understand the clicking inconvenience, but as far as I understand, all other modes used by DXpeditions require the operator to key the transmitter for each exchange in a QSO, either by stepping on a foot switch or a mike PTT button or by pressing a function key on a keyboard, so I don't know if clicking the "Enable TX" button once per QSO is widely different or too much to ask for FT8 Fox operations. man. 18. nov. 2019 kl. 01:03 skrev Rich Zwirko - K1HTV <[email protected]>: Grant, By any chance could the problem described have been caused because under Settings, General tab you had the "Disable Tx after sending 73' check box checked? I don't know if this might be bypassed in the Fox mode. If not, it should be disabled automatically when the Fox mode is used. 73, Rich - K1HTV = = = VK5GR wrote: 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. _______________________________________________ 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
