Its a great idea, Paul. As you know, the CQWW committee is using SDRs
around the world to collect spectrum audio and use it in the case of
adjudication of log checking (http://cqww.com/blog/?p=67).
I also record the whole contest so that I have my own recording of
what I heard, and on it are many examples of very poor audio.
As a contester who works hard to have a clean signal, I sometimes
wonder if thats actually a disadvantage, because others can get closer
to me than someone with poor audio, and essentially push me away if
they are wide.
Its one thing to have a poor adjustment, be told about it, and fix it
during the contest, its yet another to be that way every time, despite
being told about it, and never fix the problem.
As you suggest, if enough people logged a station as having poor
audio, then it would be an objective way for the contest committee to
investigate and adjudicate those that choose to continue with poor
audio.
73 de N6GQ, YN2AA
On Mon, Nov 4, 2013 at 6:06 AM, Paul O'Kane <pokane@ei5di.com> wrote:
>
> The CQWW sponsors are leading the way in defining and,
> hopefully, clamping down on unsportsmanlike conduct.
>
> They say " "Examples of unsportsmanlike conduct include.....
> 5. Signals with excessive bandwidth (e.g., splatter, clicks)"
>
> Anyone who uses SDR-based panadaptors, including the Elecraft
> P3, can recognise and measure wide signals instantly - by just
> looking at them.
>
> It seems to me that if we had an agreed method of reporting
> excessive bandwidth, contest sponsors could confirm it for
> themselves by checking their SDR recordings - using times
> and frequencies from our Cabrillo logs.
>
> The question arises, how would each of us indicate wide
> signals from other stations we work - not to mention the
> ones we might prefer not to work.
>
> The ones we work are easy. My suggestion is to add /Q to
> the callsign logged. I'm using Q, because it cannot be
> confused with another country's callsign - no calls begin
> with Q. There may be implications for dupe-checking with
> some software, but nothing that can't be supported with a
> few extra lines of code.
>
> There are other options, but I would not consider varying
> the usual 59(9) reports because it would take longer.
>
> 73,
> Paul EI5DI
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> CQ-Contest mailing list
> CQ-Contest@contesting.com
> http://lists.contesting.com/mailman/listinfo/cq-contest
_______________________________________________
CQ-Contest mailing list
CQ-Contest@contesting.com
http://lists.contesting.com/mailman/listinfo/cq-contest
|