RE: [digitalradio] Re: ROS back bigger and better !

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of John B. Stephensen
Sent: Sunday, August 29, 2010 4:29 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: ROS back bigger and better !



The ARRL response was that the final proposal retained the existing
automatic subands.

>>>My recollection is that a flurry of desperate activity preceded the
ARRL's retracting its proposal; if part of that flurry included a
modification that would have retained the automatic sub-bands, I don't
recall seeing it.

73,

Dave, AA6YQ


- Original Message -
>>>When that 1 percent deploys unattended stations that transmit without
first checking to see if the frequency is in use, they can create havoc far
out of proportion to their fraction of ham community.

Regulation by bandwidth and not by mode seems to be working everywhere that
it is allowed. under a bandwidth regulatory environment, there is no "phone
band."

>>>True, if ops generally have the courtesy to not QRM existing QSOs. Those
who rudely deploy unattended stations without competent busy frequency
detectors are what make "regulation by bandwith" unacceptable.

BTW, it wasn't "winlink" that wanted anything, it was the ARRL who wrote the
proposal. There were flaws in it, but it was headed in the proper direction.
it will return as we move toward a digital future.

>>>The ARRL withdrew its "regulation by bandwidth" proposal because it had
no effective response to the factual assertions that this proposal would
greatly expand the frequency range accessible to unattended stations without
providing any means of ensuring that such stations would not QRM existing
QSOs. When those who deploy unattended stations upgrade them to rarely QRM
existing QSOs (emergency conditions excepted), "regulation by bandwidth"
will become possible.

73,

Dave, AA6YQ

RE: [digitalradio] Re: ROS back bigger and better !

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of k4cjx
Sent: Sunday, August 29, 2010 2:12 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: ROS back bigger and better !




Amazing that one thinks that 1 percent can cause any type of difference,
anywhere, especially on the Phone bands.

>>>When that 1 percent deploys unattended stations that transmit without
first checking to see if the frequency is in use, they can create havoc far
out of proportion to their fraction of ham community.

Regulation by bandwidth and not by mode seems to be working everywhere that
it is allowed. under a bandwidth regulatory environment, there is no "phone
band."

>>>True, if ops generally have the courtesy to not QRM existing QSOs. Those
who rudely deploy unattended stations without competent busy frequency
detectors are what make "regulation by bandwith" unacceptable.

BTW, it wasn't "winlink" that wanted anything, it was the ARRL who wrote the
proposal. There were flaws in it, but it was headed in the proper direction.
it will return as we move toward a digital future.

>>>The ARRL withdrew its "regulation by bandwidth" proposal because it had
no effective response to the factual assertions that this proposal would
greatly expand the frequency range accessible to unattended stations without
providing any means of ensuring that such stations would not QRM existing
QSOs. When those who deploy unattended stations upgrade them to rarely QRM
existing QSOs (emergency conditions excepted), "regulation by bandwidth"
will become possible.

73,

 Dave, AA6YQ

RE: [digitalradio] TAPR/ARRL DCC conference.

[Dave AA6YQ]

I suggested this to Rick a few months ago; he thought it worthy of
consideration.

 73,

   Dave, AA6YQ

-Original Message-
From: Victor Poor [mailto:vp...@att.net]
Sent: Thursday, August 19, 2010 5:02 PM
To: 'Dave AA6YQ'; digitalradio@yahoogroups.com; win...@yahoogroups.com;
winlink_programs_gr...@yahoogroups.com; mars_winl...@yahoogroups.com
Cc: 'Steven Bible'
Subject: RE: [digitalradio] TAPR/ARRL DCC conference.


Dave.



We haven't used PMBOs in years. Perhaps you are thinking of RMS Pactor?
Using the WINMOR busy detector with Pactor seems unlikely but we can talk
about it at the conference if you are going to be there.



Vic, W5SMM



From: Dave AA6YQ [mailto:aa...@ambersoft.com]
Sent: Thursday, August 19, 2010 4:48 PM
To: digitalradio@yahoogroups.com; win...@yahoogroups.com;
winlink_programs_gr...@yahoogroups.com; mars_winl...@yahoogroups.com
Cc: 'Steven Bible'; 'Victor Poor'
Subject: RE: [digitalradio] TAPR/ARRL DCC conference.



Will there be a session on retrofitting WINMOR's excellent busy frequency
detector into Winlink PMBOs?



73,



  Dave, AA6YQ



-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Rick Muething
Sent: Thursday, August 19, 2010 10:06 AM
To: win...@yahoogroups.com; winlink_programs_gr...@yahoogroups.com;
mars_winl...@yahoogroups.com; digitalradio@yahoogroups.com
Cc: 'Steven Bible'; 'Victor Poor'
Subject: [digitalradio] TAPR/ARRL DCC conference.



All,

Just a reminder to those interested in digital radio and WINMOR.  Vic Poor,
W5SMM and I will be giving papers on RMS Express and WINMOR at this year's
TAPR/ARRL DCC conference http://www.tapr.org/dcc.html  Sept 24-26 in
Portland, OR.  I will also be giving a 4 hour short course tutorial Sunday
morning on DSP which includes a CD handout (PowerPoint and .pdf), sample DSP
software and evaluation DSP tools.  I believe TAPR/ARRL also plan to make
the CD available after the conference.

I look forward to meeting any of you that are attending and put a face to
the emails we've exchanged!  Vic and I plan to have some demo's set up for
RMS Express, WINMOR and a new keyboard QSO protocol V4.  I have attended
many of the DCC conferences and always found them interesting and a great
source of information, inspiration and ideas.

73,

Rick Muething, KN6KB

RE: [digitalradio] TAPR/ARRL DCC conference.

[Dave AA6YQ]

Will there be a session on retrofitting WINMOR's excellent busy frequency
detector into Winlink PMBOs?

73,

  Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Rick Muething
Sent: Thursday, August 19, 2010 10:06 AM
To: win...@yahoogroups.com; winlink_programs_gr...@yahoogroups.com;
mars_winl...@yahoogroups.com; digitalradio@yahoogroups.com
Cc: 'Steven Bible'; 'Victor Poor'
Subject: [digitalradio] TAPR/ARRL DCC conference.




All,



Just a reminder to those interested in digital radio and WINMOR.  Vic Poor,
W5SMM and I will be giving papers on RMS Express and WINMOR at this year's
TAPR/ARRL DCC conference http://www.tapr.org/dcc.html  Sept 24-26 in
Portland, OR.  I will also be giving a 4 hour short course tutorial Sunday
morning on DSP which includes a CD handout (PowerPoint and .pdf), sample DSP
software and evaluation DSP tools.  I believe TAPR/ARRL also plan to make
the CD available after the conference.



I look forward to meeting any of you that are attending and put a face to
the emails we've exchanged!  Vic and I plan to have some demo's set up for
RMS Express, WINMOR and a new keyboard QSO protocol V4.  I have attended
many of the DCC conferences and always found them interesting and a great
source of information, inspiration and ideas.



73,



Rick Muething, KN6KB

RE: [digitalradio] sound card manager software

[Dave AA6YQ]

>>>AA6YQ comments below
-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Hal
Sent: Tuesday, August 10, 2010 9:10 PM
To: DigitalRadio
Subject: [digitalradio] sound card manager software



To The Group:

The "sound card manager software" is about all I can think to call this
program. It would allow you to set up different settings for each program
you use with your soundcard and not have to constantly change mixer
settings.

For an example, you run Echolink,click this "program" and the Echolink
settings come up.  You run MultiPsk and those preset settings were saved and
named and  your ready to run the MultiPsk program. Ect etc.

I have a new AMD/Dual Core  Desktop machine running XP Pro. 3GB ram,1GB
Radeon Card, 2.7 speed, 500 GB HD,multi-monitor set up.

I run DxLab suite,N1MM/Mtty,MultiPsk,Echolink and work SSB on morning chats.
I have a AFSK interface for my digital modes and logging.

Why, you ask? Because several weeks ago on 40 meter chat the group said you
have a Bad Feed back in the audio.  I was at a loss. I had been running two
NetVista desktops. One for digital programs, the other for SSB and Echolink.
It was no problem because they ran independent of one another.  Now I have a
Workhorse AMD Machine and it won't function the way I want it to. I learned
that by disconnecting the speaker line from the new AMD machine, no feedback
into SSB chats.I could mute the line-out, no feedback. Now I go into to set
up the Multipsk and I have to reset the soundcard settings.  If  I want to
play music on the New machine the same thing occurs. That is the problem.

It may have been on one of the other digital groups , but I can't find the
source for this.  A Ham suggested this and another program or two to a
digital group ( I am on most of them). I had it saved but took a hit on the
Laptop/Vista machine and had to rebuild it from scratch and cannot find the
replies(late last year)  that were sent. Nor can I find it by researching
the groups. I know, from watching this reflector that many of you run the
same programs I run. So I thought I would start here. A Ham will know what I
need and why I need it to function in a certain way.  I hope you can help.

Any help or suggested programs would be appreciated.  Thanks, 73

>>>Try QuickMix:

<http://www.ptpart.co.uk/quickmix/>

73,

   Dave, AA6YQ

RE: [digitalradio] Re: Direct RTTY Generation

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of IMR
Sent: Thursday, August 05, 2010 6:04 AM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Direct RTTY Generation




>In your MMTTY folder (the one that contains the file mmtty.exe),
>is the file extfsk.dll present?
>
>
No.
n fact that file is nowhere to be found on the machine at all :-(

>>>The standard MMTTY installation package includes EXTFSK.dll


So guess I need to go back to your download page and find it.

>>>I sent you a copy via email.


Its all getting too complicated - the design was a request for a simple Tx
for beginners that wasn't yet another CW QRP transmitter - and I was hoping
RTTY would be as dead-simple to get going as it used to be back in the days
of yore. Clearly not.

It might even be easier to wrirte my own simple RTTY Tx terminal in VB6.
Waggling the TXD line using the "MSComm1.Break = True/False" function will
do the job if timing can be assured.

>>>Travelling to Alpha Centauri will be easy if the Warp Drive can be
assured.

73,

Dave, AA6YQ

RE: [digitalradio] Re: Direct RTTY Generation

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of IMR
Sent: Wednesday, August 04, 2010 9:09 AM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Direct RTTY Generation



OK Tnx...

found the COM port output facility and got it working on a Desktop with a
proper COM1. But when I tried a USB COM port - as suspected it wouldn't work
directly. On trying the EXTFSK option, it just comes back with a message
that says "Can't Configure EXTFSK"
Downloaded the latest MMTTY version 1.66G, just to make sure.

>>>In your MMTTY folder (the one that contains the file mmtty.exe), is the
file extfsk.dll present?


What I'm not sure about, if EXTFSK is set as the data output option, how
does the software know which USB Comport is to be used for its output of the
data - if that makes sense :-)

>>>When you configure MMTTY to use EXTFSK for FSK output, an EXTFSK window
appears that lets you select the serial port, as well as the serial port pin
(TxD, RTS, DTR) that will be used to generate the FSK signal.

   73,

   Dave, AA6YQ

RE: [digitalradio] Direct RTTY Generation

[Dave AA6YQ]

>>>AA6YQ comments below.

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of AC TALBOT
Sent: Tuesday, August 03, 2010 5:46 AM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Direct RTTY Generation



A  back-to-basics question for once...

Is there any modern RTTY datacomms software that gives a single wire digital
output for driving an FSK transmitter?   Looked in the MultiPSK and MMTTY
setup menus and nothing.

>>>MMTTY provides this "FSK signal" via the TxD pin of the serial port
specified in the "PTT & FSK" panel on the "Setup MMTTY" window's "TX" tab.
Since using this signal requires a serial port capable of 45 baud operation,
which some USB-to-serial-port-adaptors can't do, you can set the "PTT & FSK"
panel's port selector to EXTFSK, which displays a window that lets you
configure the generation of an FSK signal on a serial port's RTS or DTR
pins. In this latter configuration, the timing of the FSK signal is
software-generated, and thus less accurate than that generated by a 45 baud
serial port.

>>>Digital mode applications that use MMTTY as their "RTTY Engine" --
WinWarbler, HamScope, etc. -- thus offer this capability.


While I realise there may be little call for such a one-wire drive now

>>>Not true! Modern transceivers provide RX filtering for RTTY that is only
availalble when the transceiver is operated in RTTY mode, thus requiring the
"FSK signal" when transmitting. Icom's ic-7200, ic-7600, ic-7700, and
ic-7800 all provide a very nice twin-peak filter that is only available in
RTTY mode.

73,

 Dave, AA6YQ

RE: AW: AW: AW: [digitalradio] ROS v 4.8.X not spamming cluster

[Dave AA6YQ]

Thanks, Laurie.

 73,

   Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on 
Behalf Of Laurie, VK3AMA
Sent: Sunday, July 25, 2010 3:08 AM
To: digitalradio@yahoogroups.com
Subject: Re: AW: AW: AW: [digitalradio] ROS v 4.8.X not spamming cluster


  
Yes Dave,

Apart from my test PC virus/malware protection, whenever there is a 
change in an executable or dll I run them through an online scanner 
(20MB file limit) here  http://virusscan.jotti.org/en/

It runs the submitted file through 19 different scanners, with the 
occasional false-positive on one or two. Results of the scans are shared 
with the anti-virus companies.

The site generates a permalink for each file that allows you to 
distribute the scanning results to whomever.

Just ran the 3 executables through the site

Cluster.exe

http://virusscan.jotti.org/en/scanresult/7142b3c4c3e3076d5f55aa826a272678a67d1cbb

PSKReporter.exe

http://virusscan.jotti.org/en/scanresult/b8e275b738f1634bcc24fa081b1a83eb27e1289c

ROS v4.8.4 Beta.exe

http://virusscan.jotti.org/en/scanresult/e6e6238fb976a46d4db4dae564d59c5f2757ab73

de Laurie, VK3AMA

On 25/07/2010 1:29 PM, Dave AA6YQ wrote:
> 
>
> Has anyone checked to see whether the ROS code contains a keylogger,
> trojans, or a rootkit?
> 73,
> Dave, AA6YQ
>

RE: AW: AW: AW: [digitalradio] ROS v 4.8.X not spamming cluster

[Dave AA6YQ]

Has anyone checked to see whether the ROS code contains a keylogger, trojans, 
or a rootkit?

 73,

  Dave, AA6YQ

   
-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on 
Behalf Of KH6TY
Sent: Saturday, July 24, 2010 7:37 PM
To: digitalradio@yahoogroups.com
Subject: Re: AW: AW: AW: [digitalradio] ROS v 4.8.X not spamming cluster


  
> >Jose uses Cluster Auto-Spots to advertise his software. The more spots,
> >the more it appears to be a popular mode to the uninformed Cluster User.

To me, this attempted deception has been obvious ever since the issue of 
any auto-spots came up.

Isn't there any honesty at all possible with this author! :-(

This wholesale abuse of ham radio traditions and spamming clusters, etc. 
by this author, is just not acceptable, and to my knowledge has never 
been done before.

73, Skip KH6TY

QRE: AW: AW: [digitalradio] Operating ROS In USA

[Dave AA6YQ]

The ARRL withdrew its "regulation by bandwidth instead of mode" proposal
before the FCC responded. This proposal generated a lot of commentary from
the US amateur community, all of which remains available online. If you
review these, you will find that most comments opposing the proposal cited
the QRM caused by unattended digital stations, whose permitted range would
have been dramatically increased had the proposal been adopted.

Opposition to this proposal was "anti-QRM", not "anti-wide". An unattended
station running a narrow mode without an effective busy frequency detector
is as offensive as an unattended station running a wide mode without an
effective busy frequency detector; neither belongs on the amateur bands.

73,

  Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of "John Becker, WOJAB"
Sent: Tuesday, July 20, 2010 2:10 PM
To: digitalradio@yahoogroups.com
Subject: Re: AW: AW: [digitalradio] Operating ROS In USA



At 12:19 PM 7/20/2010, you wrote:
>Do you know if any US amateurs are raising a Petition for Rulemaking to
move to regulation by bandwidth instead of mode ?

Trevor,
We in the USA have been down this path before.
And every time the FCC has said the same thing.

I really don't know just where you are trying to go
but it seems that it is again an "anti wide" rant.

If it is you can save the rest of us from it.

John, W0JAB

RE: [digitalradio] Re: ROS back bigger and better !

[Dave AA6YQ]

Enough of this juvenile garbage.

Amateur radio in the US is governed by regulations to which we agree to
abide when we are granted a license. These regulations are particularly
important in amateur radio because we all share one set of frequencies.
These regulations are not perfect; in particular, the regulation
constraining Spread Spectrum usage is insufficiently precise, and as a
result precludes the use of techniques on HF that the FCC would likely
approve given a competent exposition. In this situation, an amateur radio
operator interested in using these techniques on HF should hold off until
the regulation has been changed to permit their use, contributing to or
leading the effort to change the regulation if capable.

There is absolutely nothing wrong with asking the FCC for their view of
whether a particular mode or technique is legal under the current
regulations. The knowledge that many amateurs are confused about what
constitutes Spread Spectrum should if anything make the FCC more receptive
to a proposal to clarify the regulation. The claim that asking the FCC a
question can kill amateur radio is amazingly ridiculous; asking the FCC a
question is more likely to teleport the Loch Ness Monster into your swimming
pool than kill amateur radio.

Unlike broadcast television stations, amateur radio operators don't
individually negotiate their licenses with the FCC. Thus the comments below
regarding regulations being trumped by station permits negotiated by
attorneys is completely irrelevant.

The nasty name-calling that appears below and in previous posts today is
flat-out unacceptable. Were I moderator of this group, the offending parties
would be long gone.

 73,

  Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of W2XJ
Sent: Monday, July 19, 2010 10:10 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: ROS back bigger and better !




Skip if you call this a regulation, I agree with Garret. It is a misguided
one and a victim  of unintended consequences. The whole discussion is stupid
and you, Skip, are too anal retentive. I work in broadcast and there are
many un-updated FCC regulations that the commission subsequently licenses in
a manner contrary to their own rules. Look at the FCC definition of
translator and then tell me how under the letter of the law how AM and HD-2
and HD-3 stations can legally use that service. Regardless stations get
legal  permits every day.  Washington is a town of double and denial speak,
the rules mean next to nothing in many cases. What your communications
attorney can wring out of them is all that counts. It is whiners like you
that damage the system.  Ham radio is supposed to be self regulating which
means please do not disturb the FCC. I guess you still do  not get it.
People like you will kill this hobby.



On 7/19/10 8:56 PM, "KH6TY"  wrote:








  > Just use common sense..
  Garrett / AA0OI


  "Common sense" says follow the regulations, because they were made for the
benefit of everyone, and not just for what a few who would like to do what
they wish without regard for others that want to use the bands.

  Regulations are not "guide lines" - they are LAW for the benefit of all.
Band plans are "guide lines", not regulations.

  What may seen nit picking to you may seem necessary to others. The
regulations are a great balancing act to both protect and enable as many
users to be treated as fairly as possible.

  73, Skip KH6TY

  On 7/19/2010 8:42 PM, AA0OI wrote:




The rules and regulations are a "guide line" they were never meant to be
written on 2 stone tablets and prayed to on the seventh day..  if everyone
followed every little nit picking rule and regulation the world would come
to a stand still..

(the government told Wilbur and Orville that they were "forbidden" to
fly)

I'm sure everyone drives the speed limit too..

Just use common sense..


Garrett / AA0OI










From: "John Becker, WØJAB" 
 To: digitalradio@yahoogroups.com
 Sent: Mon, July 19, 2010 6:03:07 PM
 Subject: Re: [digitalradio] Re: ROS back bigger and better !




The hell with the rules and law, right Garrett?

John, W0JAB

At 05:48 PM 7/19/2010, you wrote:

>What is absurd is that its a fight in the first place.. do you ever
just back up and look at what is being said?? Your all acting like this is
life or death..ITS NOT..I have been using it all along... NO FCC at my
door,, NO FBI,, NO KGB.. You are all fighting for something that no one
cares about.. Cross all the T's and Dot all the I's--- but the key is NO ONE
is looking to see if its been done..
>And ANYONE who puts "Our Freedom" and "Absurd" in the same sentence
needs to move to Iraq.. see if they agree with you !
>
>Garrett / AA0OI12c1104.jpg

RE: [digitalradio] RE-NEW LICENSE

[Dave AA6YQ]

I just renewed my license via ULS, as described below. I had an FRN, but no
password, so I requested a password on Monday 7/12 and received one
immediately via email. After logging in, I applied for renewal, which took
less than a minute. Yesterday morning, I logged in to check the status of my
renewal, and found that it had been issued on 7/13; a hardcopy arrived by
postal mail yesterday afternoon.

I don't see how this process could be any simpler...

  73,

Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of J. Moen
Sent: Saturday, July 17, 2010 1:30 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] RE-NEW LICENSE



John,

There is an FCC Registration Number (FRN) associated with your call.  You
need the FRN and a password to logon to FCC's Universal Licensing System
(ULS).

Go to http://wireless2.fcc.gov/UlsApp/UlsSearch/searchLicense.jsp and search
for your callsign.  It's there, of course, and so is your FRN.  Write that
down.  Before you go any farther, you should know the FCC database says your
call expires 7/31/2011.  So you have a year to do this, and as I recall, you
cannot renew until there are 90 days to go.

When you do the renewal process next year , you'll need your password.  If
you've done this before in the past, it may be burried in your files.

However, it is more likely that when you got your license, the VE did all
the FCC paperwork for you, and you were automatically assigned an FRN but
you never set up a password.  So you will need to set one up.  Go to
https://wireless2.fcc.gov/UlsEntry/licManager/login.jsp - enter your FRN and
click on Forgot your password?  "Contact Tech Support".   First you'll need
to "Set Personal Security Question".

I'd recommend you get all that set up now, including a password, then save
the FRN and password in your files so it will be easy to log on and renew
when it is time.

There's a simpler alternative.  The major VECs like ARRL and W5YI Group
offer renewal services for a small fee.

ARRL's is described at http://www.arrl.org/call-sign-renewals-or-changes

The W5YI Group's process is at http://www.w5yi.org/page.php?id=87

You've got plenty of time, the way I read the FCC database.

   Jim - K6JM


- Original Message -
From: Chris Robinson
To: digitalradio@yahoogroups.com
Sent: Saturday, July 17, 2010 9:28 AM
Subject: Re: [digitalradio] RE-NEW LICENSE
I use the free method of the
FCC.http://wireless.fcc.gov/uls/index.htm?job=home



On Sat, Jul 17, 2010 at 11:18 AM, "John Becker, WØJAB" 
wrote:


What does one have to do to re-new their ticket on-line
now? Been so lone I forgot







http://www.obriensweb.com/digispotter.html
Chat, Skeds, and "Spots" all in one (resize to suit)

Facebook= http://www.facebook.com/pages/digitalradio/123270301037522

Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/digitalradio/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/digitalradio/join
(Yahoo! ID required)

<*> To change settings via email:
digitalradio-dig...@yahoogroups.com 
digitalradio-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
digitalradio-unsubscr...@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

RE: [digitalradio] Re: [digital radio] Re: Random data vs Spread Spectrum

[Dave AA6YQ]

When a regulation is based on a vague phrase like "using bandwidth-expansion
modulation emissions", the FCC should *expect* to hear from amateurs trying
to determine whether or not a mode is legal. There are certainly many
situations where amateurs can indeed be expected to "sort it out
themselves"; this isn't one of them.

73,

 Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of W2XJ
Sent: Tuesday, July 13, 2010 4:35 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: [digital radio] Re: Random data vs Spread
Spectrum



The creator of ROS does not present himself as a very nice or honest person
but I also believe there are cultural and language issues that add to the
problem. Before all this started several months ago, I did not believe the
initial presentation that it was really spread spectrum but rather something
written by someone with a bad grasp of  the English language.

That being said, Skip, you are also misrepresenting the situation by stating
the FCC made an analysis. Read the documentation and it is clear they made a
fairly non committal statement based on the published material.  The FCC
does not like being involved in such matters. This is like the Dstar
controversy a few years back when an FCC official publicly told hams at
Dayton that if they were qualified to hold a license they should be able to
sort it out themselves. The commission will not do the thinking that hams
themselves should be doing for them selves. Please keep the sandbox fights
away from the FCC it will ultimately destroy the hobby. With the hunt for
more spectrum to sell be careful or there may not be any frequencies above
222 MHZ to even worry about spread spectrum.


On 7/13/10 3:23 PM, "KH6TY"  wrote:








  Rein,

  I said I would not comment further on ROS, but look at it in perspective.
The author defined ROS as spread spectrum and produced a two page document
to that effect. He is the only one who knows for sure if it is spread
spectrum or not.

  When it was posted that spread spectrum was not legal below 222 Mhz, he
conveniently (for his benefit) tried to redefine ROS as FSK, in an apparent
attempt to change the FCC opinion, which originally was based on his own
two-page declaration, which he wanted us to believe.

  The FCC then made their own analysis and concluded it was not FSK but
truly spread spectrum. This was communicated to us by the ARRL as is usually
the case.

  The author, if he would have disclosed his code, could have  proven
whether or not  the  randomization is for spread spectrum purposes or for
some other reason, but he steadfastly refused to disclose the code, which
would either have resulted in it being OK for us to use, or prove it was
truly FHSS. Perhaps he decided to try and bluff the FCC because it would be
determined, on the basis of his code, to really be FHSS, in agreement with
his first description, and in disagreement with the second description he
wrote, obviously just to try to get approval.

  It is just not reasonable to think that a person of his ability, as the
author of the software, could make such a huge mistake in his first
characterization of
  ROS as spread spectrum and then completely revise the characterization as
something else which he knew would be usable by US hams.

  You can imagine how the FCC feels about that attempted deception, and to
top it off, he posts a phoney statement of FCC approval besides! I seriously
doubt that the FCC is going to want to revisit the question, since the
author simply cannot be believed. I met Dan Henderson at a hamfest right
after all this happened and he had been in contact the FCC, and opined that
it was highly doubtful that any further reconsideration would be done.

  The ONLY way for us to ever use ROS on HF is to petition the FCC to amend
the rules to allow limited spread spectrum below 222 Mhz, citing enough good
reasons why it will not harm existing operations of lesser bandwidth.

  Instead of constantly arguing that the FCC made a mistake, or we should
interpret the rules as we wish they were, I suggest that either a petition
be filed, or the code released to prove the author's contention that it is
not spread spectrum. Of course the submitted code would have to be
recompiled and tested to prove it is really the original code, and another
attempted deception by the author.

  Understand that I am NOT "against" ROS, and never have been, even though I
strongly dislike the author's behavior and suspect his motives. I would keep
using it on HF if it were legal for me to do so. I do respect the FCC
regulations, even those that I do not like, and follow them as best I can,
because in the overall picture, they protect the weak from the strong for
the benefit of everyone, until revised in a non-harmful way.

  This will be my (final) final word on this subject, so please do n

RE: [digitalradio] Re: Random data vs Spread Spectrum

[Dave AA6YQ]

The definition of Spread Spectrum in 97.3(c)8 rests on the phrase "using
bandwidth-expansion modulation emissions". This clearly lacks the technical
precision required

- for digital mode developers to know what techniques can and can not be
incorporated in modes used by US stations (e.g. pseudo-random coding, as
Alan points out below)

- for US digital mode users to determine if and on what frequencies an
accurately-documented mode can be used

A constructive response to the Ros debacle would be to propose improved
language for 97.3(c)8 that is clear and unambiguous. Assuming the proposed
definition does not increase the likelihood of causing harmful interference
or permit encrypted communications (concerns implicit in 97.311), the FCC
would likely welcome a change that improves our ability to abide by the
regulations without consuming their scarce resources.

73,

Dave, AA6YQ



-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Alan Barrow
Sent: Tuesday, July 13, 2010 1:22 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: Random data vs Spread Spectrum



graham787 wrote:
> So, if bits are added to the transmit waveform that are not performing a
function of helping to re-create an error free replication of the input
data, it meets my test as spread spectrum. If the symbols in the transmit
waveform cannot be predicted by the previous sequence of bits over time at
the input, it also would meet my test as spread spectrum. To reiterate on
this point, just because the symbols of the transmit waveform are changing
during an unchanging input, does not imply spread spectrum.
>
> Instead, they may well be the result of a defined randomizer process
followed by multiple layers of FEC and modulation coding.
>

