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?
[digitalradio] Re: Busy Detectors
Let me point out that you are not talking about co-channel interference to your signal. You are discussing interference to your ability to use the spectrum. Two entirely different subjects. Using your example, there is only one lane and that is all there will ever be, just like the amateur spectrum. You can advocate for banning tractor-trailers but you probably won't get it done. The only way to get more traffic on the one lane would be to use narrower vehicles where you can make the one lane into two lanes. When you make the choice to use wide bandwidth, high speed signals you are also limiting the amount of time that space is available for that purpose. That is simply the way it is with shared spectrum. If you want to increase the time available, then go to more narrow modes and give up the throughput. Or you can advocate for non-shared spectrum but I wouldn't hold my breath waiting for this. Jim WA0LYK --- In digitalradio@yahoogroups.com, Steve Hajducek [EMAIL PROTECTED] wrote: 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 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.
[digitalradio] Re: Busy Detectors
AA6YQ comments below --- In digitalradio@yahoogroups.com, Robert Thompson [EMAIL PROTECTED] wrote: snip The issue is that if a human is involved, at worst everyone shrugs and figures he's an impolite operator. If a human is involved one can send the frequency is in use, please QSY. Most of the time, the offending operator will sheepishly apologize and move. In the few cases where that doesn't happen, you know you're dealing with a lid. If an automatic station is involved, it is the evil enemy and deep dark motives are imputed to its operator. I disagree. QRM by an automatic station generates enormous frustration because there's no way to say the frequency is in use, please QSY. The build-up of this frustration over multiple events does causse operators to question how any considerate amateur could operate equipment that transmits without first ensuring that the frequency is clear. The implication is that operators of automatic stations without busy frequency detectors believe their traffic to be more important than everyone elses; this arrogance breeds contempt. 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. I disagree. To my knowldedge, there are no automatic amateur stations employing busy frequency detectors. Thus there is no evidence that human operators are unwilling to accept anthing short of perfection; other than the SCAMP Beta test, there has been no deployment of imperfect solutions for human operators to reject. As I've said before, busy frequency detectors that are 80% effective would make a huge difference, both by dramatically reducing the incidence of QRM from automatic stations, and by eliminating the perception that operators of automatic stations are arrogantly unconcerned with the impact of that QRM to ongoing QSOs. 73, Dave, AA6YQ
[digitalradio] Re: Busy Detectors
Your prescription for doing away with spectrum sharing is totally in conflict with the amateur radio paradigm of shared spectrum/no owns a frequency. It will result in the balkanization of the spectrum as competing modes/protocols/services all ask for their piece of the spectrum. You will destroy experimentation because new types of communication will not have assigned spectrum to use. 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? You might also elucidate a little on how you would share this traffic automation spectrum between winlink, ntsd, packet, pskmail, ALE, and other services that will come along. Perhaps you feel your little niche should also be declared a primary user and all other modes/services should have to give way when you are ready to begin transmission. I suspect that if you have time sensitive traffic to send and since you have already declared that waiting is upsetting, you will not be satisfied with waiting for a pskmail or packet session to complete either. Jim WA0LYK --- In digitalradio@yahoogroups.com, Steve Hajducek [EMAIL PROTECTED] wrote: 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
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?
[digitalradio] Re: Busy Detectors
AA6YQ comments below --- In digitalradio@yahoogroups.com, Robert Thompson [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. Agreed 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. Agreed. No technology can overcome a total breakdown in civility. In general, non-automated users resent the automated stations and often regrettably attempt to interfere. There is no excuse for intentional interference of any kind. The resentment of automated stations is rooted in their perceived lack of civility: they transmit over ongoing QSOs, and there is no way to ask them to QSY. The installation of effective busy detectors in automated stations would dramatically improve their civility, and thus reduce both frustration and polarization among the different communities. 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*. I am an incurable optimist, and so believe that the amateur community's reaction to the installation of busy detectors in automated stations would be a collective sigh of relief. Those lids who previously vented their frustration by QRMing automated stations would most likely find more constructive uses of their time. 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. 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. 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. 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. As pointed out above, this need not be the case. 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. 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. 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
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
[digitalradio] Re: Busy Detectors
AA6YQ comments below --- In digitalradio@yahoogroups.com, Robert Thompson [EMAIL PROTECTED] wrote: 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. Agreed 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. Yes, that makes perfect sense. The client station's software could make this all transparent to the end user. 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. As you say above, it will take some time to tune this properly. The tuning might actually be an adaptive procedure implemented by the software based on conditions. 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 no signal detected, the automated (or human/automated) station initiates its traffic and the frequency is now in use. Advantage: Whistling into a SSB mic, keying a CW transmitter, transmitting anything on most other common protocols would be enough to busy-flag the transmission. No need for the humans to do anything special. No complaints about not wanting to have to reconfigure to send CW, etc. Just make sure you immediately transmit whatever mode you're currently set up to transmit. Yes, that would work well. We seem to be on the same wavelength here... 73, Dave, AA6QY
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
[digitalradio] Re: Busy Detectors
Perhaps you misunderstood what I was saying. Allowing designated frequencies for just one purpose, in your case email, will open the doors for requesting designated frequencies for all kinds of things, not just mode restrictions. Some will want restricted frequencies for qrp only, dx only, emcomm only, social nets only, traffic nets only, ad infinitum. You will end up with a balkanized set of frequency restrictions that will not be manageable. Please explain how you would handle these requests in a fair manner. Simply saying that automated traffic systems should have designated spectrum free of interference while no one else has the same advantage doesn't explain why these systems should receive special treatment. Why do you feel peer-to-peer should be blocked from using any frequency? Are these conversations somehow worth less than the email you wish to send. You also didn't address the issue of how you will handle qrm from other automated systems. This will be as important as the peer-to-peer conversations you feel are the problem. With the complaining right now, I wonder what it will be like 5 years from now when we start reaching solar maximum. 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. The desire for wide bandwidth, high throughput modes on HF is like taking a midget race car to a go-cart track and telling everyone my car is better so get off the track so I can use it. You had better be able to explain why rag chewing and paper chasing are not worthy endeavors for hams to pursue rather than just saying people should get out of your way because you have a better use for the spectrum. Somehow I think your attitude has a hint of arrogance in it. Jim WA0LYK --- In digitalradio@yahoogroups.com, Steve Hajducek [EMAIL PROTECTED] wrote: 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
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.
[digitalradio] Re: Busy Detectors
AA6YQ comments below --- In digitalradio@yahoogroups.com, expeditionradio [EMAIL PROTECTED] wrote: There are down sides to busy-detection: 1. There is no way to know the relative interference temperature threshold for distant co-channel users on HF. SNR at every station is different. A signal that seems in the background at one location, for one mode, may be interference to another mode working at a different SNR or a different mode at another station. This is easily resolved. If *any* intelligence is detected, QSY. 2. What to detect? How sensitive? It is possible to engineer a busy-detector that can be set for a very sensitive threshold, and detect almost any mode or almost any level. That same detector will also falsely show a busy channel most of the time on the HF ham bands. That renders the busy-detector useless for the busy-detector user who wants to have a QSO or send an important message. This is one of those we can't make it perfect, so let's not do it at all arguments. SCAMP demonstrated several years ago that busy detection is practical, but the advocates of unattended operation have chosen to spend their time politicking rather than further developing this technology into something that would allow them to politely and effectively share spectrum with the rest of the amateur community. 3. When does the receiving station with busy-detection know whether the content of such an incoming message is an emergency? Busy detectors prevent messages from being transmitted, not from being received. A too-sensitive busy detector might prevent such a message from being run in the first place, and the result would not be good. Thus, stations that are on the air specifically with a very likely possible purpose of running emergency traffic should probably not use a busy-detector. It is possible to envision a busy-detector that could be programmed to remotely disengage upon reception of a specific command... but such a system is not readily available at the present time, and the use of it would certainly unnecessarily complicate the sending of an emergency message at a critical time. A unattended station designed to carry emergency traffic could easily be designed to reliably decode an emergency enabled message and disable its busy detector from impeding the transmission of outgoing messages until an emergency disabled message is received. 4. It may be counter-productive for networks or users to announce what type of busy-detection they use or don't use, because this sort of information can be used nefariously (has been and will be) by individuals on purpose to maliciously interfere or thwart normal operation. During emergencies, busy detection would be disabled. During non- emergencies, even the most pathological lid would quickly tire of QRMing an unattended station that never reacts with frustration or anger, patiently waiting to pass its messages until the frequency clears. 5. We all know that there are many feuds and grudges out there on the air. It seems that certain hams who are most prone to carrying on feuds or grudge-matches may also be the same individuals who clamor most loudly for busy-detectors to be put in place by their enemy :) If unattended stations adopted busy detectors and stopped QRMing ongoing QSOs, the level of frustration among digital mode operators would drop. As pointed out above, intentionally QRMing an unattended station is a most unsatisfying pastime. 73, Dave, AA6YQ
[digitalradio] Re: Busy Detectors
Pactor is not the problem. Unattended stations without busy detectors are the problem -- whether they're operating in Pactor, PSK, RTTY, or CW. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Andrew O'Brien [EMAIL PROTECTED] wrote: but Bonnie, a fundamental issue has been the frustration with PACTOR just switching on mid-stream and interfering with a QSO. Other than under contesting conditions, it rarely happens with other modes. Would not it be fairly easy for programmers to build in a variable parameter that allows the user to set a signal to noise ratio and a waterfall bandwidth. If the software detects a signal above the specified SNR within the specified bandwidth, the software refused to xmit? A off setting could be used when emergencies exists. For example MixW and PC-ALE both have a pseudo way of measuring SNR. Andy. On 9/16/07, expeditionradio [EMAIL PROTECTED] wrote: There are down sides to busy-detection: 1. There is no way to know the relative interference temperature threshold for distant co-channel users on HF. SNR at every station is different. A signal that seems in the background at one location, for one mode, may be interference to another mode working at a different SNR or a different mode at another station. 2. What to detect? How sensitive? It is possible to engineer a busy-detector that can be set for a very sensitive threshold, and detect almost any mode or almost any level. That same detector will also falsely show a busy channel most of the time on the HF ham bands. That renders the busy-detector useless for the busy-detector user who wants to have a QSO or send an important message. 3. When does the receiving station with busy-detection know whether the content of such an incoming message is an emergency? A too-sensitive busy detector might prevent such a message from being run in the first place, and the result would not be good. Thus, stations that are on the air specifically with a very likely possible purpose of running emergency traffic should probably not use a busy-detector. It is possible to envision a busy-detector that could be programmed to remotely disengage upon reception of a specific command... but such a system is not readily available at the present time, and the use of it would certainly unnecessarily complicate the sending of an emergency message at a critical time. 4. It may be counter-productive for networks or users to announce what type of busy-detection they use or don't use, because this sort of information can be used nefariously (has been and will be) by individuals on purpose to maliciously interfere or thwart normal operation. 5. We all know that there are many feuds and grudges out there on the air. It seems that certain hams who are most prone to carrying on feuds or grudge-matches may also be the same individuals who clamor most loudly for busy-detectors to be put in place by their enemy :) Bonnie KQ6XA -- Andy K3UK www.obriensweb.com (QSL via N2RJ)
[digitalradio] Re: Busy Detectors
Busy detectors are the solution to the hidden transmitter problem for unattended stations. For those convinced that the world is out to get them (or their favorite modes), I suggest meditation. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, John Becker, WØJAB [EMAIL PROTECTED] wrote: At 08:18 PM 9/16/2007, Andy, K3UK in part wrote: but Bonnie, a fundamental issue has been the frustration with PACTOR just switching on mid-stream and interfering with a QSO. If I may jump in here. Does this not go back to the so called hidden transmitter issue ?? This I think has bee beat to death by many times on this list. Find a fix for that and you will die a very rich man. But I really think a lot has to do with those that just *HATE* the wide modes (RTTY Amtor Pactor) . John, W0JAB
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.
[digitalradio] Re: Busy Detectors
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. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, John Becker, WØJAB [EMAIL PROTECTED] wrote: Not sure what mode the mode is but should it not be for all modes? Case in point - the other evening I was in QSO with a ham in Dallas Texas keyboard to keyboard Pactor 3 on 7077.4 LSB when N4CE started calling CQ on HELL (for half an hour) . He was so strong here in the mid west that we last the link. I feel sure that he had no clue whatsoever who or even that it was a KB to KB QSO. My point being it's just not only Pactor stations. In fact last week I have see more ALE stations and JT65A then anything else blasting away on a freq already in use. John, W0JAB At 07:15 AM 9/17/2007, you wrote: Exactly the reason the mode should be taken to some other band(s). 73 Bill KA8VIT
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
[digitalradio] Re: Busy Detectors
Could you not switch to CW and send QRL pse QSY at 10 wpm? N4CE's email address is available via QRZ.com. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, John Becker, WØJAB [EMAIL PROTECTED] wrote: 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.
[digitalradio] Re: Busy Detectors
--- In digitalradio@yahoogroups.com, Rud Merriam [EMAIL PROTECTED] 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 Hi Rud, Some like to argue on internet than get on the air!!! 73 de Demetre SV1UY
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?
[digitalradio] Re: Busy Detectors
If neither the attended nor unattended stations in a semi-automatic QSO can hear a QSO on frequency, then they can proceed. By doing so they may QRM a QSO that neither can hear (due to differences in antenna gain or orientation, for example), but this is not preventable on the amateur bands. The fact that there are scenarios where QRM can't be prevented is no excuse for continuing to QRM ongoing QSOs in scenarios where a busy frequency detector would have prevented that QRM. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Rud Merriam [EMAIL PROTECTED] 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
[digitalradio] Re: Busy Detectors
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. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, John Becker, WØJAB [EMAIL PROTECTED] wrote: 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?
[digitalradio] Re: Busy Detectors
AA6YQ comments below --- In digitalradio@yahoogroups.com, Demetre SV1UY [EMAIL PROTECTED] wrote: Some like to argue on internet than get on the air!!! Some try to avoid inconvenient facts by attacking the messenger. 73, Dave, AA6YQ
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 =)
[digitalradio] Re: Busy Detectors
AA6YQ comments below --- In digitalradio@yahoogroups.com, Demetre SV1UY [EMAIL PROTECTED] wrote: Cheer up man. At least some do not end up in name calling as you and someone else did a few messages ago. You accused me of preferring internet arguments to amateur radio operations, Demetre. My response was to simply note your diversionary tactics; I did not call you a name or in any way attack you. ou seem to forget that radio amateurs should show some courtesy. It doesn't hurt you know. There was nothing discourteous in my response to your accusation. We all like to do our hobby, if you are only interested to bully people and not get on the air, it's your choice, but reverting in name calling will never resolve the busy detector issue, nor will it stop Winlink, ale or whatever you see as threatening you! You need to talk , have an open mind and try to convince the other guy with facts and not by telling him/her to medicate. Perhaps you need that. Stating facts and taking exception to incorrect assertions is not bullying people. How have you reached the conclusion that I am not active on the air? Please re-read my earlier post. I suggested that those who believe the world is out to get their favorite mode should meditate. Meditate, as in carefully rethink their position, not medicate. Because you hate seen messaging systems (semiautomatic) on HF does not give you the right to stop others using them. For US amateurs, willful transmission on a frequency that is already in use is a violation of the regulations governing amateur radio: 97.101(d) No amateur operator shall willfully or maliciously interfere with or cause interference to any radio communication or signal. Largely through education, Amateurs have long taken responsibility for minimizing violations of these regulations. When statements are made in a public forum that condone the violation of these regulations and/or the abandonment of good operating practice, I will take exception in a constructive manner. 73, Dave, AA6YQ
[digitalradio] Re: Busy Detectors
--- In digitalradio@yahoogroups.com, Dave Bernstein [EMAIL PROTECTED] wrote: AA6YQ comments below --- In digitalradio@yahoogroups.com, Demetre SV1UY sv1uy@ wrote: Some like to argue on internet than get on the air!!! Some try to avoid inconvenient facts by attacking the messenger. 73, Dave, AA6YQ Dave, Cheer up man. At least some do not end up in name calling as you and someone else did a few messages ago. You seem to forget that radio amateurs should show some courtesy. It doesn't hurt you know. This is the most important aspect of Amateur Radio, at least this is what I was taught when I sat for my Radio Amateur Examination in this country. We all like to do our hobby, if you are only interested to bully people and not get on the air, it's your choice, but reverting in name calling will never resolve the busy detector issue, nor will it stop Winlink, ale or whatever you see as threatening you! You need to talk , have an open mind and try to convince the other guy with facts and not by telling him/her to medicate. Perhaps you need that. Because you hate seen messaging systems (semiautomatic) on HF does not give you the right to stop others using them. If you want to have a constructive discussion by all means you are welcome, but name calling is no good. It has a negative effect. Back to digital amateur radio now. 73 de Demetre SV1UY
[digitalradio] Re: Busy Detectors
+++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. snip Has this been widely tested by third parties on a large number of differing HF channel conditions? +++There was a beta test in which many operators participated; everyone, including SCAMP's developer, was surprised by its effectiveness and relative freedom from false positives. I don't think the test ran long enough to claim that a large number of differing HF channel conditions were encountered. This was a quick- and-dirty attempt that could undoubtedly be improved with focused effort. 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. We do not need a busy detector that is guaranteed to detect all possible modulations under all circumstances. 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. +++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. 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. +++Agreed. 73, Dave, AA6YQ
[digitalradio] Re: Busy Detectors
That operator's email address is available via QRZ.com . If you let him know that he QRM'd your QSO, perhaps there will be one less operator in the world who thinks its okay to call over Pactor transmissions (if that's what happened). Try sending QRL pse QSY in 10 wpm CW the next time you're QRM'd by an attended digital mode station, John. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, John Becker, WØJAB [EMAIL PROTECTED] wrote: 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
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?
