Bob,
It is interesting to speculate whether many changes/hour is effective
or not. But that is all it is, speculation. I agree with your
analysis that if only two bands are open (like next Spring when 10M
dies), two bands covers you. However, what does one do when
160/80/40/20/15 are all open? What about two signals/band? How does
on manage this and make the right choices. The proper choices are
what contesting is all about. One guy may make hay with 20 band
changes/hour while another ends up penalizing himself. SO2R
illustrates this point very well.
By the way, I don't think it is all about mults. Chasing "fresh meat"
via spots shouldn't be ignored.
Enforcement isn't really the issue. There are always plenty of ways
to cheat.
People who want to cheat will. It doesn't matter what the rules are.
I believe that rules which exist must be practical for the operators
to follow. Limitations and class distinctions should be clear cut,
make sense and be able to be easily followed.
It appears here that many are finding is no practical way to monitor
band changes/hour. This posting would not exist if there were easy,
implemented and practical. The last thing we need is manual clerical
work.
73 de Brian/K3KO
Bob Naumann - N5NJ wrote:
>
> 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
>
> _______________________________________________
> 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
|