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? > >
