Carl R. Stevenson wrote:
The concern/fear/issues being raised by
many are that the ARRL "regulation
by bandwidth" proposal will result in
practically all of the HF CW/data
bands being "over-run by Winlink/PactorIII
robots," that those stations
don't "play nice" with real-time human to
human modes, that PactorIII takes
a lot of bandwidth for a non-proportional
gain in throughput, and that
Winlink and PactorIII are closed, proprietary
modes that are only available
through the purchase of some rather expensive,
sole-source hardware and software.

I'd state the first part somewhat differently:

One concern is that the proposed rules would/could
unleash "robot" stations of all kinds anywhere in the
non-voice/image parts of the bands. There would be
no way for the typical PSK31, RTTY or Morse Code
operator to know they were on a frequency used by
a "robot" until the robot fired up on top of their
QSO.

A human operator who fires up on top of an existing
QSO can be in violation of the rules. What gives
robots an exception?

PactorIII and Winlink are indeed proprietary, which
goes against the grain of open-sourcing and freeware.
Compare those modes to, say, PSK31, with its wide-open
software and hardware.

To most of us there's nothing wrong with hams using
propietary software or hardware - until it becomes
an endorsed standard. IOW, 'buy this particular
piece of hardware and software from this particular
company or you cannot play the game' doesn't sit well.

There seem to be rather widely held views that
"robot" stations that "don't
play nice" with conventional human-human modes
should be restricted to
limited sub-bands because otherwise they will
cause considerable interference problems,

Yup. Makes sense, too.

that they don't need to be able to take over huge
swaths of the bands, and that closed, proprietary systems
should not be
"pushed" in the ham bands. (conversely, the feeling seems
to be widespread
that modes used in the ham bands should be "open source" - both h/w and s/w)

Exactly.

It is my understanding that Winlink has become the method of
choice for some folks with boats to send and receive their
email. This raises the question of commercial/pecuniary content
as well - how are such things filtered?

Add to the mix that it's ARRL pushing the Winlink/PactorIII
thing and you can see the opposition rising...

What's your take on such 'robots' on HF, Carl? Should they
be treated just like any other station, or should they have
some special restrictions based on their unattended nature?

Should ARRL endorse/standardize/push modes requiring the
purchase of proprietary hardware and software from specific
providers?

73 de Jim, N2EY

wrote:
Carl R. Stevenson wrote:
The concern/fear/issues being raised by
many are that the ARRL "regulation
by bandwidth" proposal will result in
practically all of the HF CW/data
bands being "over-run by Winlink/PactorIII
robots," that those stations
don't "play nice" with real-time human to
human modes, that PactorIII takes
a lot of bandwidth for a non-proportional
gain in throughput, and that
Winlink and PactorIII are closed, proprietary
modes that are only available
through the purchase of some rather expensive,
sole-source hardware and software.

I'd state the first part somewhat differently:

One concern is that the proposed rules would/could
unleash "robot" stations of all kinds anywhere in the
non-voice/image parts of the bands. There would be
no way for the typical PSK31, RTTY or Morse Code
operator to know they were on a frequency used by
a "robot" until the robot fired up on top of their
QSO.

How is that different from anything else In a strnge place I don't know
when I start an FM simplex QSO that this area uses that simplex freq
for packet links

and why is it a problem I thought CW always got through, yet it needs
protecting from Pactor?

Assuming the robot listens before sending well it looks like anything
else I hear about in HF


A human operator who fires up on top of an existing
QSO can be in violation of the rules. What gives
robots an exception?

Only if the Human operators does not know, if they check then well how
is this different from a Human operator smash a distant low power
signal not reaching his attenna


PactorIII and Winlink are indeed proprietary, which
goes against the grain of open-sourcing and freeware.
Compare those modes to, say, PSK31, with its wide-open
software and hardware.

To most of us there's nothing wrong with hams using
propietary software or hardware - until it becomes
an endorsed standard. IOW, 'buy this particular
piece of hardware and software from this particular
company or you cannot play the game' doesn't sit well.

What is so specail about the coding thatham cold not mange to make
something that does essentcaily the same thing?


There seem to be rather widely held views that
"robot" stations that "don't
play nice" with conventional human-human modes
should be restricted to
limited sub-bands because otherwise they will
cause considerable interference problems,

Yup. Makes sense, too.