While I do not support ROS in any form, I think the group is on a very
slippery slope here with well intentioned but misinformed definitions &
tests that may haunt us in the future!

Just the fact that data is randomized does not define SS. There has to
be a spreading factor, which has some rough definitions based on
practical applications, but is not addressed in any FCC definitions.

Skip's well intentioned but overly simplistic test of looking at the bit
stream is not enough to define SS. There are many legitimate reasons to
code data resulting in a pseudo-random fashion that have nothing to do
with SS!

The most common is coding so the transitions between bit's can easily be
detected even in noise. It's a problem when sequential bits look the same.

You can also factor in FEC. There are many, many writeups on
convolutional encoding that go into this. (Viterbi & reed-solomon are in
wide usage)

But it's also useful to spread the energy out in the bandwidth and avoid
sidebands created by single tones of long duration. There are multiple
modem/modes which do this, some in very wide usage.

So yes, SS (really DSSS) is pseudo-random. But not all pseudo-random
coding is SS, and we should not be proposing that as a litmus test!

The real test should be:
- direct or BPSK modulation via a pseudo-random code in addition to any
coding for FEC (convolutional, etc)
- A spreading factor significantly higher than the original data rate

The 2nd item is the key part, and it's listed but virtually never quoted
in this group, but is listed in nearly all the SS definitions. Nor is it
addressed in the FCC part 97 rules.

It's not enough that the bandwidth is higher than the data rate would
imply, as nearly all modes with FEC would fail that by definition.

The key is the "significantly wider" aspect, also referred to in
ITU/IEEE definitions as "typically orders of magnitude greater than the
data rate". And this is why many engineers question whether any SSB
generated mode could be "real" SS. ROS only did it by having the
original data rate lower than the SSB bandwidth.

About the lowest commercial DSSS implementations use a spreading factor
of 16:1, and that's for consumer grade without noise performance concerns.

Most DSSS implementations in the real world use spreading factors of 100
or greater, as that's when you start seeing significant noise recovery
improvements.

In DSSS, the "processor gain" which improves noise resilience is
directly related to the spreading factor.

I've posted multiple definitions from the ITU & IEEE in the past for
DSSS. Wikipedia, which has some good information, does not constitute a
formal definition like the ITU & IEEE references do. (Part of the reason
that wikipedia is not admissible as sources for college & research papers).

There is no shortage of formal definitions, we should not have to invent
our own. There are also some very readable definitions from mfg's for
their DSSS components. Like this one:
< http://www.maxim-ic.com/app-notes/index.mvp/id/1890 >

So

RE: [digitalradio] ROS are sending data from your PC

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on 
Behalf Of rein...@ix.netcom.com
Sent: Friday, July 09, 2010 4:31 PM
To: digitalradio@yahoogroups.com
Subject: RE: [digitalradio] ROS are sending data from your PC


  
Hi Dave,

Let me ask your a question after assuring that the use of ROS world
wide is increasing rapidly.

We can ignore that, as most do, we can be mad about it, we can as US
licensed radio amateurs say it does not concern us,it is not fair, etc etc.

If there is such a list, I plan to make a real big stink about it. I am 
disappointed that John as a potential member on the list, does not want 
to research that. But then I can't force people.

Have plenty idea;'s about doing that. But before starting such an action
I like to know whether such a list still exists or not. 

Is that unreal? 

>>>I don't know what you mean by "unreal", but it's certainly a waste of time 
>>>as far as you, W0JAB, or I am concerned. US operators can't use ROS on HF 
>>>whether they're on the list or not. 

I tried to contact the ARRL just a few minutes ago and was
given a go around, from one phone number to another, 20 minutes waiting.
Friday afternoon in CT, with the Executive Chief Officer out of the country?

>>>Given that it represents the interests of US operators, you'll have a 
>>>difficult time convincing the ARRL to do anything about a mode that US 
>>>operators can't use on HF anyway. The IARU would be the more appropriate 
>>>organization with which to raise this issue.
 
Do not want to start here a flame war on the ARRL. But is this not the place
to discuss issues related to digital modes? 

>>>Yes it is.

A digital mode with a list of banned calls?

>>>Certainly, though of course Andy K3UK has the last word on this.

 73,

Dave, AA6YQ

RE: [digitalradio] ROS are sending data from your PC

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of "John Becker, WOJAB"
Sent: Friday, July 09, 2010 3:01 PM
To: digitalradio@yahoogroups.com
Subject: RE: [digitalradio] ROS are sending data from your PC


And many are still looking for an answer of why some (at one point or
another) was banned from using the program.

>>>John, no one but Jose knows why specific ops were banned from using his
application. Empirically, one ham was added to the "persona non grata" list
shortly after posting that he had asked the FCC whether or not ROS was
legal. My callsign appeared on the list after I sought to verify with FCC
personnel the claim on Jose's blog that the FCC had approved ROS for use by
US amateurs -- a claim the FCC characterizes as both false and fabricated.
Perhaps my "promotion" was motivated by some earlier perceived infraction,
but its entirely irrelevant because ROS is not legal for use by US
operators; it's like being put on the "no use of aviation frequencies" list.

   73,

Dave, AA6YQ

RE: [digitalradio] ROS are sending data from your PC

[Dave AA6YQ]

US operators that avoid ROS because it is illegal in the US are not zombies, 
they are simply abiding by the regulations that govern amateur radio operation 
here and thus protecting their licenses.

The immature antics of Jose Ros are most likely the result of an over-driven 
ego untempered by any understanding of the social aspects of amateur radio. 
Hopefully, some wise Elmer will take Jose in hand and help him grow up to more 
constructively apply his obvious technical talent.

   73,

 Dave, AA6YQ

 
-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on 
Behalf Of rein...@ix.netcom.com
Sent: Friday, July 09, 2010 2:59 PM
To: digitalradio@yahoogroups.com
Subject: RE: [digitalradio] ROS are sending data from your PC


  

John,

Why not give it a serious try? It's is worth getting to the bottom of this
or perhaps not, Are we all becoming zombies?
You are sort of accusing the author without really trying or proof.

Some 3000 People on this reflector. Silence, silence.

There has to be many on this board that can answer that question. If you 
do not want to show who you are. contact me of the reflector 
I will keep your input just between you and me.

Don't want to be involved. Please let me just play. I am tired, don't bother me

73 Rein W6SZ 

-Original Message-
>From: "John Becker, WØJAB" 
>Sent: Jul 9, 2010 2:18 PM
>To: digitalradio@yahoogroups.com
>Subject: RE: [digitalradio] ROS are sending data from your PC
>
>I think many would like to have a answer once and for all
>on this issue if some have been "banned" from using the 
>software.
>
>John, W0JAB
>digitalradio co moderator
>
>At 12:54 PM 7/9/2010, you wrote:
>>Could this ROS discussion be taken offline or elsewhere? 
>>
>>I expect others, like I, are sick of the rehashing. (And if you are sick
>>please don't reply in support of this message - that would be as bad as the
>>rehashing.) 
>>
>>Andy??
>>
>> 
>> - 73 - 
>>Rud Merriam K5RUD 
>>http://mysticlakesoftware.com/
>
>
>
>
>
>http://www.obriensweb.com/digispotter.html
>Chat, Skeds, and "Spots" all in one (resize to suit)
>
>Facebook= http://www.facebook.com/pages/digitalradio/123270301037522
>
>Yahoo! Groups Links
>
>
>

RE: [digitalradio] Busy detect screenshot for Winmor

[Dave AA6YQ]

+++ More AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of KH6TY
Sent: Sunday, June 27, 2010 7:02 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Busy detect screenshot for Winmor



>>>Its my impression that the WinMOR busy frequency detector has been
well-characterized as effective (going back to its original deployment in
SCAMP), so its not clear to me why more evaluation is required.

More evaluation is required simply because it has not been tested in general
use, so it may have been "characterized" as effective, but a full-blown use
(in the subbands) will confirm that is characterization is correct. It will
also show if there are people disabling the busy detector for reasons they
deem necessary or convenient.

+++ "in the subbands" is by definition not full-blown use.


The safest way to find that out is to use it in the automatic subbands. This
way, if it needs improvement, or people are disabling it, the least amount
of harm to the busy detector reputation will be incurred, and potentially
many less people will be angered that might otherwise retaliate and
intentionally block.

+++ WinMOR servers have been operational for months; not a single report of
a WinMOR busy frequency detector failure has appeared here. Contrast that
with ROS.


There is no incentive NOT to keep the Winmor busy detector active - yet.

+++ Are you saying that there has been no intentional QRM of WinMOR servers?
If so, does the WinMOR community agree with you?

So, there is no need to demonstrate to the broader community that it is
already "safe". PROVE that it is safe first, with a wider use (in the
subbands), and if it is, then turn it loose into the wild. Just
characterizing it as such on a limited beta test program with a few beta
testers does not prove what will happen with wider usage. Keeping it in the
unattended subbands can serve just as well as having Winmor mailboxes
everywhere immediately, and if it turns out it truly is a good neighbor,
then the use can be wider.

I think Andy also feels it is too soon to operate his Winmor mailbox outside
the unattended subbands.

+++ As I've already said, individual operators should apply their good
judgement; if they aren't yet confident in the busy frequency detector's
effectiveness, then running their server within the "automatic subbands" is
entirely appropriate. But when experience leads such operators to become
confident, they should be free to venture out onto other frequencies to
which they are by regulation entitled to use.

  73,

 Dave, AA6YQ

RE: [digitalradio] Busy detect screenshot for Winmor

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of KH6TY
Sent: Sunday, June 27, 2010 2:07 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Busy detect screenshot for Winmor



Dave,

I realize you have championed the idea of a busy detector for a long time,
but unless it cannot be switched off, it will eventually be switched off,
and those mailboxes will be spread over the bands, since they are allowed to
go anywhere RTTY can.

>>>I would be happy to see servers incorporate busy frequency detectors that
cannot be disabled. However, adoption by server operators will require the
elimination of intentional QRM.


What is wrong with keeping narrow bandwidth servers with busy detectors
operating at the high end of Winlink Pactor-III channels, since Pactor-III
seldom reaches the highest speed level for very long and decreases bandwidth
to suit the lower speeds?

>>>There are two reasons to encourage servers with effective busy frequency
detectors to utilize available frequencies:

1. it provides an incentive for server operators to incorporate busy
frequency detectors

2. it demonstrates to the broader community that servers with busy frequency
detectors are as polite as human operators, which should reduce the rate of
intentional QRM

>>>If a server operator is not yet confident in the effectiveness of the
busy frequency detector included in his or her server, then using
frequencies within the "automatic sub-bands" is good way to monitor the busy
frequency detector's effectiveness and either gain the confidence that the
detector works well enough to operate outside those sub-bands, or not.


Your assumption is that Winmor servers and clients will always keep busy
detect activated, but it has been shown that mailbox operators grow
impatient to retrieve email, and if a channel is busy too often, will
transmit anyway in an attempt to override the traffic already on the
channel, even among servers of like kind.

>>>As I've said, it would be best if busy frequency detectors were
permanently enabled -- but there will likely need to be progress on all
sides before this happens. Just getting an effective busy frequency detector
into every WinLink PMBO would be a huge positive step.


Why not try the busy detector/busy operators in a place designed for other
automatic stations and see how well the whole system works. That is my
suggestion.

>>>Its my impression that the WinMOR busy frequency detector has been
well-characterized as effective (going back to its original deployment in
SCAMP), so its not clear to me why more evaluation is required.

>>>The longer we keep digging our hole deeper, the longer it will take to
escape.

  73,

   Dave, AA6YQ

RE: [digitalradio] Busy detect screenshot for Winmor

[Dave AA6YQ]

I disagree. Being able to operate outside the "automatic sub-bands" is an
incentive for operators to preferentially choose servers that include an
effective automatic busy frequency detector and to keep that busy frequency
detector enabled.

We're in a deep hole dug by those who ran (and continue to run) servers
(e.g. WinLink PMBOs) without busy frequency detectors. This has generated
enormous frustration over the years, to the point where some operators now
intentionally QRM such servers. This intentional QRM is as disgusting as
running a server without a busy frequency detector, and provides a
convenient excuse for server operators to continue avoiding or disabling
busy frequency detectors.

The first step in escaping from a deep hole is to stop digging. In our case,
this means that

1. servers with effective busy frequency detectors enabled should be welcome
across the full range of frequencies available to them as specified in the
applicable regulations

2. the intentional QRM must stop

3. servers without busy frequency detectors (e.g. WinLink PMBOs) should
immediately be retrofitted with effective busy frequency detectors -- a
possibility that Rick KN6KB stated here a few months ago that he would
investigate

  73,

   Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of KH6TY
Sent: Sunday, June 27, 2010 9:25 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Busy detect screenshot for Winmor



Thanks, Andy.

Unless it is not impossible to disable busy detect, to answer your previous
question about where to operate with Winmor, I personally think that Winmor
frequencies should ALL be kept within the automatic subbands, since the
tendency is going to be to disable it due to the uncertainty if there is
malicious blocking or not. This way, busy detect can still be useful in
enabling frequency sharing with other Winmor stations, and if someone
disables busy detect, the effect on the rest of the hams will not be
significant. This brings to mind the edict by Winlink that busy detect must
not be enabled because of others trying to harm Winlink. It is highly
unlikely that any malicious blocking will be done in the automatic subbands,
because there is no reason to do so. The only blocking will be if the
frequency is already in use by another mailbox.

The recently reported problem with a PSKmail server still interfering with
JT65 points up to another reason that ALL mailbox stations need to be in the
same area, regardless of bandwidth. The more narrow the bandwidth, the
easier it is to find a clear frequency there, so there is still an advantage
to using a more narrow bandwidth.

The frustration of being blocked too often if operating in the general use
areas is, sooner or later, going to result in operator deactivation of the
busy detection, especially as more and more Winmor mailboxes are set up.
Before things get to that point, I think that it would be wise for early
adopters, such as yourself, to set a good example by operating Winmor only
in the automatic subbands and using the busy detection feature to more
efficiently share frequencies there.

73, Skip KH6TY

On 6/27/2010 8:46 AM, Andy obrien wrote:


  Skip (and anyone else interested), see the attached screenshot showing
  the Winmor server busy detect

  Andy K3UK

RE: [digitalradio] Re: Individual software programs for various digital modes????

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of g4ilo
Sent: Wednesday, June 16, 2010 11:47 AM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Individual software programs for various digital
modes

The disadvantage of using different programs instead of standardizing on one
is that you lose the benefits of computer logging. I guess the OP maintains
a paper log so he isn't concerned with that aspect.

 >>>You can make digital mode QSOs with DM780, FLDigi, MixW,  MMSSTV, MMTTY,
MMVARI, MultiPSK or WinWarbler while logging QSOs to DXKeeper, using either
Commander or HRD for transceiver control.

>>>See <http://www.dxlabsuite.com/download.htm#Bridges, Gateways, and
Extenders>

  73,

Dave, AA6YQ

[digitalradio] RE: [SDRlist] Digital ID Skimmer mock-up

[Dave AA6YQ]

http://www.dxlabsuite.com/winwarbler/Heard.jpg

Entries can be sorted by clicking a column header (like a spreadsheet).

- Add a column to indicate mode.

- Provide filtering by mode (e.g. "only show Olivia and Contestia entries")

73,

Dave, AA6YQ

-Original Message-
From: sdrl...@yahoogroups.com [mailto:sdrl...@yahoogroups.com]on Behalf Of
Andy obrien
Sent: Wednesday, May 12, 2010 6:37 AM
To: digitalradio; sdrl...@yahoogroups.com
Subject: [SDRlist] Digital ID Skimmer mock-up



See http://www.obriensweb.com/digidskimmer.htm for a crude mock-up
of how a digital mode "skimmer" could look , The concept would be ...
digital mode applications that already use RS ID detect (Fldigi,
Multipsk, DM780, Pocketdigi) expand their current displays of received
RS IDs in to something that provides more interactive information that
is "clickable" so you can QSY to the particular frequency, sortable by
mode of frequency, and color coded for easier visual reference. Call
ID (a very useful feature within Multipsk) could also be part of this
and , when used, the call sign of the station that ID's would be
displayed. This concept would support wider range frequencies
provided by an SDR, just as CW Skimmer does.

Anyone have any improvements on this idea ?

RE: [digitalradio] Re: Opposing 60M proposal

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on 
Behalf Of David Little
Sent: Tuesday, May 11, 2010 8:35 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: Opposing 60M proposal


  
  You further reinforce my position; the amateur radio service is not going 
to support long haul emcomm infrastructure.

  It doesn't matter what color you paint it.

  If the amout of wasted envy spent on lamenting P3 was devoted to 
promoting the Amateur Radio Service; then it may have a chance of surviving a 
few more decades.

  The others who take a serious look at your stance, and the credibility 
the ARS stands to lose have a good idea about who is destroying the villiage.

  Of course I have heard the same complaints about WINMOR; I live on planet 
Earth.   

  >>>I have not seen a single complaint about WinMor on this reflector, or 
anywhere else on the internet. If you have, please post a couple of URLs.
   

  By the same token, if we had to resort to smoke signals, the same group 
would be protesting unattended operation of fire. 

  To me, the discussion is a passing amusement.

  I don't anticipate the need to generally waste time or effort trying to 
use Amateur Radio Service spectrum for any useful long haul communications in 
an emergency; except voice when I may need a larger audience in an affected 
area. 

  The SATERN nets in the first week of the Haiti response brought out the 
jammers.  They had the same hatred for sustained net operations as the anti P3 
crowd have for effective emcomm infrastructure.  The end result is the same;  
ineffective interference...

  Long Haul Emcomm has migrated to NTIA spectrum.  I am reaping a great 
crop of effective communications there.  How well did your crop come in?? 

  >>>Quite well, thanks: some new ones on 160m and 80m, 3500+ QSOs in 2 
weeks as 8P9RY, some great digital-mode rag chews, a post here from Rick KN6KB 
saying that he'd consider backfitting the WinMor busy frequency detector into 
WinLink PMBOs, and lots of fun adding SDR Console support to DXLab.

   73,

 Dave, AA6YQ



 


 
.
 

[digitalradio] Re: Opposing 60M proposal

[aa6yq]

>>>AA6YQ comments below

--- In digitalradio@yahoogroups.com, "David Little"  wrote:

This would be a good plan to insure that the Amateur Radio Service is treated 
as hobby-only communications.

>>>"We had to destroy the village in order to save it"

>snip<

I run a 24/7 RMS WINMOR server.

>snip<

If things were different, I would put up a second station 24/7 within
the Amateur Radio Service spectrum.  It simply isn't worth listening to the 
whining.

>>>I've heard no complaints about QRM from WinMor stations. Have you?

  
Also, the potential for being effective in an emergency is too heavily
weighted toward Federal spectrum for the same reasons that the
Winlink/P3 whining never ceases when it concerns Amateur spectrum.  

>>>Complaints about QRM from WinLink PMBOs will cease when WinLink PMBOs stop 
>>>QRMing ongoing QSOs. 

>>>The only WinLink whining I hear is from those offering lame excuses for why 
>>>the same busy frequency detection mechanism deployed years ago in SCAMP and 
>>>now deployed in WinMor hasn't long been incorporated into WinLink PMBOs.
  

You reap what you sow 

>>>Exactly.

   73,

Dave, AA6YQ

[digitalradio] Re: Opposing 60M proposal

[aa6yq]

Where does one file comments on this proposal?

I sure wish the WinLink guys would backfit the WinMor busy frequency detector 
and deploy it to every PMBO. I'd much rather write code than letters to the 
FCC...

   73,

  Dave, AA6YQ

--- In digitalradio@yahoogroups.com, Andy obrien  wrote:
>
> FYI, I plan to file a comment opposing the PIII on 60M proposal.  My
> objections are
> 
> PIII is a proprietary mode .
> PIII as used in non-busy detect Winkink system has  been the leading cause
> of QRM complaints for the past 10 years, hence they are likely to cause the
> same for the primary services  that have 60M allocations.
> Recent tests of NBEMS with FLICS and WRAP have proven as effective as PIII
> and take up less spectrum (and are not proprietary)
> Winmor 500 offers most of the Winlink capabilities without the problems
> associated with wide PIII and is freely available to all hams.
> 
> I will probably suggest that they authorize PS31, MFSK16 and Winmor 500 if
> they are going to get mode specific.
> 
> Andy K3UK
> 
> 
> On Mon, May 10, 2010 at 8:54 PM, Dave Wright  wrote:
> 
> >
> >
> > On May 10, 2010, at 7:26 PM, Chris Jewell wrote:
> >
> >
> >
> > Rick Ellison writes:
> > "recommending that instead of authorizing only PSK-31 and Pactor-III,
> > that the FCC instead permit all publicly-documented data modes "
> >
> >
> > So, has Pactor III every been publicly-documented???
> >
> >
> >
> > Dave
> > K3DCW
> >
> > Real radio bounces off the sky
> > --
> >
> >
> >  
> >
>

RE: [digitalradio] Why does the ARRL continue to push for Pactor III support...

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of "John Becker, WOJAB"
Sent: Monday, May 10, 2010 12:50 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Why does the ARRL continue to push for Pactor
III support...



I can clearly see that this anti Pactor rant will Never end.

 >>>It's an "anti-Winlink without busy frequency detection" rant, John.

 73,

 Dave, AA6YQ

RE: [digitalradio] Re: Unattended narrow mode transmission "protection"

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Rick Muething
Sent: Sunday, April 11, 2010 7:11 AM
To: digitalradio@yahoogroups.com
Cc: 'Vic Poor'
Subject: [digitalradio] Re: Unattended narrow mode transmission "protection"



Dave,

Using the WINMOR busy detector for Pactor sounds like a workable idea.

The WINMOR busy detector hasn't yet been integrated into other WL2K Pactor
Servers but it could be.  The basic WINMOR TNC application (the virtual TNC)
has the function but would need to be integrated into the Pactor driver for
the SCS. When Vic gets back from vacation I'll talk to him about this and
when we might be able to do that.

>>>Rick and Vick, that would be a huge positive step. If there is any way I
can help with this, please let me know.

  73,

   Dave, AA6YQ

.

RE: [digitalradio] Re: Unattended narrow mode transmission "protection"

[Dave AA6YQ]

Thanks, Rick.

I have suggested in the past that your SCAMP/WINMOR "channel busy detector"
could be inexpensively back-fit into WinLink PMBOs. Has anyone taken a look
at this?

 73,

 Dave, AA6YQ


-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Rick Muething
Sent: Saturday, April 10, 2010 8:30 AM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Unattended narrow mode transmission "protection"




All,



I have been busy with WINMOR but do monitor the group and thought it might
add some balance to put forth some facts and observations.



1)   The majority of WL2K users are not 30 day wonder hams on expensive
yachts. Marine mobile users are probably < 20% of all registered WL2K users
(about 15,000 total current active users).

2)   Those that are Marine Mobile have (on average) the same radio
skills as the average ham.some much better. Getting digital radio to work at
all on a small sailboat (most MM users are not wealthy and have "yachts" of
< 35 feet) when you are sitting in a plastic boat inside the antenna near
field is a challenge. I have seen and helped set up over 100 such
installations.

3)   Certainly there are a number of operators that fail to "listen
first"  or don't use the tools and procedures recommended to connect. E.g.
AirMail limits the calling cycle to normally < 20 seconds for most stations.
Unfortunately bad operators and procedures exist in ham radio in every mode.

4)   Marinas by and large don't do or sell radio installations (I have
NEVER seen even one).  They sell GAS/Diesel, dockage, supplies, beer and
bait. In fact most marine radio service companies have minimal experience
with ham radios or HF digital modes.

5)   Scanning has been used in the past to improve the utilization of HF
Pactor server stations but can be an issue.  Pactor has some but limited
busy channel detection capability.  WL2K is now looking at and testing
alternatives to the conventional scanning used in Pactor.  The new WINMOR
protocol allows more options and experimentation.

a.   RMS WINMOR server stations [Beta operation started in January 2010]
operate on ONE frequency which can be changed (on the hour) during the day
(most use 1 - 3  frequencies over a 24 hour day). The frequency list clients
use indicate which frequency is in use on which UTC hour. The client
software (RMS Express) shows users ONLY those frequencies in current use
along with the propagation prediction to the remote server stations.  Users
can refresh their server station list over the air or over the internet if
available.

b.  WINMOR uses an effective "channel busy detector" to warn users if a
channel appears busy in the bandwidth of interest. The detector isn't
perfect (neither is the human ear!) but it can detect most modes even in
weak conditions (SSB, CW, PSK, Pactor, Olivia, WINMOR etc).

c.   The RMS WINMOR stations (servers) also have a similar DSP based
detector which can block a reply to a connect request. This will prevent for
example answering a connect request "over" an existing session/QSO not
audible to the station originating the connect request (hidden transmitter
situation). We're still experimenting and refining this but it definitely
helps avoid accidental interference.



To summarize: Painting all Winlink users with a broad brush of "wealthy
yachties with limited radio skills"  is no where near the truth and is an
obvious attempt distort the facts to promote some agenda.  If given the
flexibility to work on and experiment with these digital modes it is
possible to address issues and make progress improving our hobby.  If we try
and legislate every detail we end up generating rules or band plans that
become obsolete quickly.  This discourages experimentation (I still hope
that is part of our hobby.) and progress.



I don't have the time to get into flame wars or extended blogging ..If you
have a legitimate technical question on WINMOR or a question about WL2K I
will try and answer it with accurate facts.



73,



Rick Muething, KN6KB

RE: [digitalradio] Unattended narrow mode transmission "protection"

[Dave AA6YQ]

>>>AA6YQ comments below


-Original Message-
From: Jaak Hohensee [mailto:jaak.hohen...@eesti.ee]
Sent: Thursday, April 08, 2010 2:50 PM
To: digitalradio@yahoogroups.com
Cc: Dave AA6YQ
Subject: Re: [digitalradio] Unattended narrow mode transmission "protection"


Busy detection in case of QRP Olivia 500/32 signals about snr -17dB is myth.

>>>One could include an Olivia decoder in one's busy frequency detector. A
busy detector need not detect all possible digital modes simultaneously; it
could continuously reconfigure.

>>>And as I said, "perfect is the enemy of good" (with apologies to
Voltaire). A busy detector that is "only" 80% effective would reduce QRM
rates from unattended stations by a factor of 5.

 73,

Dave, AA6YQ

8.04.2010 19:41, Dave AA6YQ kirjutas:


  If there were no means for such stations to avoid transmitting atop
detectable on-going QSOs, I might consider supporting such a proposal. Busy
frequency detection, however, is demonstrably feasible and practical.
Rewarding the long-term rude behavior of ops running unattended
semi-automatic and automatic stations without busy detection by giving them
dedicated sub-bands would send a very clear message: the way to obtain
dedicated frequencies is to unrelentingly drive everyone else out of them.

  Appeasement never works.

  73,

   Dave, AA6YQ

  -Original Message-
  From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Andy obrien
  Sent: Thursday, April 08, 2010 7:50 AM
  To: digitalradio@yahoogroups.com
  Subject: [digitalradio] Unattended narrow mode transmission "protection"



  Let me "drill down" on this some more to find out the prevailing view...
Would those that object to Bonnie's idea, also object if the "wide" modes
were not part of the issue?.  How about these objections if there was a
digital mode under 500 Hz that transmitted "unattended" under automatic
control?  It seems to me, that after years of complaints that PACTOR, ALE,
and CW (W1AW) just fire up in the middle of a on-going QSO, that having an
area designated for automatic unattended operations makes sense.  Then, if
we operate there, we do so knowing that W1AW or a WINMOR server may activate
at any moment? (actually W1AW has a schedule , but you get my drift).  A 500
Hz sliver of spectrum in 80, 60 (yes)  30, 17,  and  10M would be all that
is needed.  The current ALE, Winmor, Pactor, operators (there really are
only about 200 in the world ,  TOTAL  ) would then use narrow forms of their
mode to achieve their aims . coordinate schedules between them, and have
2500 Hz where their operations are primary, and other hams communications in
these segments would be secondary.

  Andy K3UK



  On Wed, Apr 7, 2010 at 10:50 PM, n9dsj  wrote:




