Re: [digitalradio] Re: Busy Detectors

2007-09-19 Thread Steve Hajducek

Hi Jim,

You really must be making a tongue in check joking reply here, that 
is the only way that I can take such a reply as the Amateur Radio 
bands have been broken down into specific use for decades and ever 
changing. I can NOT go down to 14.004Mhz and make a SSB contact as it 
is dedicated to CW as a prime example. On the other hand I can not go 
into the dedicate Phone and lessor Image sub bands and use MT63.

In my opinion, tor the Amateur Radio Service to continue it needs to 
constantly change and adapt to the times and the needs of those that 
the ARS serves and I see it, that does not mean the individual that 
just wants to Rag Chew or Chase Paper ( which I love to do by the 
way), but the larger picture overall and in this day and age that 
also means providing for higher speed digital communications at 
greater BW in support of traffic automation with multiple routing and 
embedded document support for HF e-mail. Creating a sub band for 
traffic automation which has basically always been done, but still 
allowed for peer-to-peer in the mix ( which as always a stupid 
approach) where the sub band is set aside such activity only, keeping 
it away from peer-to-peer and keep peer-to-peer away from it seems to 
be the best solution as then, the only interference to and from such 
activity would be from such activity, it really makes sense to me and 
hopefully it will make sense to those who regulate the Amateur Radio 
Service at the world level.

/s/ Steve, N2CKH


At 11:20 AM 9/18/2007, you wrote:
   Once you set
a precedent that amateur spectrum can be assigned to a specific use,
you open the doors for everyone to claim their piece of the pie.  Just
exactly how would you propose to deal with this?



Re: [digitalradio] Re: Busy Detectors

2007-09-19 Thread Robert Thompson
I was not claiming that SCAMP *did* violate; I just had no information.

Given that SCAMP didn't directly link to or modify any GPL code, the
following is slightly off-topic...

By the way, a very good resource for what the GPL *really* does and
does not mean is at http://www.gnu.org/licenses/  . If you see a
contradiction between what I say and information found at that url,
I'm the one in error.


In general, the GPL source distribution clauses trigger on a
release. This means that, if the project was released (even
limited-distribution), the source must be made available to those
people at the same time.

The free-software world doesn't focus on finished products. The
philosophy is that *any* member of the community is free to improve
upon anything, and that useful improvements benefit everyone, no
matter who wrote them. This isn't possible if only finished code is
released.

Something with widespread value in the community tends to get
widespread development. A niche project may only see a couple of
developers. If they get bored and quit, the GPL is designed to
preserve their progress for the next generation of
developers/experimenters. After all, just because it didn't do what
*you* needed doesn't mean that someone else won't find it useful.

Note that GPL code isn't free. In exchange for full access to the
community-developed code, you promise that all improvements will be
contributed back to the community on the same terms as you received
it.

 Further, how can you insist a developer do a general release on an
 experimental or research project? This is especially true when the project
 did not reach fruition, i.e. a general release. I have a number of
 half-baked projects on my system. I would hate to have to release them

How can you insist that only finished products can benefit others?
If nothing else, learning your 30,000 ways *not* to make a lightbulb
may save someone else wasted time and effort.  Besides, if they were
not distributed to anyone, the GPL doesn't make you release the code.
The rule is that any binary you distribute must be accompanied by the
source used to make it (if it's just modifications to
already-available code, diffs sufficient to rebuild this binary from
source are acceptable) or an offer to provide the source on request.

If you don't sell or give away *any* copies of the program, you need
not make the source available.

Incidentally, you *can* charge money for the product, however you
cannot add any restrictions beyond those already embodied in the GPL,
so your customer can legally treat it as any other GPL-licensed
product they downloaded: They can give it away, distribute the source,
modify the source (and distribute the modified source), or even *sell*
it (just like you did). It is quite possible to make money with
GPL-based systems, just not by treating the software itself as secret
sauce.


Assuming anyone is still reading, I should make clear that I usually
distribute my own code as unrestricted public domain code. This means
that, like any public domain material, you can pretty much do anything
you want with it, you just can't de-public-domain it. You can even
re-release it under any license you want (with or without changes to
the code), you just can't claim the original code(or third-party
modifications to it) violates your license or rights.

The bottom line on the GPL: It enshrines others' right to stand on
your shoulders just as you stood on the shoulders of previous giants.


Re: [digitalradio] Re: Busy Detectors

2007-09-19 Thread Robert Thompson
My comments are interspersed.

On 9/18/07, Rick [EMAIL PROTECTED] wrote:
 My comments interspersed with Mr. Thompsons
 - - - - -



 The complete SCAMP specification is available and will be released under
 the GPL as a blueprint for client developers to insure compatibility
 across different implementations. Muething says further protocol
 optimization continues to up system throughput and improve its robustness
 in poor HF multipath channels.

If the only third party GPL code was aggregated (by calling external
binaries, or a few other ways), then all code generated by the SCAMP
developers is GPL if and  only if they actually release it under that
license. Moreover, the original developers can do anything they want
with the code (including dual-license release, suddenly change the
license for future releases, etc). This is of course only true as long
as *all* the code in question is their own property. In the SCAMP
case, it appears that this might be true since the RDFT code was
apparently only externally called.

 
  Did anyone ever test the busy channel detect code by intentionally
  holding a qso on the frequencies used by SCAMP? That would be an
  interesting and useful test.
 

 You could not initiate a transmission until the frequency was clear
 within the passband. Once you started transmitting the assumption was
 that you had the frequency and any other transmission were interfering
 with you and it would work through noise/QRM, to the best of its ability.