why?


that they don't need to be able to take over huge
swaths of the bands, and that closed, proprietary systems
should not be
"pushed" in the ham bands. (conversely, the feeling seems
to be widespread
that modes used in the ham bands should be "open source" - both h/w and s/w)

Exactly.

It is my understanding that Winlink has become the method of
choice for some folks with boats to send and receive their
email. This raises the question of commercial/pecuniary content
as well - how are such things filtered?



Add to the mix that it's ARRL pushing the Winlink/PactorIII
thing and you can see the opposition rising...

What's your take on such 'robots' on HF, Carl? Should they
be treated just like any other station, or should they have
some special restrictions based on their unattended nature?

Should ARRL endorse/standardize/push modes requiring the
purchase of proprietary hardware and software from specific
providers?

73 de Jim, N2EY

an_old_friend wrote:
wrote:

and why is it a problem I thought CW always got through, yet it needs
protecting from Pactor?

No, CW does *not* "always get through".

Assuming the robot listens before sending well it looks like anything
else I hear about in HF

No, robots do *not* listen before transmitting which is against the
regs and is the crux of the problem.

A human operator causing QRM is either lousy operating practice or an
accident, a robot blindly causing QRM via it's inherent design is
illegal. One solution might be to come up with a robot which tunes
around it's frequency before transmitting. There's one for you
code-writers to chew on.

w3rv

wrote:
an_old_friend wrote:
wrote:

and why is it a problem I thought CW always got through, yet it needs protecting from Pactor?

No, CW does *not* "always get through".

No mode always gets through. There are some times when Morse
Code gets through and other available modes do not. This plain,
simple fact has been misquoted and perverted by some.

Assuming the robot listens before sending well it looks like anything else I hear about in HF

No, robots do *not* listen before transmitting which is against the regs and is the crux of the problem.

There's also the issue of what constitutes "listening". A robot
may listen for another Pactor III signal, yet not for a PSK31
or Morse Code signal.

How much of a listen is long enough, and on how much on either
side of the frequency?

A human operator causing QRM is either lousy operating practice or an accident, a robot blindly causing QRM via it's inherent
design is illegal.

There's also the 24/7 nature of the robots.

One solution might be to come up with a robot which tunes
around it's frequency before transmitting.

Yup. And maybe sends "QRL?" in Morse Code before it opens up.

There's one for you code-writers to chew on.

The situation is somewhat like the dawn of the FM repeater
era on the ham bands. A typical ham FM repeater essentially
takes over two frequencies (input and output)in its coverage
area.

There was a time when a ham repeater required a special license
with special callsign, and the application for it involved a
pretty detailed description of the setup, its operation, etc.,
with things like HAAT specified. Even today we have repeater
coordination.

But VHF/UHF coverage is fairly predictable and consistent. A
typical ham VHF/UHF repeater covers a few hundred square miles
except during unusual conditions. Even a moderately powered HF
station can cover millions of square miles.

The "regulation by bandwidth" proposal has some good basic
concepts, but it needs some serious work before it is ready
for prime time. The fact that so many different groups are
opposed to it, and so few in favor, shows that it needs rework.

73 de Jim, N2EY

wrote:
an_old_friend wrote:
wrote:

and why is it a problem I thought CW always got through, yet it needs
protecting from Pactor?

No, CW does *not* "always get through".

then the proceder have been teling another lie


Assuming the robot listens before sending well it looks like anything
else I hear about in HF

No, robots do *not* listen before transmitting which is against the
regs and is the crux of the problem.

then the problem is a lack of enforcement not a rules issue at all


A human operator causing QRM is either lousy operating practice or an
accident, a robot blindly causing QRM via it's inherent design is
illegal. One solution might be to come up with a robot which tunes
around it's frequency before transmitting. There's one for you
code-writers to chew on.

Or for it just to listen a bit for a signal first


w3rv

wrote:
wrote:
an_old_friend wrote:
wrote:

and why is it a problem I thought CW always got through, yet it needs protecting from Pactor?

No, CW does *not* "always get through".

No mode always gets through. There are some times when Morse
Code gets through and other available modes do not. This plain,
simple fact has been misquoted and perverted by some.

but can't you read the CW signal though the noise?

Assuming the robot listens before sending well it looks like anything else I hear about in HF

No, robots do *not* listen before transmitting which is against the regs and is the crux of the problem.

