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 multiple minutes before using it for only a few seconds. > 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. I personally haven't asked. Others have, and have been rebuffed. I (and probably others) are attempting to develop our own code to do this, and eventually someone will succeed. However, the code complexity of the resulting solution will probably preclude ever using it on simple "no computer" nodes, due to a lack of processing power. > > 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. Once again, until such code undergoes significant testing on intentionally busy channels, I am not willing to accept that technology has *already* made it necessary. On the other hand, I have no doubt that it will eventually (and maybe quite soon) make it unnecessary. A practical solution may also require some change in expectations on the part of pure human-to-human qso partners, too. Regards, Robert Thompson