Specifically, if someone was already holding a SSB QSO (one of the
more difficult standard cases), would it successfully hold off until
they abandoned the frequency before initiating its own traffic? It's
well known that modes that concentrate their energy into a relatively
narrow bandwidth are easy to detect compared to noise-distribution
modes. SSB is somewhat difficult, as it tends to spread the energy in
a way that tends not to peak when integrated over a one or two
second window. What I'm trying to find out is if the algorithm was
just a standard windowed fft (with possibly a few flourishes like
automatic thresholding) or whether it was something fundamentally new.

 
  In practice, one way propagation is more of an issue than you'd think.
  A human in Seattle talking to an automatic node in Dallas may cause
  problems with a human-to-human QSO from Boston to Europe, especially
  if low power or compromise antennas are being used. Neither the west
  coast human nor the robot is likely to hear the European human.
 
 Nothing is perfect of course, but one way propagation is not peculiar to
 automatic operation. As long as both sides have the ability to hear what
 is on the frequency before transmitting you would be no different than
 two human operators, so I consider it to be a mute point in all this.

The issue is that if a human is involved, at worst everyone shrugs and
figures he's an impolite operator. If an automatic station is
involved, it is the evil enemy and deep dark motives are imputed to
its operator. An automatic station should properly achieve a higher
standard than a human operator, if only because it is less able to
apologize and abort, but it seems that many human operators are
unwilling to accept anything short of perfection. Anything that *can*
be attacked *will* be attacked, regardless of whether a human would
have done any better.

While I don't think that intentional interference (or even intentional
operation of a configuration that is likely to interfere) is
acceptable, I  also think that the rabid attack of automated digital
modes tends to drive developers away, thus preventing significant
improvement in the modes.


Re: [digitalradio] Re: Busy Detectors

2007-09-19 Thread Rick
To the best of my recollection, any signals within the passband would 
prevent a transmission. Even fleeting ones like voice SSB, but it was 
not as affected by wide band noise as much, even static crashes. I don't 
know if it was more than what you ask, but I will say that most 
reasonable hams would be quite  impressed with the ability to not 
transmit except on a clear frequency.

73,

Rick, KV9U


Robert Thompson wrote:

 Specifically, if someone was already holding a SSB QSO (one of the
 more difficult standard cases), would it successfully hold off until
 they abandoned the frequency before initiating its own traffic? It's
 well known that modes that concentrate their energy into a relatively
 narrow bandwidth are easy to detect compared to noise-distribution
 modes. SSB is somewhat difficult, as it tends to spread the energy in
 a way that tends not to peak when integrated over a one or two
 second window. What I'm trying to find out is if the algorithm was
 just a standard windowed fft (with possibly a few flourishes like
 automatic thresholding) or whether it was something fundamentally new.
   


Re: [digitalradio] Re: Busy Detectors

2007-09-19 Thread Robert Thompson
I'm glad to hear that. It sounds like it's implemented the obvious
way, and thus should be very easy to duplicate. I'll try to set up a
test harness and see whether I can duplicate its functionality.

If I do, I'll report success here.


On 9/19/07, Rick [EMAIL PROTECTED] wrote:
 To the best of my recollection, any signals within the passband would
 prevent a transmission. Even fleeting ones like voice SSB, but it was
 not as affected by wide band noise as much, even static crashes. I don't
 know if it was more than what you ask, but I will say that most
 reasonable hams would be quite  impressed with the ability to not
 transmit except on a clear frequency.

 73,

 Rick, KV9U


 Robert Thompson wrote:
 
  Specifically, if someone was already holding a SSB QSO (one of the
  more difficult standard cases), would it successfully hold off until
  they abandoned the frequency before initiating its own traffic? It's
  well known that modes that concentrate their energy into a relatively
  narrow bandwidth are easy to detect compared to noise-distribution
  modes. SSB is somewhat difficult, as it tends to spread the energy in
  a way that tends not to peak when integrated over a one or two
  second window. What I'm trying to find out is if the algorithm was
  just a standard windowed fft (with possibly a few flourishes like
  automatic thresholding) or whether it was something fundamentally new.
 



Re: [digitalradio] Re: Busy Detectors

2007-09-18 Thread Robert Thompson
On 9/17/07, Dave Bernstein [EMAIL PROTECTED] wrote:
 +++More AA6YQ comments below

 --- In digitalradio@yahoogroups.com, Robert Thompson
 [EMAIL PROTECTED] wrote:
 
  On 9/17/07, Dave Bernstein [EMAIL PROTECTED] wrote:

  Two years ago, SCAMP demonstrated a multi-mode busy detector for
 HF that proved highly effective, despite the fact that it was a
 quickand dirty first attempt.


I would *love* to see either code or a large-scale test, including
prearranged intentional usage on a busy channel. If both false
positive rate and false negative rate are good enough, this could
easily be the way forward for many different projects.

 The hard part isn't the *busy* channel detection, it's the *clear*
 channel detection.  As long as *clear* channel detection (Clear to
 Send) generates so many missed transmission opportunities, people
 will disable it. After all, it's the one change that will
 dramatically improve their message delivery throughput, so barring a
 gun to the head, why would they *not* disable it?

 +++For the same reason that most of us don't run with 10 KW output
 power or 10 kHz of bandwidth on HF -- because it would be a violation
 of both amateur radio regulations and operating practice. We should
 not allow our equipment to transmit over top an existing QSO if its
 possible to prevent it.

