While I understand that you CAN change bands this many times, I would
suggest that it might not be most effective to do so, since you really
should be running on two bands at once in Multi-2. Granted that there are
times when rates cannot be sustained on two bands. Then, change to another
band, work everything there, then go to another band and so on.
I think that packet gives us a way to measure the value of bandchanging
without taking the time to "test the waters" as we used to have to in the
old days.
Practically speaking, let's say you're running on 15 and 10. Anything pops
up on either of those bands, you're covered - no band changes necessary.
How many other bands are open that are going to be worth stopping a run for
to go work a mult? Will this happen 8 times per hour? Doubt it. By late
in the contest, since you've been running on all bands at their prime-time
already, you've worked most everything that'll be calling CQ anyway. To
draw in the rare mults, you must call CQ - even late in the contest.
I would further suggest that if there are mults on another band showing up,
you should go there and work a bunch of them, and perhaps run some other
stations instead of a flip-flopping bandchange scenario showing up in your
log.
Can you flip-flop? Sure. Is it worth it? I don't think so, and would be
interested in an analysis of the effectiveness of it given the other aspects
of multi-2 operation. I'm not convinced - but I'm also not closed to
persuasion.
And, the logic behind the band-change limitation is to prevent a
more-than-two-operating-position-station from interweaving their QSOs and
operating essentially as a multi-multi station - which, there is a
classification for already. Many M2 stations run 3 or 4 operating
positions, or even more. It would be easy for them to man all of them and
time slice the log to appear that only two were on the air at one time.
This would be cheating.
If we could mandate that all multi-2 stations would only have 2 operating
positions, and only two people operating them, this would be an unnecessary
rule. However, that's not practical and cannot be monitored.
I would suggest that if you really want to do a lot of band flip-flopping,
do a single op with SO2R.
That'll keep you busy.
N5NJ
----- Original Message -----
From: "alsopb" <alsopb@gloryroad.net>
To: "Ct-User@Contesting.Com" <ct-user@contesting.com>
Sent: Wednesday, November 13, 2002 6:12 AM
Subject: Re: [ct-user] Tools for CQWW M2 category ?
> Bob,
>
> I disagree.
>
> 8 band changes/hour is really only four- one to a band and one back.
> It can easily be exceed by searching and pouncing spots across
> multiple bands. In fact, with an ACOM amp and/or any of today's
> transcievers (for those not in high power categories), bands are
> irrelevant. One goes where the contacts are.
>
> Late in the contest, band hopping is perhaps the only way to maintain
> a decent rate.
>
> It is a stupid limitation, in my opinion, which technology has made
> passe. The sponsors need to find something else to differentiate M2
> from MM. How about only two operators?
>
> 73 de Brian/K3KO
>
> Bob Naumann - N5NJ wrote:
> >
> > I'm not aware of any tools to do this - yet.
> >
> > The rule allows you 8 band changes per hour for each rig. I would think
> > that you'd really have to try hard to exceed that number.
> >
> > I reviewed the log manually for AA5NT's Multi-2 log. It took a little
while
> > to go through, but I found that we didn't even come close to exceeding
that
> > number.
> >
> > ----- Original Message -----
> > From: "David L Sharred" <G3NKC@thersgb.net>
> > To: "Ct-User@Contesting.Com" <ct-user@contesting.com>
> > Sent: Tuesday, November 12, 2002 4:48 PM
> > Subject: [ct-user] Tools for CQWW M2 category ?
> >
> > > BlankDid I hear that someone was going to develop a tool for CT, to
check
> > > teh band change times for Multi-2 ??
> > >
> > > Am in need of something now -about to submit logs
> > >
> > > 73
> > > Dave Sharred
> > > G3NKC (op from MD4K)
> > >
> > >
> > >
> > >
> > >
> > > --- StripMime Report -- processed MIME parts ---
> > > multipart/related
> > > multipart/alternative
> > > text/plain (text body -- kept)
> > > text/html
> > > application/octet-stream
> > > ---
> > > _______________________________________________
> > > CT-User mailing list
> > > CT-User@contesting.com
> > > CT-User-request@contesting.com Subject=unsubscribe to unsubscribe
> > > http://lists.contesting.com/mailman/listinfo/ct-user
> >
> > _______________________________________________
> > CT-User mailing list
> > CT-User@contesting.com
> > CT-User-request@contesting.com Subject=unsubscribe to unsubscribe
> > http://lists.contesting.com/mailman/listinfo/ct-user
> _______________________________________________
> CT-User mailing list
> CT-User@contesting.com
> CT-User-request@contesting.com Subject=unsubscribe to unsubscribe
> http://lists.contesting.com/mailman/listinfo/ct-user
|