There's also the issue of what constitutes "listening". A robot
may listen for another Pactor III signal, yet not for a PSK31
or Morse Code signal.

so your issue is one that the robot doesn't do a good enough job of
listening


How much of a listen is long enough, and on how much on either
side of the frequency?

Isn't pactor relitively wide compared to CW and PSK 31? so if they are
lsitening across thier bandwidth they should detect a signal wether
they can read or not

and how long would satify you?


A human operator causing QRM is either lousy operating practice or an accident, a robot blindly causing QRM via it's inherent
design is illegal.

There's also the 24/7 nature of the robots.

Why is this a problem? indeed if they are doing thiss al thetime then
you could avoid them esierly enough

again if the they are lsitening

One solution might be to come up with a robot which tunes
around it's frequency before transmitting.

Yup. And maybe sends "QRL?" in Morse Code before it opens up.

why should it favor Morse code over PSK 31?


There's one for you code-writers to chew on.

The situation is somewhat like the dawn of the FM repeater
era on the ham bands. A typical ham FM repeater essentially
takes over two frequencies (input and output)in its coverage
area.

There was a time when a ham repeater required a special license
with special callsign, and the application for it involved a
pretty detailed description of the setup, its operation, etc.,
with things like HAAT specified. Even today we have repeater
coordination.

and today things seem to go enough without specail licenses

Why should Morse Code receive specail breaks that PSK 31 and RTTY don't
get?


But VHF/UHF coverage is fairly predictable and consistent. A
typical ham VHF/UHF repeater covers a few hundred square miles
except during unusual conditions. Even a moderately powered HF
station can cover millions of square miles.

that is the story you folks tell gues you haven't dealt with 6M
repeaters and the coverage is more viable than I think you accept Jim,
althought they are generaly smaller than HF I grant you


The "regulation by bandwidth" proposal has some good basic
concepts, but it needs some serious work before it is ready
for prime time. The fact that so many different groups are
opposed to it, and so few in favor, shows that it needs rework.

Indeed I am not certain why everyone is keying in this discussion on
the ARRL's regualtion by bandwidth proposal or is there only a real
problem with pactor when that proposal is discussed

73 de Jim, N2EY

"John Smith" wrote in message
news
Carl:

I can't say the lack of anything in linux forces me to use windows...
however, the lack of commercial video games written for linux forces me to
revert to windows to run them... "Neverwinter Nights" is an exception, and
is ported to linux, however, the game is now a few years old and I went
on to others and this is the main reason my private computers sport
windows also...

The only factor truly forcing windows on me is other windows users, and I
am paid 85%+ of the time to develop on the windows platform because of
them, and almost exclusively for NT these days (thin clients like cell
phones are an exception)...

Anything windows can do--Linux can do, Linux can just do it better...
windows on the other hand cannot do all which linux can--mostly this is
because of MS having to hold the source secret and pursue proprietary
ends... what is good for MS pockets is not good for the
consumer--generally...

John

John,

I don't disagree ... there are applications (CAD programs and others) that I
*must* use, and running dual-boot and having to shift back and forth and not
have "everything in one place" is just too annoying for me.

I had a Linux box running Fedora Core, but had to repurpose it for something
else and haven't gotten a new machine yet to run Linux on ... but I will.

73,
Carl - wk3c

wrote in message
ups.com...

[snip]

What's your take on such 'robots' on HF, Carl? Should they
be treated just like any other station, or should they have
some special restrictions based on their unattended nature?

Jim, et al,

I don't think that unattended stations should be allowed to "set up camp"
anywhere they choose in the HF bands ... at least until someont *proves(
that they have solved the QRM problems that such stations can and do cause
do to the "hidden terminal" problem.

For now, at least, I think the only reasonable solution is to confine them
to a (reasonably sized - YMMV on what that means and I would need more data
on the "requirements" to pick a number) sub-band so that the machines don't
pound the human operators into submission with their (effectively)
relentless attempts to get a message through. (Let them figure out how to
"play nice" with the other machines first ...)

Should ARRL endorse/standardize/push modes requiring the
purchase of proprietary hardware and software from specific
providers?

I do not believe so ... I think that proprietary modulation techniques and
protocols are "bad" for several reasons:
1) It locks out the expermenters who could, in an "open source" model
provide enhancements, additional features, etc.
2) It prevents people from building their own compatible unit if the want to
and have the necessary level of technical knowledge and skill
3) The lack of competition amongst vendors of compatible hardware
artificially inflates prices to the detriment of the user community.
(I am big on "open consensus standards" - something I do in IEEE 802.)