--- In digitalradio@yahoogroups.com, Andy obrien  wrote:


>
> Andy K3UK


Personalities aside, the proposed "bandplan" is a bad idea. I cannot
think of a present or future mode that could be better served by this. ROS
has its own problems and standard ALE and PactorIII presently have areas
they can reside. Neither are new or "advancing the state of art". Even
Winmor, which is relatively recent, can not co-exist with existing Winlink
PactorIII; is why they were told to stay out of the wide bandwidth automatic
sub-bands. I have not found ALE to be a problem as they stay on
pre-determined frequencies and actually have little traffic (no offense
intended). The prospect of wide bandwidth Winlink bots being able to operate
on the suggested frequencies is problematic and antithetical to the need for
frequency conservation.

Bill N9DSJ
>




  


--
Kirjutas ja tervitab
Jaak Hohensee

RE: [digitalradio] Unattended narrow mode transmission "protection"

[Dave AA6YQ]

Rick KN6KB developed an effective busy frequency detector that he included
with his implementation of the SCAMP protocol several years ago. A
high-level description of SCAMP is available via

<http://www.eham.net/articles/9785>

RIck was initially reluctant to develop a busy-frequency detector because he
couldn't make it perfect. My contribution was to help him understand that in
this domain, perfect is the enemy of good; the resulting effectiveness of
his busy frequency detector surprised Rick, as well as the SCAMP beta
testers.

My understanding is that WINMOR, which Rick characterizes as a descendent of
SCAMP, incorporates a descendent of SCAMP's busy frequency detector. I have
not seen a technical paper describing Rick's busy frequency detector, much
less code that you could borrow, but based on my experience I suspect that
Rick would be happy to discuss it with you.

73,

  Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Simon HB9DRV
Sent: Thursday, April 08, 2010 2:30 PM
To: digitalradio@yahoogroups.com
Subject: RE: [digitalradio] Unattended narrow mode transmission "protection"




I've seen (but not yet read) references to this in the SDR world.



Out of interest what would you have in mind?



Simon Brown, HB9DRV

http://sdr-radio.com



From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On
Behalf Of Dave AA6YQ



Busy frequency detection, however, is demonstrably feasible and practical.

RE: [digitalradio] Unattended narrow mode transmission "protection"

[Dave AA6YQ]

If there were no means for such stations to avoid transmitting atop
detectable on-going QSOs, I might consider supporting such a proposal. Busy
frequency detection, however, is demonstrably feasible and practical.
Rewarding the long-term rude behavior of ops running unattended
semi-automatic and automatic stations without busy detection by giving them
dedicated sub-bands would send a very clear message: the way to obtain
dedicated frequencies is to unrelentingly drive everyone else out of them.

Appeasement never works.

73,

 Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Andy obrien
Sent: Thursday, April 08, 2010 7:50 AM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Unattended narrow mode transmission "protection"



Let me "drill down" on this some more to find out the prevailing view...
Would those that object to Bonnie's idea, also object if the "wide" modes
were not part of the issue?.  How about these objections if there was a
digital mode under 500 Hz that transmitted "unattended" under automatic
control?  It seems to me, that after years of complaints that PACTOR, ALE,
and CW (W1AW) just fire up in the middle of a on-going QSO, that having an
area designated for automatic unattended operations makes sense.  Then, if
we operate there, we do so knowing that W1AW or a WINMOR server may activate
at any moment? (actually W1AW has a schedule , but you get my drift).  A 500
Hz sliver of spectrum in 80, 60 (yes)  30, 17,  and  10M would be all that
is needed.  The current ALE, Winmor, Pactor, operators (there really are
only about 200 in the world ,  TOTAL  ) would then use narrow forms of their
mode to achieve their aims . coordinate schedules between them, and have
2500 Hz where their operations are primary, and other hams communications in
these segments would be secondary.

Andy K3UK



On Wed, Apr 7, 2010 at 10:50 PM, n9dsj  wrote:




  --- In digitalradio@yahoogroups.com, Andy obrien  wrote:


  >
  > Andy K3UK


  Personalities aside, the proposed "bandplan" is a bad idea. I cannot think
of a present or future mode that could be better served by this. ROS has its
own problems and standard ALE and PactorIII presently have areas they can
reside. Neither are new or "advancing the state of art". Even Winmor, which
is relatively recent, can not co-exist with existing Winlink PactorIII; is
why they were told to stay out of the wide bandwidth automatic sub-bands. I
have not found ALE to be a problem as they stay on pre-determined
frequencies and actually have little traffic (no offense intended). The
prospect of wide bandwidth Winlink bots being able to operate on the
suggested frequencies is problematic and antithetical to the need for
frequency conservation.

  Bill N9DSJ
  >

RE: [digitalradio] SS definitions

[Dave AA6YQ]

>>>8P9RY comments below

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On 
Behalf Of Trevor .
Sent: Wednesday, March 10, 2010 3:21 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] SS definitions

 

  

--- On Wed, 10/3/10, KH6TY mailto:kh6ty%40comcast.net> > 
wrote:
> Alan, though we may disagree as to the amount or nature of FHSS in ROS, 
> the bottom line is that the FCC engineers, as well as the ARRL engineers,
> reviewed both the documentation and the signal footprint, and have 
> concluded it is FHSS. 

Who are these "FCC Engineers" ? All we've has is a response from someone that 
may be assumed to be an office clerk who simply quoted back the words in Part 
97. 

>>>What a convenient assumption. Have you spoken with the agent in question, 
>>>assessed her technical skills, and inquired as to what effort went into the 
>>>response she conveyed?

 73,

 Dave, 8P9RY

 

 

RE: [digitalradio] Re: 1976 FCC - Delete all Emission Types from Part 97

[Dave AA6YQ]

Yes, lots of modern transceivers have a dedicated data mode, but they're
generally too wide for optimal RTTY reception. In contrast, consider the
Twin Peak filter available on recent Icom transceivers, for example; it's
only available with the transceiver's mode set to RTTY.

 

   73,

 

Dave, 8P9RY

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On
Behalf Of g4ilo
Sent: Tuesday, March 09, 2010 6:59 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: 1976 FCC - Delete all Emission Types from Part
97

 

  

I've heard this argument many times, Dave, but whilst it was probably true
10 or more years ago, surely all decent modern transceivers have a dedicated
data mode that allows the use of narrow filters? Heck, even the humble
FT-817 has one.

Julian, G4ILO

--- In digitalradio@yahoogroups.com <mailto:digitalradio%40yahoogroups.com>
, "Dave AA6YQ"  wrote:
>
> The advantage of using FSK is that one can take advantage of the excellent
> RTTY filters built into some transceivers. These filters are generally not
> available when operating in USB/LSB. This is particularly important to
> contesters operating in a crowded environment and DXers dealing with weak
> signals.

RE: [digitalradio] Re: 1976 FCC - Delete all Emission Types from Part 97

[Dave AA6YQ]

The advantage of using FSK is that one can take advantage of the excellent
RTTY filters built into some transceivers. These filters are generally not
available when operating in USB/LSB. This is particularly important to
contesters operating in a crowded environment and DXers dealing with weak
signals.

 

73,

 

Dave, 8P9RY

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On
Behalf Of g4ilo
Sent: Tuesday, March 09, 2010 1:54 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: 1976 FCC - Delete all Emission Types from Part
97

 

  

It also doesn't suffer from the ridiculous printing up garbage because a
shift character was lost. If there ever was an outdated mode, it's RTTY.

Unfortunately logic or technical arguments play very little part in the
reason why people choose to use particular modes. Many RTTY operators insist
on actually FSK-ing their radios instead of using AFSK, even though it means
they have to accurately tune in every signal instead of just clicking on a
waterfall, which would surely be quicker.

Julian, G4ILO

--- In digitalradio@yahoogroups.com 
, KH6TY  wrote:
>
> The hope was that PSK63 could replace RTTY, being both spectrally more 
> efficient, and more usable for a panoramic presentation for contesters 
> to see who is on the band, but it never came about. Too bad, I think, 
> because it would help reduce congestion during contests. PSK63's overall 
> time to complete an exchange is roughly equal to RTTY (twice as fast as 
> PSK31), which is considered too slow for "RTTY" contesting, but I don't 
> understand why it has not been adopted. I even wrote an article on PSK63 
> for the National Contest Journal, but there appeared to be little 
> interest and few comments.
> 
> 73 - Skip KH6TY
> 

RE: [digitalradio] Re: 1976 FCC - Delete all Emission Types from Part 97

[Dave AA6YQ]

EPC runs a PSK63 contest, and the mode works quite well. Panoramic reception
and broadband decoding are a potent combination.

 

It's the only contest I've ever entered, and I took first place in NA, hi.

 

   73,

 

   Dave, AA6YQ

 



 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On
Behalf Of KH6TY
Sent: Tuesday, March 09, 2010 1:40 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: 1976 FCC - Delete all Emission Types from
Part 97

 

  

The hope was that PSK63 could replace RTTY, being both spectrally more
efficient, and more usable for a panoramic presentation for contesters to
see who is on the band, but it never came about. Too bad, I think, because
it would help reduce congestion during contests. PSK63's overall time to
complete an exchange is roughly equal to RTTY (twice as fast as PSK31),
which is considered too slow for "RTTY" contesting, but I don't understand
why it has not been adopted. I even wrote an article on PSK63 for the
National Contest Journal, but there appeared to be little interest and few
comments.

73 - Skip KH6TY
 



g4ilo wrote: 

  


I don't think digital voice will ever replace SSB, any more than PSK31 and
other spectrally more efficient modes will replace RTTY. Radios have a long
lifetime. But unlike digital modes whose bandwidth is fixed, phone can
communicate using reduced bandwidth. Look what happens in a contest.

Julian, G4ILO

 

RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97

[Dave AA6YQ]

It’s more easily decoded than two handclaps in front of the microphone…

 

   73,

 

 Dave, 8P9RY

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On 
Behalf Of Warren Moxley
Sent: Monday, March 08, 2010 2:25 PM
To: digitalradio@yahoogroups.com
Subject: RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97

 

  


"something simple like “QRL” in CW, or 3-seconds of carrier at ~1 khz.)"
At least this is an idea.

Let's here more brain storming, even ones that sound silly at first might or 
can be modified to a solution or cause someone else to think in an entirely new 
way.


--- On Mon, 3/8/10, Dave AA6YQ  wrote:


From: Dave AA6YQ 
Subject: RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97
To: digitalradio@yahoogroups.com
Date: Monday, March 8, 2010, 9:58 AM

  

(unless the “Universal QRL signal” is something simple like “QRL” in CW, or 
3-seconds of carrier at ~1 khz.)

 

   73,

 

Dave, 8P9RY

 

From: digitalradio@ yahoogroups. com [mailto:digitalradi o...@yahoogroups. com] 
On Behalf Of Dave AA6YQ
Sent: Monday, March 08, 2010 11:55 AM
To: digitalradio@ yahoogroups. com
Subject: RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97

 

  

Unless you can convince the transceiver manufacturers to include the capability 
in each unit, someone operating without a computer connected to his transceiver 
– e.g. a phone operator -- will be unable to generate the “universal QRL” 
signal.

 

   73,

 

Dave, 8P9RY

 

From: digitalradio@ yahoogroups. com [mailto:digitalradi o...@yahoogroups. com] 
On Behalf Of Warren Moxley
Sent: Monday, March 08, 2010 11:36 AM
To: digitalradio@ yahoogroups. com
Subject: Re: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97

 

  


Skip,

"since there is no way to cross-communicate to resolve mutual interference."

This is a very interesting topic. I have been a software engineer for over 35 
years and have heard there is "no way" a lot of times only to come up with a 
solution a few days later either by myself or others on my team.

It seems to me that the problem of cross-communication can be solved by using 
an already used technique via RSID. RSID is fast becoming a defacto standard. 
Maybe we can solve this by modifying the RSID protocol. Currently we are using 
it to just let others know what mode we are in. Maybe more information can be 
put in the the RSID packet, for example, Call sign and some reserved bits for 
the purpose of QSY. Like codes that mean, please QSY, this frequency is already 
in use and many other codes that can be expanded for this use.

Hey guys, come on, there are a lot of smart people and great problem solvers on 
this reflector who can expand this protocol or come up with a solution. Let's 
use our brains and solve this problem for the good of the hobby. I am ONLY 
making and example for the purpose of brain storming. RSID expansion may or may 
not be a good idea. Do not take my RSID packet expansion as what we should do 
but as a point of discussion on how to solve a problem. That's the real point 
here. Let's take my simplistic example as start and let's go from here. Let's 
not get bogged down on who is right and who is wrong, who has the better mode 
and it is just too hard of a problem to solve.

Warren - K5WGM

--- On Mon, 3/8/10, KH6TY  wrote:


From: KH6TY 
Subject: Re: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97
To: digitalradio@ yahoogroups. com
Date: Monday, March 8, 2010, 8:14 AM

  

Trevor,

The problem with such a regulation is that, unless CW is required as a common 
mode, there is no way for a phone QSO, being able to request an interfering 
digital signal to QSY. Our frequencies are shared, and accidental transmission 
on existing QSO's in unavoidable, but the mitigation is the ability for the 
user of one mode to be able to communicate with the user of another mode. The 
problem already exists between digital operators, but the regulations were 
written long ago when essentially there was only phone and CW and everyone was 
required to know CW.

I don't know what the solution to the current problem is, but the problem with 
solely "regulation by bandwidth" is NOT a solution, especially between phone 
and digital, since there is no way to cross-communicate to resolve mutual 
interference. This is why the ARRL "regulation by bandwidth" petition to the 
FCC was withdrawn after already once being denied by the FCC. There have been 
arguments that bandwidth-only regulation works in other countries (perhaps with 
less ham population density), but it definitely will not work here. That is why 
legal separation between data and phone has been maintained at all costs, and 
data kept separate from phone. CW usage may be declining, and therefore using 
less space, leaving more for digital modes to use, but u

RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97

[Dave AA6YQ]

(unless the “Universal QRL signal” is something simple like “QRL” in CW, or 
3-seconds of carrier at ~1 khz.)

 

   73,

 

Dave, 8P9RY

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On 
Behalf Of Dave AA6YQ
Sent: Monday, March 08, 2010 11:55 AM
To: digitalradio@yahoogroups.com
Subject: RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97

 

  

Unless you can convince the transceiver manufacturers to include the capability 
in each unit, someone operating without a computer connected to his transceiver 
– e.g. a phone operator -- will be unable to generate the “universal QRL” 
signal.

 

   73,

 

Dave, 8P9RY

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On 
Behalf Of Warren Moxley
Sent: Monday, March 08, 2010 11:36 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97

 

  


Skip,

"since there is no way to cross-communicate to resolve mutual interference."

This is a very interesting topic. I have been a software engineer for over 35 
years and have heard there is "no way" a lot of times only to come up with a 
solution a few days later either by myself or others on my team.

It seems to me that the problem of cross-communication can be solved by using 
an already used technique via RSID. RSID is fast becoming a defacto standard. 
Maybe we can solve this by modifying the RSID protocol. Currently we are using 
it to just let others know what mode we are in. Maybe more information can be 
put in the the RSID packet, for example, Call sign and some reserved bits for 
the purpose of QSY. Like codes that mean, please QSY, this frequency is already 
in use and many other codes that can be expanded for this use.

Hey guys, come on, there are a lot of smart people and great problem solvers on 
this reflector who can expand this protocol or come up with a solution. Let's 
use our brains and solve this problem for the good of the hobby. I am ONLY 
making and example for the purpose of brain storming. RSID expansion may or may 
not be a good idea. Do not take my RSID packet expansion as what we should do 
but as a point of discussion on how to solve a problem. That's the real point 
here. Let's take my simplistic example as start and let's go from here. Let's 
not get bogged down on who is right and who is wrong, who has the better mode 
and it is just too hard of a problem to solve.

Warren - K5WGM

--- On Mon, 3/8/10, KH6TY  wrote:


From: KH6TY 
Subject: Re: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97
To: digitalradio@yahoogroups.com
Date: Monday, March 8, 2010, 8:14 AM

  

Trevor,

The problem with such a regulation is that, unless CW is required as a common 
mode, there is no way for a phone QSO, being able to request an interfering 
digital signal to QSY. Our frequencies are shared, and accidental transmission 
on existing QSO's in unavoidable, but the mitigation is the ability for the 
user of one mode to be able to communicate with the user of another mode. The 
problem already exists between digital operators, but the regulations were 
written long ago when essentially there was only phone and CW and everyone was 
required to know CW.

I don't know what the solution to the current problem is, but the problem with 
solely "regulation by bandwidth" is NOT a solution, especially between phone 
and digital, since there is no way to cross-communicate to resolve mutual 
interference. This is why the ARRL "regulation by bandwidth" petition to the 
FCC was withdrawn after already once being denied by the FCC. There have been 
arguments that bandwidth-only regulation works in other countries (perhaps with 
less ham population density), but it definitely will not work here. That is why 
legal separation between data and phone has been maintained at all costs, and 
data kept separate from phone. CW usage may be declining, and therefore using 
less space, leaving more for digital modes to use, but use of digital modes is 
still very small compared to CW and phone. Since it is possible to create a 
digital mode that is very spectrum inefficient for the benefit it brings, there 
will probably have to be a future restriction of digital mode bandwidths in 
proportion to the need and benefits of the mode. Digital modes will probably 
have to restricted by bandwidth in the future, but there still needs to be a 
"common language" for frequency use mitigation.

73 - Skip KH6TY



Trevor . wrote: 

  

Following the recent discussions about the US license restrictions I was 
looking through the archive of QST mags at www.arrl.org 

On April 22, 1976 the FCC introduced Docket 20777, the QST report (page June 
1976) says 

"Rather than further complicate the present rules," the Commission said, "with 
additional provisions to accomodate the petitioner

RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97

[Dave AA6YQ]

Unless you can convince the transceiver manufacturers to include the capability 
in each unit, someone operating without a computer connected to his transceiver 
– e.g. a phone operator -- will be unable to generate the “universal QRL” 
signal.

 

   73,

 

Dave, 8P9RY

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On 
Behalf Of Warren Moxley
Sent: Monday, March 08, 2010 11:36 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97

 

  


Skip,

"since there is no way to cross-communicate to resolve mutual interference."

This is a very interesting topic. I have been a software engineer for over 35 
years and have heard there is "no way" a lot of times only to come up with a 
solution a few days later either by myself or others on my team.

It seems to me that the problem of cross-communication can be solved by using 
an already used technique via RSID. RSID is fast becoming a defacto standard. 
Maybe we can solve this by modifying the RSID protocol. Currently we are using 
it to just let others know what mode we are in. Maybe more information can be 
put in the the RSID packet, for example, Call sign and some reserved bits for 
the purpose of QSY. Like codes that mean, please QSY, this frequency is already 
in use and many other codes that can be expanded for this use.

Hey guys, come on, there are a lot of smart people and great problem solvers on 
this reflector who can expand this protocol or come up with a solution. Let's 
use our brains and solve this problem for the good of the hobby. I am ONLY 
making and example for the purpose of brain storming. RSID expansion may or may 
not be a good idea. Do not take my RSID packet expansion as what we should do 
but as a point of discussion on how to solve a problem. That's the real point 
here. Let's take my simplistic example as start and let's go from here. Let's 
not get bogged down on who is right and who is wrong, who has the better mode 
and it is just too hard of a problem to solve.

Warren - K5WGM

--- On Mon, 3/8/10, KH6TY  wrote:


From: KH6TY 
Subject: Re: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97
To: digitalradio@yahoogroups.com
Date: Monday, March 8, 2010, 8:14 AM

  

Trevor,

The problem with such a regulation is that, unless CW is required as a common 
mode, there is no way for a phone QSO, being able to request an interfering 
digital signal to QSY. Our frequencies are shared, and accidental transmission 
on existing QSO's in unavoidable, but the mitigation is the ability for the 
user of one mode to be able to communicate with the user of another mode. The 
problem already exists between digital operators, but the regulations were 
written long ago when essentially there was only phone and CW and everyone was 
required to know CW.

I don't know what the solution to the current problem is, but the problem with 
solely "regulation by bandwidth" is NOT a solution, especially between phone 
and digital, since there is no way to cross-communicate to resolve mutual 
interference. This is why the ARRL "regulation by bandwidth" petition to the 
FCC was withdrawn after already once being denied by the FCC. There have been 
arguments that bandwidth-only regulation works in other countries (perhaps with 
less ham population density), but it definitely will not work here. That is why 
legal separation between data and phone has been maintained at all costs, and 
data kept separate from phone. CW usage may be declining, and therefore using 
less space, leaving more for digital modes to use, but use of digital modes is 
still very small compared to CW and phone. Since it is possible to create a 
digital mode that is very spectrum inefficient for the benefit it brings, there 
will probably have to be a future restriction of digital mode bandwidths in 
proportion to the need and benefits of the mode. Digital modes will probably 
have to restricted by bandwidth in the future, but there still needs to be a 
"common language" for frequency use mitigation.

73 - Skip KH6TY



Trevor . wrote: 

  

Following the recent discussions about the US license restrictions I was 
looking through the archive of QST mags at www.arrl.org 

On April 22, 1976 the FCC introduced Docket 20777, the QST report (page June 
1976) says 

"Rather than further complicate the present rules," the Commission said, "with 
additional provisions to accomodate the petitioners' requests, we are herein 
proposing to delete all references to specific emission types in Part 97 of the 
Rules. "We propose, instead," the Commission continued, "to replace the present 
provisions with limitations on the permissible bandwidth which an amateur 
signal may occupy in the various amateur frequency bands. Within the authorised 
limitations any emission would be permitted." 

It would seem that deletion of emission types from Part 97 is exactly what is 
needed now to permit experimenta

RE: [digitalradio] Re: ARRL/FCC Announcement about ROS

[Dave AA6YQ]

>>>AA6YQ comments below

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On 
Behalf Of rein...@ix.netcom.com
Sent: Saturday, March 06, 2010 5:50 AM
To: digitalradio@yahoogroups.com
Subject: RE: [digitalradio] Re: ARRL/FCC Announcement about ROS

 

  


Hi Dave, ( AA6YQ )

Thanks. I might just do that next Monday.

I understand it to be, some help/emergency phone line?

>>>It’s not an emergency phone line. I
Lost the number, so if you have it, please send it to me.

>>>call (877) 480-3201, choose option #2, and when a person answers ask for 
>>>“Dawn” (agent 3820).


I am also very much interested in your definition of ss.


I have not been able to find anything, Wikipedia really
does not count in this case.

>>>I don’t have a definition, Rein; I agree with you that the Wikipedia entry 
>>>is not authoritative. The fact that part 97 references spread spectrum 
>>>without defining it is one of the root causes of this controversy, leaving 
>>>us to make “individual decisions” in the absence of decision criteria. 
>>>Transparency (ability for anyone to copy without a private key) and 
>>>spreading factor are clearly important factors, but to what does the 
>>>spreading factor apply? Information content? Bandwidth of the signal being 
>>>spread? Mike N4QLB claims in a post on the ROS reflector that “it’s not 
>>>spread spectrum if the resulting bandwidth is 3 khz”. Is that true? If so, 
>>>why 3 khz, as opposed to, say, 3.1 khz?

>>>While the assessment of a digital mode’s legality in the US is left to the 
>>>operator, the decision to impose a penalty in an operator for using an 
>>>illegal mode lies with the FCC. Given the FCC’s declaration that “ROS is 
>>>viewed as spread spectrum” and the ARRL’s similar public announcement, I 
>>>would be hard-pressed to explain why my use of ROS should not result in a 
>>>serious fine or loss of license. Thus I am not using ROS on HF bands.

>>>Said another way, US amateurs can decide to use ROS, but they’d best have a 
>>>killer technical argument for its legality at the ready.

73,

  Dave, AA6YQ

RE: [digitalradio] What is SS?

[Dave AA6YQ]

Mike N4QLB's claims that "A frequency in Ham radio consist of a 3kh wide
channel. Ros does not signal a receiver to hop outside of that channel (3
Khz) therefore it is not SS and is just like anyother FSK mode used in the
amatuer radio service." are incorrect, in my opinion.

 

Amateur radio frequencies on HF bands are not channelized at 3 khz or any
other bandwidth (with the exception of 60m).

 

I have asked Mike to cite justification for his claim on the ROS reflector
that spreading a ~50 hz signal across 3 khz using classic spread spectrum
techniques (e.g. a pseudo-random sequence) isn't spread spectrum.

 

73,

 

  Dave, AA6YQ

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On
Behalf Of Rein A
Sent: Friday, March 05, 2010 3:16 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] What is SS?

 

  

Hello All,

I have been trying to understand from the very beginning of this
circus what the real problem was and where I could read about it,
from 3d independant sources.

Jose the programmer has done a poor job in pinning down the core
of the problem.

Here is a reprint that for my limited mental capacities defines
the core quite well.

I have asked Mike the author for some references, no lack of trust
though.

In my searches on the internet I had seen pieces directing to Mike's
arguments but never connected the dots.

After checking with Mike N4QLB, he has been able to hear me on
ROS with a couple of hundred mW, he allowed me to post it here.

-

> -Original Message-
> >From: n4qlb 
> >Sent: Mar 5, 2010 1:15 PM
> >To: rosdigitalmodemgr...@yahoogroups.com
<mailto:ROSDIGITALMODEMGROUP%40yahoogroups.com> 
> >Subject: [ROSDIGITALMODEMGROUP] Re: How do you like ROS Now?
> >
> >Thank You for your comments Sig. Let me explain what SS is. Spread
spectrum is a method by which a bank of channels (Frequencies)are designated
between a Transmitter and Receiver and are shared or (Frequency Hopped) to
facilitate a clear Transmisson. The Transmitter actually signals the
Receiver to Hop from one frequency to another. A good example is a 900mhz
digital cordless telephone or a 800Mhz digital radio truncking system.
(Motorla Astro). A frequency in Ham radio consist of a 3kh wide channel. Ros
does not signal a receiver to hop outside of that channel (3 Khz) therefore
it is not SS and is just like anyother FSK mode used in the amatuer radio
service. The ease of obtaining a License in the U.S. by people that are not
technically qualified to hold one is the main culprit regarding the
controversy over new modes such as ROS. I am confident that all variations
of ROS are perfectly legal in the U.S.
> >
> >Mike
> >N4QLB

--

Hope this is a positive contribution to the ongoing discussions.

73 Rein W6SZ

RE: [digitalradio] Re: Statement on Withdrawal of Support for ROS (K3UK Sked Pages)

[Dave AA6YQ]

>>>AA6YQ comments below

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On 
Behalf Of J. Moen
Sent: Friday, March 05, 2010 10:11 PM
To: digitalradio@yahoogroups.com
Subject: RE: [digitalradio] Re: Statement on Withdrawal of Support for ROS 
(K3UK Sked Pages)

 

  

Dave,

You make good points, and you've already hugely contributed and continue
to contribute to Ham Radio, so I don't mean to question you. 

>>>The fact that I write free software for the amateur community doesn’t mean 
>>>my posts are beyond question. I make mistakes just like everyone else does, 
>>>and don’t mind being called on them.

But if the FCC agent does not consider us Hams a bunch of squabbling children, I
guess we are lucky. We sure look that way to me. I am deeply
disappointed about this ROS affair. The major parties in the conflict
did not conduct themselves well. 

As a citizen of the US, it is embarassing the FCC rules don't take
bandwidth into account when defining what modes are legal on what bands,
and they don't, as you point out, technically define spread spectrum. 
This probably does not look good to most of the rest of the ham radio
world. 

But given the FCC's statement about each amateur radio operator being
responsbile for determining what a mode is and where, therefore, it can
be legally operated, I suspect the ham community in the US would have
been better off letting each amateur make that determination. I don't
think it was wise to immediately contact FCC and ask them, given the
givens. This is usually true in every general situation like this,
until all the facts can be gathered. 

