Ned- AA7A,
Thanks for your insightful response to my post. We agree that new chunks of
spectrum need to be identified and used on each band. On 20M that may mean
using a segment above 14.115 MHz. Also, the use of FT8 operation can only be
successful if calling stations spread out, but as you mentioned, not all
transceivers have super wide receive capabilities. But almost all DO have
mechanical SPLIT capability, which also could be used. Stations calling the DX
from +100 Hz to +2.2 KHz higher than his TX frequency do this software split
with a mouse click.
But.......... SPLIT can also be done with the caller using his transceiver's
mechanical SPLIT capability OR by using his transceiver's XIT feature. A DX
station transmitting on 14070.2 KHz could easily call "CQ14116 VK9MA" or
"UP14KHZ VK9MA" and listen up there. This would force users to do a mechanical
transceiver SPLIT. The DX would NOT respond to anyone in the 14.074-076 range.
Callers will eventually get the message that the DX is listening UP....really
UP :-). This info, of course, would be published in advance.
Longer CQ messages may require a software change, but there is a feature used
when doing MSK144 split operations. That is, check the box below the "T/R 15 s"
box and type in the 3 digit QSX frequency. This will embed the QSX frequency
into the CQ message.
As mentioned in one of my earlier posts, if the DX decides to stay withing the
14.074-076 segment to work stations, allowing the software to force his TX
frequency to QSY to the caller's TX frequency can have positive results with
less QRM being received by the calling station. This will be so because the
caller hopefully has selected his TX frequency to be on a clear spot on his
waterfall display. This should result in fewer repeats by the DX station to the
caller being worked.
Either way, staying withingthe present 20M FT8 segment or doing a big split,
the DX station, after making a number of contacts on one TX frequency may have
to move to another one to avoid DQRM.
More thoughts/discussion on the SPLIT topic?
73,
Rich - K1HTV
= = =
> On August 20, 2017 at 12:18 PM Ned <a...@cox.net> wrote:
>
>
> Rich,
>
> I would like to add some perspective of what might happen when what is
> called a "Top Ten" DXpedition (a DXCC entity that is in the Top Ten slots in
> published need lists...examples being Bouvet and Baker Island that will be
> QRV early next year) takes place on RTTY (or any digitial) mode. Having been
> the "RTTY guy" on both VP8STI and VP8SGI last year (both on the Top Ten at
> that time), the pileups are hard to describe. RTTY operation on these two
> DXpeditions was confined to 2 bands, basically, in order to prevent issues
> that arise in the use of Clublog Leaderboard. So the DXpedition leadership
> opted to limit RTTY to two bands (30 and 15 meters) in order to maximize the
> number of ATNOs (All Time New Ones) on the digital modes. As a result, the
> pileups were huge and stayed huge until we left both islands.
>
> When I called CQ the very first day on South Sandwich Island (VP8STI),
> the pileup was 30 KHz wide and hundreds deep. I have been in many RTTY
> contests and other DXpeditions (27 so far), but I had never experienced
> anything like this before. Using MTTY from within N1MM, the logging
> application for the DXPedition, it was virtually impossible at times to find
> complete calls in the pile. Over half of the time, I had to work QSOs in the
> same manner as one does on CW where I would type in a partial call and fix it
> when the station would send their report. There seemed to be few chances for
> me to use a mouse to pick a call out of an area on the computer screen. My
> hands were literally glued to the keyboard to make QSOs at a high rate. I
> manually spread the pile by trying to randomly pick calls across the breadth
> of the pile to prevent "tailending". I could never pick out one call in a
> tailend pile. So, while I was sending my QSL/QRZ message, I literally spun
> the dial of the receiver either up or down to a new frequency to work the
> next station. After doing this a while, everyone in the pile stopped trying
> to tail end and the rates settled into the best that could be done. FT8 is
> perfect for doing this, BTW.
>
> The only real tool in the hands of the DXpedition operator is to spread
> the pile until calls could be copied and making it easy for the DXpedition
> team operator to briskly sweep the spreadout pile to find calls. What Rich is
> suggesting below is spot on. FT8 operation at a Top Ten DXpedition might only
> be possible if the operator can make QSOs at a good rate, otherwise they will
> go back to RTTY. Rate is king. My fear is that the piles might get so deep
> that the decoders produce nothing and the rate goes to zero. Bad things
> happen when the rates go to zero on DXpeditions. Blistering emails and
> jamming are a few of the normal byproducts when confidence in the DXpedition
> team is lost. I am of the opinion that a Top Ten DXpedition will need more
> than one 2KHz slot to thin down piles at times...maybe all the time.
>
> Here are a couple of suggestions...I am a frequent user of FT8 and have
> been using JT65 on EME DXpeditions for years, so these are hopefully framed
> correctly...
>
> 1. Create a DXpedition mode in FT8 (similar to Contest Mode) where the
> appropriate information is used in an exchange. I don't think grid squares
> are needed. Signal reports are dubious in my mind. Some are saying that
> signal report info might be useful in analyzing propagation. My experience
> with FT8 so far is that the report has something to do with SNR in code
> space, but has nothing really to do with the strength of the signal in the
> radio. Propagation models might not really benefit from these reports, so I
> am of the opinion that their value is questionable.
>
> 2. Create DXpedition roles...either you are the Fox or one of the Hounds.
> The Fox sends his transmission in 1st slot, all Hounds in the second. Maybe
> other tailoring options set up when you select your role.
>
> 3. Create DXpedition "Channels". These are chunks of spectrum that fit in
> current radios. 2 KHz might be right. 4KHz works in my K3 but maybe not your
> TS-520. So, settle on one. It would be nice if everybody's radio were an SDR
> radio and we could define a wider channel, but that is years away.
>
> 4. Make it easy for either the Fox or any of the Hounds to select which
> channel to TX in or RX in. Maybe the Fox always stays in one channel and
> hounds spread out over one or more channels.
>
> I really think it best for Fox to be frequency agile within a channel. If
> not, the whole operation could be brought to its knees with a few jammers.
> Another concern that I hadn't thought much about until just now is pirates.
> It might be difficult to authenticate the station you work as being the real
> DXpedition group and not some bogus station. Maybe Hounds will listen on
> their headsets to use audible info to confirm that the signal "sounds" right
> like they currently do on RTTY...not sure.
>
> Thanks for reading this far.
>
> 73,
>
> Ned
>
> One of the ops on the upcoming KH1 Top Ten DXpedition
>
>
> On 8/20/2017 3:27 PM, Rich - K1HTV wrote:
>
> > >
> > Additional 20 M FT8 frequencies for DXpeditions & general DX use
> >
> > ------------------------------------------------------------------------------------------------
> >
> > The question has been posed as to the best frequencies for
> > DXpeditions while operating the FT8 mode.
> >
> > Lets focus on 20 Meters, which will probably be the most heavily
> > used DX band as we approach the bottom of the solar cycle.
> >
> >
> > From the IARU Region 1,2 & 3 Bandplan documents:
> >
> > IARU Region 1:
> >
> > 14 060 – 14 070 (200 Hz BW) CW,
> > 14 060 kHz – QRP Centre of Activity
> >
> > 14 070 – 14 089 (500 Hz BW) - Narrow band modes – digimodes
> >
> > 14 089 – 14 099 (500 Hz BW) -Narrow band modes - digimodes
> > automatically controlled data stations (unattended)
> >
> > 14 099 – 14 101 - IBP, exclusively for beacons
> >
> > 14 101 – 14 112 (2700 Hz BW) - All modes – digimodes, automatically
> > controlled data stations (unattended)
> >
> > 14 112 – 14 125 (2700 Hz BW) All modes
> >
> >
> > * * * * **
> >
> >
> > IARU Region 2:
> >
> > 14060-14090 (500Hz BW) - ALL MODES, DIGIMODES
> > 14100.5-14125 (2700Hz BW) - ALL MODES, FAST DIGIMODES, AUTOMATIC
> >
> >
> > IARU Region 3:
> >
> > Considering the dramatic increase in data mode usage on the 20
> > meter band, it is recommended that the sub-band for
> > these classes of signals be 14.070 MHz to 14.112 MHz (with +/- 500
> > Hz at 14.100 MHz for beacons), and within that
> > data sub-band the current practices of traditional data modes may
> > continue up to 14.095 MHz with 14.095 to 14.112 MHz
> > being reserved for other data modes including Packet.
> >
> >
> > - - - - - - -
> >
> >
> > In IARU Regions 1 & 2, both indicate ALL modes up to 14.125 MHz.
> > Only in Region 3 are the digital modes recommended
> > between 14.070 and 14.112 MHz.
> >
> >
> > For major DXpeditions in Regions 1 & 2 is there any reason why
> > frequencies above 14.112 MHz can't be used for the FT8 mode by
> > DXpeditions or for FT8 DXing in general? It has been less that 2
> > months since WSJT-X software with the FT8 mode has been made available to
> > the general Ham population. But already the frequency range between 14074.2
> > and 14076.4 KHz is very often packed with hundreds of stations
> > simultaniously using that small segment. And the congestion will only get
> > worse in the months to come, especially when DXpeditions start using the
> > new digital mode.
> >
> >
> > I would strongly suggest that serious consideration be given for
> > the use the FT8 mode on 20 Meter frequencies between
> > 14.112 and 14.125 MHz.
> >
> >
> > 73,
> > Rich - K1HTV
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > _______________________________________________
> > wsjt-devel mailing list
> > wsjt-devel@lists.sourceforge.net
> > mailto:wsjt-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wsjt-devel
> >
> > >
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
