Grant, I'd respectfully discourage any lower than about .065 for 20/15/10m.
.060 is the standard CW QRP activity frequency for each of those bands, and
.061 to .064 are the standard calling frequencies for CW SOTA activations
in most if not all IARU regions. The majority of the activity centers on
062. Many dedicated chasers monitor 062 throughout the day for mountaintop
portable QRP signals.

73,
Brian AF7MD

On Fri, Apr 26, 2019 at 4:19 AM Grant VK5GR <vk5gr.ra...@gmail.com> wrote:

> Joe et al,
>
> A word if I may about frequency choices. Some of those proposed for FT4
> probably leave a bit to be desired. Here are some thoughts to consider:
>
> 80m 3.595 - PROPOSE 3562kHz - 3595 is completely out of band for JA
> completely and into the phone part of the band outside of Region 2. My
> suggestion based on occupancy and proximity to existing digital sub-bands
> is
> something around 3562kHz (at least keeping away from 3560 which is
> sometimes
> a CW QRP frequency). While the IARU band plans currently have digital as
> 3570-3590kHz a case can be made for expanding that - and given other
> restrictions in some countries on 80m, expanding digital down at least 8kHz
> to 3562kHz makes some sense. A case to be made for the IARU - but you can
> "help" their decision by starting to use it anyway. BTW 3600kHz is the
> centre frequency for IARU R3 80m disaster comms - LSB - so FT4 on 3595 USB
> will badly clash with that - another reason not to use 3595.
>
> 40m 7.090 - PROPOSE 7052kHz (inside the digital sub-band) or 7062kHz (just
> above the digital sub-band noting it is heavily used for SSB at least in
> region 3) - 7090 only makes sense in the USA! Many other countries have
> this
> as SSB voice use. The IARU digital segment is (depending on region)
> 7040-7060 or 7040-7060. With 7056 already being used for FT8 F/H mode on a
> fairly regular basis it would make sense to use say 7050 or 7052kHz
> instead.
> Note that 7090 is the designated SSB QRP frequency. I would promote 7050
> for
> FT4. The only reason not to is that the RTTY guys if FT4 and RTTY are in
> the
> same contest might object - but during the contests the RTTY guys spread
> out
> and use anything from 7030 to 7120 anyway in complete disregard of the band
> plans. If they are going to be that unruly then putting FT4 down there
> doesn't seem all that bad.
>
> ********* 30m / 17m / 12m - should NOT have FT4 allocations at all. FT4 is
> a
> CONTESTING mode and CONTESTING is by global agreement excluded from those
> WRC79 bands!!! *********
>
> 20m 14.140 - PROPOSE 14062kHz - the original proposed use of 14140KHz again
> is well outside the digital segments where FT4 belongs. If anything,
> creeping down into 14060-14070 might be considered acceptable despite not
> being in the band plan if the aim was to separate RTTY and FT4 users in the
> same contest. Going high above 14.112 (the acknowledged edge of the global
> 20m digital band plan segment) will be frowned upon. Take a leaf from 80m
> and use 14062kHz - again at least that keeps it away from the CW QRP Centre
> of activity and meets the objective of separating it from RTTY.
>
> 15m 21.140 - PROPOSE 21062kHz - follow 20m and choose 21062kHz - although
> 21140kHz is the first proposed FT4 frequency that fell inside a digital
> subband...
>
> 10m 28.180 - POROPOSE 28062kHz - again follow 20m
>
> 6m 50.318 - PROPOSE somewhere below 50.313 not above. Moving above is just
> moving further into several countries beacon segments. Not likely to get a
> lot of airplay as a international contesting band for FT8 so not as
> critical
> - but my suggestion would be look below 50.313 not above.
>
> For discussion folks.....
>
> Regards,
> Grant VK5GR
> WIA Appointee to the IARU Region 3 Band Plan committee
>
>
>
>
> -----Original Message-----
> From: Joe Taylor [mailto:j...@princeton.edu]
> Sent: Tuesday, 23 April 2019 1:04 AM
> To: WSJT software development
> Subject: [wsjt-devel] The FT4 Protocol for Digital Contesting
>
> To:   WSJT-X users interested in testing FT4
> From: K1JT, K9AN, and G4WJS
>
> Soon after the "FT8 Roundup" held on December 1-2, 2018, we started
> serious work on a faster, more contest-friendly digital mode that can
> compete with RTTY-contesting QSO rates while preserving many of the
> benefits of FT8.  The result is FT4 -- a new digital mode specifically
> designed for radio contesting.
>
> Over the past month a small group of volunteers have been conducting
> on-the-air tests of FT4.  The early tests were very successful and
> helped us to make a number of important design decisions.  We believe
> FT4 has considerable promise for its intended purpose.
>
> We'll soon be ready for testing by a larger group.  If you might be
> interested in participating and offering your considered feedback,
> please read the descriptive document "The FT4 Protocol for Digital
> Contesting", posted here:
> http://physics.princeton.edu/pulsar/k1jt/FT4_Protocol.pdf
>
> We plan to post downloadable installation packages for WSJT-X 2.1.0-rc5
> on April 29, one week from today.  The document linked above includes
>
>   - Instructions for installing WSJT-X 2.1.0-rc5 and FT4 configuration
>
>   - Operating instructions for FT4
>
>   - Basic description of the FT4 protocol, modulation, and waveform
>
>   - Detailed sensitivity measurements for FT4 under a wide variety of
>     simulated propagation conditions
>
>   - Schedule for upcoming test sessions
>
> Please consider helping us to make FT4 a successful mode for digital
> contesting
>
> With best wishes and 73,
>
>         -- Joe (K1JT), Steve (K9AN), and Bill (G4WJS)
>
>
>
> _______________________________________________
> 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
>
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to