At the same time, we have to admit that the author or ROS, similar to
FCC's lack of clarity in their rules, has not technically defined ROS
very well so far. I hope that changes.

Overall, these past weeks have not been amateur radio's finest hours.

>>>It has been a bit of a perfect storm: attractive new mode, described as 
>>>spread spectrum by its developer, US hams unable to use spread spectrum on 
>>>HF, but no clear definition of what constitutes spread spectrum.

   73,

Dave, AA6YQ

 

 

 

RE: [digitalradio] Re: ARRL/FCC Announcement about ROS

[Dave AA6YQ]

Rein, why don’t you call Dawn (FCC agent 3820) and ask her why the FCC chose to 
communicate through the ARRL; the  phone number has been posted in previous 
messages here, but I’ll dig it back up if needed.

 

73,

 

Dave, AA6YQ

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On 
Behalf Of rein...@ix.netcom.com
Sent: Friday, March 05, 2010 12:18 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: ARRL/FCC Announcement about ROS

 

  

Hi Trevor.

In my opinion, your points are very well taken.

It appears to me strange, at best, that an US federal branch is 
using an hobby club with a membership ratio of some 50 % of 
the total US population to communicate via thatclub matters 
of law.

Even with the 50 % membership, the percentage of members 
following the day in and out operations is much lower.

I can imagine perhaps one reason that this has not happened,
a lack of resources at the Federal Communication Commission
though that seems to be unlikely. 

The FCC has very effective ways to communicate with us, if
need be,

I am a member of the ARRL and have been that for 40 years.

73 Rein W6SZ


-Original Message-
>From: "Trevor ." mailto:m5aka%40yahoo.co.uk> >
>Sent: Mar 5, 2010 5:13 AM
>To: digitalradio@yahoogroups.com <mailto:digitalradio%40yahoogroups.com> 
>Subject: Re: [digitalradio] Re: ARRL/FCC Announcement about ROS
>
>All the ARRL announcement really does is reference the FCC statement of Feb. 
>23. 
>
>That statement said the FCC was not going to say if it considered ROS to be 
>spread spectrum. Individual operators were the ones responsible for making a 
>decision. 
>
>The FCC has never said ROS is "illegal" nor have the ARRL. 
>
>I've had a trawl through the FCC site but couldn't find a definition there of 
>what they mean by the words "Spread Spectrum" and it's their definition that 
>matters not other peoples. 
>
>If the FCC were concerned about the use of ROS on HF you would have thought 
>they would have written to at least one of the US stations that they had 
>observed using it and informed them of a breach of regulations. I am not aware 
>that they have done so. 
>
>73 Trevor M5AKA
>
>
>
> 
>
>
>
>
>Try Hamspots, PSKreporter, and K3UK Sked Page 
>http://www.obriensweb.com/skedpskr4.html
>Suggesting calling frequencies: Modes <500Hz 3583,7073,14073,18103, 
>21073,24923, 28123 . Wider modes e.g. Olivia 32/1000, ROS16, ALE: 14109.7088.
>Yahoo! Groups Links
>
>
>

RE: [digitalradio] FCC on "ROS" post on ARRL website!

[Dave AA6YQ]

>>>AA6YQ comments below.

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On 
Behalf Of Dave Ackrill
Sent: Friday, March 05, 2010 3:14 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] FCC on "ROS" post on ARRL website!

 

  

Dave AA6YQ wrote:

However the source of this proof would have to come from someone other than the 
ROS developer, who now has no credibility with the FCC whatsoever.

Is that what the FCC said, or is that just your opinion, Dave?

>>>My opinion, Dave. My posts have been explicit when attributing comments or 
>>>positions to FCC personnel.

 Dave

RE: [digitalradio] FCC on "ROS" post on ARRL website!

[Dave AA6YQ]

The FCC said

" 'ROS' is viewed as 'spread spectrum,' and the creator of the system describes 
it as that. We assume that he knows what he created."

This is unequivocal.

However, the FCC also says

"The Commission does not determine if a particular mode 'truly' represents 
spread spectrum as it is defined in the rules. The licensee of the station 
transmitting the emission is responsible for determining that the operation of 
the station complies with the rules."

Thus if someone were to convince the FCC that ROS is in fact not spread 
spectrum, then ROS could be used on HF by US operators. However the source of 
this proof would have to come from someone other than the ROS developer, who 
now has no credibility with the FCC whatsoever.

 73,

 Dave, AA6YQ


-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on 
Behalf Of Rik van Riel
Sent: Thursday, March 04, 2010 5:54 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] FCC on "ROS" post on ARRL website!


  
On 03/04/2010 02:02 PM, Alan wrote:
> http://www.arrl.org/news/stories/2010/03/04/11377/?nc=1
> So we can forget about here in the US...too bad it looked really nice...73, 
> Alan

I don't read it like that.

The FCC just says that:
1) spread spectrum is not allowed on HF, and
2) The Commission does not determine if a particular mode
'truly' represents spread spectrum, and
3) The licensee of the station transmitting the emission is
responsible for determining that the operation of the
station complies with the rules.

Once Jose publishes a full specification for ROS (one that
is complete enough to create an interoperable alternative
implementation), US hams will be able to make the technical
determination that the FCC requires us to make.

Until then, there is no way to be sure whether or not ROS
is legal to use in the US. We simply do not have enough
info to make the determination.

I expect that cautious US hams will avoid ROS until there
is certainty that ROS is in fact legal.

-- 
All rights reversed.

RE: [digitalradio] Re: Statement on Withdrawal of Support for ROS (K3UK Sked Pages)

[Dave AA6YQ]

I disagree. We are required to determine whether a mode is legal before
using it. The author initially described ROS as being spread spectrum. Part
97 precludes the use of spread spectrum on HF, but gives no clear definition
of spread spectrum. The FCC bears responsibility for this lack of clarity,
and so cannot blame amateurs who seek their help in determining whether ROS
is legal on HF. They do work for us, after all.

In my conversation with Dawn (FCC agent 3820), there was not a whiff of "why
are you guys annoying us with this nonsense?". She wasn't happy about having
her words publicly twisted into "ROS is legal on HF", though.

 73,

  Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of J. Moen
Sent: Wednesday, March 03, 2010 1:04 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: Statement on Withdrawal of Support for ROS
(K3UK Sked Pages)




"And think real hard next time before calling the FCC. Ham radio was the
net loser in this episode. We are already viewed as squabbling children
at the FCC, and this type of episode just reinforces that view of
amateur radio."

AMEN.

   Jim - K6JM

  - Original Message -
  From: Alan Barrow
  To: digitalradio@yahoogroups.com
  Sent: Wednesday, March 03, 2010 8:06 AM
  Subject: Re: [digitalradio] Re: Statement on Withdrawal of Support for ROS
(K3UK Sked Pages)



  pd4u_dares wrote:
  > ... considering legal action ... has an apparent plan ... may have
understandably frustrated Jose
  >

  I really have mixed feelings about how this all played out as well.
  While I don't agree with ban lists, I can see where the software author
  could get very frustrated at what could be perceived as an attempt to
  get a new mode banned.

  My observation is that when an "arms length" ham goes to the ARRL/FCC
  with an "is this legal" it nearly always results in a "at first glance
  we do not think so". Historically, this is nearly always done by people
  opposed to the new mode, and looking to see it banned.

  Having seen this happen more than once, and having detailed information
  on two of those cases, it's the wrong way to handle such a query, even
  if done in good faith.

  And like most times this occurs, with more detail, and maybe a bit more
  objective presentation (like making it clear it's ssb bandwidth with an
  audio sample), the FCC Input is reversed. (it was never a decision, just
  an opinion based on the facts at hand)

  In this particular case it's made much worse by the sparse, poor wording
  in the fcc regs.

  The issue was not that ROS technically used SS type techniques. Or even
  could clearly be called SS using the ITU definition.

  Instead, the core issue was: "did ROS behave like traditional SS in a
  way that would cause interference and thus was banned under 220 mhz. "
  And the answer to that is clearly no. It behaves like many other
  AFSK'ish modes that use an SSB bandwidth. Other legal modes use
  randomization in a way that by very strict interpretation could be
  called SS. Had it hopped across 100khz, using vco rf stages, it'd
  clearly be illegal.

  Personally, I think it's unfair to compare to the other authors, as they
  have never had such a (real or perceived) attack on their software, the
  product of many hours of work. And we had cross language/culture issues
  at play here as well. This was not an "I don't like it", or "it does not
  work well", all authors have to deal with that. It was a "we don't think
  it should be used" debate. And much more personal and at risk.

  So my view is that we should all learn from this, put the swords back in
  the scabbards, and not alienate someone who took the time to create
  something innovative, and made it available for use. For free.

  And think real net loser hard next time before calling the FCC. Ham radio
was the
  in this episode. We are already viewed as squabbling children
  at the FCC, and this type of episode just reinforces that view of
  amateur radio.

  Sincerely,

  Alan
  km4ba

[digitalradio] RE: ROS

[Dave AA6YQ]

For the record, I have no problem with the ROS mode whatsoever. Soon after
its announcement, I emailed the developer offering interoperation with
DXLab -- an offer that stands.

Developing a great new mode or application does not entitle one to threaten,
belittle, or mock those who respond with scathing criticism, much less those
who simply ask questions. I strongly disagree with attempts to position
legitimate concerns about ROS legality on the part of US amateurs as
evidence of a bias against innovation in amateur radio. In response to such
a claim on the ROS reflector yesterday, I posted the message below.

73,

Dave, AA6YQ


From: rosdigitalmodemgr...@yahoogroups.com

On Behalf Of Dave AA6YQ

Sent: Tuesday, March 02, 2010 4:08 PM

To: rosdigitalmodemgr...@yahoogroups.com Subject:

RE: [ROSDIGITALMODEMGROUP] Experimentation and Amateur Radio



1. The author publicly described ROS as spread spectrum



2. Hams in the US are required to determine whether a mode is legal in the
US before using it



3. In the US, spread spectrum is not legal on HF bands



#1 was an egregious technical error. A engineer making a mistake of this
magnitude should exhibit contrition and patience, not belligerance and
outrage. Threatening legal action against a ham attempting in good faith to
fulfil obligation #2 was far outside the spirit of amateur radio -- and from
a legal perspective, ridiculous. Framing the amateur community's reaction as
"anti-innovation" is disingenuous; we've seen many new digital modes from
all quarters over the years, and none produced anything close to this
situation.



Had the author correctly described ROS from the outset, or had he
forthrightly corrected his error without lashing out at everyone who sought
to understand what technology ROS actually employs so they could confidently
use this attractive new mode, this teapot tempest would never have occurred.



You reap what you sow.

    73,

   Dave, AA6YQ

[digitalradio] ROS

[Dave AA6YQ]

Earlier this morning, I called the FCC to confirm the "FCC: ROS LEGAL IN
USA" assertion made in

<http://rosmodem.wordpress.com/>

I asked for confirmation that the FCC had deemed ROS legal for use on HF by
US amateurs. When asked for a case number, I provided the case number given
on the above web page -- but was informed that this case number refers to a
"password reset" request, not ROS. I asked if I could speak with agent 3820,
and was immediately connected; her name is Dawn. I gave Dawn the above URL,
and read her the salient paragraph. She said that the information about ROS
legality posted on the above web site was not accurate. Dawn went on to say
that FCC staff members were working on this issue, and asked me to not make
public comments until further progress had been made. She offered to call me
at that time.

Dawn called me a few minutes ago, and stated that FCC staff consider the
information on the above web page to be out of context and misleading. She
further stated that FCC staff is working with the ARRL on this issue, and
that the outcome will be publicized by the ARRL. Dawn expects this to happen
soon; there is nothing related to ROS posted on <http://www.arrl.org/> as of
a few minutes ago.

Note that all telephone conversations with FCC personnel are recorded.

73,

 Dave, AA6YQ

RE: [digitalradio] Calculating CPU use for multiple applications?

[Dave AA6YQ]

my pleasure, Rick.

   73,

   Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on 
Behalf Of Rick Westerfield
Sent: Monday, March 01, 2010 9:11 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Calculating CPU use for multiple applications?


  

Hello Dave,


  This is awesome. A real keeper of an e-mail. I am not in the market for a 
computer but this is still excellent knowledge to have and I do not have to buy 
a bunch of magazines or join another Yahoo group to get it.


Again, thank you.


Rick - KH2DF

Sent from my iPhone

On Feb 28, 2010, at 9:10 PM, "Dave AA6YQ"  wrote:




  CPU "capability" is but one set of dimensions (clock speed, instruction issue 
rate, cache size, cache organization) in a multi-dimensional problem that 
includes motherboard capabilities (CPU-memory interface, GPU organization and 
interface, memory organization and speed), disk capabilities (rotational 
latency, track-to-track seek time, transfer rate), and Windows configuration 
(settings on "Performance Options" window's Advanced tab, and a bunch more 
accessible via a Registry Editor).

  If you monitor the excellent FlexRadio reflector, you'll see how challenging 
it is to "compute" a hardware configuration for optimized for just one 
application; building and evaluating multiple configurations was required to 
find the "sweet spot". Computing an optimal configuration to host 12 
applications is hopeless; this requires the application of general principles, 
not a spreadsheet.

  The most critical decision should be made up front: do all of the 
applications you need run correctly in a 64-bit environment? If so, then plan 
on building a 64-bit system (Windows 7, if your applications will all run there 
correctly); I wouldn't choose a motherboard that supports less than 16 GB of 
RAM, but you can start out by populating it with 2GB or 4GB as your budget 
allows (don't start with an initial increment that's would have to be discarded 
to utilize the maximum memory capacity, however). A 64-bit operating system 
does reduce the choice of serial port interfaces; see

  <http://www.dxlabsuite.com/dxlabwiki/Win7VistaHardware>

  As far as I know, none of the applications on your list can exploit more than 
one processor core, so you should choose a dual-core processor (Windows will 
run on one core, and your applications will compete for the second core); if 
PhotoShop were on you list, you'd reach a different conclusion. Spend some time 
on Intel's and AMD's web sites looking at the desktop processor comparison 
charts, e.g.

  <http://www.intel.com/consumer/products/processors/corei7-specs.htm>

  Dvorak's old rule of "third best" is a good starting point, as companies 
charge big premiums for their most-powerful CPUs. CPU selection should also 
consider cache size and architecture (bigger, with more sets is better). Also 
don't buy a CPU built with an older production process. From Intel, you want 32 
nm lithography, not 45 nm; smaller transistors run faster and generate less 
heat.

  In choosing a GPU, pick one that offloads all graphics processing, and will 
handle the screen resolution you'll likely be using over the next couple of 
years (taking multiple monitors into account, if that's a possibility). This 
will be an add-in card that can later be upgraded, so tradeoffs can be made. 
Alternatively, you can save some money by starting with the GPU from your 
current PC, assuming its above the bar and will run under the new PC's version 
of Windows.

  With hard drives, its tempting to buy the biggest disk you can afford, but 
those spacious 1+TB drives are relatively slow, and a PC with one hard drive is 
slower than a PC with two hard drives. If you can, go with two hard drives - a 
~100 GB device with fast track-to-track times and low rotational latency to 
host the operating system, and a larger slower drive for your applications and 
data. Western Digital's Velociraptor family is a good candidate for the 
small/fast C: drive; you could consider a solid state "drive" for this role, 
but I have no personal experience with them. Choose a motherboard that supports 
a 3 GB SATA interface, and choose hard drives that exploit this interface. 
Again, you can save some money up front by starting with your current PC's hard 
drive in your new system, and upgrade later.

  All DXLab applications run correctly under 64-bit XP, Vista, and Windows 7.

   73,

   Dave, AA6YQ


  -Original Message-
  From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on 
Behalf Of Andy obrien
  Sent: Sunday, February 28, 2010 7:17 PM
  To: digitalradio
  Subject: [digitalradio] Calculating CPU use for multiple applications?



  I like to multitask, and I am gree

RE: [digitalradio] Calculating CPU use for multiple applications?

[Dave AA6YQ]

CPU "capability" is but one set of dimensions (clock speed, instruction
issue rate, cache size, cache organization) in a multi-dimensional problem
that includes motherboard capabilities (CPU-memory interface, GPU
organization and interface, memory organization and speed), disk
capabilities (rotational latency, track-to-track seek time, transfer rate),
and Windows configuration (settings on "Performance Options" window's
Advanced tab, and a bunch more accessible via a Registry Editor).

If you monitor the excellent FlexRadio reflector, you'll see how challenging
it is to "compute" a hardware configuration for optimized for just one
application; building and evaluating multiple configurations was required to
find the "sweet spot". Computing an optimal configuration to host 12
applications is hopeless; this requires the application of general
principles, not a spreadsheet.

The most critical decision should be made up front: do all of the
applications you need run correctly in a 64-bit environment? If so, then
plan on building a 64-bit system (Windows 7, if your applications will all
run there correctly); I wouldn't choose a motherboard that supports less
than 16 GB of RAM, but you can start out by populating it with 2GB or 4GB as
your budget allows (don't start with an initial increment that's would have
to be discarded to utilize the maximum memory capacity, however). A 64-bit
operating system does reduce the choice of serial port interfaces; see

<http://www.dxlabsuite.com/dxlabwiki/Win7VistaHardware>

As far as I know, none of the applications on your list can exploit more
than one processor core, so you should choose a dual-core processor (Windows
will run on one core, and your applications will compete for the second
core); if PhotoShop were on you list, you'd reach a different conclusion.
Spend some time on Intel's and AMD's web sites looking at the desktop
processor comparison charts, e.g.

<http://www.intel.com/consumer/products/processors/corei7-specs.htm>

Dvorak's old rule of "third best" is a good starting point, as companies
charge big premiums for their most-powerful CPUs. CPU selection should also
consider cache size and architecture (bigger, with more sets is better).
Also don't buy a CPU built with an older production process. From Intel, you
want 32 nm lithography, not 45 nm; smaller transistors run faster and
generate less heat.

In choosing a GPU, pick one that offloads all graphics processing, and will
handle the screen resolution you'll likely be using over the next couple of
years (taking multiple monitors into account, if that's a possibility). This
will be an add-in card that can later be upgraded, so tradeoffs can be made.
Alternatively, you can save some money by starting with the GPU from your
current PC, assuming its above the bar and will run under the new PC's
version of Windows.

With hard drives, its tempting to buy the biggest disk you can afford, but
those spacious 1+TB drives are relatively slow, and a PC with one hard drive
is slower than a PC with two hard drives. If you can, go with two hard
drives - a ~100 GB device with fast track-to-track times and low rotational
latency to host the operating system, and a larger slower drive for your
applications and data. Western Digital's Velociraptor family is a good
candidate for the small/fast C: drive; you could consider a solid state
"drive" for this role, but I have no personal experience with them. Choose a
motherboard that supports a 3 GB SATA interface, and choose hard drives that
exploit this interface. Again, you can save some money up front by starting
with your current PC's hard drive in your new system, and upgrade later.

All DXLab applications run correctly under 64-bit XP, Vista, and Windows 7.

 73,

 Dave, AA6YQ


-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Andy obrien
Sent: Sunday, February 28, 2010 7:17 PM
To: digitalradio
Subject: [digitalradio] Calculating CPU use for multiple applications?



I like to multitask, and I am greedy... I like to keep an eye on
several things at once. I am thinking about a better PC, one with
enough CPU capability to run many tasks at the same time. Is there a
way to calculate the total CPU demands of severall applications. Here
is a list of what I often run at the same time (or wish i could)

Commander (or HRD)
Winwarbler (or Multipsk)
DX Keeper
Spotcollector
Pathfinder
DX View
Weather Watcher
Firefox
Spectravue or SDR-RADIO Console
Fldigi
WSJT/JT65-HF
Dimension 4

Andy K3UK

RE: [digitalradio] Re: PSK SPOTS in DXLAB

[Dave AA6YQ]

>>>AA6YQ comments below
-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Alan Barrow
Sent: Tuesday, February 23, 2010 11:57 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: PSK SPOTS in DXLAB



obrienaj wrote:
> Thanks Dave, Although I use Winwarbler and Spot Collector a lot, I have
never really tried clicking on PSK31 spots . I will have to give that a try.
Very useful. I wonder if this is the only application that does work well
with PSK31 spots?
>

The issue is not generating spots, it's the fact that very few psk spots
are done in a fashion that when clicked, you are on the frequency &
decoding.

I use DXLabs, great program (Thanks Dave!). I suspect if all used dxlabs
we would not have this problem.

But it appears that different programs spot the psk in different
fashions. Some do an exact frequency spot, others a base frequency plus
an offset (+1k) in the note, etc.

This would be an opportunity for someone to develop a standard approach
& align. But if dx4win, and logger32 don't do it, you'll miss most of
the dx'ers.

>>>Users of these applications could request that PSK spot generation be
automated to post the correct frequency (rig frequency +/- audio offset).

Likewise, some of us use multipsk, and other digi programs instead of
the suite program. So it needs to play in that regard as well.

I see roughly a ten percent success rate clicking on psk spots, with
rtty & sstv being in the high 90% range.

I don't lose sleep over this problem, but I have hardcore contester &
dxer friends (yes, I admit it) who like psk, but never use it for dx.
And that's the reason when asked. And based on my experience, it's an
opportunity for standardization.


 >>>During my occasional holiday-style DX operations, the primary impediment
to using PSK has been the slow QSO rate caused by macro-itis.


It needs to be a dial frequency type thing, not a "get close & hunt" if
you want to see more psk usage by that crowd. But there's another side
of it. I kindof like not having contesters & major dx chasers on
psk! Maybe not being clickable is a good thing?

>>>Broadband decoding has the potential of making pileups much more
efficient. XF4DL made ~1000 PSK QSOs (out of 58K total) over the course of
10 days; perhaps Juergen DL8LE can share his perspective.

 73,

Dave, AA6YQ

RE: [digitalradio] BREAKING NEWS. ARRL: ROS is SS and NOT legal on HF in USA

[Dave AA6YQ]

You were right, Skip.

   73,

   Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com
[mailto:digitalra...@yahoogroups.com]on Behalf Of Andy obrien
Sent: Tuesday, February 23, 2010 11:53 AM
To: 30...@yahoogroups.com; digitalradio
Subject: [digitalradio] BREAKING NEWS. ARRL: ROS is SS and NOT legal on
HF in USA


FYI
From: Henderson, Dan N1ND
Subject: RE: Spread Spectrum
To: "Carol & Fred deleted for privacy.
Date: Tuesday, February 23, 2010, 7:13 AM

Hi Fred:

I ran this by our technical experts.  They concur that ROS is a spread
spectrum mode and as such is not allowed by the FCC on bands below 222
MHz.  Remember that approved emissions vary from IARU Region at times
as well as between countries.  So while the IARU Band Plan for Region
2 would allow it, SS is not permitted on the HF bands by the FCC/

Thanks and 73


Dan Henderson, N1ND
Regulatory Information Manager
ARRL, the national association for Amateur Radio™
860-594-0236
dhender...@arrl.org




Try Hamspots, PSKreporter, and K3UK Sked Page
http://www.obriensweb.com/skedpskr4.html
Yahoo! Groups Links



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.730 / Virus Database: 271.1.1/2704 - Release Date: 02/23/10
02:34:00





Try Hamspots, PSKreporter, and K3UK Sked Page 
http://www.obriensweb.com/skedpskr4.html
Suggesting calling frequencies: Modes <500Hz 3583,7073,14073,18103, 
21073,24923, 28123 .  Wider modes e.g. Olivia 32/1000, ROS16, ALE: 14109.7088.
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/digitalradio/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/digitalradio/join
(Yahoo! ID required)

<*> To change settings via email:
digitalradio-dig...@yahoogroups.com 
digitalradio-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
digitalradio-unsubscr...@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

RE: [digitalradio] PSK SPOTS

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Andy obrien
Sent: Monday, February 22, 2010 9:56 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] PSK SPOTS



That is a good point, Alan.  Now that i think about it, you would think that
after 10 years we would have come up with a point and click method.

>>>In WinWarbler, one click in the waterfall selects a PSK signal, and one
click of the Spot button generates an outgoing spot (via SpotCollector).

>>>Double-clicking a PSK Spot Database Entry in SpotCollector directs
WinWarbler or MultiPSK to immediately begin decoding the spotted station,
QSYing the transceiver as required to achieve the specified optimal offset.
Alternatively, one can click a plotted DX spot on DXView's World Map or
click a DX spot on Commander's bandspread to accomplish the same result.

>>>WinWarbler's broadband decoder continuously identifies active PSK QSOs
within the receiver bandpass, listing the decoded callsigns in its "Stations
Heard" window. Optionally, these callsigns can be inserted into
SpotCollector's Spot Database, where they are color coded for "need" with
respect to the user's award objectives and award progress, dynamically
obtained from DXKeeper. Thus its straightforward to identify needed PSK DX.

>>>These capabilities have been in broad use by DXLab users for many years.

73,

   Dave, AA6YQ

RE: [digitalradio] Re: Curious sound card modes question -

[Dave AA6YQ]

re "PSK31 accomplishes the same typing speed in a bandwidth of 31 Hz,
instead of in 2000 Hz, so ROS is probably truly spread-spectrum."

Applying this logic to RTTY, which employs ~10X the bandwidth employed by
PSK31, would lead us to conclude that RTTY is also spread spectrum.

73,

Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of KH6TY
Sent: Monday, February 22, 2010 8:30 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: Curious sound card modes question -



It will be spread spectrum if the tone frequencies are controlled by a code
as explained in the ROS documentation:

"A system is defined to be a spread-spectrum system if it fulfills the
following requirements:
1. The signal occupies a bandwidth much in excess of the minimum bandwidth
necessary to send the information.
2. Spreading is accomplished by means of a spreading signal, often called a
code signal, which is independent of the data.
3. At the receiver, despreading (recovering the original data) is
accomplished by the correlation of the received spread signal with a
synchronized replica of the spreading signal used to spread the information.
Standard modulation schemes as frequency modulation and pulse code
modulation also spread the spectrum of an information signal, but they do
not qualify as spread-spectrum systems since they do not satisfy all the
conditions outlined above.

Note that all three conditions must be met to be considered spread spectrum.
I don;t know if it would be possible to send the data in less bandwidth,
but, for example, PSK31 accomplishes the same typing speed in a bandwidth of
31 Hz, instead of in 2000 Hz, so ROS is probably truly spread-spectrum.

Remember that spread spectrum was conceived as a way of coding transmissions
so they could not be intercepted and decoded. In fact actress Hedy Lamarr
invented spread spectrum, and you can read that here:
http://en.wikipedia.org/wiki/Hedy_Lamarr.  The difference is the use of a
code to spread the data and signals to avoid detection and monitoring by
those without the same code.

Download the documentation from www. rosmodem.wordpress.com and read about
spread spectrum and the ROS implementation. That will make it clear I think.
Remembering that a single tone creates a single RF carrier makes it easy to
see how just about anything can be done with tones, including sending data
over several tones at once so if one carrier is lost, others carry the same
data, or using a psuedo-random code to determine the carrier frequencies, as
I think is done in ROS.

That documentation also explains the difference between FHSS and modes like
MFSK16.  However, a main point is that the data does not have to be
scattered over such a wide bandwidth to achieve communication, but ROS does,
so it qualifies as spread spectrum.

If you have a receive bandwith of 10,000 Hz, and you spread over that
bandwidth, you really are using way more bandwidth than necessary to send
the same data at a given speed. MT63 uses 64 carriers with the data divided
among the carriers for redundancy and about 40% of the signal can be
obilterated by QRM and still produce good copy. I think the difference with
ROS is that the carrier frequencies are varied according to a code, instead
of being at a fixed position, but I am no expert on modes, so someone else
can probably explain it better and with more accuracy.

Generally it is qualifies as spread spectrum if a code is used for the
spreading, and in military communications (and even cell phones, I think)
the code prevents anyone else from reconstructing the signal so that the
intelligence can be recovered if they do not possess the same code.


73 - Skip KH6TY



John wrote:

  Thanks Skip,

  Unfortunately, this really does not get to the crux of my question(s). I
understand how an SSB transmitter works, but that is not really what I am
after.

  What I am driving at is if like this. If I use DM780 to run some version
of digital mode via an SSB transceiver, it uses a tone or series of tone
modulation/shifting to create the output of the transmitter, and not one
single mode is called "spread spectrum" output, but is called FSK or PSK,
etc. Now, we get into the aforementioned discussion regarding ROS, and
suddenly, still via the microphone input of the same transmitter, those
shifted frequencies are now called "spread spectrum" instead. I am having a
great deal of difficulty understanding, other than the author happened to
call his scheme "spread spectrum" in his technical documentation.

  Thanks 

  John
  KE5HAM

  --- In digitalradio@yahoogroups.com, KH6TY  wrote:
  >
  > John,
  >
  > Given sufficient carrier suppression, any tone inputed to the microphone
  > makes the transmitter output a pure RF carrier at a frequency of the
  > suppressed carrier frequency plus the tone frequency for USB, or

RE: [digitalradio] Winlink and Regulation by Bandwidth

[Dave AA6YQ]

The issue is not the protocol, but rather automatic operation without a busy 
frequency detector. An operator invokes a remote automatic station, whose 
subsequent transmissions QRM an ongoing QSO that the operator doesn't hear (but 
would hear clearly if he or she were monitoring the remote station's receiver). 
Participants in the ongoing QSO have no way convey "QRL" to the automatic 
station.

   73,

Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on 
Behalf Of John B. Stephensen
Sent: Monday, February 22, 2010 3:47 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Winlink and Regulation by Bandwidth


  
 

Pactor was FSK with a 100% duty cycle (or peak to average power ratio - PAPR), 
but Pactor-III is OFDM which has a PAPR similar to SSB and much less than SSB 
with RF clipping so I don't see how its any worse than digital voice or SSTV. 
Were the two stations in the automated segments fighting or just transferring 
data in both directions? I just don't see the threat from automated Pactor 
stations as they are legal on every amateur frequency outside the U.S. and they 
haven't taken over there.

73,

John
KD6OZH

  - Original Message - 
  From: KH6TY 
  To: digitalradio@yahoogroups.com 
  Sent: Monday, February 22, 2010 00:04 UTC
  Subject: Re: [digitalradio] A closer look at ROS]]

  John,

  The principle of regulation by bandwidth that was fostered by Winlink through 
