Hello, OZ0J and OZ1RH has spent a week on American Samoa taking advantage of the FT8 Fox/Hound mode. We had not been on an expedition before and thus had never used DXpedition mode, but soon got the hang of F/H, reaching a 10 minutes high of 293 Q/hour measured in N1MM+. Here are some observations and proposals:
1. It seemed quite a few people did not know or understand how to use DXpedition (F/H) mode. Some kept calling under 1000 Hz and strong stations kept calling above 1000 Hz even after being answered by me the Fox. Suggestion: automatic switch from normal to Hound mode when calling a Fox - and switch back when calling a non Fox. This means the normal user does not have to worry about F/H setting, he only have to find the Fox on another frequency than the normal FT8 frequencies. For the Fox however it can be assumed he knows what he is doing. 2. In order to start my pile up I usually checked the conditions on the regular WSJT frequencies by making a few QSO's without being a Fox. When I get many callers I send a message 'QSYnn.nnn F/H' two times in each period to attract attention to my new QRG and F/H. This requires both a QSY and some clicks to shift in and out of F/H mode, so having a button on the working screen for a Fox to switch out or into Fox mode would be nice, as a Fox (hopefully) is struggling to keep the rate up. Though self spotting is not popular I sometimes also spotted myself on the cluster to get things going. Note that my suggestion 1 and 2 works together so the normal user has automatic switch from normal to Hound mode and back while a station wanting to be a Fox has to enable Fox mode in the Advanced setting. After that the Fox can jump in and out of Fox mode clicking on the red FOX button on the normal working screen. 3. When a Fox selects a call to work from the left white row that call is transferred to the queue at the right. However TX-ing to that station is delayed one TX-period. This happens even when that call ends up as being the only one in the queue and all slots are free as WSJT sends one more period with CQ. This happens even if I manage to double click on the call during the 2 seconds between RX and TX. To save one period I suggest: The Fox should have a 'Call first' button meaning: if there are free slots available start QSO'ing all the first callers immediately so all available slots are used immediately, no need to call CQ for one more period when the are callers (unless there are free slots after answering all callers and 'CQ more' is checked). I know that this 'Call first' for a Fox looks quite a lot like being a QSO-robot, but the Fox-operator still has the job of selecting the relevant number of slots depending of the conditions and has to prioritize the list of callers (strongest S/N, S/N<nn dB, call, grid, distance...). Keeping a good rate does not come by itself. This 'Call first' solution should be simple to implement as the normal FT8 mode has this feature. 4. The first call from a Hound should include the report he receives the Fox with, so the Fox can judge when and how he should answer the caller e.g. prioritizing and perhaps using only one slot when answering someone sending a weak report. 5. I have the impression that some Hounds called me blindly, that is without ever having heard me. Proposal number 4 above could be enhanced so the program refuses to call a Fox that has never been heard by the Hound. 6. I have got several complaints of having send RR73 to people who did not end up in log. This might be someone who want to get into the log afterward in order to get a QSL for a QSO never made, but it could also be a program error. I was running with decode Deep and 'Save all' so it might be possible to check for a program error. I think this it is not worthwhile to investigate unless other Fox'es has experienced the same. 7. I had a situation where Halt TX was blinking and did not work so I was stuck in in TX (Tune). I think this was after pressing Tune in Fox mode, inadvertently being on a normal FT8 QRG. Only way out of this deadlock was exiting and restarting WSJT-X. As the deadlock likely came after an operator error this is not an error of much concern. 8. I had several situations where the checked ''Enable TX' suddenly was unchecked. It could well have been the TX runaway prevention that had kicked in. I was watching the screen and judging from the yellow transmissions it looked like everything was running as it should and it took me some minutes to realize I was not TX-ing. I suggest that when the TX runaway prevention terminates TX the operator should be clearly alarmed by more than the 'Enable TX' not being red any more. 9. As mentioned in number 8 above the yellow window of transmissions does not give the operator the full overview of what is going on. The operators can see what he is sending in each slot, but that's it. There is better overview of the initial callers in the window to the left, where call, dB, age and frequency are displayed. When I transfer a call to my TX queue at the lower right only call and dB is shown, his Freq is missing. When I start TX-ing to a call I miss information on both his original Freq and dB. At this point I would still like to know his original Freq, as it would make me able to see if he is not mowing down in Freq - either because he has not heard my answer or more likely he is not in Hound mode. If I knew he dB I heard his first call with I could judge if a one slot transmission is needed to make the QSO. Also it seems all received transmissions from the hounds are not displayed, only the ones with Rnn are shown. Thus when the automatic QSO-progressing has started I as the operator has lost overview of what is going on. If things are progressing fast and without retransmissions I don't need this overview, but in the situations where the QSO rate is low and things are not running well an overview of what is going on would be helpful. 10. The best way of enhancing the overview of operator would be to display decoded calls, dB's and age on the waterfall. Calls just decoded could have one color, calls I call another color and calls answering me yet another color. Then I could instantly see the callers, if they answer me below 1.000 Hz and if they keeps sending a report either just dB or a Roger dB. 11. It would be easy for both the Fox and all the Hounds if the Fox could transmit on the normal FT8 frequencies. The Hounds then quickly sees an interesting call and start calling. Now having a giant pileup on the normal FT8 frequencies is not a good idea as those frequencies are already quite full. This could be remedied if my proposal 1. Automatic switch to Hound mode is implemented so all calls to the Fox are done in Hound mode.Then transmitting in Hound mode should have an frequency offset for first time callers determined by the Fox, id could be +2.000 Hz, +5.000 Hz or even negative -10.000 Hz which is added to the callers original Freq. Thus the pileup is moved away from the normal FT8 frequencies without the knowledge of the Hounds, who does not have to understand DXpedition mode at all. When the Fox initiates a QSO the frequency of the caller could be changed once more to a band where only QSO-partners are transmitting, just like now like now where hounds are moved below 1.000 Hz. Notice that there is no need to use an offset within the original audio bandpass as long as CAT is used and every modern radio has CAT. 12. DXpedition mode is all about getting as high a rate as possible. One obvious way of increasing the rate is to reduce the QSO time by shortening the periods. This was what happened when the transition from JT65 to FT8 was made. Why not do this again going to 5 sec periods? One serious disadvantage is that sensitivity decreases with shorter periods and we obviously want WSJT-X to be able to decode weak signals. Now for the many strong callers a 5 sec period could be enough to get in the log, but the weaker ones that really interests us needs a longer period. Notice WSPR decodes to -30 dB using 2 minutes periods. What is needed is a mode using 5 sec (or less?) for the strong ones and a longer or more period for increased sensitivity. JT65 has this feature as JT65 is able to integrate the received signal over several periods. If a similar integration over several 5 sec periods is done the strong ones can be worked in a few 5 sec periods and the weaker ones can be worked slowly using many periods. Integrating over 2 min = 24x5 sec periods might give around -30 dB sensitivity like WSPR. The QSO time could approach half an hour for the weakest ones which is not very practical, but if the alternative is no QSO it might be acceptable. In short my proposal is integrating over an adaptive number of periods and that number is just as large as needed for a more or less reliable QSO and with a maximum of periods of say 25. Perhaps the Fox should be able to set a lower number of periods depending of the traffic and conds. One slot could even be reserved for the weak and slow QSO's. As I flew back form Pago Pago (34+ hours in planes and airports) FT4 was announced and FT4 does indeed reduce the lengths of the periods to 6 sec loosing some sensitivity. At present it is not made public to what extend FT4 has F/H or uses adaptive number of periods when decoding. Our equipment on American Samoa was to stations each K3S and SPE 1.3K-FA linear and several verticals running CW, SSB and FT8. We ran 7-900 W output on FT8 in order to have some power in each slot as the signals often were weak due to the large distances involved and our less than optimal antennas. We worked many stations sending -18 to -20 dB and we received often more than 10 dB weaker reports than transmitted. We even brought our own WSTX TX with us so we and the rest of the world was able to judge conds, see results on http://wsprnet.org/olddb?mode=html&band=all&limit=50&findcall=kh8%2Foz1rh&findreporter=&sort=db&uniquereporters=on The WSPR TX was a RF-ZERO with 2 W PA and GPS for timing and frequency: http://www.rfzero.net/ 73, Palle, OZ1RH Info on KH8/OZ0J and KH8/OZ1RH info is on www.kh8.oz0j.dk
_______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