This is only true if both parties respect the other party's rights and
trust the other party to reciprocate. In general, non-automated users
resent the automated stations and often regrettably attempt to
interfere. Given this fact, the automated station operators are often
unwilling to enable features that can be used by others to destroy the
automatic stations' functionality. Note that I am not saying this
*should* happen, but that given human nature, it *does*.

 snip

 Actually your statistics are misleading. The detector isn't rolling
 the dice once for the QSO, it's rolling the dice once, coming
 up Busy, holding off n seconds, rolling the dice again, coming
 up Busy, etc... four of five (forty or fifty, whatever) events
 later, it comes up (falsely) Clear and *then* steps on the QSO.
 Think Russian Roulette, not Busy signal... =) Especially since,
 if the unattended station is doing a stream protocl, it's not going
 to stop transmitting for some time.

 +++There are two important characteristics of a busy frequency
 detector: its success rate (the fraction of truly busy frequency
 conditions that are correctly identified) and its false positive rate
 (the fraction of truly not-busy frequency conditions that are
 incorrectly identified). I suggested that a busy frequency detector
 with an 80% success rate would reduce QRM to ongoing QSOs by a factor
 of 5; you say this statistic is misleading, but offer no explanation;
 please elaborate.

The problem is that a one-shot accuracy of 80% is trivially
achievable, but real use isn't one-shot. My probability-math reference
is at home out of reach at the moment, so I can't just quote you the
formula to determine the actual probability of failure given repeated
one-shot attempts. The bottom line, however, isn't good.

An example follows:

There is an ongoing SSB QSO on a given frequency. The automated
station begins listening for a couple of seconds, and (correctly)
detects activity on the frequency. It initiates a hold-off for N
seconds. N seconds pass. It listens again, and (correctly) detects
activity, initiating another hold-off. This sequence repeats for a few
times until statistics catch up with us and it (erroneously) detects a
clear channel and begins transmitting. Thus, assuming an 80% success
rate and a hold-off algorithm that is reasonably balanced for both
avoiding interference *and* efficiently using a  shared channel (5
seconds  N  60 seconds), over the course of a ten minute QSO,  the
chance that the automatic station will interfere approaches unity.

If you pick too big of an N, the automatic station wastes lots of time
waiting on the channel to clear. If you pick too small of an N, your
busy detector's error rate increases the chance of a failure. In
either case, one party suffers unduly.

This is ignoring that in the above SSB case, even a continuous
detector is going to misdetect periods of silence or other reduced
modulation as channel now empty.






 +++There is clearly a tradeoff between a busy frequency detector's
 success rate and its false positive rate. That's one reason I'm
 assuming an 80% success rate -- to permit a reasonably low false
 positive rate.


I'm only arguing that the one-shot success rate needs to be much
greater than 80% to result in ruining only one out of 5 QSOs on
frequency.

On the wider discussion of automated stations and non-automated
stations sharing spectrum, I suspect that the way forward will
actually involve changes on both sides.

An example: If the initiating member of the automatic conversation
would, after the busy detector says the frequency is clear, use some
standard modulation to ask Is this 

RE: [digitalradio] Re: Busy Detectors

2007-09-18 Thread Rud Merriam
The code for busy detect, ARQ, etc was not GPL'd. It was their own work.
Since it was all research it probably was not the cleanest implementation. 

While replying to your previous message I was wondering about sub-audible
tones being included in transmission, ala repeater tone usage. 

 
Rud Merriam K5RUD 
ARES AEC Montgomery County, TX
http://TheHamNetwork.net


-Original Message-
From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Robert Thompson
Sent: Tuesday, September 18, 2007 1:57 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: Busy Detectors



