Re: [digitalradio] Re: Busy Detectors
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
