One option would be to adopt a "mean spirited" approach like Winlink that
says busy frequency detectors are NOT needed.
However, MMTTY has FFT data available via its API (the data that drives the
waterfall display). I am not sure about 2-tone. By having access to the
FFT data, one could make a good decision if the frequency was busy. I have
some old code written 10 years ago somewhere that interfaces into MMTTY and
pulls in the FFT data using VB6. If done today, the language of choice
would be C#.
Terry AB5K
-----Original Message-----
From: RTTY [mailto:rtty-bounces@contesting.com] On Behalf Of Joe Subich,
W4TV via RTTY
Sent: Saturday, April 19, 2014 1:23 PM
To: rtty@contesting.com
Subject: Re: [RTTY] New proposal for a Automated Digital Contest
> One question, is it legal for a automated station to beacon, i.e.
> call CQ?
It's not a beacon (a one way transmission) if one is soliciting a contact.
However, to be fair and set a good example, MMTTY and 2-Tone would need to
be extended to provide a "channel busy" signal to hold off CQ transmissions
or automatically QSY prior to a CQ if the frequency was busy.
73,
... Joe, W4TV
On 4/19/2014 1:58 PM, Terry via RTTY wrote:
> Well my last proposal flopped big time but it spawned a very
> interesting thread on the history of RTTY RU and the amount of efforts
spent in
> processing contesting results. Thanks for all of the comments.
>
> So I am now thinking about proposing a new contest. The contest would
> be used to study propagation. The initial thoughts are somewhere along
the
> line of a RTTY sprint contest but do it in a fully automated way. Since
> its automated it should probably be done in the FCC sub-bands set aside
for
> automated digital stations. In order to do a proper study of
propagation
> we probably need to run the contest 24 x 7.
>
> Both client and server software would need to be developed to support
> the contest.
>
> The client software would:
>
> 1. Interface into MMTTY and 2-tone
>
> 2. Initiate a contact or accept a contact and exchange the contest
> format
>
> 3. Interact with a central server logging QSO's/Scores
>
> 4. Interact with a central server reporting the frequency the
station
> is listing on
>
> 5. Interact with the station radio to control the frequency
>
> The server software would:
>
> 1. Take care of logging QSO's and scores
>
> 2. Take care of sharing station operating frequencies
>
> 3. Provide a FTP site where raw QSO data could be downloaded for
folks
> interested in propagation studies
>
> 4. Provide a web site that automatically summarizes and displays
> contest results
>
> Most of the software is fairly straight forward. The hardest part would
be
> providing support for radios that are not available for testing.
>
> Since the end goal is to collect propagation data, stations would be
> encouraged to run SO2R and even SO3R covering several bands at once.
>
> The results of the contest would be automated and published on the web
site
> with weekly, monthly and yearly totals. Perhaps we could get a sponsor
for
> a few plaques for the yearly awards.
>
> One question, is it legal for a automated station to beacon, i.e. call CQ?
>
>
>
> Thoughts?
>
> Terry AB5K
>
>
>
>
>
>
>
> _______________________________________________
> RTTY mailing list
> RTTY@contesting.com
> http://lists.contesting.com/mailman/listinfo/rtty
>
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|