the ARRL was that any mode would be allowed in a particular segment of 
bandwidths as long as the bandwidth was the same or similar. No restriction on 
content or operating methods.This would have meant that the messaging stations 
would have full access to all of the phone bands with no restrictions. For 
example, Pactor-III which has about 100% duty cycle (modulation), compared to 
30% average for uncompressed phone, could easily displace any phone QSO and the 
phone operator would not even be able to identify the interfering station 
because he would not be operating Pactor-III. The result would have been 
dominance by messaging systems with no place left to have phone QSO's without 
the possiblity of being interfered with by an automatic messaging station. 
Messaging stations are run with ARQ so they fear competition of their own kind 
and you can often see two automatic stations battling automatically for a 
frequency. As a result they want to spread out over the band as much as 
possible to avoid interference from each other instead of sharing frequencies 
on a first-come-first-served basis like everyone else.

RE: [digitalradio] A closer look at ROS]]

[Dave AA6YQ]

The amendment you cite below was part of a desperate, last-minute attempt to 
salvage RM-11306. A month after filing this amendment, the ARRL retracted 
RM-11306 in its entirely.

73,

 Dave, AA6YQ

   
-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on 
Behalf Of John B. Stephensen
Sent: Sunday, February 21, 2010 6:44 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] A closer look at ROS]]


  
 

The final ARRL petition didn't change the rules in 97.221 for automatic 
stations:
APPENDIX A – AMENDED March 22, 2007

PROPOSED RULE CHANGES

Part 97 of Chapter I of Title 47 of the Code of Federal Regulation is proposed 
to be amended as follows:

Section 97.3(a)(8) is amended to read as follows:

(8) Bandwidth. For a given class of emission, the width of the frequency band 
which is just sufficient to ensure the transmission of information at the rate 
and with the quality required under specified conditions (See the definition of 
Necessary Bandwidth in Section 2.1 of this Chapter and Section 97.101(a) of 
this Part). 

Section 97.3(a)(42) is amended to read as follows:

(42) Spurious Emission. For the purposes of this Part, emission on a frequency 
or frequencies which are outside the allocated frequency band and which may be 
reduced without affecting the corresponding transmission of information. 
Spurious emissions include harmonic emissions, parasitic emissions, 
intermodulation products and frequency conversion products.

Section 97.119 is amended to read as follows:  

§ 97.119  Station identification.

*

(b)…

(1)  By a CW or MCW emission. When keyed by an automatic device used only for 
identification, the speed must not exceed 20 words per minute;

(2)  Where phone emissions are permitted, by a phone emission in the English 
language. Use of a standard phonetic alphabet as an aid for correct station 
identification is encouraged;

(3)  By the same emission as used for the communication.

(4)  (Deleted)



Section 97.305 is amended to read as follows:

§ 97.305  Authorized emission types.

*

(b) A station may transmit a test emission on any frequency authorized to the 
control operator for brief periods for experimental purposes. Test 
transmissions are authorized in the segments 51-54 MHz, 144.1-148.0 MHz and on 
all bands above 222 MHz.

(c) Pulse emissions are permitted on all bands authorized to the control 
operator above 902 MHz except in the 23 cm and 3 cm bands.

(d) SS emissions are permitted on all bands authorized to the control operator 
above 222 MHz.
(e) A station may transmit the following emission types on the frequencies 
indicated, as authorized to the control operator, subject to the standards 
specified in § 97.307(f) of this part; except that on frequencies below 28.0 
MHz, a Station having a control operator holding a Novice Class or Technician 
Class operator license may only transmit a CW emission using the international 
Morse code. 


  Wavelength band  Frequencies
 Emission Types Authorized
 Standards, see §97.307(f), paragraph:
 
  MF:
 
 
 
 
  160 m
 Entire band
 RTTY, data
 (3)
 
  -do-
 -do-
 Phone, image
 (1), (2)
 
  HF:
 
 
 
 
  80 m
 Entire band
 RTTY, data
 (3)
 
  75 m
 Entire band
 Phone, image
 (1), (2)
 
  40 m
 7.000-7.125 MHz
 RTTY, data
 (3)
 
  40 m
 7.075-7.100 MHz
 Phone, image
 (1), (2), (4)
 
  40 m
 7.125-7.300 MHz
 Phone, image
 (1), (2)
 
  30 m
 Entire band
 RTTY, data
 (3)
 
  20 m
 14.00-14.15 MHz
 RTTY, data
 (3)
 
  -do-
 14.15-14.35 MHz
 Phone, image
 (1), (2)
 
  17 m
 18.068-18.110 MHz
 RTTY, data
 (3)
 
  -do-
 18.110-18.168 MHz
 Phone, image
 (1), (2)
 
  15 m
 21.0-21.2 MHz
 RTTY, data
 (3) 
 
  -do-
 21.20-21.45 MHz
 Phone, image
 (1), (2)
 
  12 m
 24.89-24.93 MHz
 RTTY, data
 (3)
 
  -do-
 24.93-24.99 MHz
 Phone, image
 (1), (2)
 



(f) Except as otherwise provided in this Section, a station may transmit any 
emission on any frequency authorized to the control operator subject to the 
following bandwidth limitations:

  Wavelength
  band
 Frequencies authorized
 Maximum bandwidth
 Standards 
  See §97.307(f) paragraph:
 
  10 m
 28.00-28.05 MHz
 200 Hz
 
 
  -do-
 28.05-28.120 MHz
 500 Hz
 
 
  -do-
 28.120-29.0 MHz
 3 kHz
 (5) 
 
  -do-
 29.0-29.7 MHz
 16 kHz
 
 
  6 m
 50.0-50.1 MHz
 200 Hz
 
 
  -do-
 50.1-50.3 MHz
 3 kHz
 
 
  -do-
 50.3-54 MHz
 100 kHz
 
 
  2 m
 144.0-144.1 MHz
 2

RE: [digitalradio] A closer look at ROS]]

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on 
Behalf Of John B. Stephensen
Sent: Sunday, February 21, 2010 6:14 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] A closer look at ROS]]


  
 

The current restrictions on automatic stations can stay in place with 
regulation by bandwidth so this shouln't be an impediment.

>>>In the ARRL's proposal to regulate by bandwidth (RM-11306), the current 
>>>restrictions on semi-automatic stations would have been eliminated. This and 
>>>other aspects of the ARRL's proposal generated a large negative reaction, 
>>>which resulted in the ARRL retracting its proposal before the FCC acted upon 
>>>it.

   73,

   Dave, AA6YQ

RE: [digitalradio] Multipsk- CPU tests with SDR-IQ Direct active.

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Patrick Lindecker
Sent: Sunday, January 31, 2010 5:30 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Multipsk- CPU tests with SDR-IQ Direct active.




Hello Tony,

>Would it be possible for me to run the SDR feature without actually having
and SDR rig attached? If so, how can I activate it?
The SDR feature in Multipsk is only doing a I/Q processing, shifting in base
band, in USB or LSB, a selected band (inside the 48, 96 or 192 KHz SdR
band).

Now as I discovered, thanks to Andy, is that professional SdR are controlled
through a defined protocol, something as a Cat system protocol.

Perhaps, Dave (AA6YQ) will add, in the future, through Commander, the
necessary commands to control the different SdR...

 >>>Commander has long been able to control PowerSDR. If you send me the
protocols you need supported, Patrick, I will extend Commander to support
them.

 73,

  Dave, AA6YQ

RE: [digitalradio] Future of ALE and HF Link.

[Dave AA6YQ]

Re "the control is to prevent ALE bashing"

 

Across a broad range of technical offerings, organizations that actively
solicit criticism and respond constructively tend to flourish, whereas
organizations focused on protecting their baby often fail to gain traction,
despite expending a comparable amount of energy. The "open" approach
motivates users to help - in reporting defects, suggesting enhancements, and
spreading the word - and naturally leads to a enthusiastic user community.
The defensive approach drives off everyone but the true believers; only
something incredibly valuable can survive this.

 

   73,

 

Dave, AA6YQ

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On
Behalf Of Andy obrien
Sent: Sunday, January 24, 2010 8:24 PM
To: digitalradio; alera...@yahoogroups.com
Subject: [digitalradio] Future of ALE and HF Link.

 

  

I have decided that I will not be a part of HF Link, in the formal
sense. Many members of the Yahoo group HFlink have been helpful over
the years and Steve especially has been of tremendous help to all.
However, I have concluded that the rigid control and moderation of
that group, have contributed to the failure of ALE to take hold as an
effective method of amateur radio communication. Despite years of
efforts, ALE remains perhaps the least used method of ham radio
contact management, and is regularly used by less than 75 hams
world-wide. I know of no other amateur radio method that is dependent
solely on one group , and that one group has such prohibitive
practices that it essentially dictates terms. The copyright policy of
the HF Link group is directly contributing to a lack of openness that
is rarely seen in the amateur radio world. PSK and digital modes
have many organizations and email lists, CW has lots of groups,
SSB-phone a zillion clubs, RACES/ARES accepts a wider choices of
systems, weak signals modes like JT65A have varying groups, but ALE on
hams bands remains centralized via HF link. Winmor has tight control
on the software but is generally open to input and openly allows
dissent. ALE should be allowed to flourish in an "open market" where
hams take the idea and help it evolve and succeed. Steve and Charles
Brain have made huge contributions but the warehousing of it via HF
link have reduced it to a little understood concept . I will continue
to use ALE both PC-ALE and Multipsk . but no longer associate with HF
Link. I have raised this matter before , and have received
constructive comments the suggest that the "control" is to prevent
"ALE bashing" . I think that there is not a lot to "bash" about
ALE...it is a very effective system, However the protectionism
exhibited by HF Link has harmed ALE more than the occasional ALE
bashing would ever do. So, the problems of "busy detect" and
unattended operation notwithstanding, I will remain an advocate of ALE
and hope others will help it get rid of its shackles. Heck , lets get
rid of ALE as an "emcomm " concept , it isn't really (it could be ,
one day). ALE might be more "sellable" as a DXing method or net
control software!

Andy K3UK



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.730 / Virus Database: 271.1.1/2636 - Release Date: 01/24/10
03:33:00

RE: [digitalradio] Re: Comparison of RTTY software sensitivity

[Dave AA6YQ]

MMTTY provides a choice of three different RTTY decoders, with the ability
to shape the filters for each. There is also an optional bandpass filter and
an optional notch filter, with user control of shape for each.  As a first
step in improving MMTTY's RTTY decoding performance, I am determining how to
optimize performance given the capabilities Mako-san JE3HHT has already
provided, using a setup similar to what Alex VE3NEA and Wes WZ7I  have used.

 

Note that on the chart Wes posted, WinWarbler running the HyperSensitive
profile with both the bandpass and notch filters enabled yields sensitivity
close to that of TrueTTY. WinWarbler uses MMTTY as its RTTY engine, so this
performance is possible with MMTTY alone.

 

By synchronous detection, Vojtech, do you mean treating the first start bit
as the beginning of a synchronous multi-character sequence, thereby
providing some protection against "broken" start and stop bits within that
sequence? Brian K6STI referred to his decoding technique as employing a
"flywheel", which I interpreted as a means of adjusting the synchronous
timing with high-quality start bits decoded within the sequence.

 

    73,

 

 Dave, AA6YQ

 

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On
Behalf Of Vojtech
Sent: Friday, January 22, 2010 8:27 AM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Comparison of RTTY software sensitivity

 

  

Here is another, similar chart:
http://www.dxatlas.com/RttyCompare/

I was comparing MMTTY with MultiPSK and gMFSK against RTTY in white noise.
Interesting observation was that MMTTY was better than MultiPSK at better
than marginal SNR, but MultiPSK was slightly better than MMTTY at very low
SNR. My best bet is that MMTTY is doing some kind of signal processing after
detector, which fixes some errors, but makes things worse in very low SNR.

Both yours and Alex's graphs show superiority of TrueRTTY and MixW. I wonder
whether TrueRTTY is doing synchronous detection. This is what I plan to try
when I retire, hi.

73, Vojtech OK1IAK



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.730 / Virus Database: 271.1.1/2636 - Release Date: 01/21/10
15:34:00

RE: [digitalradio] Comparison of RTTY software sensitivity

[Dave AA6YQ]

Thanks Wes.

 

WinWarbler uses MMTTY as its RTTY engine; thus MMTTY can be configured to
achieve the same performance as that shown for WinWarbler.

 

73,

 

 Dave, AA6YQ

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On
Behalf Of Wes Cosand
Sent: Wednesday, January 20, 2010 7:02 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Comparison of RTTY software sensitivity

 

  

Recently during a QSO a ham said the software I was using was not very
sensitive.  I decided I needed to collect some data to make an informed
decision about which software I should be using.  I ran several of the RTTY
software packages through the AWGN function of PathSim and used RttyCompare
to calculate the percentage of errors in the resulting text.  The data can
be found at 
http://mysite.verizon.net/wz7i/RTTY.html

This is not meant to be a polemical posting.   I may well have made less
than optimal choices in setting program parameters and I am anxious to
receive suggestions about how the testing could be improved.  Also, I am
aware that sensitivity is only one factor in choosing what communications
software to use.

Wes, WZ7I
www.wz7i.com
CW Skimmer CQ spots:  cw.wz7i.com:7300



No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.730 / Virus Database: 270.14.150/2632 - Release Date: 01/20/10
05:12:00

RE: [digitalradio] Clublogs... see standings versus others

[Dave AA6YQ]

There have been several reports on the DXLab reflector that Club Log ignores
the DXCC entity uploaded with each QSO, attempts to determine the DXCC
entity itself from its database, and sometimes gets it wrong.

   73,

Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Andy obrien
Sent: Monday, January 11, 2010 8:35 AM
To: digitalradio
Subject: [digitalradio] Clublogs... see standings versus others







-- Forwarded message --
From: Rob - G4LMW 
Date: Mon, Jan 11, 2010 at 8:26 AM
Subject: Re: [skcc] SKCC Now Listed at Clublogs... see standings versus
others
To: s...@yahoogroups.com




Thanks Andy

Can I correct the URL: http://www.clublog.org

ClubLog is a GREAT facility. The best bit is that it helps you to correct
the actual DXCC entity that you have worked. There is a massive database of
callsign sitting behind it that tells you if the VP8 that you worked was in
the Falklands or Antarctica etc.

73, Rob
G4LMW
http://www.G4LMW.co.uk

RE: [digitalradio] Nominations for 2009 Digitalradio Awards needed

[Dave AA6YQ]

Patrick, F6CTE.

 73,

   Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Andy obrien
Sent: Sunday, December 06, 2009 11:11 AM
To: digitalradio
Subject: [digitalradio] Nominations for 2009 Digitalradio Awards needed



It is that time again, as we approach our 10th January in existence
it is time to seek you nominations for the Annual Digitalradio Awards.
The 2008 winners are listed below.

Send your suggestions to me by December 30th 2009.

, I make the final determination...

Andy K3UK

--

(2008) Digitalradio Awards :

Best "new" Digital Mode : WSPR by Joe Taylor , K1JT . . Very useful
and robust super low power digital mode .

Best New Software: FL-Digi with NBEMS , great work from Dave and
Skip. The "new" aspect refers to the Windows version. Should be
standard for any RACES/ARES op. Windows version was on our wish list
for 2008, nice to see it arrive early in the year.

Best Logging Software: DX Keeper by Dave AA6YQ, , again ! Many
emails received from people again nominating this software. May have
some competition from the new logger in Ham Radio Deluxe in 2009

Biggest Surprise Of The Year:
1 . ALE. Yep, I thought it might suffer death in 2008 but users
actually increased and some interesting innovations from the folks at
HFN. ALE in Multipsk helped a lot.

2. A updated version of MixW, Nick lives!

3. Much needed new touches to MMTTY, thanks to Dave AA6YQ. MMTTY
has come a long way from the days when I wrote the first English help
file! MMTTY, Winwarbler and FSK RTTY make great "music" together.

Digital Innovations Award 2008 : Patrick Lindecker F6CTE and
Multipsk, many innovations in 2008 and plenty of unique capabilities.
The "serious app" for the digital mode enthusiast.

Biggest Disappointments Of The Year :
1. PSK31 Contests: Over driven signals makes such events
intolerable. Maybe we have this group to blame since we promoted and
organized most of the first PSK contests back when PSK31 was new.
2. The demise of Olivia as a routinely heard digital mode..
3. WSPR QSO Mode. Not much activity.

The Picaso Award: Simon Brown HB9DRV . The addition of SSTV
applications to DM780 and Satellite Tracker to Ham Radio Deluxe are
works of art.

Best Digital Mode Website : KE7HPV's Digital spotting page, now
moved to http://www.hamspots.net/30m/ . Well organized , great auto
spots system, .

Digital Mode Aid - Innovation of the Year : Philip Gladstone's PSK
Reporter . Integrated with DM780, this tool is one of the most useful
for those days when you wonder if you are getting out! Find it at
http://www.hamspots.net/30m/ or within DM780.

Experimenter Of The Year :
Tony K2MO : Still playing with digital voice and finding time to
test path simulations for all common digital modes.

Lost in 2008 Cesco HB9TLK , where is this key digital mode developer?

Oddest Mode in 2008: MFTTY . Phone freaking back in vogue?

Needs Inventing in 2009 :

1. Windows Version of PSKmail
2. New codec for FDMDV
3 Easy to use/build software based automatic over driven signal
control . PSK bands are painful to listen to !

Most Anticipated Event in 2009: Release of WINMOR