If there was GPL code involved, they are in violation of the license of the
code they borrowed.  Distributing only a binary (with or without suicide
timers) is to put it mildly, EXTREMELY in violation of the spirit as well as
the letter of that license. Of course, if they themselves wrote *all* of the
code in use, there is no limitation on what they can themselves do with it.
(This exception vanishes if they release their code as GPL to make it
compatible with other GPL code they're using, then fail to actually comply
with the GPL for their own code.

snip

A practical solution may also require some change in expectations on the
part of pure human-to-human qso partners, too.

Regards, Robert Thompson


Announce your digital presence via our Interactive Sked Page at
http://www.obriensweb.com/drsked/drsked.php
 
Yahoo! Groups Links







Re: [digitalradio] Re: Busy Detectors

2007-09-18 Thread Robert Thompson
On 9/17/07, Rick [EMAIL PROTECTED] wrote:
 Robert,

 I have brought this up many times, but there are new people that may not
 be aware of the SCAMP (Sound Card Amateur Messaging Protocol) testing

I am slightly aware of this. However, I haven't seen any code or
large-scale busy-channel testing.

 that we did several years ago. I spent many hours with this technology
 and I can tell you that it is an outstanding program. I am not sure why
 the software author thought that RDFT was going to operate down close to
 zero dB. Some of us pointed out that it was not reasonable considering

Yes, I played with some of that code for a while. I'm personally more
interested in a low-data-rate ad-hoc message passing architecture that
works at very low SNR and bandwith, giving away data rate as necessary
to achieve the other constraints. 75 baud would be quite enough for my
specific interest.


 that the Linux source was used by other programmers to develop the first
 SSTV programs and we knew that they required signals well above the
 noise.  Unfortunately when the program did not work as well as expected
 they completely abandoned it (and us) and worse, had timers to insure
 that the software would self destruct so that no one else could use it
 or share it with anyone. To say that I was appalled is putting it mildly.

If there was GPL code involved, they are in violation of the license
of the code they borrowed.  Distributing only a binary (with or
without suicide timers) is to put it mildly, EXTREMELY in violation of
the spirit as well as the letter of that license. Of course, if they
themselves wrote *all* of the code in use, there is no limitation on
what they can themselves do with it. (This exception vanishes if they
release their code as GPL to make it compatible with other GPL code
they're using, then fail to actually comply with the GPL for their own
code.



 At the time that SCAMP was developed, the common wisdom (that is often
 not that wise) said that you could not do what you also claim can not be

To clarify: I'm not claiming that it cannot be done. I'm claiming that
no simple and reliable repeatable methods of doing this have thus far
been demonstrated. To contradict an old saying, the proof isn't in the
pudding, it's in the recipe ;)


 done, with detecting and responding to many different waveforms, and
 within a given bandwidth, and at a certain level, and that it could be
 adjustable. SCAMP proved them wrong. Steve Ford, WB8IMY, who is now QST
 Editor and long time digital promoter, and others such as myself, were
 able to get the software up and running and made connections through one
 of the three SCAMP HF servers that were then available.

Did anyone ever test the busy channel detect code by intentionally
holding a qso on the frequencies used by SCAMP? That would be an
interesting and useful test.


 The timing feature (like throwing dice) is basically the same concept we
 use in networking such as ethernet to reduce (but not completely avoid)
 collisions. It is an excellent feature but could be changed any way you
 wanted, assuming you had a better way. Even if modulation stops within
 the passband, it does not necessarily mean that the frequency is no
 longer in use, it could mean that the other station is now transmitting
 and can not hear the signals.

Note that IEEE-802.11b/g don't even try to do serious free-channel
detection and collision detection. It turns out that a simple
modulation energy detector (for busy channel detection; only reliably
detects other 802.11b/g packets otherwise bluetooth users would
*totally* jam the channel) and missing-ACK retry-backoff were the best
solutions anyone could find.  Unfortunately for amateur
shared-spectrum use, these tend to ruin the channel for
non-ACK/non-packetized protocols (such as SSB/CW/RTTY, etc) and thus
other solutions must be found.


 But if a human operator is on one side with a modicum of ability to
 detect a busy frequency, and the robot side has some kind of ability to
 detect a busy frequency, then you don't have the main issue of the
 hidden transmitter problem (unless maybe some unusual one way propagation).

In practice, one way propagation is more of an issue than you'd think.
A human in Seattle talking to an automatic node in Dallas may cause
problems with a human-to-human QSO from Boston to Europe, especially
if low power or compromise antennas are being used. Neither the west
coast human nor the robot is likely to hear the European human.


 Bottom line is the busy frequency detection has been invented, it works
 well, and no one should be arguing about whether it can work. What they

Even granting for a moment that it provably works well for one use
doesn't mean that it would work well for all uses. An example for
which it would work poorly is a situation where you have short
packetized conversations (aprs or similar, or short-burst-message or
similar). It is unreasonable to expect such a user to inspect the
channel for 

RE: [digitalradio] Re: Busy Detectors

2007-09-18 Thread Rud Merriam
In conjunction with getting contributions and collaboration for my site (see
sig line) I exchanged a few message with Rick KN6KB. I asked him for the
details on the SCAMP busy detect. He added digging out the details to a long
to-do list. He did indicate that detecting narrow band protocols (PSK, etc)
was fairly easy. Detecting broadband protocols is much more difficult
because when working properly they appear as noise, as per Claude Shannon.
He did not indicate whether voice could be detected. 

 
Rud Merriam K5RUD 
ARES AEC Montgomery County, TX
http://TheHamNetwork.net


I would *love* to see either code or a large-scale test, including
prearranged intentional usage on a busy channel. If both false positive rate
and false negative rate are good enough, this could easily be the way
forward for many different projects.




Re: [digitalradio] Re: Busy Detectors

2007-09-18 Thread Robert Thompson
If *any* code they link to was GPL, their code is GPL or in violation
of the GPL. This is true of code they cut-and-paste, code they use as
a library and link to, but not code where they call an unmodified GPL
external program.

The idea behind the GPL is that you cannot freeload on the work of the
community. If you improve a tool, the improvements must be returned to
the community under the same terms as you received the original tool.

As far as subaudible tones are concerned, the real issue is how they
would affect the (human) mode. In SSB, they'll look like fixed
carriers offset from zero. This is easy to detect as signal, thus
busy, even if you can't reliably decode them (you need to know what
their dial frequency and USB/LSB setting is to know what that
carrier represents, but then you don't *need* to know)

For FSK, they would be pointless, as there's already one or another
carrier that is itself detectable. They would also create a two-tone
situation which would cause problems with linearity and crest factor.
There are similar issues with PSK and similar. With CW, there's also
no reason.


I would expect that AM voice would be detectable (due to the carrier),
ssb would be difficult, any of the wide/noise-like modulations would
be difficult to detect as well. Anything narrow, or with high energy
in a narrow bandwith, should be easily detected. Multitone modes with
relatively few carriers would be easy for this reason; numerous
carriers spread the energy and make it harder to detect unless you
know exactly where the carriers are expected to be.

I can think of several relatively trivial ways to detect the
high-energy/narrow easy cases, but SSB voice and
broadband/noise-like modulations... those are the real challenge.

Just off of the top of my head, say, take a one-second-window FFT of
the signal, find the total energy in the spetrum, then find if it's
relatively evenly spread or concentrated in a few buckets. The second
case is likely a busy channel.



On 9/18/07, Rud Merriam [EMAIL PROTECTED] wrote:
 The code for busy detect, ARQ, etc was not GPL'd. It was their own work.
 Since it was all research it probably was not the cleanest implementation.

 While replying to your previous message I was wondering about sub-audible
 tones being included in transmission, ala repeater tone usage.


 Rud Merriam K5RUD
 ARES AEC Montgomery County, TX
 http://TheHamNetwork.net


 -Original Message-
 From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On
 Behalf Of Robert Thompson
 Sent: Tuesday, September 18, 2007 1:57 PM
 To: digitalradio@yahoogroups.com
 Subject: Re: [digitalradio] Re: Busy Detectors



 If there was GPL code involved, they are in violation of the license of the
 code they borrowed.  Distributing only a binary (with or without suicide
 timers) is to put it mildly, EXTREMELY in violation of the spirit as well as
 the letter of that license. Of course, if they themselves wrote *all* of the
 code in use, there is no limitation on what they can themselves do with it.
 (This exception vanishes if they release their code as GPL to make it
 compatible with other GPL code they're using, then fail to actually comply
 with the GPL for their own code.

 snip

 A practical solution may also require some change in expectations on the
 part of pure human-to-human qso partners, too.

 Regards, Robert Thompson


 Announce your digital presence via our Interactive Sked Page at
 http://www.obriensweb.com/drsked/drsked.php

 Yahoo! Groups Links







 Announce your digital presence via our Interactive Sked Page at
 http://www.obriensweb.com/drsked/drsked.php

 Yahoo! Groups Links






-- 

Regards, Robert Thompson


~   Concise, Complete, Correct: Pick Two
~   Faster, Cheaper, Better: Pick Two
~   Pervasive, Powerful, Trustworthy: Pick One
~Whom the computers would destroy, they first drive mad.
~-- Anonymous



Re: [digitalradio] Re: Busy Detectors

2007-09-18 Thread Steve Hajducek

Hi Jim,

You really must be making a tongue in check joking reply here, that 
is the only way that I can take such a reply as the Amateur Radio 
bands have been broken down into specific use for decades and ever 
changing. I can NOT go down to 14.004Mhz and make a SSB contact as it 
is dedicated to CW as a prime example. On the other hand I can not go 
into the dedicate Phone and lessor Image sub bands and use MT63.

In my opinion, tor the Amateur Radio Service to continue it needs to 
constantly change and adapt to the times and the needs of those that 
the ARS serves and I see it, that does not mean the individual that 
just wants to Rag Chew or Chase Paper ( which I love to do by the 
way), but the larger picture overall and in this day and age that 
also means providing for higher speed digital communications at 
greater BW in support of traffic automation with multiple routing and 
embedded document support for HF e-mail. Creating a sub band for 
traffic automation which has basically always been done, but still 
allowed for peer-to-peer in the mix ( which as always a stupid 
approach) where the sub band is set aside such activity only, keeping 
it away from peer-to-peer and keep peer-to-peer away from it seems to 
be the best solution as then, the only interference to and from such 
activity would be from such activity, it really makes sense to me and 
hopefully it will make sense to those who regulate the Amateur Radio 
Service at the world level.

/s/ Steve, N2CKH


At 11:20 AM 9/18/2007, you wrote:
   Once you set
a precedent that amateur spectrum can be assigned to a specific use,
you open the doors for everyone to claim their piece of the pie.  Just
exactly how would you propose to deal with this?



Re: [digitalradio] Re: Busy Detectors

2007-09-18 Thread Robert Thompson
On 9/18/07, Rud Merriam [EMAIL PROTECTED] wrote:
 In conjunction with getting contributions and collaboration for my site (see
 sig line) I exchanged a few message with Rick KN6KB. I asked him for the
 details on the SCAMP busy detect. He added digging out the details to a long
 to-do list. He did indicate that detecting narrow band protocols (PSK, etc)
 was fairly easy. Detecting broadband protocols is much more difficult
 because when working properly they appear as noise, as per Claude Shannon.
 He did not indicate whether voice could be detected.

Very cool. If you ever get this information, please share! If Rick is
comfortable with it, I'd love to get details; if not, even a general
outline would be useful.

What you describe is pretty much what I'd expect from the method I
described in my previous message. The voice and noise-like
modulation pieces might end up needing much more complex detectors.
I'd expect SSB to get detected some of the time, if a high-modulation
burst hit during the busy-analysis window.

A related but not identical challenge would be to find the listen
window period that results in best busy-detection yet impacts the
turnaround and transmission/message delay for the automated stations.
Too long of a listen window both places more stress on the busy
channel logic and significantly reduces the rate at which messages
(or whatever) can be transferred between automated nodes. Too short a
window leads to misdetecting the gaps in a QSO as clear channels.

Regards, Robert Thompson


Re: [digitalradio] Re: Busy Detectors

2007-09-18 Thread Robert Thompson
On 9/18/07, Dave Bernstein [EMAIL PROTECTED] wrote:
 AA6YQ comments below
 The problem is that a one-shot accuracy of 80% is trivially
 achievable, but real use isn't one-shot. My probability-math reference
 is at home out of reach at the moment, so I can't just quote you the
 formula to determine the actual probability of failure given repeated
 one-shot attempts. The bottom line, however, isn't good.

 That would be true if the trials were independent, but they are
 not. For example, If the busy detector detects modulation on three
 successive samples, then it can conclude that a QSO is in progress,
 and set a substantially higher threshold for inactivity before
 assuming the frequency is clear. One would not implement a busy
 detector as a simple binary device that returns busy or not busy; its
 a context-driven state machine.

Yes, a bounded-backoff mechanism would almost certainly be necessary.
I would probably also choose to implement a detector that required the
channel to appear clear for several sequential tests before
initiating communication if this station had not been using this
channel in the past few minutes. The problem is that too long of a
listen window, or too long of a QSO-tail overshoot can *seriously*
impact a station that has a large stack of traffic to pass, especially
if each message is separated by a gap to allow other automated users
to communicate with the same station. Of course, such a situation
would result in high enough channel usage that it would be unlikely
any human would honestly believe the frequency was free. Thus, I guess
it's a non-issue.



 An example follows:

 There is an ongoing SSB QSO on a given frequency. The automated
 station begins listening for a couple of seconds, and (correctly)
 detects activity on the frequency. It initiates a hold-off for N
 seconds. N seconds pass. It listens again, and (correctly) detects
 activity, initiating another hold-off. This sequence repeats for a few
 times until statistics catch up with us and it (erroneously) detects a
 clear channel and begins transmitting.

 This would be a suboptimal design. Once a QSO is known to be in
 progress on the frequency, the busy detector should not return not
 busy based on a single modulation-free sample. At the first
 modulation-free sample during a QSO in progress condition, the busy
 detector might begin sampling every 15 seconds and only change state
 to not busy after seeing, say, 3 minutes without any modulation on
 the frequency.

See the above response. I suspect that it would take much trial and
error to actually pick numbers that work well, but I agree that such
numbers could be picked. Actually, this is the case where IMO the
automated station(s) should switch to another of the monitored
frequencies. If you study the problemspace ALE is actually designed to
solve, many ways of improving automated station operation in presence
of busy-channel conditions make themselves obvious. No need to
actually use ALE itself . That's a debate for another time, and other
than compatibility with hardware ALE, I'm not convinced there is a
reason to pick the ALE modulation and state machine. However, whether
you use ALE waveforms or not, letting the server station scan
multiple contact frequencies, and the client station try to initiate
on a frequency that is idle (retrying on different frequencies in the
list until successful) is just an obvious solution.



 Waiting 3 minutes for a QSO to clear doesn't seem like undue
 suffering for a message-passing system --- except during emergency
 conditions, during which the busy detector would be disabled.

Unless the automated station actually owns the frequency (at least
in  emergency times), it would probably be a wise idea to merely
reduce the listen window and shorten the maximum backoff time. The
busy detector, if it works, is important to efficient shared-channel
use between message-passing nodes, and there is also the issue that
the stepped upon QSO might itself be life-and-safety traffic.



 This is ignoring that in the above SSB case, even a continuous
 detector is going to misdetect periods of silence or other reduced
 modulation as channel now empty.

 A universal QRL signal would allow busy detectors to be less
 conservative -- if an automated station's transmitter was given a
 premature go-ahead, one of the participants in the QRM'd QSO could
 send QRL (just as happens today between attended stations), which the
 automated station would instantly respect.

An alternate way of doing this: When initiating traffic on a channel
that the busy detector said was free, make the automated (or
human/automated) station merely initiate its traffic with a this
channel in use? canned emission in some standard modulation
(synthetic/recorded SSB, 5 or 10 wpm morse etc) and wait some short
period listening for *ANY* detectable signal. The we're here, go
away signal should be at least 10 seconds long, so the detector can
avoid noise-triggering. Assuming 

Re: [digitalradio] Re: Busy Detectors

2007-09-18 Thread Robert Thompson
 We seem to be on the same wavelength here...


Now, to break it own into small enough chunks that it fits into time
away from work an d such... I actually have been working on some code
for things like the busy detector and connection-logic state machines
in my spare time. I may even have something worth experimenting with
in another year or so...


RE: [digitalradio] Re: Busy Detectors

2007-09-18 Thread Rud Merriam
The SCAMP testing only used the RDFT executables, not the original source
code modified or included in other programs. The GPL does not apply to their
use. Specifically from the GPL COPYING.TXT accompanying RDFT:

In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.

SCAMP was an aggregation, not a derivative work.

RDFT is a set of command line utilities that take a file, process it, and
creates a .wav file. The .wav is transmitted and received using the OS media
player. RDFT takes the received .wav, processes it and generates an output
file. Rick used those command lines combined with other utilities he wrote.

All this is available from the TAPR DCC proceedings where Rick published his
work. 

Further, how can you insist a developer do a general release on an
experimental or research project? This is especially true when the project
did not reach fruition, i.e. a general release. I have a number of
half-baked projects on my system. I would hate to have to release them
simply because part of them used GPL code. Most would be misleading because
they did not accomplish their purpose. Some would be embarrassing for
various reasons.



 
Rud Merriam K5RUD 
ARES AEC Montgomery County, TX
http://TheHamNetwork.net


-Original Message-
From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Robert Thompson
Sent: Tuesday, September 18, 2007 3:16 PM
To: digitalradio@yahoogroups.com
Subject: Re: [digitalradio] Re: Busy Detectors


If *any* code they link to was GPL, their code is GPL or in violation of the
GPL. This is true of code they cut-and-paste, code they use as a library and
link to, but not code where they call an unmodified GPL external program.

The idea behind the GPL is that you cannot freeload on the work of the
community. If you improve a tool, the improvements must be returned to the
community under the same terms as you received the original tool.




Re: [digitalradio] Re: Busy Detectors

2007-09-18 Thread Rick
Thanks for your clarification of the GPL use in this case, Rud.

The reason for expecting Rick to GPL the code is because he said that he 
was going to GPL the code. Pretty clear cut.

73,

Rick, KV9U



Rud Merriam wrote:
 The SCAMP testing only used the RDFT executables, not the original source
 code modified or included in other programs. The GPL does not apply to their
 use. Specifically from the GPL COPYING.TXT accompanying RDFT:

 In addition, mere aggregation of another work not based on the Program
 with the Program (or with a work based on the Program) on a volume of
 a storage or distribution medium does not bring the other work under
 the scope of this License.

 SCAMP was an aggregation, not a derivative work.

 RDFT is a set of command line utilities that take a file, process it, and
 creates a .wav file. The .wav is transmitted and received using the OS media
 player. RDFT takes the received .wav, processes it and generates an output
 file. Rick used those command lines combined with other utilities he wrote.

 All this is available from the TAPR DCC proceedings where Rick published his
 work. 

 Further, how can you insist a developer do a general release on an
 experimental or research project? This is especially true when the project
 did not reach fruition, i.e. a general release. I have a number of
 half-baked projects on my system. I would hate to have to release them
 simply because part of them used GPL code. Most would be misleading because
 they did not accomplish their purpose. Some would be embarrassing for
 various reasons.



  
 Rud Merriam K5RUD 
 ARES AEC Montgomery County, TX
 http://TheHamNetwork.net

   


Re: [digitalradio] Re: Busy Detectors

2007-09-18 Thread Steve Hajducek

Hi Jim,

A good analogy of sharing spectrum between peer-to-peer and 
remote-to-automated is like a car or any size sharing a single road 
lane with a tractor trailer, where both are competing to have the 
lane, the outcome is clear in the long run, however what would be 
better, especially for the car, is separate lanes for like vehicles 
of transport.

Within the current Amateur Radio Service rules and regulations the 
limitations imposed and conflicts caused  are not in the best 
interest of the future of the ARS and many of the purposes for the 
ARS existence in my opinion.

I am in agreement with the point you make below to the extent that we 
need to convince the powers to be that bandwidth and mode spectrum 
allocation is needed. In addition, I believe that in the digital 
world of peer-to-peer vs. remote-to-automated applications,  sub band 
management, call it arrogant or anything else you like, it is the 
only logical and 100% effective way to mitigate co-channel 
interference between these two categories of operations where the ARQ 
based operations in either category suffer the least amount of 
negative affects.

/s/ Steve, N2CKH

At 11:09 PM 9/18/2007, you wrote:
Until someone can convince the FCC to change tradition and move away
from shared amateur spectrum to a assigned channels for different
modes/purposes, we will need to share.



Re: [digitalradio] Re: Busy Detectors

2007-09-17 Thread Simon Brown
I misread your posting as 'I suggest medication' - possibly more 
appropriate.

Simon Brown, HB9DRV

- Original Message - 
From: Dave Bernstein [EMAIL PROTECTED]

 For those convinced that the world is out to get them (or their
 favorite modes), I suggest meditation. 



Re: [digitalradio] Re: Busy Detectors

2007-09-17 Thread John Becker, WØJAB
Not really Dave.
I pulled the audio going to one of the other TNC's and 
ran that into the laptop that has the hell software on it 
to copy him. was an RX only setup.

At 11:03 AM 9/17/2007, you wrote:
Since you'd decoded N4CE's callsign, at least you had the option of 
sending back a QRL message -- in either Hell or CW. That would not 
be the case had you been QRM'd by an unattended station.



RE: [digitalradio] Re: Busy Detectors

2007-09-17 Thread Rud Merriam
How many times is a QSO busted because neither the attended or unattended
stations could hear the QSO?

I suspect this happens more frequently than most like to consider. It is
easier to get aggravated. 

 
Rud Merriam K5RUD 
ARES AEC Montgomery County, TX
http://TheHamNetwork.net


-Original Message-
From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Bernstein
Sent: Monday, September 17, 2007 1:23 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Busy Detectors


When an attended station attempts to activate an unattended automatic 
station on some frequency, an ongoing QSO on the same frequency could 
be inaudible to the attended station, but easily copied by the 
unattended station; from the perspective of the attended station, the 
participants in that ongoing QSO are hidden transmitters. A properly 
configured busy detector in the unattended station would prevent the 
ongoing QSO from being QRM'd -- the unattended station would simply 
not respond to the attended station's attempted activation because it 
knows that by doing so it would QRM an ongoing QSO.


   73,

   Dave, AA6YQ



RE: [digitalradio] Re: Busy Detectors

2007-09-17 Thread Steve Hajducek

Hello Rud,

How often does a remote users sending traffic through an automated 
station have to wait due to an exasberated number of ARQ retries due 
to stations purposely transmitting CQ's or whatever just because they 
don't care that its not a two-way QSO that is inhabiting the channel. 
It's more than a two way street, worst when you consider that the 
human factor does what it does knowingly and without regard to the 
remote automated station user.

Again, what is really needed for the ARS to grow and continue to be 
of value is set aside spectrum for traffic automation where 
peer-to-peer steer clear, then we shall have the best of situation. 
Until that happens its just going to be what we have now, which is 
not the best situation from either perspective.

/s/ Steve, N2CKH

At 02:46 PM 9/17/2007, you wrote:
How many times is a QSO busted because neither the attended or unattended
stations could hear the QSO?

I suspect this happens more frequently than most like to consider. It is
easier to get aggravated.


Rud Merriam K5RUD
ARES AEC Montgomery County, TX
http://TheHamNetwork.net


-Original Message-
From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Dave Bernstein
Sent: Monday, September 17, 2007 1:23 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Busy Detectors


When an attended station attempts to activate an unattended automatic
station on some frequency, an ongoing QSO on the same frequency could
be inaudible to the attended station, but easily copied by the
unattended station; from the perspective of the attended station, the
participants in that ongoing QSO are hidden transmitters. A properly
configured busy detector in the unattended station would prevent the
ongoing QSO from being QRM'd -- the unattended station would simply
not respond to the attended station's attempted activation because it
knows that by doing so it would QRM an ongoing QSO.


73,

Dave, AA6YQ



Announce your digital presence via our Interactive Sked Page at
http://www.obriensweb.com/drsked/drsked.php

Yahoo! Groups Links






Re: [digitalradio] Re: Busy Detectors

2007-09-17 Thread John Becker, WØJAB
Sure Dave.
I could have pulled the keyer from the other rig and plugged
in into this rig. But with a lot of no code hams on the HF bands
I pretty much gave up on that idea.

At 01:27 PM 9/17/2007, you wrote:
Could you not switch to CW and send QRL pse QSY at 10 wpm?








Re: [digitalradio] Re: Busy Detectors

2007-09-17 Thread John Becker, WØJAB
Really Dave I had no way of doing it easy.
But since he is in Houston and the guy I was in QSO with
was in Dallas I can't help but to think he did hear one of us.
But you know how it is when you hear a pactor signal.
Who really cares it's just pactor.

I guess next time it will be 1.5 KW that should do it right?


At 02:51 PM 9/17/2007, you wrote:
In other words, you didn't even try. 

If you choose to not inform a QRMing station that the frequency is in 
use, then its on you, IMHO.



















Re: [digitalradio] Re: Busy Detectors

2007-09-17 Thread Robert Thompson
On 9/17/07, Dave Bernstein [EMAIL PROTECTED] wrote:


 Two years ago, SCAMP demonstrated a multi-mode busy detector for HF
 that proved highly effective, despite the fact that it was a quick
 and dirty first attempt. Deploying this busy detector on WinLink
 PMBOs would eliminate most of the inadvertent disruption to ongoign
 QSOs fro which they are responsible. Further development of the SCAMP
 busy detector would undoubtedly improve its effectiveness. Thus your
 statement It is very much not feasible to detect all likely
 modulations, especially in non-ideal real world HF channel
 conditions was demonstrated to be false years ago.


Has this been widely tested by third parties on a large number of
differing HF channel conditions? The hard part isn't the *busy*
channel detection, it's the *clear* channel detection.  As long as
*clear* channel detection (Clear to Send) generates so many missed
transmission opportunities, people will disable it. After all, it's
the one change that will dramatically improve their message delivery
throughput, so barring a gun to the head, why would they *not* disable
it?


 We do not need a busy detector that is guaranteed to detect all
 possible modulations under all circumstances. We simply need one that
 detects most likely modulations most of the time. An 80% effective
 busy detector would decrease the disruption of ongoing QSOs by
 unattended stations by a factor of 5. As is often the case in
 engineering, perfect is the enemy of good.

Actually your statistics are misleading. The detector isn't rolling
the dice once for the QSO, it's rolling the dice once, coming up
Busy, holding off n seconds, rolling the dice again, coming up
Busy, etc... four of five (forty or fifty, whatever) events later,
it comes up (falsely) Clear and *then* steps on the QSO. Think
Russian Roulette, not Busy signal... =) Especially since, if the
unattended station is doing a stream protocl, it's not going to stop
transmitting for some time.

In practice, 80% is often achievable, and works well enough in the
packetized world. Worst that happens if a conversation gets stepped on
is that the other party either detects the collision and retries or
times out and retries. There are tricks with sliding ack windows and
multi-ack responses to even avoid the sudden drop in throughput, but
this doesn't work well on stream-oriented (especially not
ear-in-the-loop) communication.

In a military or commercial channelized environment, the problem is
mitigated, but definitely not totally avoided. It's pretty common when
doing military utility listening to hear an ongoing voice conversation
get interrupted by a data transmission. The difference: the military
infrastructure has a very strict enforcement of its priority model
(barring the senior officer whose multi-megabyte powerpoint file gets
maximum priority, of course =)


Re: [digitalradio] Re: Busy Detectors

2007-09-17 Thread Rick
Robert,

I have brought this up many times, but there are new people that may not 
be aware of the SCAMP (Sound Card Amateur Messaging Protocol) testing 
that we did several years ago. I spent many hours with this technology 
and I can tell you that it is an outstanding program. I am not sure why 
the software author thought that RDFT was going to operate down close to 
zero dB. Some of us pointed out that it was not reasonable considering 
that the Linux source was used by other programmers to develop the first 
SSTV programs and we knew that they required signals well above the 
noise.  Unfortunately when the program did not work as well as expected 
they completely abandoned it (and us) and worse, had timers to insure 
that the software would self destruct so that no one else could use it 
or share it with anyone. To say that I was appalled is putting it mildly.

At the time that SCAMP was developed, the common wisdom (that is often 
not that wise) said that you could not do what you also claim can not be 
done, with detecting and responding to many different waveforms, and 
within a given bandwidth, and at a certain level, and that it could be 
adjustable. SCAMP proved them wrong. Steve Ford, WB8IMY, who is now QST 
Editor and long time digital promoter, and others such as myself, were 
able to get the software up and running and made connections through one 
of the three SCAMP HF servers that were then available.

The timing feature (like throwing dice) is basically the same concept we 
use in networking such as ethernet to reduce (but not completely avoid) 
collisions. It is an excellent feature but could be changed any way you 
wanted, assuming you had a better way. Even if modulation stops within 
the passband, it does not necessarily mean that the frequency is no 
longer in use, it could mean that the other station is now transmitting 
and can not hear the signals.

But if a human operator is on one side with a modicum of ability to 
detect a busy frequency, and the robot side has some kind of ability to 
detect a busy frequency, then you don't have the main issue of the 
hidden transmitter problem (unless maybe some unusual one way propagation).

Bottom line is the busy frequency detection has been invented, it works 
well, and no one should be arguing about whether it can work. What they 
should be doing is either trying to implement it from the developers 
code, or if they will not share with the amateur community (has anyone 
asked?) then try and reinvent it.

Because our bands are relatively small for the number of users, 
particularly during certain times, it seem very unlikely that we will be 
able to find bandwidth for automatic operation where there is no 
requirement (as their currently is) to insure that you are not 
intentionally interfering with an ongoing busy frequency as has been 
recently suggested. I certainly would not support such an idea 
considering that the technology has made it unnecessary.

73,

Rick, KV9U


Robert Thompson wrote:
 On 9/17/07, Dave Bernstein [EMAIL PROTECTED] wrote:
 Has this been widely tested by third parties on a large number of
 differing HF channel conditions? The hard part isn't the *busy*
 channel detection, it's the *clear* channel detection.  As long as
 *clear* channel detection (Clear to Send) generates so many missed
 transmission opportunities, people will disable it. After all, it's
 the one change that will dramatically improve their message delivery
 throughput, so barring a gun to the head, why would they *not* disable
 it?