My comments interspersed with Mr. Thompsons - - - - -
Robert Thompson wrote: > > I am slightly aware of this. However, I haven't seen any code or > large-scale busy-channel testing. > The only information we have is from the SCAMP testers. My view is that the busy frequency detect was quite excellent. Lets put it this way ... it greatly exceeded our expectations. > > 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. > The purpose of SCAMP was to allow a non-proprietary sound card mode to compete with Pactor modes for the Winlink 2000 system. It did this with good signals but had no fall back design. My interest is not specific to Winlink 2000, but rather the availability of S.C. modes for any messaging system. The current speeds from sound cards are not very competitive at this time. > > 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. > In the past, I have mentioned the GPL issue. I don't fully comprehend the GPL, even v2, much less v3:) Others, like yourself, claimed that if they used GPL code they would be required to include the source. I don't know if that is true or not. All I know is that they did not do so. The GPL code they used was the RDFT protocol developed by Barry Sanderson, KB9VAK, who won a major award for this program. From the Dec 10, 2005 ARRL Letter the alpha testers were: "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." At least some of us were willing to test this mode, partially to move sound card modes along and busy frequency detection, but also because we took Rick's statements that he would be GPL'ing the code. Maybe he has violated the GPL license, but no one has acted on that to my knowledge. Unless they found out he has not violated the GPL license and did not pursue it further. My hope is that he will still be willing to share such a major breakthrough and not hold it back for fear of allowing competition to the Winlink 2000 system by other e-mail and messaging systems. > > > 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. > > 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. > > 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. > APRS is another one of those problematic modes along with propagation beacons and any other unattended automatic operation. We really have not come to terms with these modes, and basically just tolerate them even though they may not always be abiding by the rules. > > Regards, Robert Thompson >