These annual awards are based on suggestions from the over 3000
members of Digitalradio , the world's leading digital mode discussion
group (http://groups.yahoo.com/group/digitalradio/ ) since 2000. The
final awards are determined by Andy K3UK

RE: [digitalradio] Digital busy detect

[Dave AA6YQ]

###AA6YQ responses below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Alan Barrow
Sent: Wednesday, November 25, 2009 8:34 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Digital busy detect



Dave AA6YQ wrote:

> +++The rules to be honored by all stations are:

> 1. if you're not yet in QSO, don't transmit on a frequency that is
> already in use (meaning that signals have been detected during the
> past 5 minutes)

> 2. if you're in QSO and signal other than that of your QSO partner
> appears (the busy frequency detector indicates the presence of signal,
> but you aren't decoding your QSO partner), wait for that signal to
> disappear, send "QRL QRL" in CW, and resume your QSO

OK so far

### Progress!


> +++Amateur radio operators have been trusting each other to mutually
> obey these rules since the service began. On what possible basis can
> you claim exemption?

Here's where it falls apart. many, many digi ops neither copy CW even to
understand QRL, or would not hear it.

### They need not copy it: they need only understand that CW in response to
a CQ in any mode means "frequency in use, please move elsewhere".

### There will be cases where asymmetry in equipment or propagation results
in a station sending CQ not being able to hear either of the stations in an
on-going QSO that are sending "QRL" in response, but this a fortunately
infrequent occurrence that cannot be addressed by any technology. The fact
that we can't prevent this is no excuse for not addresses the more common
scenario that we can mitigate; as Voltaire said, "the perfect is the enemy
of the good".

And another large percentage would not honor a QRL request, they don't in
other situations for sure.

### I don't agree that this is a large percentage now, and believe that the
amount of negative behavior would decrease as we eliminated the QRM.


> Kindof like asking all cellphone users to install a device that allows
> anyone to disable their ringtone. Just what do you think the compliance
> on that would be?
>
> +++No, its not remotely like asking cellphone users to install such a
> device; there is no parallel whatsoever.

I'd be OK if all mfg's had such a device. But to selectively enforce it  is
unworkable. IE: Multipsk, others should have similar detect & honor a   QRL
request. Recioprocity is part of being a good neighbor.

>>>MultiPSK only needs a busy frequency detector when its operating as an
unattended automatic station. Attended stations can use their ears.


+++ Only attended stations need detect the QRL; if automatic stations never
transmit on a frequency that is in use, then they will rarely QRM an ongoing
QSO, and so have no need of automatic QRL detection

This does not deal with hidden terminal,

### I disagree. If an attended station obeys rule 1, the probability that
the frequency was clear for 5 minutes before transmission and yet the
attended station's transmission will QRM an on-going QSO is very low. Within
that 5 minutes, the attended station's busy frequency detector would have
heard one of the two participants in that QSO. A collision would only occur
in the asymmetric equipment or propagation scenario.

nor does it address the cases where attended mode ops interfere with
non-attended

### I disagree. Rule 2 says that an unattended station in QSO that detects a
signal not sent by its QSO partner should send "QRL QRL" in CW. The operator
sending that signal would be governed by the "if you hear CW in response to
a CQ, the frequency is in use" principle. Barring an asymmetric scenario,
the unattended QSO would be preserved.



> +++When not in QSO, automatic stations can easily monitor the
> frequency to determine whether a QSO is in progress, even if they are
> only hearing one of the stations involved; this is easily implemented.
> If an automatic station receives a connection request and its busy
> frequency detector has seen no activity for the past 5 minutes, it can
> respond to the request without compunction. If its busy frequency
> detector has been intermittently reporting signals over the past 5
> minutes, it should not respond.

Unworkable on most auto sub-bands, there is just that much traffic. If you
held off 5 minutes for many parts of the day you'd never, ever be able
transmit.

### I have two reactions to this statement:

1. I'd like to see the statistics that back it up

2. if its true, you are acknowledging that unattended stations are QRMing a
lot of on-going QSOs

### If what you say is true, the proper solution would be to widen the auto
sub-bands; but this will only happen after its been demonstrated that
unattended automatic stations cause no more QSO breakage than good human
operators.

RE: [digitalradio] Digital busy detect

[Dave AA6YQ]

+++ AA6YQ responses below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Alan Barrow
Sent: Wednesday, November 25, 2009 8:12 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Digital busy detect


Dave AA6YQ wrote:
>
>
> To be clear, an attended station need not wait for 5 minutes of clear
> frequency before transmitting; 30 seconds of no signals (meaning no
> automatic station is QRV) followed by a "QRL?" sent "in mode" with no
> response should be sufficient.

What does "in mode" mean on shared frequencies? The interfering station
could be packet, pactor 2-3, ALE, whatever.

+++If you're about to send CQ in PSK, you send "QRL?" in PSK; if you're
about to send CQ in RTTY, you send "QRL?" in RTTY.

This concept demonstrably does not work even in attended mode ops, like   in
PSK. RTTY ops do not honor a QRL in psk, same for CW.

+++If an operator sends "QRL?" in PSK  on a frequency being used by a RTTY
QSO that he or she did not hear beforehand, one or both participants of that
RTTY QSO can ask you to move by sending "QRL QRL" in CW; the participants
don't need to know what the operator sent, they just need to respond with
"QRL QRL" in CW.

+++If an operator sends "QRL?" in PSK  on a frequency being used by an
unattended automatic station that he or she did not hear beforehand, the
automatic station will respond by sending "QRL QRL" in CW (rule #1 from my
previous post).

+++In both cases, the operator should QSY on hearing the "QRL QRL".

 Cross mode is the majority of the issue. Most of the protocols will hold
off for their mode already.

You are asking some modes to solve a problem that has not been addressed
even in attended mode. (CW x PSK, RTTY x PSK, etc)

+++ Listening for a clear frequency before transmitting "QRL?" has long been
the recommended practice before calling CQ; sending "QRL" in-mode to a
station that appears on your frequency mid-QSO is also standard practice. I
agree that there has been no concerted effort to address cross-mode
scenarios, but the use of "QRL QRL" in CW is quite straightforward. Yes,
digital ops that didn't learn CW will have to recognize this signal, though
"if you call CQ in a digital mode and hear CW in response, the frequency is
in use" is all we'd really need to broadly syndicate. As I said before, I'd
be happy to drive this effort.

   73,

Dave, AA6YQ

RE: [digitalradio] Contesters and DXers should use busy detectors

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of expeditionradio
Sent: Wednesday, November 25, 2009 4:29 AM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Contesters and DXers should use busy detectors

 All contesters and DX pileup participants should use busy detectors!

>>>All contesters and DX pileup participants *have* busy frequency
detectors: their ears.

This is quite evident since it has been proven that such types of operation
are the source of 99% of "harmful interference" and "intentional
interference" on the HF ham bands.

>>>Please provide or cite this proof.

Manual methods of busy detection have been proven to be devoid of merit.

Contesters and DX pileup technologists can start developing the "DX/Contest
Busy Detector" with SSB and PSK and RTTY and CW, the most common modes.

When they have a busy detector that is proven to work during contests and
pileups, then the remaining 1% of rare other modes and other types of
operation that are normally the recipient of "harmful interference" and
"intentional interference"   can consider adopting the tried and proven
"DX/contest Busy Detector".

The 1% "rare mode" operators should continue to use the present methods that
have proven to have a high probability of not causing harmful or intentional
interference.

Put your money where your mouth is. Develop a busy detector for
DX/contesters.

If your busy detector is successful in preventing the vast majority of
harmful and intentional interference of contests and DX pileups, then the
rest of the  ham community can widely adopt it.

>>>The above is one more instance of a bogus argument you and others have
long made: "because some contesters and DXers cause QRM, all unattended
automatic stations are entitled to cause QRM". By the same logic, you could
claim that "because some contesters and DXers splatter, all unattended
automatic stations are entitled to splatter". Or that all unattended
automatic stations are entitled to operate with 5 KW, or are entitled to
operate out of their licensed band segments.

>>>This attitude is cynical and destructive. Amateur radio involves the
shared use of limited spectrum among users with diverse interests. This has
worked through a combination of sensible rules, useful guidelines, and
generally good judgment on the part of individual operators. However, when
one group decides that their interest is superior to all others, and that
they are therefore free to ignore the rules and guidelines, the result is
chaos and frustration -- as we've seen over the past several years. You have
made it clear that you consider the use of amateur radio to make random
contacts to be archaic. That's fine; you are entitled to you use our shared
spectrum however you see fit -- as long as you obey the rules and guidelines
so that you do not prevent those with different interests and perspectives
from using that same spectrum. Deploying unattended automatic stations that
cannot determine whether or not they will QRM an on-going QSO before
transmitting is a blatant violation of our service's rules, guidelines and
ethics; justifying this behavior by arguing that some human operators
violate these rules is the antithesis of the principles underlying amateur
radio. As I'm sure you know, two wrongs do not make a right.

73,

Dave, AA6YQ

RE: [digitalradio] Digital busy detect

[Dave AA6YQ]

To be clear, an attended station need not wait for 5 minutes of clear
frequency before transmitting; 30 seconds of no signals (meaning no
automatic station is QRV) followed by a "QRL?" sent "in mode" with no
response should be sufficient.

73,

 Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Dave AA6YQ
Sent: Wednesday, November 25, 2009 2:29 AM
To: digitalradio@yahoogroups.com
Subject: RE: [digitalradio] Digital busy detect




+++ AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Alan Barrow
Sent: Tuesday, November 24, 2009 10:30 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Digital busy detect

Dave AA6YQ wrote:
>
> Its only unworkable because the implementation of the busy frequency
> detector in question is obviously quite poor.

Significantly more to it than that... unless *all* stations honor &
abide by common rules/tech, it simply won't work. This is true of just
about any network, not just radio. (remember the FRACK wars back in
packet days?)

+++The rules to be honored by all stations are:

1. if you're not yet in QSO, don't transmit on a frequency that is already
in use (meaning that signals have been detected during the past 5 minutes)

2. if you're in QSO and signal other than that of your QSO partner appears
(the busy frequency detector indicates the presence of signal, but you
aren't decoding your QSO partner), wait for that signal to disappear, send
"QRL QRL" in CW, and resume your QSO

+++There is nothing complicated about this. Automation is only required in
unattended automatic stations.


> No, an automatic station already in QSO need only respond with "QRL"
> in CW, which will be understood by the majority of attended stations.
With full respect: "Yeah, right" :-) You want me to hold off my
transmissions automatically, but trust other ops (in other modes) to do
the same. Voluntarily. Cross-mode. Right.

+++Amateur radio operators have been trusting each other to mutually obey
these rules since the service began. On what possible basis can you claim
exemption?

Kindof like asking all cellphone users to install a device that allows
anyone to disable their ringtone. Just what do you think the compliance
on that would be?

+++No, its not remotely like asking cellphone users to install such a
device; there is no parallel whatsoever.

I agree CW QRL is probably the most universal approach, but you'd have
to match the exact beat frequency of the cw sig for them to hear it. And
be able to decode CW on the fly (CWget in all busy detectors) to honor
it from others.

+++Only attended stations need detect the QRL; if automatic stations never
transmit on a frequency that is in use, then they will rarely QRM an ongoing
QSO, and so have no need of automatic QRL detection.

>
> This is rarely problem with attended stations; you might not hear one
> side of an in-progress QSO, but you will hear the other side, and be
> able to respond appropriately when the side you hear asks you to QSY.
> Only automated stations without busy frequency detectors suffer the
> vulnerability you describe here.

Only true if you listen for 1-2X the average transmission length or do a
"?" query. Voice ops do that, because it's not cross mode, and
transmission times are shorter.

Digi modes do not do that by practice (even RTTY), the transmission
times are longer, and the price of an interuptted transmission higher.
(resend)

+++When not in QSO, automatic stations can easily monitor the frequency to
determine whether a QSO is in progress, even if they are only hearing one of
the stations involved; this is easily implemented. If an automatic station
receives a connection request and its busy frequency detector has seen no
activity for the past 5 minutes, it can respond to the request without
compunction. If its busy frequency detector has been intermittently
reporting signals over the past 5 minutes, it should not respond.

And it's not rarely a problem in attended modes, I see it daily on PSK.

+++I didn't say it rarely occurs, I said its rarely a problem -- because
attended stations can communicate with each other and resolve the conflict,
thereby preserving the QSO in progress. Unattended automatic stations are
incapable of doing this.

>
> Effective multi-mode busy frequency detection has been demonstrably
> feasible for years. Had a concerted effort been made to equip all
> automatic stations with competent busy frequency detectors, the rate
> of "QSO breakage" caused by such stations would have plummeted, the
> anger caused by this QSO breakage would have dissapated, and we'd be
> efficiently sharing spectrum in the pursuit of our diverse
> objectives

RE: [digitalradio] Digital busy detect

[Dave AA6YQ]

+++ AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Alan Barrow
Sent: Tuesday, November 24, 2009 10:30 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Digital busy detect

Dave AA6YQ wrote:
>
> Its only unworkable because the implementation of the busy frequency
> detector in question is obviously quite poor.

Significantly more to it than that... unless *all* stations honor &
abide by common rules/tech, it simply won't work. This is true of just
about any network, not just radio. (remember the FRACK wars back in
packet days?)

+++The rules to be honored by all stations are:

1. if you're not yet in QSO, don't transmit on a frequency that is already
in use (meaning that signals have been detected during the past 5 minutes)

2. if you're in QSO and signal other than that of your QSO partner appears
(the busy frequency detector indicates the presence of signal, but you
aren't decoding your QSO partner), wait for that signal to disappear, send
"QRL QRL" in CW, and resume your QSO

+++There is nothing complicated about this. Automation is only required in
unattended automatic stations.


> No, an automatic station already in QSO need only respond with "QRL"
> in CW, which will be understood by the majority of attended stations.
With full respect: "Yeah, right" :-) You want me to hold off my
transmissions automatically, but trust other ops (in other modes) to do
the same. Voluntarily. Cross-mode. Right.

+++Amateur radio operators have been trusting each other to mutually obey
these rules since the service began. On what possible basis can you claim
exemption?

Kindof like asking all cellphone users to install a device that allows
anyone to disable their ringtone. Just what do you think the compliance
on that would be?

+++No, its not remotely like asking cellphone users to install such a
device; there is no parallel whatsoever.

I agree CW QRL is probably the most universal approach, but you'd have
to match the exact beat frequency of the cw sig for them to hear it. And
be able to decode CW on the fly (CWget in all busy detectors) to honor
it from others.

+++Only attended stations need detect the QRL; if automatic stations never
transmit on a frequency that is in use, then they will rarely QRM an ongoing
QSO, and so have no need of automatic QRL detection.

>
> This is rarely problem with attended stations; you might not hear one
> side of an in-progress QSO, but you will hear the other side, and be
> able to respond appropriately when the side you hear asks you to QSY.
> Only automated stations without busy frequency detectors suffer the
> vulnerability you describe here.

Only true if you listen for 1-2X the average transmission length or do a
"?" query. Voice ops do that, because it's not cross mode, and
transmission times are shorter.

Digi modes do not do that by practice (even RTTY), the transmission
times are longer, and the price of an interuptted transmission higher.
(resend)

+++When not in QSO, automatic stations can easily monitor the frequency to
determine whether a QSO is in progress, even if they are only hearing one of
the stations involved; this is easily implemented. If an automatic station
receives a connection request and its busy frequency detector has seen no
activity for the past 5 minutes, it can respond to the request without
compunction. If its busy frequency detector has been intermittently
reporting signals over the past 5 minutes, it should not respond.

And it's not rarely a problem in attended modes, I see it daily on PSK.

+++I didn't say it rarely occurs, I said its rarely a problem -- because
attended stations can communicate with each other and resolve the conflict,
thereby preserving the QSO in progress. Unattended automatic stations are
incapable of doing this.

>
> Effective multi-mode busy frequency detection has been demonstrably
> feasible for years. Had a concerted effort been made to equip all
> automatic stations with competent busy frequency detectors, the rate
> of "QSO breakage" caused by such stations would have plummeted, the
> anger caused by this QSO breakage would have dissapated, and we'd be
> efficiently sharing spectrum in the pursuit of our diverse
> objectives. Instead, we've been treated to years of blatantly lame
> excuses as to why busy frequency detection either can't be designed,
> can't be implemented, can't be deployed, won't work, causes warts,
> causes cancer, causes global warming, or will cause the universe to
> expand forever. Few are fooled by this.

OK, here's the challenge: Demonstrate it's feasibility if it's JSMOP.
Implement one that balances the right of the sending station not to be
QRM'd VS the expectation not to

RE: [digitalradio] Digital busy detect

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of WD8ARZ
Sent: Tuesday, November 24, 2009 10:06 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Digital busy detect



Scamp busy detector "as used in Scamp at the time of the group testing" I
was part of, was NOT the end all of busy detectors.

>>>Correct. It was a first attempt somewhat reluctantly taken by the author
with encouragement from me and several others.

Finding a setting of the threshold was very difficult. Too sensitive and the
throughput operation of Scamp was poor due to being held up by the threshold
trigger. Not sensitive enough and it did not perform at times when you knew
it should have. What worked for one type of band condition for awhile, did
not work well during a different type of band condition.

>>>There were quite a few more positive reports from Scamp beta testers
posted on this forum at the time.

Personally witnessed operators that would intentionally come on frequency
and put out signals solely for the purpose of triggering the busy detector
to stop operations. When Scamp operations were not active, they didnt seem
to be active on the frequency. Start Scamp activity and some of the same
lids would start up again with just enough activity to activate the busy
detector.

>>>This hardly a good reason to not move forward with a mechanism that would
reduce the ill-will responsible for these actions.

End result was the agreement to not use it as it was not living up to
expectations  and stayed that way through the shut down of the group by
the author.

>>>Scamp was terminated because the RDFT protocol on which it was based
performed poorly under typical band conditions. Rick KN6KB evidently reached
a different conclusion than you did regarding the efficacy of busy frequency
detection, as he included busy frequency detection in Winmor.

73,

   Dave, AA6YQ

RE: [digitalradio] Digital busy detect- it's not a technology issue

[Dave AA6YQ]

>>>AA6YQ comments below

-Original Message-
From: digitalradio@yahoogroups.com
[mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow
Sent: Tuesday, November 24, 2009 9:57 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Digital busy detect- it's not a technology
issue


Andy obrien wrote:
>
>
> FYI, the author of Winmor advised me that 3rd party busy detect IS part of
Winmor.

so what does it do when it's already involved in a qso, waiting to ack or
transmit, and someone starts transmitting? That's the core issue, not
detecting that a frequency is in use.

Not many options, it can:

A) backoff, and effectively abandon the frequency to the new station, even
though they are the one who QRM'd

>>>There is no reason to do this, presuming that the frequency was clear
before your QSO began


B) Try to signal the interfering station in the mode
(cw/rtty/clover/ax.25/psk/etc) that the station is using hmm, but that
assumes the station is listening, so you have to wait for that station to
stop, and try to get a break in. Meanwhile, your sending station you were
originally in qso with has timed out!

>>>Wait until the "offending" signal dissappears, send "QRL QRL" in CW, and
either initiate reconnection or await connection as dictated by the
protocol.


C) Go ahead and transmit anyway, since it was in qso already. Which will
still generate complaints, as most of the perceived qrm is really hidden
terminal issues and unintentional

>>>No, most of the perceived QRM is not the result of attended stations
breaking in on an on-going QSO in which one of the stations is automatic.
Several years ago, I monitored WinLink PMBOs with my SCS PTC-IIe. In every
case where QRM occured, it was the result of a PMBO responding to a
connection request on a frequency that was already in use.


For any of the busy detection schemes to work, all stations have to be using
it, and it would need to a universal "freq is in use" signal honored by all.

>>>No, only unattended automatic stations need include a busy frequency
detector. As suggested earlier, "QRL" is a universal "freq in use" signal
that will be honored by most attended stations. As long as an unattended
automatic station never initiates transmission on a frequency that is in
use, then it will rarely QRM an on-going QSO, and thus need not have the
means to detect a QRL sent by an attended station. The only collision
scenario that is not covered is "change in propagation", where two QSOs that
were initially sharing a frequency without interfering with each other begin
hearing each other because propagation has changed; if one of these QSOs
involves an unattended automatic station, it will by the above rules either
complete its QSO (if the QRM doesn't prevent it), or break off (if the QRM
impedes communication).


The only other alternative is for all stations/modes:

- Listen for 2X the average transmission length for the slowest mode
possibly in use on the frequency to eliminate the chance of hidden terminal.

- For most frequencies/modes, that would be CW or RTTY, so you are looking
at a listen period of a minute or more.

>>>When not in QSO, an automatic station monitors its frequency
continuously, so it very well knows whether or not another QSO is in
progress on that frequency, even if it can only copy one side of that QSO.


- Have some algorithm that factors in if you are in QSO vs just starting
a QSO

>>>Obviously.


My view: This is not a technology issue, it's an operator expectation issue.
we could have the miracle BD (busy detection) widget. But until ops in all
modes started respecting & listening for other modes, it won't work.

>>>The scheme described above is straightforward to implement and will
prevent QRM most of the time. As I pointed out to Rick KN6KB while
attempting to persuade him to implement a busy frequency detector in Scamp,
a scheme that's only 80% effective would reduce the incidence of QSOs broken
by automatic stations by a factor of 5.


Ex: The rtty guy in the middle of a qso has a cw op break in. He can't
answer in rtty, and his radio is in fsk or ssb mode. IE: He can't just send
CW to tell the interloper the freq is in use.

>>>Certainly he can; I have done so. This is easier in FSK where the
transceiver is displaying the mark frequency; digital mode apps could easily
be extended to automate this operation.


Same for RTTY/CW in psk. (even worse, due to the long psk transmissions).
Shift to ALE/Pactor, and it's even less likely that the op is setup for the
mode.

>>>Saving your PSK frequency, changing mode to CW, sending "QRL", and
returning to PSK is just not that difficult. It certainly beats losing your
PSK QSO.


So all that said, what are the odds that the homebrew cw op is going t

RE: [digitalradio] Digital busy detect

[Dave AA6YQ]

re "Problem is, just like other mode operators have found out, it's
unworkable as the majority of legal, in progress qso's will be derailed by
someone else firing up."

Its only unworkable because the implementation of the busy frequency
detector in question is obviously quite poor.

re "Since the CW op has no way to ask in ALE, PSK, whatever mode "is the
frequency in use", all they can do is interfere. so the mythical busy
detection software would have to have a way to answer back "sorry OM, the
frequency is in use" in every imaginable mode."

No, an automatic station already in QSO need only respond with "QRL" in CW,
which will be understood by the majority of attended stations.

re "Fact: Radio is vulnerable to "hidden terminal" effect like most shared
media. We live in that world. And because of that, there will be some
unintentional interference."

This is rarely  problem with attended stations; you might not hear one side
of an in-progress QSO, but you will hear the other side, and be able to
respond appropriately when the side you hear asks you to QSY. Only automated
stations without busy frequency detectors suffer the vulnerability you
describe here.

Effective multi-mode busy frequency detection has been demonstrably feasible
for years. Had a concerted effort been made to equip all automatic stations
with competent busy frequency detectors, the rate of "QSO breakage" caused
by such stations would have plummeted, the anger caused by this QSO breakage
would have dissapated, and we'd be efficiently sharing spectrum  in the
pursuit of our diverse objectives. Instead, we've been treated to years of
blatantly lame excuses as to why busy frequency detection either can't be
designed, can't be implemented, can't be deployed, won't work, causes warts,
causes cancer, causes global warming, or will cause the universe to expand
forever. Few are fooled by this.

73,

Dave, AA6YQ




-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Alan Barrow
Sent: Tuesday, November 24, 2009 8:14 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Digital busy detect



Charles Brabham wrote:
>
>
> Packet radio gets by with a simple carrier detect, PACTOR can only
> detect other PACTOR stations, and from what I can tell, ALE has no
> busy detection at all.
Absolutely not the case. ALE listen's before transmit for other ALE by
protocol. And the commonly used ham implementation has a busy detection
mode that works for rtty, carrier, and most CW. Just does OK on voice,
but that's less of an issue as any operation in the voice sub-bands are
attended.

Problem is, just like other mode operators have found out, it's
unworkable as the majority of legal, in progress qso's will be derailed
by someone else firing up. Since the CW op has no way to ask in ALE,
PSK, whatever mode "is the frequency in use", all they can do is
interfere. so the mythical busy detection software would have to have a
way to answer back "sorry OM, the frequency is in use" in every
imaginable mode.

I see this in the PSK bands by CW & RTTY ops, and happens to pretty much
any digi mode. It's not unique to ALE for sure.

Fact: Radio is vulnerable to "hidden terminal" effect like most shared
media. We live in that world. And because of that, there will be some
unintentional interference.

Regarding busy detection, I've posted youtube video's of ALE's busy
detection in action. Packet's is not the most effective, by any means.

All that said, until there is mutual respect of the digi modes right to
exist, no one will widely use the busy detection as it's too easy to
hold off or interfere with a station running it. see it happen every day
on the busy ALE frequencies, and for sure this has soured winlink on
busy detection. It's not technology, it's your fellow hams.

When I see all psk ops wait for 2 complete transmission cycles to ensure
there is no hidden terminal effect, then ask "is the frequency in use"
before transmitting I'll concede. Same for RTTY. Until then, it's just
one mode complaining about the other, and we won't see progress.

Have fun,

Alan
km4ba

[digitalradio] Re: Digital busy detect

[aa6yq]

+++ AA6YQ comments below

--- In digitalradio@yahoogroups.com, "Charles Brabham"  wrote:

If WinMore was in the public domain, you might have a point there. When the 
WinLink group deep-sixes their proprietary software, then who can use it?

>>>We are discussing what is and is not possible in the domain of busy 
>>>detection. The capabilities of Winmor's busy frequency detector are what's 
>>>relevant to this discussion, not its long-term disposition. A key result of 
>>>Scamp was the recognition that a modest, first-iteration busy frequency 
>>>detector performed remarkably well.

   73,

   Dave, AA6YQ

RE: [digitalradio] Disinformation about ALE by N5PVL Re: Getting serious about ALE / LID factor

[Dave AA6YQ]

re "So you add a magic "frequency is occupied" device to your digi mode. You
are legitimately on a frequency, in a digi qso. Yet someone who does not the
remote station (hidden) fires up, and stays fired up. At that point, your
anti-qrm tripped, and you just lost the frequency, and your qso is
terminated. "

This would only be true of an extremely naive implementation of a busy
frequency detector. The purpose of a busy frequency detector is to prevent
an unattended station from initiating a QSO (or responding to a request to
initiate a QSO) on a frequency that is already busy. If the unattended
station is already in QSO, detection of a signal other than that of its QSO
partner would not terminate the QSO.

re "Lot's of the (perceived) issue is the classic "hidden terminal" nature
of radio you may think a frequency is clear because you hear nothing,
but in fact, it's a qso in progress where you can only hear one end. You
fire up, and turns out you just stomped on someone. Happens on voice, cw,
psk, RTTY, it's equal opportunity."

Yes, this does happen, but you neglected to describe the rest of the
scenario. The "end" that you can hear says "QRL, pse QSY", and most
operators quickly oblige. In contrast, unattended automatic stations
*cannot* oblige; they blithely QRM away. An unattended station with a proper
busy frequency detector would have likely been monitoring the frequency long
enough to detect the copiable half of the QSO already in progress, and thus
would never have transmitted on the first place.

re "Happens all the time. Some versions of ALE software have reasonable busy
freq detectors. Winkink has deployed & tested busy detection. Yet in real
life it's unusable, as it pretty much derails any legit qso in progress when
other folks (cw, rtty, pactor, whatever) fire up.

The naive busy frequency detector, again.

re "And when it's been deployed in the winlink world, there has clearly been
intentional QRM to hold off the digi's"

Yes, Winlink has generated an enormous amount of ill will, to the point
where some ops have become so angry that they will waste their time QRMing
an automatic station. There is no excuse for this illegal behavior, but its
*ludicrous* to use this as an excuse to avoid eliminating the problem by
deploying busy frequency detectors. Once Winlink and other unattended
automatic stations reduce their QRM rate to something approaching that of
the average human operator, the anger will dissipate and the QRMing of
automatic stations will dissappear.

73,

 Dave, AA6YQ



-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Alan Barrow
Sent: Tuesday, November 24, 2009 7:14 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Disinformation about ALE by N5PVL Re: Getting
serious about ALE / LID factor



KH6TY wrote:
> Your prejudice is obviously showing! (Uh - long live HFlink and others
> that run unattended transmitters outside the beacon bands and transmit
> without checking for a clear frequency???)
>
With tongue in cheek: "your ignorance is showing" (in the misinformed
sense, no insult implied)

All unattended ALE operation associated with HFLINK operates solely in
the band segments set aside by the FCC for "automatic" operation,
including unattended. It's a very narrow slice in each band, and quite
full of packet BBS, winlink, and ALE. Given the huge (comparatively)
segments where narrow modes (rtty, psk, etc) are allowed that are free
from competition, I don't see just cause for complaint.

You may not like it, but it's an allowed operation mode in an allowed
band segment.

ALE activity in other portions of the band is attended mode, with the
same guidelines/recommendations for listen before transmit.

> The point Charles is making is that transmitting without listening is
> simply exceptionally inconsiderate on shared frequencies by all widely
> accepted standards of behavior, but you obviously do not get it, and I
> guess you really don't want to, do you... Simply put, "frequency
> sharing" means not using a frequency unless you have made a reasonable
> attempt to verify it is not being used. There is no technology yet
> implemented that makes this possible for an unattended station.
So help me out, how does the repeated rtty transmissions in contest
weekends handle this? I see 100x the examples of xmit without listening
during rtty contests then all the semi-auto modes put together?

Lot's of the (perceived) issue is the classic "hidden terminal" nature
of radio you may think a frequency is clear because you hear
nothing, but in fact, it's a qso in progress where you can only hear one
end. You fire up, and turns out you just stomped on someone. Happens on
voice, cw, psk, RTT

RE: [digitalradio] Digital busy detect

[Dave AA6YQ]

I am fully aware of WinLink's political tactics, but the topic of this
thread is busy frequency detection. Independently of why it might have been
developed, the busy frequency detector in Scamp surprised many with its
effectiveness, including its own developer. I'm assuming that Winmor's busy
frequency detector is a descendent of Scamp's, as both were developed by
Rick KN6KB. Hold your nose if you must, but I suggest that you evaluate
Winmor's busy frequency detector before making additional claims about what
is and is not possible.

    73,

   Dave, AA6YQ


-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Charles Brabham
Sent: Tuesday, November 24, 2009 7:36 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Digital busy detect




I knew one of the hams who first envisioned what would later end up being
SCAMP, followed its development with interest, and was thoroughly disgusted
at the way the WinLink group used those efforts as a cheap propaganda ploy
instead of pursuing it honestly. SCAMP was at no point intended by the
WinLink group to see actual use, its development was stretched out and used
as a talking point for political purposes. As soon as its utility for that
purpose became unsupportable, it was uncerimoniously killed.

At no point did the WinLink group intend to phase out the use of the SCS
harmful interference mills. This still holds true today.

WinMore is just one more SCAMP, unfortunately. Knowing the level of
character and intelligence to be found in the WinLink group, I have not
followed WinMore's development. - I already know it's fate. After stretching
out its supposed development for as long as possible, milking it for
political traction ( We are working on ending our widespread inteference -
honest! ) there will come the inevitable point where it is reluctantly
admitted that WinMore just cannot do the job nearly as well as PACTOR III
and then all of a sudden, you won't hear anything more about WinMore.

The thing that the ARRL, the FCC, and all amateurs should understand is that
WinLink will never be reformed. They hope to become so thoroughly
established with delaying tactics like SCAMP and WinMore that eventually the
FCC will throw up their hands and award them private spectrum of their own,
or re-write PART97 so that we no longer enjoy the use of shared spectrum,
thus bringing amateur radio to an end. They want a channelized, CB-like
environment and the ARRL, to its discredit, is behind them 100%.

As was the case with city and county entities forcing thier employees to get
ham tickets as they pursued DHS grant money, and eventually starting to eye
amateur radio spectrum as something to lobby for the possession of, our only
real hope for a good outcome in this case is for the FCC to step in. We
cannot hope for help or support from the ARRL, which again is part of the
problem.

So no, I have not followed WinMore's development at all, since I already
know its fate. Note how WinMore is not open source but is strictly
proprietary to the WinLink group, just like SCAMP was. They will be using
this control to be sure that it is not developed further or used for any
other purpose by anyone else. When they decide to kill it, they will want it
to stay dead. - Just as dead as SCAMP is today.


73 DE Charles Brabham, N5PVL

Prefer to use radio for your amateur radio communications? - Stop by at
HamRadioNet.Org !

http://www.hamradionet.org


  ----- Original Message -
  From: Dave AA6YQ
  To: digitalradio@yahoogroups.com
  Sent: Monday, November 23, 2009 10:50 PM
  Subject: RE: [digitalradio] Digital busy detect




  Did you evaluate the busy frequency detector in Scamp, Charles?

  Have you evaluated the busy frequency detector in Winmor?

  73,

  Dave, AA6YQ

  -Original Message-
  From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Charles Brabham
  Sent: Monday, November 23, 2009 9:55 PM
  To: digitalradio@yahoogroups.com
  Subject: [digitalradio] Digital busy detect




  Packet radio gets by with a simple carrier detect, PACTOR can only detect
other PACTOR stations, and from what I can tell, ALE has no busy detection
at all.

  Several years ago I took a serious look at automated busy detection, and
always ran across the same stone wall:

  A more sophisticated busy detect that can usually tell the difference
between noise and a human activity like speech or digital transmissions is
possible - BUT - only after the software has a fairly long audio sample to
work with, and can look back upon that sample.

  It can't do this instantly, or even very quickly unless you have a
supercomputer to work with.

  If it listens to a long sample and a new signal comes in toward the end of
that sample, that new signal may or may not end up being identified.

  This is a terrible thing to have to report, but

[digitalradio] Re: Ham HF networking digital communication systems

[aa6yq]

Despite your vigorous attempt below to paint this issue as "old vs new", it's 
simply a conflict between good engineering and bad engineering. Include a 
competent busy frequency detector in your automatic station design, and 
opposition to such stations will disappear. 

If you really believe that your approach merits the assignment of amateur 
frequencies for your exclusive use, then go convince the FCC and IARU to 
allocate them. In the mean time, kindly refrain from QRMing ongoing QSOs when 
you operate on frequencies that we all share.

   73,

   Dave, AA6YQ

--- In digitalradio@yahoogroups.com, "expeditionradio"  
wrote:
>
> There are anti-automatic and negative-hams who 
> would like to hold digital ham radio back in the 
> same tired olde structure of "brass pounding nets" 
> and "CQ random contacts" and bulletin boards of 
> the 20th century. 
> 
> But the facts of the matter are, that the old 
> nets based upon manual monitoring and manual 
> message-passing and even "logging in to check messages"  
> are not up to the standards of modern communications. 
> 
> The only way for ham radio to stay relevant in 
> today's world and in the future, is to keep moving 
> forward with new methods of interfacing ham networks 
> with the world's digital communication systems. 
> 
> For those hams who are still living in the past, 
> possibly they would rather not open their eyes to see 
> the reality of what our service has become these days... 
> The number of active hams on HF is dwindling. Except 
> for weekend (contests) or evening (80m ragchews in 
> the major population areas), in many areas of the 
> world you can tune through several megahertz of 
> HF ham spectrum without copying many strong signals. 
> 
> The fact that HF ham bands are not crowded, is not 
> completely due to the low solar cycle. It is partly 
> the result of the HF active ham radio population dying off. 
> 
> We have not attracted new younger hams to HF because the 
> older hams have literally pushed away the young hams 
> with bad attitude and lack of vision and enthusiasm 
> for the future of technological progress. As one 
> example, for the critical years in the last decade 
> of the 20th century, we showed our contempt for a 
> new generation of hams by putting up the obstacle of 
> morse code testing. But this isn't about the dead 
> issue of morse code testing... what young person 
> wants to be a part of a dying technology?
> 
> We, as hams and radio experimenters and communicators and 
> emergency volunteers should be wholeheartedly embracing 
> all the new and wonderful ways that we can make more 
> interesting connections with people and communication 
> technology. There is more variety in digital communication 
> systems these days than there ever has been in history.  
> 
> How can we continue to bring HF ham radio into 
> the future of communication? I can tell you for sure 
> that it won't be with the olde ham formula of calling CQ,  
> random calling, or round-table nets. 
> 
> From our mobile phone, we can instantly call a friend 
> on their mobile phone in a distant part of the world, 
> and it will ring... Can you do the same thing with 
> your ham radio? 
> 
> If you are an HF Emcomm operator, can you make an 
> emergency call, day or night, without prior notice 
> or schedule, and get the message through? If the 
> answer is yes, then what if 50 hams were trying to 
> send an HF emcomm message at same time? Could you still 
> get the message through?
> 
> These are just foundation examples, the basic minimum 
> that we need to be able to do as hams, in order to 
> be relevant in today's world of communications. There 
> is so much more that can be done. It's an exciting 
> world, we can be a vibrant part of it, or we can long 
> for the good ole days before cell phones when an HT 
> on your belt was impressive. It's our choice. 
> There are so many possibilities for new inventions 
> and techniques to be developed in ham radio  
> digital networking. It's our future. 
> 
> Bonnie VR2/KQ6XA
> 
> "That's the news. If you don't like the news, 
> go out and make some of your own." 
> --Scoop Nisker, Radio Newscaster
>

