Frode, I had to re-read your Norwegian ranslation of the maual after reading your mail, so that's the reason for replying late. In that manual, I cannot see that the need for enabling TX after every RR73 is mentioned at all. Please tell me if there is a point here that I have overlooked.
I tried FOX (WSJT-X, 2.1.0) on my last trip to Svalbard. I see you are emphasising the "rare DX"here, and JW is hardly rare, even though the pileups, and thus demand, can be really big if conditions are there. I have never seen a definitien of "really rare", so if you suggest above a specific rating on the most wanted list, I find it hard to follow you. IMHO, "rare" is decided by the demand, and not a list position. And I have a pileup when the right pane is completely red, and my own yellow TX line is scrolled up out of the window. So I took the chance, qsyed down from 7074 and started as FOX. I had the exact same experience as Rich describes. It was the same fun as running a pileup in any mode, I can tell you. Now, on an earlier trip to JW-land, in March 2019, I did the same, but with v 2.0.1 (I don't remember which RC#), and then I could "fill the queue", and TX did not stop as long as there were calls in the box. Wether this was intentional or not from the dev team I do not know, but operating as FOX, I thought it was great. I can assure you there was no unattended operation there! Since there is a limit to how "old" a call from a hound can be before it falls out of the que, you have to watch the queue constantly, keep in mind how many streams you want to operate - an important decision when the number of callers with weak signals are big - and keep the queue alive. By the way, I also think I had activated automatic logging (like in contest mode), but it is possible that my memory does not serve me right on that one. Back to v 2.1.0 in October 2019, I expected the same behaviour, and lost several TX cycles because I was unprepared for the necessity to arm the tx button for every RR73 I sent. With few repeats, and mostly operating 1 to 3 streamsI was able to maintain a qso rate of about 100/h. Without the lost TX cycles, it could have been - albeit slightly - higher. So again, I support Rich's view. The need to push TX for every RR73 is not nesessary. The 15 seconds you have from the end of one TX cycle to the next are not hard to fill with chores. 73 de Tom - from time to time JW6VDA Sendt fra min iPad Air 2 > 18. nov. 2019 kl. 12:48 skrev Frode Igland <[email protected]>: > > > 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
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
