Probably in future more 3KHz slots will be allocated, with the user
relying on spot reports to hone into signals desired.
It is the law of the jungle now, with experienced operators looking for
clear space to hold TX.
RX performance is paramount, and I find myself using separate tx/rx
antennas on upper HF, and helium balloons on
low bands to make my efforts viable.
vk4tux
On 28/8/21 3:05 pm, Phil Karn via wsjt-devel wrote:
On 8/27/21 16:20, Stan Gammons via wsjt-devel wrote:
Band planning is good idea. I've failed to understand why a given
segment of the bands were agreed on for JT65, JT9, FT4, FT8 and so
forth. Seems better to operate with any of those mode on any part of the
RTTY and data segments of the bands. Maybe the idea to use a given
frequency for each mode was because ops may not recognize what mode it
is based on the sound and how it looks in the waterfall? I'm not
condemning the decision on selecting a given frequency for a given JT
mode. Cycle 25 is picking up, but it's getting really crowded on many
of the FT8 frequencies. Personally; I'm looking forward to prop
improving and jumping into a huge SSB pileup for one of the most wanted
DXCC entities. Like Bouvet Island :)
I think the reason is already pretty clear: by grouping all FT8
signals (say) into a narrow band segment it becomes easy for the
receiver to decode everything within that segment, and this enables
the kind of thing I'm talking about.
If we all had full-blown wideband SDRs (rather than voice-band
transceivers adapted to the purpose) then it would be possible to
decode every FT8 (or whatever) signal in an entire amateur band, or
perhaps in several amateur bands, and band segment planning wouldn't
be as useful. You'll spend more CPU time searching a larger space for
these signals. But that becomes less important as time goes by, CPU
core counts increase and algorithms improve.
Phil
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