RE: [digitalradio] Digital busy detect

[Dave AA6YQ]

Did you evaluate the busy frequency detector in Scamp, Charles?

Have you evaluated the busy frequency detector in Winmor?

73,

Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Charles Brabham
Sent: Monday, November 23, 2009 9:55 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Digital busy detect




Packet radio gets by with a simple carrier detect, PACTOR can only detect
other PACTOR stations, and from what I can tell, ALE has no busy detection
at all.

Several years ago I took a serious look at automated busy detection, and
always ran across the same stone wall:

A more sophisticated busy detect that can usually tell the difference
between noise and a human activity like speech or digital transmissions is
possible - BUT - only after the software has a fairly long audio sample to
work with, and can look back upon that sample.

It can't do this instantly, or even very quickly unless you have a
supercomputer to work with.

If it listens to a long sample and a new signal comes in toward the end of
that sample, that new signal may or may not end up being identified.

This is a terrible thing to have to report, but Packet's carrier detect is
the most effective and sophisticated automatic signal detection scheme we
currently have at our disposal. - It detects more kinds of activity *right
then* than anything else that hams are currently using.

There are lots of signals that carrier detect will not detect - but it is
still the best thing out there, that can automatically detect and act in (
more or less ) real-time.

The human ear works better, detecting signal intelligence and
differentiating it from noise far better than any automated detection
system. Period.

Better still is the human eye, looking at a properly set up waterfall
display that will show you recognizable patterns in the waterfall image that
you may not be able to register just by listening.

One thing to ponder is why carrier detect, developed over twenty-five years
ago is not utilized by PACTOR or ALE, both allegedly more advanced than
Packet. My feeling on this is that if they cannot detect signals as well as
Packet does, then which mode is more advanced, more suitible for use on the
ham bands?

That is really an unfair question in the case of PACTOR III and ALE, niether
one of which was designed or ever intended for use within shared amateur
radio spectrum, in the first place. It is not the square peg's fault that it
will not fit in the round hole.

In the end, if we are not operating an automated station, then a waterfall
display in combination with speaker audio is the most effective and useful
busy detection system we have at our disposal, and this will almost
certainly continue to be the case for a very long time.

For real-time automated busy detection, carrier detect is highly likely to
be the best thing at our disposal - again for a very long time.

The Reed-Soloman ID system is a great step ahead for digital operation. It
is not really useful as a real-time busy-detect, but it does give us a first
step on something that may eventually take us there. As standards and
hardware evolve over the years, we may eventually embed information into our
data streams that can be instantly recognized as 'busy' by our software. -
It may even approach the speed of carrier detect, and work with all modes.

But don't hold your breath, it's not right around the corner.


73 DE Charles Brabham, N5PVL

Prefer to use radio for your amateur radio communications? - Stop by at
HamRadioNet.Org !

http://www.hamradionet.org

RE: [digitalradio] Dx pile ups..

[Dave AA6YQ]

In a DX pileup, calling on the same frequency that someone else is calling
generally results in neither of you getting through, particularly if you are
using a digital mode. The idea is to

1. understand the range of frequencies in which the DX station is listening

2. crop your callsign into a "hole" in this range so that it will more
likely be heard clearly

In lighter pileups, the DX station may exhibit a pattern  -- .e.g. moving up
500 hz after each RTTY QSO. Astute DXers learn this pattern, anticipate the
next frequency, and call there. However, this only works when there aren't
too many astute DXers. Spectrum scopes have made it much easier to rapidly
detect such patterns, turning the anticipated next frequency into a zoo. As
a result, many DX stations have abandoned the pattern method; instead, they
randomly look for stations in the clear across the range in which they are
operating.

No DXer should participate in a pileup if doing so would QRM an ongoing QSO.
In my experience, politely asking the participants in the ongoing QSO to
move almost always yields a polite and positive response.

   73,

Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of obrienaj
Sent: Monday, November 23, 2009 9:17 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Dx pile ups..



Bonnie said

"the same goes for "DX pileups". Basically, a pileup
is simply a contest where the number of possible contacts
is 1 and the number of possible multipliers is 1.

Everyone who enters the pileup contest is trying to
out-QRM the other entrants, or in FCC parlance...
"to harmfully interfere with", the other contestants
in the pileup contest. They are trying to keep the other
stations from working the target station, in favor of
themselves. Louder, stronger, QRMer."

Surely Bonnie is correct in this? Not ALL DXers , but the vast majority are
doing what Bonnie describes when responding to a QRZ. If I hear " P5DX
QRZ?", then I hear "November Seven Delta..." starting a call and throw in
"Kilo Three Uniform Kilo" on top of the 7 station (Danny) , Bonnie is
correct that I have QRM'd him. I guess the difference is that this is
accepted and actually encouraged.

I still remember my utter shock when a new ham reading the ARRL handbook
about DXing, and how a DX station would listen on incrementally different
QRG and NOT tell you exactly where. The book explained that the "art" of
DXing was to determine the DX station's methods and skillfully figure out
where he would be listening. In Bonnie's context, this would be encouraging
lots of QRM .

Skip's earlier point would be that this still differs from "unattendned"
transmissions but I think Bonnie's point is that the result is not that much
difference. Cue Bonnie with comments about goose and gander...

Andy K3UK

[digitalradio] Re: HF International Automatic Subbands

[aa6yq]

My recollection is that the discussions leading to the creation of the 
automatic sub-bands included expressions of the same concerns that continue to 
surface here: an operator in California who activates an unattended station in 
Denver can't know that the unattended station will QRM an ongoing QSO between 
stations in Chicago and Dallas because the operator in California hears neither 
of those stations. The FCC's solution to this problem was to

1. remind amateurs that they are expected to solve technical problems like this 
one

2. confine automatic operation above a specified baud rate to the "automatic 
sub-bands"

As has been pointed out here too many times, viable busy frequency detectors 
have indeed been developed, but they have unfortunately not been widely 
deployed. Perhaps Winmor will user in a new age of enlightenment. 

Your ALE setup is automatic, but its only unattended if its operating while you 
aren't in control.

 73,

 Dave, AA6YQ



--- In digitalradio@yahoogroups.com, Andy obrien  wrote:
>
> > When there's no emergency underway, however, the "automatic bands" are 
> > available to all amateur stations, not just unattended stations. Its no 
> > more acceptable for unattended stations to QRM ongoing QSOs in the 
> > "automatic bands" than it is to QRM them anywhere else within the amateur 
> > spectrum.
> >
> > 73,
> >
> > Dave, AA6YQ
> >
> 
> 
> Excuse me for being so dumb, Dave...  what is the purpose for allowing
> "unattended" stations in a specific part of a band if they have to
> listen to make sure a frequency is clear?  I don't "get it".  Also, am
> I wrong in thinking  that "unattended versus "automatic" means the
> same thing?
> 
> 
> Hmm, in thinking back to the days that all this may have started,
> packet days,   I remember that my TNC would not transmit a packet if
> the TNC detected another station, it would wait a second or two.  is
> this the difference , that unattended with busy detect is fine ?
> 
> Andy K3UK
>

[digitalradio] Re: HF International Automatic Subbands

[aa6yq]

During an emergency, no one has a problem ceding frequencies to emcomm 
stations; its like heading for the shoulder when you hear an ambulance while 
driving.

When there's no emergency underway, however, the "automatic bands" are 
available to all amateur stations, not just unattended stations. Its no more 
acceptable for unattended stations to QRM ongoing QSOs in the "automatic bands" 
than it is to QRM them anywhere else within the amateur spectrum.

   73,

   Dave, AA6YQ

--- In digitalradio@yahoogroups.com, "expeditionradio"  
wrote:
>
> > I would also like the ALE and digital community to 
> > recognise that they share the bands with everyone else  
> > Dave (G0DJA) 
> 
> Hi Dave,
> 
> While I can't speak for the whole "digital community", 
> I can probably speak with some authority for 
> the "ALE community"... 
> 
> ALE operators have been sharing the ham bands 
> for many many years without harmful interference. 
> This is primarily due to the way that ALE has been 
> adapted to amateur radio by hams, a protocol adaption 
> known as "ham-friendly ALE". 
> 
> 99% of ALE operation is in organised emcomm networks 
> and 99% of the organised networks are operating in the 
> internationally recogised HF automatic sub-bands, 
> where automatic modes have been in use for many years. 
> 
> 73 Bonnie VR2/KQ6XA
>

[digitalradio] Re: Moderator comments : Listen-Don't listen

[aa6yq]

Bonnie your argument is "some contesters and DXers QRM ongoing QSOs, so 
therefore its ok for ALL unattended stations to QRM ongoing QSOs. This is poor 
engineering; when we automate things, the idea is to automate good practice, 
not bad practice. You don't see anyone designing autopilots that can become 
disoriented, do you?

And by the way, most DXers in a pileup do not seek to QRM each other, as that 
guarantees they won't be clearly heard by the DX -- even when using a powerful 
station. The idea is to seek clear spots in the pileup into which to drop your 
call so you can more likely be heard by the DX. This is particularly true in 
digital mode pileups.

73,

Dave, AA6YQ

--- In digitalradio@yahoogroups.com, "expeditionradio"  
wrote:
>
> > Skip KH6TY wrote:
> > A contester who calls CQ Contest is usually doing 
> > it on a frequency that is clear at the moment 
> 
> Hi Skip,
> 
> What planet do you live on?  :)
> I want to live there in that mythical land, 
> where all contesters get to transmit on 
> "clear frequencies". 
> 
> Don't get me wrong, I am not "anti contest", in 
> fact, far from it. I was once a very active 
> and avid contester. 
> 
> From experience, I can say without any doubt that 
> successful contesting primarily boils down to 
> who can QRM better and talk over top of all the 
> other stations better. That is why the most successful 
> contesters use high-powered amplifiers and large 
> antenna arrays. 
> 
> The same goes for "DX pileups". Basically, a pileup 
> is simply a contest where the number of possible contacts 
> is 1 and the number of possible multipliers is 1. 
> 
> Everyone who enters the pileup contest is trying to 
> out-QRM the other entrants, or in FCC parlance... 
> "to harmfully interfere with", the other contestants 
> in the pileup contest. They are trying to keep the other 
> stations from working the target station, in favor of 
> themselves. Louder, stronger, QRMer.
> 
> Anyone who has listened or participated in 
> contests knows that there will be QRM generated 
> by the contest, and QRM/interference is 
> "just all part of the game".
> 
> In fact, when you think about it, really... living 
> with QRM and interference is part of life on HF. 
> 
> Bonnie VR2/KQ6XA
>

[digitalradio] Kurzweil on exponential progress

[aa6yq]

<http://www.youtube.com/watch?v=qRDqvnPfIfc&feature=player_embedded> 

In this presentation, Kurzweil refers to Cooper's Law. We're familiar with (and 
daily enjoy the benefits of) Moore's Law, which predicts an exponential 
increase in the number of transistors that can be placed on an integrated 
circuit, progress that began in the early 1970s: 

<http://en.wikipedia.org/wiki/Moore's_law> 

Cooper's Law predicts an exponential increase in the number of "conversations" 
(voice or data) that can theoretically be conducted over a given area in all of 
the useful radio spectrum, a progression that began with Marconi in the early 
1900's: 

<http://www.arraycomm.com/serve.php?page=Cooper> 

Martin Cooper was the lead engineer of the Motorola team that developed the 
handheld mobile phone.

73,

Dave, AA6YQ

RE: [digitalradio] Re: Why would anyone

[Dave AA6YQ]

I agree that there were positive aspects to the ARRL's "regulation by
bandwidth" proposal. However, expanding the range of frequencies available
to unattended stations without including a requirement that they verify
their frequency to be clear before transmitting was a showstopper, in my
opinion.

73,

   Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of John B. Stephensen
Sent: Friday, October 30, 2009 11:47 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: Why would anyone



I  meant any frequency where RTTY/data is allowed. The objection that people
had then seems to be that a wider bandwidth was allowed for semi-automatic
stations in the proposed 3 kHz bandwidth segments.

However, the proposed rules would have pushed the wideband semi-automatic
stations up in frequency and out of the areas where people were complaining
of interference to narrowband RTTY/data QSOs. They also allowed RTTY/data
QSOs to occur anywhere in the band which would seem to provide even more
flexibility to avoid interference. I liked this feature of the proposal.

73,

John
KD6OZH

  - Original Message -
  From: Dave AA6YQ
  To: digitalradio@yahoogroups.com
  Sent: Friday, October 30, 2009 08:54 UTC
  Subject: RE: [digitalradio] Re: Why would anyone




  Your assertion below that current rules allow an automatic station to
operate on any frequency is incorrect. See §97.221

  http://www.arrl.org/FandES/field/regulations/news/part97/c.html#221

  With a bandwidth of 500 hz or less, such stations can can only operate
wherever RTTY or data emissions are authorized.

  With a bandwidth of more than 500 hz, such stations are limited to the
sub-bands enumerated in §97.221(b).

  73,

    Dave, AA6YQ


  -Original Message-
  From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of John B. Stephensen
  Sent: Friday, October 30, 2009 4:30 AM
  To: digitalradio@yahoogroups.com
  Subject: Re: [digitalradio] Re: Why would anyone



  I just reread it and it seems to be more restrictive than the current
rules.
  The current rules establish segments for automatic forwarding between
  digital stations on all HF bands and these were eliminated below 28 MHz in
  the ARRL proposal. The current rules allow for an automatic station that
  only responds to queries by a manually-controlled station to operate on
any
  frequency and that was unchanged in the ARRL proposal.

  73,

  John
  KD6OZH

  - Original Message -
  From: Dave AA6YQ
  To: digitalradio@yahoogroups.com
  Sent: Friday, October 30, 2009 07:48 UTC
  Subject: RE: [digitalradio] Re: Why would anyone

  Had the ARRL's "regulation by bandwidth" proposal been accepted, the range
  of frequencies available to automatic stations without busy frequency
  detectors would have significantly increased, which was why so many
amateurs
  opposed it, which was why the ARRL abandoned it.

  73,

  Dave, AA6YQ

RE: [digitalradio] Re: Why would anyone

[Dave AA6YQ]

Your assertion below that current rules allow an automatic station to
operate on any frequency is incorrect. See §97.221

http://www.arrl.org/FandES/field/regulations/news/part97/c.html#221

With a bandwidth of 500 hz or less, such stations can can only operate
wherever RTTY or data emissions are authorized.

With a bandwidth of more than 500 hz, such stations are limited to the
sub-bands enumerated in §97.221(b).

73,

  Dave, AA6YQ


-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of John B. Stephensen
Sent: Friday, October 30, 2009 4:30 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: Why would anyone


  I just reread it and it seems to be more restrictive than the current
rules.
The current rules establish segments for automatic forwarding between
digital stations on all HF bands and these were eliminated below 28 MHz in
the ARRL proposal. The current rules allow for an automatic station that
only responds to queries by a manually-controlled station to operate on any
frequency and that was unchanged in the ARRL proposal.

73,

John
KD6OZH

- Original Message -
From: Dave AA6YQ
To: digitalradio@yahoogroups.com
Sent: Friday, October 30, 2009 07:48 UTC
Subject: RE: [digitalradio] Re: Why would anyone

Had the ARRL's "regulation by bandwidth" proposal been accepted, the range
of frequencies available to automatic stations without busy frequency
detectors would have significantly increased, which was why so many amateurs
opposed it, which was why the ARRL abandoned it.

73,

Dave, AA6YQ

RE: [digitalradio] Re: Why would anyone

[Dave AA6YQ]

Had the ARRL's "regulation by bandwidth" proposal been accepted, the range
of frequencies available to automatic stations without busy frequency
detectors would have significantly increased, which was why so many amateurs
opposed it, which was why the ARRL abandoned it.

73,

 Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of John B. Stephensen
Sent: Friday, October 30, 2009 2:43 AM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: Why would anyone


  The FCC could make part 97 more understandable if they adopted regulation
by
bandwidth but that effort died. EZPal on 14.233-14.237 MHz is OK as there
are very few restrictions on image transmission.

73,

John
KD6OZH

- Original Message -
From: John
To: digitalradio@yahoogroups.com
Sent: Friday, October 30, 2009 02:21 UTC
Subject: [digitalradio] Re: Why would anyone

So sorry John .

of course you are right .

we were supposed to have read and understood the contents of part 97 .

I guess I must have forgotten the part that demanded we also memorize it
verbatim with all it's technical terms and specs. I must be the one to admit
it, I am the one that forgot some pieces of it 

could you remind me again about where that rule was located?  HiHi

In all seriousness, I was simply trying to illustrate a point that seemed to
be misleading in the discussion. As I read the discussion, and indeed I
could have missed some posts, but it appeared some were alluding that the
maximum baud rate was 300 PERIOD, which as you have so expertly pointed out
is quite untrue .

Thank you for the clarification, however these limits still seem to fly in
the face of such things as EZPal and a few others, especially when operating
on customary HF frequencies around 20 meters (14.233 - 14.237 khz) 

Thanks again

RE: [digitalradio] Throught of a Digital Propagation Tool

[Dave AA6YQ]

In the post below, the sentence

"The PropView component will also generate graphical propagation forecasts
using the VOACAP or ICEPAC engines, and use the beacon network to calibrate
these forecasts."

should have been

"The PropView component will also generate graphical propagation forecasts
using the VOACAP or ICEPAC engines; you can use the beacon network to
calibrate these forecasts."

Automatically calibrating propagation forecasts based on actual beacon
signal strength is not yet available...

73,

 Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Dave AA6YQ
Sent: Tuesday, October 20, 2009 10:00 PM
To: digitalradio@yahoogroups.com
Subject: RE: [digitalradio] Throught of a Digital Propagation Tool



The is a worldwide network of 18 beacons operated by the Northern California
DX Foundation and the International Amateur Radio Union on 5 HF bands from
20m through 10m:

<http://www.ncdxf.org/beacons.html>

At the moment, the beacons in Russia and Sri Lanka are down due to hardware
problems; repairs are underway.

Each beacon transmits for 10 seconds, giving its callsign in CW followed by
four dashes: the first at 100 watts, the second at 10 watts, the third at 1
watt, and the fourth at 100 milliwatts:

<<http://www.ncdxf.org/beacon/beaconschedule.html>

By monitoring a beacon frequency for 3 minutes, you can assess actual
propagation from your QTH on that band. Alternatively, you can construct a
beacon schedule to quickly determine what bands are open to a particular
area of the world from your QTH. Syncing your PC's time-of-day clock with an
internet-accessible time service is recommended.

The freeware DXLab Suite's PropView component lets you specify a set of
beacons you wish to monitor and will direct the Commander component to QSY
your transceiver to monitor them. You can select beacons individually, by
band, or by bearing (octant) from your QTH. The PropView component will also
generate graphical propagation forecasts using the VOACAP or ICEPAC engines,
and use the beacon network to calibrate these forecasts. See

<http://www.dxlabsuite.com/propview/>

A list of other tools that can be used to monitor NCDXF/IARU beacons is
provided in

<http://www.ncdxf.org/beacon/beaconprograms.html>

You can also assess propagation by using DXLab's WinWarbler component's
broadband decoder to generate a "stations heard" list for all PSK31
transmissions heard on a particular band:

<http://www.dxlabsuite.com/winwarbler/Heard.jpg>

This approach depends on stations being QRV, which is not always the case
when a band opening is underway.

73,

Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Gmail - Kevin, Natalia, Stacey & Rochelle
Sent: Tuesday, October 20, 2009 4:05 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Throught of a Digital Propagation Tool




Hi All,

Just having a brain spark (not so many now-a-days)

With all the new digital modes being devopled upto this date and the way
some work; I was wondering if there could be some of propagation tool here?
Thought would be some form of automation on spot frequecies on the different
bands that cold record/monitor the propergation between continents.
Of course this would require stations to dedicate their radio to this, but
it could only be when the radio was not in operator use.
I can remember quite a few years ago a ham friend who was a Amtor/Packet
Sysop (using a PK-232) and he mentioned the band switching would allow him
to get a good propagation view. But it was limited as it was setup for
specific remote stations, he was not transferring to Asia or Europe, his hop
was Austrailia and a couple of West Coast stations.

It would require the software to control the scanning and switching of bands
on the radio. Most radios that have scan functions, once switched to TX will
not satrt scanning again.

