On 29/04/2019 16:05, Grant VK5GR wrote:
At the risk of incurring the wrath of the JT65 folks, your suggestion
in my mind has some merit. I would go as far to say an alternate
strategy is to take the old JT65 frequencies and use them for FT4, and
have the JT65 folks move to the JT9 channels – grouping both of the
weak signal modes together in one segment. WSJT can decode both
simultaneously and neither JT65 or JT9 has a lot of traffic these days
so maybe that is the ultimate for everyone – given that in days gone
by JT9 and JT65 used to share anyway to an extent).
You could apply that across the board – with the exception of Region 3
on 80m. I would agree with the compromise that Bill has suggested with
3568 in R3 and 3575 elsewhere (n fact make it 3576 and follow the
above suggested convention).
Bill – a different approach – do you think it has merit?
HI Grant and George,
I agree that it could work but it will compress all the 60 T/R modes
into a 2 kHz section. Although that is not unreasonable it does have the
issue that there is no decoder that can decode JS8CALL and JT9 and JT65.
The dual mode JT9+JT65 decoder in WSJT-X relies on JT9 signals being
separated above other signals and decoder performance is severely
degraded if that is not the case.
Anyway, for now we are going with my suggested changes since we have a
deadline rushing up towards us. We are only into a beta testing phase
and changes can still be made without too much disruption once we have a
better feel for how FT4 is going to be used.
In summary WSJT-X v2.1.0 RC5 will have the following FT4 suggested
frequencies (the Iter1 column):
Band Iter0 Iter1 Notes
-----------------------------------------
80 3595 3575 (plus 3568 Region 3)
40 7090 7047
30 10140 10140
20 14140 14080
17 18104 18104
15 21140 21140
12 24919 24919
10 28180 28180
6 50318 50318
2 144170 144170
73
Bill
G4WJS.
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