73,
Carl - wk3c

73 de Jim, N2EY

Carl:

Slackware has zipslack, and if my understanding is correct, you can boot
it right off windows and go into linux, when done with zipslack, you just
terminate like any other app...

I am sure you also know about wine and you can run most any windows
software on the linux boxes with it...

I have never toyed with zipslack even though I have a bunch of zip drives
here, and I think you can install zipslack on any spare partition (or hd)
you have... I run slack 9 with an updated 2.6 kernel...

That would fit most hams who are windows only users, but wish to run a
open source linux app or two for some experimentation...

http://www.slackware.com/zipslack/
http://www.slackware.com

John

On Mon, 22 Aug 2005 02:13:22 +0000, Carl R. Stevenson wrote:


"John Smith" wrote in message
news
Carl:

I can't say the lack of anything in linux forces me to use windows...
however, the lack of commercial video games written for linux forces me to
revert to windows to run them... "Neverwinter Nights" is an exception, and
is ported to linux, however, the game is now a few years old and I went
on to others and this is the main reason my private computers sport
windows also...

The only factor truly forcing windows on me is other windows users, and I
am paid 85%+ of the time to develop on the windows platform because of
them, and almost exclusively for NT these days (thin clients like cell
phones are an exception)...

Anything windows can do--Linux can do, Linux can just do it better...
windows on the other hand cannot do all which linux can--mostly this is
because of MS having to hold the source secret and pursue proprietary
ends... what is good for MS pockets is not good for the
consumer--generally...

John

John,

I don't disagree ... there are applications (CAD programs and others) that I
*must* use, and running dual-boot and having to shift back and forth and not
have "everything in one place" is just too annoying for me.

I had a Linux box running Fedora Core, but had to repurpose it for something
else and haven't gotten a new machine yet to run Linux on ... but I will.

73,
Carl - wk3c

wrote in message
ups.com...

an_old_friend wrote:
wrote:

and why is it a problem I thought CW always got through, yet it needs
protecting from Pactor?

No, CW does *not* "always get through".

Assuming the robot listens before sending well it looks like anything
else I hear about in HF

No, robots do *not* listen before transmitting which is against the
regs and is the crux of the problem.

Brian,

Most of the "robots" *do* (at least make an attempt to) listen before
transmitting ... however the vagaries of propagation and the highly dynamic
nature of usage in the HF bands cause a serious "hidden terminal" problem
and that results in interference (it's unintentional, but still there - and
it happens more with "robots" because their "listen before talk" is not as
effective as a human sending "Is the frequency in use" and being
appropriately patient before blasting away).

A human operator causing QRM is either lousy operating practice or an
accident, a robot blindly causing QRM via it's inherent design is
illegal. One solution might be to come up with a robot which tunes
around it's frequency before transmitting. There's one for you
code-writers to chew on.

Solving the hidden terminal problem on HF for automated stations is a
difficult nut to crack ... in addition to the propagation issues and the
dynamics of usage, there are so many modes that a "robot" would have to
sense/detect/recognize to optimize the "clear channel assessment" and it
would have to do it quasi-continuously ... I'm not saying that it's a
permanently insoluble problem, but for now the mechanisms aren't up to the
level that's needed.

My working group, IEEE P802.22, (http://www.ieee802.org/22) is working on
"cognitive radio," but in response to the FCC's NPRM on license-exempt
devices using geographically unused TV channels ... this situation makes the
"incumbent detection/avoidance/protection" a more soluble problem because
there are a limited number of incumbents, they are high power transmitters
at generally fixed, stable locations, they use the same standards (NTSC,
which will be going away, and ATSC the new digital TV standard), the
spectral characteristics of their transmissions have "features" that are
easily detectable (the NTSC carriers or the DTV "pilot carrier"), etc.

However the "detect and avoid" problem becomes much more difficult in an
environment with many lower powered stations that come and go, whose
locations vary, and who use a wide variety of different modulation
techniques ... again, these problems will likely be solved in the future,
but we're not there yet.

73,
Carl - wk3c