Thought would be to have the software scan each band at (say) 3 min
intervals within a 30 min period, this would allow for slight differences in
computer clocks. And then TX and monitor for 5 mins, recording any
propergation traffic. Now I might be well off the mark here, just throwing
something into the air for thoughts.
Then the cycle woud start again.
The data could then be uploaded to a central (online) monitoring database.
The software could be configured to ignor certain calls for a band as this
would swamp the reports. (I don't want to know ZL's (or even VK's) are being
heard on 80 or 40mtrs, but I would like to know and report if Europe, Asia
or the Americas are.

Here is how I would see it

mm - Band
00 - 160Mtrs
03 - 80Mtrs
06 - 40Mtrs
09 - 30Mtrs
12 - 20Mtrs
15 - 17Mtrs
18 - 15Mtrs
21 - 13Mtrs
24 - 10Mtrs
27 - 6Mtrs (Most new radios have this now)

And then back to t

RE: [digitalradio] Throught of a Digital Propagation Tool

[Dave AA6YQ]

The is a worldwide network of 18 beacons operated by the Northern California
DX Foundation and the International Amateur Radio Union on 5 HF bands from
20m through 10m:

<http://www.ncdxf.org/beacons.html>

At the moment, the beacons in Russia and Sri Lanka are down due to hardware
problems; repairs are underway.

Each beacon transmits for 10 seconds, giving its callsign in CW followed by
four dashes: the first at 100 watts, the second at 10 watts, the third at 1
watt, and the fourth at 100 milliwatts:

<<http://www.ncdxf.org/beacon/beaconschedule.html>

By monitoring a beacon frequency for 3 minutes, you can assess actual
propagation from your QTH on that band. Alternatively, you can construct a
beacon schedule to quickly determine what bands are open to a particular
area of the world from your QTH. Syncing your PC's time-of-day clock with an
internet-accessible time service is recommended.

The freeware DXLab Suite's PropView component lets you specify a set of
beacons you wish to monitor and will direct the Commander component to QSY
your transceiver to monitor them. You can select beacons individually, by
band, or by bearing (octant) from your QTH. The PropView component will also
generate graphical propagation forecasts using the VOACAP or ICEPAC engines,
and use the beacon network to calibrate these forecasts. See

<http://www.dxlabsuite.com/propview/>

A list of other tools that can be used to monitor NCDXF/IARU beacons is
provided in

<http://www.ncdxf.org/beacon/beaconprograms.html>

You can also assess propagation by using DXLab's WinWarbler component's
broadband decoder to generate a "stations heard" list for all PSK31
transmissions heard on a particular band:

<http://www.dxlabsuite.com/winwarbler/Heard.jpg>

This approach depends on stations being QRV, which is not always the case
when a band opening is underway.

73,

Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Gmail - Kevin, Natalia, Stacey & Rochelle
Sent: Tuesday, October 20, 2009 4:05 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Throught of a Digital Propagation Tool



Hi All,

Just having a brain spark (not so many now-a-days)

With all the new digital modes being devopled upto this date and the way
some work; I was wondering if there could be some of propagation tool here?
Thought would be some form of automation on spot frequecies on the different
bands that cold record/monitor the propergation between continents.
Of course this would require stations to dedicate their radio to this, but
it could only be when the radio was not in operator use.
I can remember quite a few years ago a ham friend who was a Amtor/Packet
Sysop (using a PK-232) and he mentioned the band switching would allow him
to get a good propagation view. But it was limited as it was setup for
specific remote stations, he was not transferring to Asia or Europe, his hop
was Austrailia and a couple of West Coast stations.

It would require the software to control the scanning and switching of bands
on the radio. Most radios that have scan functions, once switched to TX will
not satrt scanning again.

Thought would be to have the software scan each band at (say) 3 min
intervals within a 30 min period, this would allow for slight differences in
computer clocks. And then TX and monitor for 5 mins, recording any
propergation traffic. Now I might be well off the mark here, just throwing
something into the air for thoughts.
Then the cycle woud start again.
The data could then be uploaded to a central (online) monitoring database.
The software could be configured to ignor certain calls for a band as this
would swamp the reports. (I don't want to know ZL's (or even VK's) are being
heard on 80 or 40mtrs, but I would like to know and report if Europe, Asia
or the Americas are.

Here is how I would see it

mm - Band
00 - 160Mtrs
03 - 80Mtrs
06 - 40Mtrs
09 - 30Mtrs
12 - 20Mtrs
15 - 17Mtrs
18 - 15Mtrs
21 - 13Mtrs
24 - 10Mtrs
27 - 6Mtrs (Most new radios have this now)

And then back to the top of the 30 min cycle again.

I don't know what mode would be the best but I was thinking digital PSK31,
but there could be a better digital mode.

Anyway just some thoughts I had floating around and thought I would put it
out there. I might be totally off the mark, but hey got to put things out
there to think about.

Thanks for Listening.

Kevin, ZL1KFM.

RE: [digitalradio] Top Ten Tips For Hams New To Digital Modes ?

[Dave AA6YQ]

1. don't be afraid to ask for help

2. listen to a couple of QSOs in a mode before attempting to make your first
one

3. if you must worry, worry about signal quality, not signal strength

73,

Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of obrienaj
Sent: Thursday, October 01, 2009 10:59 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Top Ten Tips For Hams New To Digital Modes ?


  So, what would your top 3 TIPS be for someone new to digital modes be ?

Andy K3UK

RE: [digitalradio] Callsign info Fill-in

[Dave AA6YQ]

DXKeeper will accept a DDE request to perform a callbook lookup, and places
the results in a set of DDE-accessible textboxes. The user specifies which
callbook to use on the Callbook tab of DXKeeper's Config window; the choices
are

1. RAC CDROM

2. HamCall CDROM

3. HamCall online (subscription)

4. QRZ CDROM

5. QRZ.com subscription

6. QRZ.com via Pathfinder (free with advertisements)

Patrick, let me know if you'd like to pursue this.

   73,

   Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Patrick Lindecker
Sent: Wednesday, September 09, 2009 2:08 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Callsign info Fill-in


  Hello Stan,

I see the need, but up to now (and as far as I know), it is not possible
from DXKeeper (through the standard DDE link proposed by Dave) to import
Name, Locator, QTH, for a given call sign (if known by the DXKeeper log).

The better would be to ask to the DXLabs group, for perhaps a future
evolution.

73
Patrick

- Original Message -
From: "mhz14071" 
To: 
Sent: Tuesday, September 08, 2009 9:16 PM
Subject: [digitalradio] Callsign info Fill-in

>I am using Multipsk v 4.14 with DXLabs.
> Commander is "Connected"
> Spot C: Is ON.
>
> Initially I have Freq, Mode, Ur RST, My RST, R, S, filled in.
> When I click on a station in the rx window, The callsign is placed Under
> CALL. However Name, Locator, QTH. remain empty.
>
> Is there a way to get these fields populated from DXLabs?
>
> Items such as SEARCH , Number which could provide pertinent information
> about the present contact require additional intervention.
>
> 73
> Stan N1ZX
>
>
>
> 
>
> Announce your digital presence via our Interactive Sked Pages at
> http://www.obriensweb.com/sked
>
> Recommended digital mode software: Winwarbler, FLDIGI, DM780, or Multipsk
> Logging Software: DXKeeper or Ham Radio Deluxe.
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

RE: [digitalradio] Fwd: [dxlab] DXKeeper 8.1.6 enhancement for LOTW and some digital modes

[Dave AA6YQ]

Thanks, Andy.

For those not familiar with the term "synchronizing" with respect to LotW
operations, it means automatically

1. updating QSOs uploaded to LotW to reflect their subsequent acceptance by
LotW (setting "LotW QSL Sent" to 'Y' and recording the date in "LotW QSL
Sent Date")

2. updating QSOs uploaded uploaded to LotW to reflect their confirmation via
LotW (setting "LotW QSL Rcvd" to 'Y' and recording the date in "LotW QSL
Rcvd Date")

The first operation is typically initiated a few hours after uploading to
LotW -- unless there's a contest in progress or just ending, in which case
its best to wait a full day. The second operation is initiated whenever you
want to check for new confirmations.

73,

 Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Andrew O'Brien
Sent: Sunday, September 06, 2009 6:07 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Fwd: [dxlab] DXKeeper 8.1.6 enhancement for LOTW and
some digital modes


  FYI

-- Forwarded message --
From: aa6yq 
Date: Sep 6, 2009 5:48 PM
Subject: [dxlab] DXKeeper 8.1.6 is available
To: dx...@yahoogroups.com




This release

- when synchronizing QSOs or QSLs with LotW, QSOs reported by LotW whose
Mode is DATA are considered to match a logged QSO whose mode "counts" as
RTTY for ARRL awards (tnx to Bob WU9Q)

- updates the AwardInfo.htm, index.htm, Log.htm, LogCompletedMain.htm,
LogNewCapture.htm, LogNewMain.htm, ModifyLog.htm, Progress.htm, QSL.htm,
Scripts.htm, and ViewEditLog.htm documentation files

If your are uploading digital mode QSOs to LotW where the digital mode is
not yet supported by LotW (e.g. JT65A), configure TQSL to "map" these
unsupported digital modes to DATA. The above enhancement allows DXKeeper to
locate these QSOs in your log when directed to synchronize with LotW;
previously, DXKeeper would report such QSOs as not matching any logged QSO
because of the change in mode introduced by TQSL.

DXKeeper 8.1.6 is available via the DXLab Launcher and via

<http://www.dxlabsuite.com/download.htm>

73,

Dave, AA6YQ





--
Andy

[digitalradio] RE: [DigitalModes] ClusterClient

[Dave AA6YQ]

The $250 Asus price quoted below is incorrect; they're available new for
$310.

 73,

Dave, AA6YQ

-Original Message-
From: digitalmo...@yahoogroups.com [mailto:digitalmo...@yahoogroups.com]on
Behalf Of Dave AA6YQ
Sent: Sunday, August 09, 2009 8:43 PM
To: digitalmo...@yahoogroups.com; illinoispacketra...@yahoogroups.com;
in_pac...@yahoogroups.com
Cc: m0...@m0pzt.net; hspac...@yahoogroups.com; digitalradio@yahoogroups.com;
ps...@yahoogroups.com
Subject: RE: [DigitalModes] ClusterClient


  Re "A netbook typically offers a low screen resolution so any fancy
graphics, windows, tables and such would immediately make a bit of a mess on
such a small screen."

Not true.

A Dell Mini 10V ($299) offers a screen resolution of 1024x600, an HP Mini
110 XP ($329) offers a screen resolution of 1024x576, and an Asus Eee PC
900HA ($250) offers a screen resolution of 1024 x 600. These units display
20+% more pixels than the 800x600 SVGA monitors still in use on desktops in
the amateur community.

1024x768 was a standard laptop resolution not that long ago...

73,

Dave, AA6YQ

-Original Message-
From: digitalmo...@yahoogroups.com [mailto:digitalmo...@yahoogroups.com]on
Behalf Of Mark Thompson
Sent: Sunday, August 09, 2009 8:15 PM
To: illinoispacketra...@yahoogroups.com; in_pac...@yahoogroups.com
Cc: m0...@m0pzt.net; hspac...@yahoogroups.com; digitalmo...@yahoogroups.com;
digitalradio@yahoogroups.com; ps...@yahoogroups.com
Subject: [DigitalModes] ClusterClient

ClusterClient

For many years, the DX Cluster network has been used to check for that
elusive "DX" - in the hey-day of packet, cluster access was achieved via a
TNC and a basic packet terminal (such as paKet62 or WinPack)...

Nowadays, radio amateurs rely heavily on the internet to provide
up-to-the-minute information on band conditions, beacon reports and
activity.

I like to operate /P from my village green (among other places) and often
find the DX cluster a useful tool to see what's happening on the HF bands.
With the advent of compact netbooks and USB broadband dongles, getting 'net
access "in the field" has never been easier.

A netbook typically offers a low screen resolution so any fancy graphics,
windows, tables and such would immediately make a bit of a mess on such a
small screen - In the absence of a simple DX cluster viewer, I wrote
'ClusterClient'.

ClusterClient is a DX Cluster monitor application that connects via telnet
to your favourite DX cluster. It offers a simple window with a spot counter
(for each band) on the left-hand-side and a couple of text-boxes that permit
easy "spotting" of stations heard/worked. The simple screen layout is thus
ideal for laptops and can be re-sized to suit operating preferences.

Spots can be filtered to display only the bands you're interested in - no
complex cluster filter commands to worry about, just (un)tick the bands on
the filter window!

This software came about as a result of my work on a /P logging package
called MiniLog (http://www.m0pzt.net/projects.php#MiniLog) and a few people
asked if I could make the DX cluster window a "standalone" package...

ClusterClient is a free application written by Charlie Davy, M0PZT and is
available at: http://www.m0pzt.net/projects.php#ClusterClient

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

[digitalradio] RE: [DigitalModes] ClusterClient

[Dave AA6YQ]

Re "A netbook typically offers a low screen resolution so any fancy
graphics, windows, tables and such would immediately make a bit of a mess on
such a small screen."

Not true.

A Dell Mini 10V ($299) offers a screen resolution of 1024x600, an HP Mini
110 XP ($329) offers a screen resolution of 1024x576, and an Asus Eee PC
900HA ($250) offers a screen resolution of 1024 x 600. These units display
20+% more pixels than the 800x600 SVGA monitors still in use on desktops in
the amateur community.

1024x768 was a standard laptop resolution not that long ago...

73,

  Dave, AA6YQ



-Original Message-
From: digitalmo...@yahoogroups.com [mailto:digitalmo...@yahoogroups.com]on
Behalf Of Mark Thompson
Sent: Sunday, August 09, 2009 8:15 PM
To: illinoispacketra...@yahoogroups.com; in_pac...@yahoogroups.com
Cc: m0...@m0pzt.net; hspac...@yahoogroups.com; digitalmo...@yahoogroups.com;
digitalradio@yahoogroups.com; ps...@yahoogroups.com
Subject: [DigitalModes] ClusterClient


  ClusterClient

For many years, the DX Cluster network has been used to check for that
elusive "DX" - in the hey-day of packet, cluster access was achieved via a
TNC and a basic packet terminal (such as paKet62 or WinPack)...

Nowadays, radio amateurs rely heavily on the internet to provide
up-to-the-minute information on band conditions, beacon reports and
activity.

I like to operate /P from my village green (among other places) and often
find the DX cluster a useful tool to see what's happening on the HF bands.
With the advent of compact netbooks and USB broadband dongles, getting 'net
access "in the field" has never been easier.

A netbook typically offers a low screen resolution so any fancy graphics,
windows, tables and such would immediately make a bit of a mess on such a
small screen - In the absence of a simple DX cluster viewer, I wrote
'ClusterClient'.

ClusterClient is a DX Cluster monitor application that connects via telnet
to your favourite DX cluster. It offers a simple window with a spot counter
(for each band) on the left-hand-side and a couple of text-boxes that permit
easy "spotting" of stations heard/worked. The simple screen layout is thus
ideal for laptops and can be re-sized to suit operating preferences.

Spots can be filtered to display only the bands you're interested in - no
complex cluster filter commands to worry about, just (un)tick the bands on
the filter window!

This software came about as a result of my work on a /P logging package
called MiniLog (http://www.m0pzt.net/projects.php#MiniLog) and a few people
asked if I could make the DX cluster window a "standalone" package...

ClusterClient is a free application written by Charlie Davy, M0PZT and is
available at: http://www.m0pzt.net/projects.php#ClusterClient

[Non-text portions of this message have been removed]

RE: [digitalradio] Re: Zapped PCs, data recovery, and Windows !

[Dave AA6YQ]

There is nothing legally or morally wrong with attaching a hard drive (as a
secondary drive, not as the C: drive)  to a PC running Windows in order to
move data to or from that hard drive -- whether or not that hard drive has
Windows installed (under any flavor of Microsoft license).

73,

 Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of damienjorgensen
Sent: Thursday, July 23, 2009 8:51 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Zapped PCs, data recovery, and Windows !


  In that sense then there is no license to run it either, just as there is
nothing saying you cannot do it, there is nothing saying you can

Its morally wrong, you might not like paying for the correct license, but it
doesnt make it any more right than borrwing some bread from a bakers when
you're hungry without paying for it.
There isnt a sign up saying "no borrowing" but that doesnt mean you can just
go ahead and do it

Pay for what you use, fine experement with something. But if you want
windows then get the correct edition, with the correct license.

OEM editions shouldnt be abused

--- In digitalradio@yahoogroups.com, "Dave AA6YQ"  wrote:
>
> I should have been more clear: there is nothing in the Windows EULA that
> precludes attaching a disk on which Windows has been installed as slave
> drive to another PC running Windows (or any other OS). Since Windows is
not
> being run on the attached drive, there is no "transfer" of Windows.
>
> I used to buy Dells, but I've been assembling my own PCs for the past
couple
> of years. Thus I don't use OEM Windows licenses.
>
> 73,
>
> Dave, AA6YQ
>
> -Original Message-
> From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
> Behalf Of frankk2ncc
> Sent: Thursday, July 23, 2009 7:57 PM
> To: digitalradio@yahoogroups.com
> Subject: [digitalradio] Re: Zapped PCs, data recovery, and Windows !
>
>
> --- In digitalradio@yahoogroups.com, "Dave AA6YQ"  wrote:
> > There is nothing in the Windows End User License Agreement that
precludes
> > attaching a disk on which Windows has been installed to another PC
running
> > Windows (or any other OS).
>
> You cannot do this with an OEM copy of Windows*. Which, unless you had it
> custom built, is likely what you have. If you own a Dell, HP, etc., it's
> OEM.
>
> That's the reason you have to re-activate Windows when you change enough
> hardware. Do enough changes and it's technically a new machine!
>
> That's also why OEM copies of Windows is less than half-price of the
retail
> version, which you ARE license to move, so long as it's one PC (assuming 1
> CPU license.)
>
> > If you have frequent power outages, I recommend adding a UPS capable of
>
> Amen! 100 bucks will save you a thousand. Brown/black outs are potentially
> just as damaging as a surge. I recommend APC brand. Get at least a 750 in
> your model number.
>
> f
>
> *"Current OEM licenses for all Microsoft operating system products are not
> transferable from one machine to another."
>
>
http://download.microsoft.com/download/4/e/3/4e3eace0-4c6d-4123-9d0c-c804361
> 81742/OSLicQA.doc
>
> (No MS Word? Download openoffice.org or the DOC viewer here:
> http://tinyurl.com/docviewer2003
> )
>

RE: [digitalradio] Re: Zapped PCs, data recovery, and Windows !

[Dave AA6YQ]

I should have been more clear: there is nothing in the Windows EULA that
precludes attaching a disk on which Windows has been installed as slave
drive to another PC running Windows (or any other OS). Since Windows is not
being run on the attached drive, there is no "transfer" of Windows.

I used to buy Dells, but I've been assembling my own PCs for the past couple
of years. Thus I don't use OEM Windows licenses.

73,

  Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of frankk2ncc
Sent: Thursday, July 23, 2009 7:57 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Zapped PCs, data recovery, and Windows !


  --- In digitalradio@yahoogroups.com, "Dave AA6YQ"  wrote:
> There is nothing in the Windows End User License Agreement that precludes
> attaching a disk on which Windows has been installed to another PC running
> Windows (or any other OS).

You cannot do this with an OEM copy of Windows*. Which, unless you had it
custom built, is likely what you have. If you own a Dell, HP, etc., it's
OEM.

That's the reason you have to re-activate Windows when you change enough
hardware. Do enough changes and it's technically a new machine!

That's also why OEM copies of Windows is less than half-price of the retail
version, which you ARE license to move, so long as it's one PC (assuming 1
CPU license.)

> If you have frequent power outages, I recommend adding a UPS capable of

Amen! 100 bucks will save you a thousand. Brown/black outs are potentially
just as damaging as a surge. I recommend APC brand. Get at least a 750 in
your model number.

f

*"Current OEM licenses for all Microsoft operating system products are not
transferable from one machine to another."

http://download.microsoft.com/download/4/e/3/4e3eace0-4c6d-4123-9d0c-c804361
81742/OSLicQA.doc

(No MS Word? Download openoffice.org or the DOC viewer here:
http://tinyurl.com/docviewer2003
)

RE: [digitalradio] Re: Zapped PCs, data recovery, and Windows !

[Dave AA6YQ]

re "Fast, effective, easy data and O/S moves is a bane for computer techs.
Are there alternatives someone can offer?. "

Yes. I use StorageCraft's ShadowProctect for backup and recovery. Like
Norton Ghost, this creates disk images -- but with the ability to perform
hardware-independent recoveries, meaning that you can restore a saved drive
image from PC #1 onto PC #2 where PC #1 and PC #2 are not identical.
Usually, I'm restoring to the same PC that created the image, but on the
several occasions where I've restored an image to different hardware, its
worked flawlessly. PC Labs extensively tested this capability and was quite
impressed.

You can dramatically reduce the time required to recover from hard drive
crash by using StorageCraft or Ghost to create a disk image after you first
loaded your PC with Windows and your applications. Assuming that you
frequently backup your data (logs, scripts, code, whatever), then recovering
from a hard drive crash entails

-- wiping the hard drive
-- restoring the image
-- applying any application updates since the image was created
-- restoring the most recent data backup(s)

StorageCraft and Ghost can both be configured to make a weekly "full backup"
and a daily "incremental" backup to an external hard-drive or to a
network-accessible drive. This reduces recovery to a single automated
operation that takes about an hour for my XP systems.

After years of using Ghost (and hating its terrible UI and many defects), I
switched to StorageCraft after seeing some very positive reviews -- and have
been quite happy with it.

I have no relationship with any of the companies mentioned above, but do
have lots of friends in the mass storage business...

73,

 Dave, AA6YQ





-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of frankk2ncc
Sent: Thursday, July 23, 2009 7:34 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Zapped PCs, data recovery, and Windows !


  Andy,

I often need to get the data off of a dead computer and move it to the new
one. The best way to do in my experience is simply to attach the old drive
as a slave to the new one and start draggin' and droppin'.

Once the old HDD detects in your new PC, go to the appropriate folders.
You'll probably want at least My Documents, Desktop, Favorites, email files,
and odd-n-ends laying around, like saved games.

Using programs to backup and restore (i.e. Files & Settings Transfer
Wizard), or swapping old Windows HDD onto new PC, simply doesn't work as
well.

You can't move Windows over, as Microsoft deems that the license goes with
the machine ('specially OEM like Dell, etc.) And most programs have to be
installed and can't be moved. Too many files and registry entries to do so
safely. And honestly, if it's been a while since you've re-installed Windows
on the old PC, you're better off with a fresh one.

Fast, effective, easy data and O/S moves is a bane for computer techs. Are
there alternatives someone can offer?. (Something they've tried themselves,
no CNET reviews or GOOGLE search results please!)

Since this isn't a computer help forum, I'm wondering if we should take this
elsewhere?

f, k2ncc

RE: [digitalradio] Zapped PCs, data recovery, and Windows !

[Dave AA6YQ]

You cannot replace the C drive of Windows PC #1 with the C drive of Windows
PC #2 and expect the resulting machine to boot unless PC #1 and PC #2 use
the same motherboard and peripherals. However, you can configure the C drive
of PC #2 to be a secondary drive in PC #1 assuming that PC #1 supports the
appropriate hardware interface -- e.g. if the PC #2's hard drive uses an IDE
interface, then you'll need an IDE interface in PC #1.

Addonics makes a product that lets you convert any IDE drive into an
external USB drive. Access via USB is significantly slower than native IDE
access, but you can connect to any PC with a USB interface; perhaps they
have a USB 2.0 version by now:

http://www.addonics.com/products/io/

While converters like these are somewhat slow, they allow you to connect a
drive up to a running PC -- eliminating the need to power it down, open its
chassis, and make the IDE or SATA connection -- which can be difficult in a
smaller chassis stuffed with cables.

I have occasionally moved IDE drives between PCs whose motherboards were
manufactured by different companies, but never encountered a driver problem.
When it doesn't work the right off the bat, its usually a master/slave
configuration issue; I've also run into IDE cables with bad slave
connectivity (cable or connector problems).

There is nothing in the Windows End User License Agreement that precludes
attaching a disk on which Windows has been installed to another PC running
Windows (or any other OS).

If you have frequent power outages, I recommend adding a UPS capable of
powering your PC long enough to shut down Windows in an orderly fashion;
otherwise, you are subjecting the data on your hard drive(s) to risk from
both power surges and from being scribbled upon if the drive happens to be
in the middle of write operation when the power fails. APC makes a nice
product, but be sure to not buy one larger than is needed for ~5 minutes of
operation.

I have no relationship with any of the companies mentioned above...

73,

 Dave, AA6YQ


-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Andrew O'Brien
Sent: Thursday, July 23, 2009 6:38 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Zapped PCs, data recovery, and Windows !


  After years or running PC's without issues, I have had 4 go bad in 12
months.  Two this week, 4 days apart via thunderstorms .  One went today
just an hour after I had fully reinstalled ham equipment on a new PC that
arrived yesterday.  The new one survived, I had unplugged it at the sound of
thunder.  I powered off the older one but forgot to remove the power cord,
it got zapped.  I put in a spare power supply that i had, that lasted  5
minutes and gave up the ghost.  Maybe something else was weakened by the
original zap and caused the second power supply to burn out.

Anyway, my main issue is the frustrating fact that I have data on hard
drives that seems ridiculously complex to retrieve when using
Windows based PCs. My local computer store tells me that one cannot simply
take a hard drive from a old Pc and place it in a new PC even if you have a
Windows license disc  for the new PC.  Is this correct?  In the past I have
taken old drives and installed them in different PC's as slave drives.
However this causes one to have to re-install many programs because they
were originally installed to the registry on a C-drive.

So what do I do with 5 hard drives laying around the shack ?  In particular
one two-drive system with 160 gigs of useful data on it (both have  Windows
OS on them since both are from different original PC systems!) .  It would
be nice to install in to a PC without having to get a HD with an OS on it.
--
Andy

RE: [digitalradio] Re: More RSID - PLEASE!

[Dave AA6YQ]

You don't know if an instantaneously "empty" spot on the waterfall is truly
empty until you send "QRL?" and receive no response, or monitor it long
enough to have heard both sides of a QSO if one were in progress.

Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of aa777888athotmaildotcom
Sent: Wednesday, July 22, 2009 10:34 AM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: More RSID - PLEASE!


  You know what's really exciting? We are a hop, skip and jump away from a
powerful, lightweight ALE implementation that would probably outperform
MIL-STD-188-141A by a large margin.

Right now the code scans an entire 3KHz bandwidth for RSID (or more with
SDR). When you add in the future, planned SELCAL feature the only things
missing after that are scanning and an automated response.

It also appears possible that the software would be capable of automatically
choosing an empty spot on the waterfall to make the call. This would allow
all calls to occur simultaneously and therefore I would suggest time
synchronized scanning a la JT65 or WSPR in order to improve probability of
intercept without long or repetitive RSID transmissions. Say 4 second dwell
per band to allow a +/-1 second guard band on the timing (given a 2 second
RSID transmission length). The occasional collision would be worth the
simplicity and reliability.

Thanks again, Simon!

Scott
k*b*l*0*0*q

--- In digitalradio@yahoogroups.com, "Simon \(HB9DRV\)" 
wrote:
>
> I think it'll take up to a year - then we'll be rocking.
>
> Also when we use SDR more there will be a big improvement.
>
> Simon Brown, HB9DRV
> www.ham-radio-deluxe.com
> - Original Message -
> From: Tony
>
> I think we're making progress with RSID Dave, it's just slow to catch on.
Have a look at the RSID video in the file section of this reflector.
>

RE: [digitalradio] Slightly off-topic

[Dave AA6YQ]

SpotCollector will do that. I connects to up to 6 spot sources (telnet
clusters, packet clusters, the DX Summit web cluster), creates a local
database with one entry for each DX station active during an interval on a
particular band and mode, and provides comprehensive searching (from simple
"check the box" filters for band, mode, LotW participation, etc. to SQL
queries, including date ranges).

SpotCollector is free, and available via www.dxlabsuite.com

73,

Dave, AA6YQ


-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Tony
Sent: Wednesday, July 15, 2009 2:55 AM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Slightly off-topic






All,

Does anyone know of a Dx Spot search engine that allows the user to go back
in time and see all spots posted for the entire month of May on say 6
meters?

Both DX Summit and  DX Watch provide a way to search spots with different
filters, but the month or day of the year is not one of them.

Any ideas?

Thanks,

Tony -K2MO

RE: [digitalradio] Re: Double Entries on Waterfall

[Dave AA6YQ]

If WinWarbler repeatedly decodes the same callsign on multiple frequencies,
it compares signal strengths to identify the primary and suppresses the
harmonics.

Harmonics can be caused by stations generating PSK with modulated audio
below 1500 Hz.

 73,

  Dave, AA6YQ

-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of Andrew O'Brien
Sent: Monday, July 13, 2009 7:40 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Double Entries on Waterfall





--- In digitalradio@yahoogroups.com, "Ralph Lambert" 
wrote:
>
> Why do I sometimes see double entries for the same call sign in the
> waterfall. Is this some one working split? It seems like it is a
> duplex issue or am I way off the boat on this one?
>
> 73, Ralph (AJ4GR)
>

How do you know they are doubles? You can expect to see doubles if using
multiple decode options like those listed as "stations heard" in Winwarbler
or in the "panoramic" view in Multipsk. In regular decode for BPSK31 you can
also see a "harmonic" every 1000 Hz if a station is transmitting with a
badly over driven signal. You may simply be seeing other close by signals,
or possibly mistaking the two parallel vertical lines normally seen in
BPSK31.

Andy K3UK

RE: [digitalradio] MMTTY VS MMVARI, et al.

[Dave AA6YQ]

Thanks, Sholto, I'm aware of the results Alex has published and the tools he
makes available. There are significant opportunities for improvement.

 

 73,

 

   Dave, AA6YQ

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On
Behalf Of Sholto Fisher
Sent: Monday, June 15, 2009 12:13 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] MMTTY VS MMVARI, et al.

 






Hi Dave,

Alex, VE3NEA has an interesting page about MMTTY performance here:

http://www.dxatlas.com/RttyCompare/

I completely agree with his results regarding the performance of TruTTY 
and has been my preferred RTTY program for while now.

73 Sholto
K7TMG

Dave AA6YQ wrote:
> 
> 
> 
> I have the source code to MMTTY, have updated MMTTY to enable operation 
> under Vista (version 1.66G), and intend to improve its RTTY decoding 
> capability.
> 
> 
> 
> MMTTY can transmit via AFSK or FSK; as far as I know, MMVARI is limited 
> to AFSK.
> 
> 
> 
> 73,
> 
> 
> 
> Dave, AA6YQ
> 
> 
> 
> 
> 
> 
> 
> *From:* digitalradio@ yahoogroups. com [mailto:digitalradi 
> o...@yahoogroups. com] *On Behalf Of *Rick W
> *Sent:* Sunday, June 14, 2009 11:38 PM
> *To:* digitalradio@ yahoogroups. com
> *Subject:* [digitalradio] MMTTY VS MMVARI, et al.
> 
> 
> 
> 
> 
> 
> After all these years, I finally downloaded N1MM Logger and spent some
> time with it today. Even logged a few contacts during the ARRL June VHF
> Contest. Previously, I could not get it work with Vista. The web site
> might even lead to believe that it may not be supported on Vista. But
> after doing a search on Vista + N1MM, I found a detailed tutorial from
> Bob, W1QA, that showed that I was mostly doing things correctly ...
> except for one little security procedure that I have never had to do
> with any other program and would never have figured out on my own, HI.
> And it turns out that the program is not as complicated as I had
> thought. In fact, the interface can be kept quite simple for the entry
> window.
> 
> >From what I understand, N1MM requires either MMTTY or MMVARI if you
> wish to interface via a soundcard for RTTY and some digital modes.
> Apparently, other digital sound card programs, such as fldigi, can not
> work with this logger as it is tailored to the MM programs. I am not
> sure that there are any cross platform contest logging programs so it
> means you almost have to stay with MS Windows, especially for what I
> would consider to be ultra high end programs such as N1MM.
> 
> Can anyone give us a comparison of MMTTY and MMVARI?
> 
> I understand that Dave, AA6YQ, has been able to update MMTTY. But then I
> have read that some hams have found MMVARI to decode better under some
> conditions. And I get the impression that only MMTTY will be updated
> with MMVARI "frozen" in beta (but a pretty darn good beta from past
> experience).
> 
> Also, does anyone have some first hand experiences with how the HRD
> Logging program will work as a contest logger compared with N1MM?
> 
> Lots of questions, but I bet some of you have the answers, HI.
> 
> 73,
> 
> Rick, KV9U
> 
> 

RE: [digitalradio] MMTTY VS MMVARI, et al.

[Dave AA6YQ]

I have the source code to MMTTY, have updated MMTTY to enable operation
under Vista (version 1.66G),  and intend to improve its RTTY decoding
capability.

 

MMTTY can transmit via AFSK or FSK; as far as I know, MMVARI is limited to
AFSK.

 

73,

 

Dave, AA6YQ

 

 

 

From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On
Behalf Of Rick W
Sent: Sunday, June 14, 2009 11:38 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] MMTTY VS MMVARI, et al.

 






After all these years, I finally downloaded N1MM Logger and spent some 
time with it today. Even logged a few contacts during the ARRL June VHF 
Contest. Previously, I could not get it work with Vista. The web site 
might even lead to believe that it may not be supported on Vista. But 
after doing a search on Vista + N1MM, I found a detailed tutorial from 
Bob, W1QA, that showed that I was mostly doing things correctly ... 
except for one little security procedure that I have never had to do 
with any other program and would never have figured out on my own, HI. 
And it turns out that the program is not as complicated as I had 
thought. In fact, the interface can be kept quite simple for the entry 
window.

>From what I understand, N1MM requires either MMTTY or MMVARI if you 
wish to interface via a soundcard for RTTY and some digital modes. 
Apparently, other digital sound card programs, such as fldigi, can not 
work with this logger as it is tailored to the MM programs. I am not 
sure that there are any cross platform contest logging programs so it 
means you almost have to stay with MS Windows, especially for what I 
would consider to be ultra high end programs such as N1MM.

Can anyone give us a comparison of MMTTY and MMVARI?

I understand that Dave, AA6YQ, has been able to update MMTTY. But then I 
have read that some hams have found MMVARI to decode better under some 
conditions. And I get the impression that only MMTTY will be updated 
with MMVARI "frozen" in beta (but a pretty darn good beta from past 
experience).

Also, does anyone have some first hand experiences with how the HRD 
Logging program will work as a contest logger compared with N1MM?

Lots of questions, but I bet some of you have the answers, HI.

73,

Rick, KV9U