Re: [digitalradio] Digital busy detect
Yes that is what I was hearing as well as watching. Sorry John, but what you are witnessing is not Packet stations transmitting on top of each other.
Re: [digitalradio] Digital busy detect
I'm sure everybody believes you, John. Try to calm down if you can. 73 DE Charles Brabham, N5PVL Prefer to use radio for your amateur radio communications? - Stop by at HamRadioNet.Org ! http://www.hamradionet.org - Original Message - From: John Becker, WØJAB To: digitalradio@yahoogroups.com Sent: Thursday, November 26, 2009 2:34 PM Subject: Re: [digitalradio] Digital busy detect Yes that is what I was hearing as well as watching. Sorry John, but what you are witnessing is not Packet stations transmitting on top of each other.
Re: [digitalradio] Digital busy detect
On Tue, 24 Nov 2009 22:30:21 -0500, Alan Barrow ml9...@pinztrek.com said: [snip] OK, here's the challenge: Demonstrate it's feasibility if it's JSMOP. Implement one that balances the right of the sending station not to be QRM'd VS the expectation not to QRM. Publish an API a spec (turnaround times, etc). IE: Not a passive (hold off) detector Make it open source so that all coders can leverage refine it. Windows assumption is OK, but we could probably find a lock/semaphore system that is multiplatform. But a windows DLL API would satisfy 90% of the commonly used digi programs. Why make a Windows or POSIX assumption? Your busy detection API could be a chunk of DSP code that works in two modes: 1) Callback: register a callback function with the detector. Feed the detector smaller fragments of audio as you process them for decoding. The callback will be invoked whenever there is a change in the busy state. 2) Blocking: feed the detector a big chunk of audio data. It will tell you if there is a signal present in the frequency range of interest. Option (1) is probably best; the digi program will take care of threading or other concurrency issues. It is possible to implement (2) on top of (1). The detector could also supply a confidence level and other details. Will have to codify a standard that would allow any program to grab soundcard resources (to monitor as well as send the qrl) along with any cat/ptt required. Or maybe you let the digi program figure out how to send CW QRL, that would be close enough. The API should just signal the digi program. Let the latter do the PTT, audio device interfacing and sending of CW QRL or whatever -- it already knows how to do all these things. This reduces complexity. Also, the detector must be capable of being used in advisory mode since it cannot hope to be correct all the time. Please note that I am not talking about a generic QRM avoidance spec. The busy detector is enough of a SMOM-type problem as it is :) -- 73, Stelios, M0GLD.
Re: [digitalradio] Digital busy detect
Dave AA6YQ wrote: To be clear, an attended station need not wait for 5 minutes of clear frequency before transmitting; 30 seconds of no signals (meaning no automatic station is QRV) followed by a QRL? sent in mode with no response should be sufficient. What does in mode mean on shared frequencies? The interfering station could be packet, pactor 2-3, ALE, whatever. This concept demonstrably does not work even in attended mode ops, like in PSK. RTTY ops do not honor a QRL in psk, same for CW. Cross mode is the majority of the issue. Most of the protocols will hold off for their mode already. You are asking some modes to solve a problem that has not been addressed even in attended mode. (CW x PSK, RTTY x PSK, etc) Have fun, Alan km4ba
Re: [digitalradio] Digital busy detect
Dave AA6YQ wrote: +++The rules to be honored by all stations are: 1. if you're not yet in QSO, don't transmit on a frequency that is already in use (meaning that signals have been detected during the past 5 minutes) 2. if you're in QSO and signal other than that of your QSO partner appears (the busy frequency detector indicates the presence of signal, but you aren't decoding your QSO partner), wait for that signal to disappear, send QRL QRL in CW, and resume your QSO OK so far +++Amateur radio operators have been trusting each other to mutually obey these rules since the service began. On what possible basis can you claim exemption? Here's where it falls apart. many, many digi ops neither copy CW even to understand QRL, or would not hear it. And another large percentage would not honor a QRL request, they don't in other situations for sure. Kindof like asking all cellphone users to install a device that allows anyone to disable their ringtone. Just what do you think the compliance on that would be? +++No, its not remotely like asking cellphone users to install such a device; there is no parallel whatsoever. I'd be OK if all mfg's had such a device. But to selectively enforce it is unworkable. IE: Multipsk, others should have similar detect honor a QRL request. Recioprocity is part of being a good neighbor. +++Only attended stations need detect the QRL; if automatic stations never transmit on a frequency that is in use, then they will rarely QRM an ongoing QSO, and so have no need of automatic QRL detection This does not deal with hidden terminal, nor does it address the cases where attended mode ops interfere with non-attended . +++When not in QSO, automatic stations can easily monitor the frequency to determine whether a QSO is in progress, even if they are only hearing one of the stations involved; this is easily implemented. If an automatic station receives a connection request and its busy frequency detector has seen no activity for the past 5 minutes, it can respond to the request without compunction. If its busy frequency detector has been intermittently reporting signals over the past 5 minutes, it should not respond. Unworkable on most auto sub-bands, there is just that much traffic. If you held off 5 minutes for many parts of the day you'd never, ever be able transmit. Again, unequal standard, do CW/RTTY ops wait 5 minutes? They sure don't when interfering with PSK. +++I didn't say it rarely occurs, I said its rarely a problem -- because attended stations can communicate with each other and resolve the conflict, thereby preserving the QSO in progress. Unattended automatic stations are incapable of doing this. While voice ops do tend to honor this if enforced, there are many, many cases where they do not. Net's being one, and ops with unequal power being another. The world is not as clean as you allude. Regarding your monitoring test with Pactor- clear selection bias (Google it) you could not hear the cases of interference that you claim do not exist. Rick KN6KB is already on the second iteration of his busy frequency detector; there is no need to re-invent this wheel. May be a wonderful thing, but does not address the need to be able to be leveraged by other programs. You propose a technical solution is not that hard. I asked for one, committed test deploy it. That would be a big win. Simple DLL, common standard. All major digi programs to implement honor it. Not just modes which you do not care for. Since we all hope winmor will be a leveragable DLL, it would be great if it's busy detector was also leveragable by other modes. No changes are required to MMTTY, WinWarbler, DM-780, MixW, Digipan, FLdigi, or MultiPSK, as these are exclusively used in attended operation. Only applications that manage unattended automatic stations require modification -- specifically, the implementation of the two rules described above. I respectfully disagree, as users of these programs interfere (perhaps unintentionally) with each other and auto stations all the time. If it's such an easy problem to solve, we should apply equal standard. Likewise, some of these programs are capable of auto-respond, or are heading in that direction. (RSID selcall work, etc) There are steps we could take to accelerate the dissipation of anger over past practices once most automatic stations are implementing the above rules; this would minimize intentional QRM aimed at triggering busy frequency detectors. I would be happy to drive this effort. As mentioned previously: Propose a standard, build/test a reference implementation, release some code, work with the various coders to integrate. Though I normally don't agree with guillotine moderation, in this case I think we've reached impasse. Have fun, Alan km4ba
Re: [digitalradio] Digital busy detect
Lots of good or interesting opinions expressed in this discussion. - But we all know about opinions... Everybody's got one. Here are some of the relevant FACTS, the framework within we must not stray with our opinions: -- §97.101 General standards. (a) In all respects not specifically covered by FCC Rules each amateur station must be operated in accordance with good engineering and good amateur practice. (b) Each station licensee and each control operator must cooperate in selecting transmitting channels and in making the most effective use of the amateur service frequencies. No frequency will be assigned for the exclusive use of any station. (c) At all times and on all frequencies, each control operator must give priority to stations providing emergency communications, except to stations transmitting communications for training drills and tests in RACES. (d) No amateur operator shall willfully or maliciously interfere with or cause interference to any radio communication or signal. -- Note in 97.101(a) the reference to good amateur practice. The accepted documentation of good amateur practice is THE AMATEURS CODE, which you can reference here: http://www.arwatch.com/info/hamcode.htm Note that if your IQ is bigger than your shoe size, then you will know without doubt that transmitting a signal without listening first on a regular basis is going to cause harmful interference. This means the resulting inteference falls within the 'willful or malicious' category. - Assuming of course that your IQ is bigger than your shoe size. WinLink and automated ALE sounder folks take note. -- §97.109 Station control. (d) When a station is being automatically controlled, the control operator need not be at the control point. Only stations specifically designated elsewhere in this Part may be automatically controlled. Automatic control must cease upon notification by a District Director that the station is transmitting improperly or causing harmful interference to other stations. Automatic control must not be resumed without prior approval of the District Director. -- It looks like the FCC District Director is the one to talk to about WinLink and ALE-sounding related interference. -- §97.113 Prohibited transmissions. (a) No amateur station shall transmit: (1) Communications specifically prohibited elsewhere in this Part; (5) Communications, on a regular basis, which could reasonably be furnished alternatively through other radio services. -- Take a look at SailMail http://www.sailmail.com/ which is identical in almost every respect to WinLink. Then carefully read 97.113(a,5). What does this tell you about WinLink? 73 DE Charles Brabham, N5PVL Prefer to use radio for your amateur radio communications? - Stop by at HamRadioNet.Org ! http://www.hamradionet.org
Re: [digitalradio] Digital busy detect
OK Charles that's enough you can now move on and bad mouth whatever mode it next on your hit list. this one is over done with. John, W0JAB
Re: [digitalradio] Digital busy detect
John, what I am 'badmouthing' is illegal and rude operating habits. I personally doubt that the WinLink group will ever clean up their act - but if they were to do so, I would be among the first to congratulate and praise them, you can count on that. 73 DE Charles Brabham, N5PVL Prefer to use radio for your amateur radio communications? - Stop by at HamRadioNet.Org ! http://www.hamradionet.org - Original Message - From: John Becker, WØJAB To: digitalradio@yahoogroups.com Sent: Wednesday, November 25, 2009 9:51 AM Subject: Re: [digitalradio] Digital busy detect OK Charles that's enough you can now move on and bad mouth whatever mode it next on your hit list. this one is over done with. John, W0JAB
RE: [digitalradio] Digital busy detect
+++ AA6YQ responses below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Wednesday, November 25, 2009 8:12 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect Dave AA6YQ wrote: To be clear, an attended station need not wait for 5 minutes of clear frequency before transmitting; 30 seconds of no signals (meaning no automatic station is QRV) followed by a QRL? sent in mode with no response should be sufficient. What does in mode mean on shared frequencies? The interfering station could be packet, pactor 2-3, ALE, whatever. +++If you're about to send CQ in PSK, you send QRL? in PSK; if you're about to send CQ in RTTY, you send QRL? in RTTY. This concept demonstrably does not work even in attended mode ops, like in PSK. RTTY ops do not honor a QRL in psk, same for CW. +++If an operator sends QRL? in PSK on a frequency being used by a RTTY QSO that he or she did not hear beforehand, one or both participants of that RTTY QSO can ask you to move by sending QRL QRL in CW; the participants don't need to know what the operator sent, they just need to respond with QRL QRL in CW. +++If an operator sends QRL? in PSK on a frequency being used by an unattended automatic station that he or she did not hear beforehand, the automatic station will respond by sending QRL QRL in CW (rule #1 from my previous post). +++In both cases, the operator should QSY on hearing the QRL QRL. Cross mode is the majority of the issue. Most of the protocols will hold off for their mode already. You are asking some modes to solve a problem that has not been addressed even in attended mode. (CW x PSK, RTTY x PSK, etc) +++ Listening for a clear frequency before transmitting QRL? has long been the recommended practice before calling CQ; sending QRL in-mode to a station that appears on your frequency mid-QSO is also standard practice. I agree that there has been no concerted effort to address cross-mode scenarios, but the use of QRL QRL in CW is quite straightforward. Yes, digital ops that didn't learn CW will have to recognize this signal, though if you call CQ in a digital mode and hear CW in response, the frequency is in use is all we'd really need to broadly syndicate. As I said before, I'd be happy to drive this effort. 73, Dave, AA6YQ
RE: [digitalradio] Digital busy detect
###AA6YQ responses below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Wednesday, November 25, 2009 8:34 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect Dave AA6YQ wrote: +++The rules to be honored by all stations are: 1. if you're not yet in QSO, don't transmit on a frequency that is already in use (meaning that signals have been detected during the past 5 minutes) 2. if you're in QSO and signal other than that of your QSO partner appears (the busy frequency detector indicates the presence of signal, but you aren't decoding your QSO partner), wait for that signal to disappear, send QRL QRL in CW, and resume your QSO OK so far ### Progress! +++Amateur radio operators have been trusting each other to mutually obey these rules since the service began. On what possible basis can you claim exemption? Here's where it falls apart. many, many digi ops neither copy CW even to understand QRL, or would not hear it. ### They need not copy it: they need only understand that CW in response to a CQ in any mode means frequency in use, please move elsewhere. ### There will be cases where asymmetry in equipment or propagation results in a station sending CQ not being able to hear either of the stations in an on-going QSO that are sending QRL in response, but this a fortunately infrequent occurrence that cannot be addressed by any technology. The fact that we can't prevent this is no excuse for not addresses the more common scenario that we can mitigate; as Voltaire said, the perfect is the enemy of the good. And another large percentage would not honor a QRL request, they don't in other situations for sure. ### I don't agree that this is a large percentage now, and believe that the amount of negative behavior would decrease as we eliminated the QRM. Kindof like asking all cellphone users to install a device that allows anyone to disable their ringtone. Just what do you think the compliance on that would be? +++No, its not remotely like asking cellphone users to install such a device; there is no parallel whatsoever. I'd be OK if all mfg's had such a device. But to selectively enforce it is unworkable. IE: Multipsk, others should have similar detect honor a QRL request. Recioprocity is part of being a good neighbor. MultiPSK only needs a busy frequency detector when its operating as an unattended automatic station. Attended stations can use their ears. +++ Only attended stations need detect the QRL; if automatic stations never transmit on a frequency that is in use, then they will rarely QRM an ongoing QSO, and so have no need of automatic QRL detection This does not deal with hidden terminal, ### I disagree. If an attended station obeys rule 1, the probability that the frequency was clear for 5 minutes before transmission and yet the attended station's transmission will QRM an on-going QSO is very low. Within that 5 minutes, the attended station's busy frequency detector would have heard one of the two participants in that QSO. A collision would only occur in the asymmetric equipment or propagation scenario. nor does it address the cases where attended mode ops interfere with non-attended ### I disagree. Rule 2 says that an unattended station in QSO that detects a signal not sent by its QSO partner should send QRL QRL in CW. The operator sending that signal would be governed by the if you hear CW in response to a CQ, the frequency is in use principle. Barring an asymmetric scenario, the unattended QSO would be preserved. +++When not in QSO, automatic stations can easily monitor the frequency to determine whether a QSO is in progress, even if they are only hearing one of the stations involved; this is easily implemented. If an automatic station receives a connection request and its busy frequency detector has seen no activity for the past 5 minutes, it can respond to the request without compunction. If its busy frequency detector has been intermittently reporting signals over the past 5 minutes, it should not respond. Unworkable on most auto sub-bands, there is just that much traffic. If you held off 5 minutes for many parts of the day you'd never, ever be able transmit. ### I have two reactions to this statement: 1. I'd like to see the statistics that back it up 2. if its true, you are acknowledging that unattended stations are QRMing a lot of on-going QSOs ### If what you say is true, the proper solution would be to widen the auto sub-bands; but this will only happen after its been demonstrated that unattended automatic stations cause no more QSO breakage than good human operators. Again, unequal standard, do CW/RTTY ops wait 5 minutes? They sure don't when interfering with PSK. ### Attended stations can listen for 30 seconds, send QRL?, interpret the result, and if negative proceed to call CQ. An unattended station with this same
Re: [digitalradio] Digital busy detect
I knew one of the hams who first envisioned what would later end up being SCAMP, followed its development with interest, and was thoroughly disgusted at the way the WinLink group used those efforts as a cheap propaganda ploy instead of pursuing it honestly. SCAMP was at no point intended by the WinLink group to see actual use, its development was stretched out and used as a talking point for political purposes. As soon as its utility for that purpose became unsupportable, it was uncerimoniously killed. At no point did the WinLink group intend to phase out the use of the SCS harmful interference mills. This still holds true today. WinMore is just one more SCAMP, unfortunately. Knowing the level of character and intelligence to be found in the WinLink group, I have not followed WinMore's development. - I already know it's fate. After stretching out its supposed development for as long as possible, milking it for political traction ( We are working on ending our widespread inteference - honest! ) there will come the inevitable point where it is reluctantly admitted that WinMore just cannot do the job nearly as well as PACTOR III and then all of a sudden, you won't hear anything more about WinMore. The thing that the ARRL, the FCC, and all amateurs should understand is that WinLink will never be reformed. They hope to become so thoroughly established with delaying tactics like SCAMP and WinMore that eventually the FCC will throw up their hands and award them private spectrum of their own, or re-write PART97 so that we no longer enjoy the use of shared spectrum, thus bringing amateur radio to an end. They want a channelized, CB-like environment and the ARRL, to its discredit, is behind them 100%. As was the case with city and county entities forcing thier employees to get ham tickets as they pursued DHS grant money, and eventually starting to eye amateur radio spectrum as something to lobby for the possession of, our only real hope for a good outcome in this case is for the FCC to step in. We cannot hope for help or support from the ARRL, which again is part of the problem. So no, I have not followed WinMore's development at all, since I already know its fate. Note how WinMore is not open source but is strictly proprietary to the WinLink group, just like SCAMP was. They will be using this control to be sure that it is not developed further or used for any other purpose by anyone else. When they decide to kill it, they will want it to stay dead. - Just as dead as SCAMP is today. 73 DE Charles Brabham, N5PVL Prefer to use radio for your amateur radio communications? - Stop by at HamRadioNet.Org ! http://www.hamradionet.org - Original Message - From: Dave AA6YQ To: digitalradio@yahoogroups.com Sent: Monday, November 23, 2009 10:50 PM Subject: RE: [digitalradio] Digital busy detect Did you evaluate the busy frequency detector in Scamp, Charles? Have you evaluated the busy frequency detector in Winmor? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Charles Brabham Sent: Monday, November 23, 2009 9:55 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Digital busy detect Packet radio gets by with a simple carrier detect, PACTOR can only detect other PACTOR stations, and from what I can tell, ALE has no busy detection at all. Several years ago I took a serious look at automated busy detection, and always ran across the same stone wall: A more sophisticated busy detect that can usually tell the difference between noise and a human activity like speech or digital transmissions is possible - BUT - only after the software has a fairly long audio sample to work with, and can look back upon that sample. It can't do this instantly, or even very quickly unless you have a supercomputer to work with. If it listens to a long sample and a new signal comes in toward the end of that sample, that new signal may or may not end up being identified. This is a terrible thing to have to report, but Packet's carrier detect is the most effective and sophisticated automatic signal detection scheme we currently have at our disposal. - It detects more kinds of activity *right then* than anything else that hams are currently using. There are lots of signals that carrier detect will not detect - but it is still the best thing out there, that can automatically detect and act in ( more or less ) real-time. The human ear works better, detecting signal intelligence and differentiating it from noise far better than any automated detection system. Period. Better still is the human eye, looking at a properly set up waterfall display that will show you recognizable patterns in the waterfall image that you may not be able to register just by listening. One thing to ponder is why carrier detect, developed
Re: [digitalradio] Digital busy detect -Winmor
WINMOR's busy detect works perfectly at the initiating station's end, a pop-up windows tells you the frequency is in use and ask if you really want to go ahead and transmit. I have not seen it work at the other end, i.e. prevent another station connecting because a third party is also detected at the receive station's end. Andy K3UK
Re: [digitalradio] Digital busy detect -Winmor
Yes, seen that myself. philw de ka1gmn On Tue, Nov 24, 2009 at 8:06 AM, Andy obrien k3uka...@gmail.com wrote: WINMOR's busy detect works perfectly at the initiating station's end, a pop-up windows tells you the frequency is in use and ask if you really want to go ahead and transmit. I have not seen it work at the other end, i.e. prevent another station connecting because a third party is also detected at the receive station's end. Andy K3UK
Re: [digitalradio] Digital busy detect
I hope you are wrong this time. All your previous comments have been right but maybe this time you could be wrong. Rick Muething is putting so much work into Winmor AND it is working so well, that this time it may become widely used. The busy detect feature works very well, even detecting voice signals at times. The speeds achieved seem to be faster than Pactor 2. They are not faster than Pactor 3 but the bandwidth is smaller too (1600 hz compared to 2400 hz). There is no guarantee that the guys with Pactor 3 modems will stop QRMing but once there is a good alternative maybe we can get the FCC to issue citations to those who interfere. The testing with the peer to peer program (RMS Express) has gone well and they are now working on the server version. It won't be long until that is broadly tested. Hang in there and let's see how it works. Howard K5HB From: Charles Brabham n5...@uspacket.org To: digitalradio@yahoogroups.com Sent: Tue, November 24, 2009 6:36:19 AM Subject: Re: [digitalradio] Digital busy detect I knew one of the hams who first envisioned what would later end up being SCAMP, followed its development with interest, and was thoroughly disgusted at the way the WinLink group used those efforts as a cheap propaganda ploy instead of pursuing it honestly. SCAMP was at no point intended by the WinLink group to see actual use, its development was stretched out and used as a talking point for political purposes. As soon as its utility for that purpose became unsupportable, it was uncerimoniously killed. At no point did the WinLink group intend to phase out the use of the SCS harmful interference mills. This still holds true today. WinMore is just one more SCAMP, unfortunately. Knowing the level of character and intelligence to be found in the WinLink group, I have not followed WinMore's development. - I already know it's fate. After stretching out its supposed development for as long as possible, milking it for political traction ( We are working on ending our widespread inteference - honest! ) there will come the inevitable point where it is reluctantly admitted that WinMore just cannot do the job nearly as well as PACTOR III and then all of a sudden, you won't hear anything more about WinMore. The thing that the ARRL, the FCC, and all amateurs should understand is that WinLink will never be reformed. They hope to become so thoroughly established with delaying tactics like SCAMP and WinMore that eventually the FCC will throw up their hands and award them private spectrum of their own, or re-write PART97 so that we no longer enjoy the use of shared spectrum, thus bringing amateur radio to an end. They want a channelized, CB-like environment and the ARRL, to its discredit, is behind them 100%. As was the case with city and county entities forcing thier employees to get ham tickets as they pursued DHS grant money, and eventually starting to eye amateur radio spectrum as something to lobby for the possession of, our only real hope for a good outcome in this case is for the FCC to step in. We cannot hope for help or support from the ARRL, which again is part of the problem. So no, I have not followed WinMore's development at all, since I already know its fate. Note how WinMore is not open source but is strictly proprietary to the WinLink group, just like SCAMP was. They will be using this control to be sure that it is not developed further or used for any other purpose by anyone else. When they decide to kill it, they will want it to stay dead. - Just as dead as SCAMP is today. 73 DE Charles Brabham, N5PVL Prefer to use radio for your amateur radio communications? - Stop by at HamRadioNet. Org ! http://www.hamradionet.org - Original Message - From: Dave AA6YQ To: digitalradio@ yahoogroups. com Sent: Monday, November 23, 2009 10:50 PM Subject: RE: [digitalradio] Digital busy detect Did you evaluate the busy frequency detector in Scamp, Charles? Have you evaluated the busy frequency detector in Winmor? 73, Dave, AA6YQ -Original Message- From: digitalradio@ yahoogroups. com [mailto:digitalradi o...@yahoogroups. com]On Behalf Of Charles Brabham Sent: Monday, November 23, 2009 9:55 PM To: digitalradio@ yahoogroups. com Subject: [digitalradio] Digital busy detect Packet radio gets by with a simple carrier detect, PACTOR can only detect other PACTOR stations, and from what I can tell, ALE has no busy detection at all. Several years ago I took a serious look at automated busy detection, and always ran across the same stone wall: A more sophisticated busy detect that can usually tell the difference between noise and a human activity like speech or digital transmissions is possible - BUT - only after the software has a fairly long audio sample to work with, and can look back upon that sample
RE: [digitalradio] Digital busy detect
I am fully aware of WinLink's political tactics, but the topic of this thread is busy frequency detection. Independently of why it might have been developed, the busy frequency detector in Scamp surprised many with its effectiveness, including its own developer. I'm assuming that Winmor's busy frequency detector is a descendent of Scamp's, as both were developed by Rick KN6KB. Hold your nose if you must, but I suggest that you evaluate Winmor's busy frequency detector before making additional claims about what is and is not possible. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Charles Brabham Sent: Tuesday, November 24, 2009 7:36 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect I knew one of the hams who first envisioned what would later end up being SCAMP, followed its development with interest, and was thoroughly disgusted at the way the WinLink group used those efforts as a cheap propaganda ploy instead of pursuing it honestly. SCAMP was at no point intended by the WinLink group to see actual use, its development was stretched out and used as a talking point for political purposes. As soon as its utility for that purpose became unsupportable, it was uncerimoniously killed. At no point did the WinLink group intend to phase out the use of the SCS harmful interference mills. This still holds true today. WinMore is just one more SCAMP, unfortunately. Knowing the level of character and intelligence to be found in the WinLink group, I have not followed WinMore's development. - I already know it's fate. After stretching out its supposed development for as long as possible, milking it for political traction ( We are working on ending our widespread inteference - honest! ) there will come the inevitable point where it is reluctantly admitted that WinMore just cannot do the job nearly as well as PACTOR III and then all of a sudden, you won't hear anything more about WinMore. The thing that the ARRL, the FCC, and all amateurs should understand is that WinLink will never be reformed. They hope to become so thoroughly established with delaying tactics like SCAMP and WinMore that eventually the FCC will throw up their hands and award them private spectrum of their own, or re-write PART97 so that we no longer enjoy the use of shared spectrum, thus bringing amateur radio to an end. They want a channelized, CB-like environment and the ARRL, to its discredit, is behind them 100%. As was the case with city and county entities forcing thier employees to get ham tickets as they pursued DHS grant money, and eventually starting to eye amateur radio spectrum as something to lobby for the possession of, our only real hope for a good outcome in this case is for the FCC to step in. We cannot hope for help or support from the ARRL, which again is part of the problem. So no, I have not followed WinMore's development at all, since I already know its fate. Note how WinMore is not open source but is strictly proprietary to the WinLink group, just like SCAMP was. They will be using this control to be sure that it is not developed further or used for any other purpose by anyone else. When they decide to kill it, they will want it to stay dead. - Just as dead as SCAMP is today. 73 DE Charles Brabham, N5PVL Prefer to use radio for your amateur radio communications? - Stop by at HamRadioNet.Org ! http://www.hamradionet.org - Original Message - From: Dave AA6YQ To: digitalradio@yahoogroups.com Sent: Monday, November 23, 2009 10:50 PM Subject: RE: [digitalradio] Digital busy detect Did you evaluate the busy frequency detector in Scamp, Charles? Have you evaluated the busy frequency detector in Winmor? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Charles Brabham Sent: Monday, November 23, 2009 9:55 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Digital busy detect Packet radio gets by with a simple carrier detect, PACTOR can only detect other PACTOR stations, and from what I can tell, ALE has no busy detection at all. Several years ago I took a serious look at automated busy detection, and always ran across the same stone wall: A more sophisticated busy detect that can usually tell the difference between noise and a human activity like speech or digital transmissions is possible - BUT - only after the software has a fairly long audio sample to work with, and can look back upon that sample. It can't do this instantly, or even very quickly unless you have a supercomputer to work with. If it listens to a long sample and a new signal comes in toward the end of that sample, that new signal may or may not end up being identified. This is a terrible thing to have to report, but Packet's carrier detect is the most effective
RE: [digitalradio] Digital busy detect
At no point did the WinLink group intend to phase out the use of the SCS harmful interference mills. This still holds true today. Now Charles just don't pick on the SCS TNC. The PK-232 is the same way And while we are at it let's add that packet group. I hear more the one stations transmitting at the same time a lot. Since the Pactor freq that I like to hang out is real close by. John, W0JAB Louisiana, Missouri
Re: [digitalradio] Digital busy detect
Dave: If WinMore was in the public domain, you might have a point there. When the WinLink group deep-sixes their proprietary software, then who can use it? 73 DE Charles Brabham, N5PVL Prefer to use radio for your amateur radio communications? - Stop by at HamRadioNet.Org ! http://www.hamradionet.org - Original Message - From: Dave AA6YQ To: digitalradio@yahoogroups.com Sent: Tuesday, November 24, 2009 5:29 PM Subject: RE: [digitalradio] Digital busy detect I am fully aware of WinLink's political tactics, but the topic of this thread is busy frequency detection. Independently of why it might have been developed, the busy frequency detector in Scamp surprised many with its effectiveness, including its own developer. I'm assuming that Winmor's busy frequency detector is a descendent of Scamp's, as both were developed by Rick KN6KB. Hold your nose if you must, but I suggest that you evaluate Winmor's busy frequency detector before making additional claims about what is and is not possible. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Charles Brabham Sent: Tuesday, November 24, 2009 7:36 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect I knew one of the hams who first envisioned what would later end up being SCAMP, followed its development with interest, and was thoroughly disgusted at the way the WinLink group used those efforts as a cheap propaganda ploy instead of pursuing it honestly. SCAMP was at no point intended by the WinLink group to see actual use, its development was stretched out and used as a talking point for political purposes. As soon as its utility for that purpose became unsupportable, it was uncerimoniously killed. At no point did the WinLink group intend to phase out the use of the SCS harmful interference mills. This still holds true today. WinMore is just one more SCAMP, unfortunately. Knowing the level of character and intelligence to be found in the WinLink group, I have not followed WinMore's development. - I already know it's fate. After stretching out its supposed development for as long as possible, milking it for political traction ( We are working on ending our widespread inteference - honest! ) there will come the inevitable point where it is reluctantly admitted that WinMore just cannot do the job nearly as well as PACTOR III and then all of a sudden, you won't hear anything more about WinMore. The thing that the ARRL, the FCC, and all amateurs should understand is that WinLink will never be reformed. They hope to become so thoroughly established with delaying tactics like SCAMP and WinMore that eventually the FCC will throw up their hands and award them private spectrum of their own, or re-write PART97 so that we no longer enjoy the use of shared spectrum, thus bringing amateur radio to an end. They want a channelized, CB-like environment and the ARRL, to its discredit, is behind them 100%. As was the case with city and county entities forcing thier employees to get ham tickets as they pursued DHS grant money, and eventually starting to eye amateur radio spectrum as something to lobby for the possession of, our only real hope for a good outcome in this case is for the FCC to step in. We cannot hope for help or support from the ARRL, which again is part of the problem. So no, I have not followed WinMore's development at all, since I already know its fate. Note how WinMore is not open source but is strictly proprietary to the WinLink group, just like SCAMP was. They will be using this control to be sure that it is not developed further or used for any other purpose by anyone else. When they decide to kill it, they will want it to stay dead. - Just as dead as SCAMP is today. 73 DE Charles Brabham, N5PVL Prefer to use radio for your amateur radio communications? - Stop by at HamRadioNet.Org ! http://www.hamradionet.org - Original Message - From: Dave AA6YQ To: digitalradio@yahoogroups.com Sent: Monday, November 23, 2009 10:50 PM Subject: RE: [digitalradio] Digital busy detect Did you evaluate the busy frequency detector in Scamp, Charles? Have you evaluated the busy frequency detector in Winmor? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Charles Brabham Sent: Monday, November 23, 2009 9:55 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Digital busy detect Packet radio gets by with a simple carrier detect, PACTOR can only detect other PACTOR stations, and from what I can tell, ALE has no busy detection at all. Several years ago I took a serious look at automated busy detection, and always ran across the same stone
Re: [digitalradio] Digital busy detect
Sorry John, but what you are witnessing is not Packet stations transmitting on top of each other. What you are seeing is AX25 allowing several stations to share the same slice of spectrum. AX25 works due to carrier detection. Packet TNC's will not transmit if there is a carrier on the air from another Packet station. ( or whatever else that transmits a carrier ) They wait so many milliseconds and try again. If the carrier is still there, it waits again. When it listens and hears no carrier, it transmits. There are occasions when two Packet stations literally transmit at the same time, but it is very rare. That's called a collision. By allowing six, eight, ten or more stations to utilize the same slice of spectrum, AX25 makes Packet one of the highest performiong modes in existence when it comes to spectral efficiency. - It gets more done for more hams - with less spectrum. The only thing at our disposal that actually beats AX25 Packet's spectral efficiency is Amateur Multicast Protocol ( AMP ). PACTOR III is one of the least spectrally efficient modes on the ham bands, if not the very least. A single station takes up 2.4 Khz to do what fifteen PSK31 stations could do with the same amount of spectrum. It is faster than most other digital modes, but not by a great margin, and that moderately higher speed comes with a very hefty price-tag in harmful interference to other hams. By monitoring a single WinLink frequency for one or perhaps two hours a day, I have logged over 150 instances of WinLink stations ruining other hams QSO's in the last year. If you interpolate this data for a projected eight-hour day, that's around a thousand ruined QSOs a year - on that single frequency. But WinLink operates on quite a few frequencies, both inside and outside of the autoforwarding sub-bands. The actual number of QSO's ruined by WinLink every year is probably in the nieghborhood of ten thousand. Tell us, John: How many ruined QSOs every year are you OK with, so that WinLink can move eMail over the ham bands a little bit faster than, say, NBEMS which does the same thing with a live operator on each end and as close to zero instances of harmful interference as is humanly possible? This is something that we should all be thinking about. - The number of ruined QSOs that the FCC thinks is OK is zero. 73 DE Charles Brabham, N5PVL Prefer to use radio for your amateur radio communications? - Stop by at HamRadioNet.Org ! http://www.hamradionet.org - Original Message - From: John Becker, WØJAB To: digitalradio@yahoogroups.com Sent: Tuesday, November 24, 2009 5:58 PM Subject: RE: [digitalradio] Digital busy detect At no point did the WinLink group intend to phase out the use of the SCS harmful interference mills. This still holds true today. Now Charles just don't pick on the SCS TNC. The PK-232 is the same way And while we are at it let's add that packet group. I hear more the one stations transmitting at the same time a lot. Since the Pactor freq that I like to hang out is real close by. John, W0JAB Louisiana, Missouri
Re: [digitalradio] Digital busy detect
Charles Brabham wrote: Packet radio gets by with a simple carrier detect, PACTOR can only detect other PACTOR stations, and from what I can tell, ALE has no busy detection at all. Absolutely not the case. ALE listen's before transmit for other ALE by protocol. And the commonly used ham implementation has a busy detection mode that works for rtty, carrier, and most CW. Just does OK on voice, but that's less of an issue as any operation in the voice sub-bands are attended. Problem is, just like other mode operators have found out, it's unworkable as the majority of legal, in progress qso's will be derailed by someone else firing up. Since the CW op has no way to ask in ALE, PSK, whatever mode is the frequency in use, all they can do is interfere. so the mythical busy detection software would have to have a way to answer back sorry OM, the frequency is in use in every imaginable mode. I see this in the PSK bands by CW RTTY ops, and happens to pretty much any digi mode. It's not unique to ALE for sure. Fact: Radio is vulnerable to hidden terminal effect like most shared media. We live in that world. And because of that, there will be some unintentional interference. Regarding busy detection, I've posted youtube video's of ALE's busy detection in action. Packet's is not the most effective, by any means. All that said, until there is mutual respect of the digi modes right to exist, no one will widely use the busy detection as it's too easy to hold off or interfere with a station running it. see it happen every day on the busy ALE frequencies, and for sure this has soured winlink on busy detection. It's not technology, it's your fellow hams. When I see all psk ops wait for 2 complete transmission cycles to ensure there is no hidden terminal effect, then ask is the frequency in use before transmitting I'll concede. Same for RTTY. Until then, it's just one mode complaining about the other, and we won't see progress. Have fun, Alan km4ba
Re: [digitalradio] Digital busy detect -Winmor
FYI, the author of Winmor advised me that 3rd party busy detect IS part of Winmor. If the client attempts to call the server and the server dtecets another signal, the connect is not allowed. This, as Dave has consutantly pointed out, is to be expected since the Winmor author has shown the ability to design a similar busy detect feature in SCAMP. Andy K3UK On Tue, Nov 24, 2009 at 9:26 AM, Phil Williams ka1...@gmail.com wrote: Yes, seen that myself. philw de ka1gmn On Tue, Nov 24, 2009 at 8:06 AM, Andy obrien k3uka...@gmail.com wrote: WINMOR's busy detect works perfectly at the initiating station's end, a pop-up windows tells you the frequency is in use and ask if you really want to go ahead and transmit. I have not seen it work at the other end, i.e. prevent another station connecting because a third party is also detected at the receive station's end. Andy K3UK
Re: [digitalradio] Digital busy detect -Winmor
My only question here: Is this a required part of the program, or can it be turned on and off? Danny Douglas N7DC ex WN5QMX ET2US WA5UKR ET3USA SV0WPP VS6DD N7DC/YV5 G5CTB All 2 years or more (except Novice). Short stints at: DA/PA/SU/HZ/7X/DU CR9/7Y/KH7/5A/GW/GM/F Pls QSL direct, buro, or LOTW preferred, I Do not use, but as a courtesy do upload to eQSL for those who do. Moderator DXandTALK http://groups.yahoo.com/group/DXandTalk Digital_modes http://groups.yahoo.com/group/digital_modes/?yguid=341090159 - Original Message - From: Andy obrien To: digitalradio@yahoogroups.com Sent: Tuesday, November 24, 2009 9:16 PM Subject: Re: [digitalradio] Digital busy detect -Winmor FYI, the author of Winmor advised me that 3rd party busy detect IS part of Winmor. If the client attempts to call the server and the server dtecets another signal, the connect is not allowed. This, as Dave has consutantly pointed out, is to be expected since the Winmor author has shown the ability to design a similar busy detect feature in SCAMP. Andy K3UK On Tue, Nov 24, 2009 at 9:26 AM, Phil Williams ka1...@gmail.com wrote: Yes, seen that myself. philw de ka1gmn On Tue, Nov 24, 2009 at 8:06 AM, Andy obrien k3uka...@gmail.com wrote: WINMOR's busy detect works perfectly at the initiating station's end, a pop-up windows tells you the frequency is in use and ask if you really want to go ahead and transmit. I have not seen it work at the other end, i.e. prevent another station connecting because a third party is also detected at the receive station's end. Andy K3UK
Re: [digitalradio] Digital busy detect- it's not a technology issue
Andy obrien wrote: FYI, the author of Winmor advised me that 3rd party busy detect IS part of Winmor. so what does it do when it's already involved in a qso, waiting to ack or transmit, and someone starts transmitting? That's the core issue, not detecting that a frequency is in use. Not many options, it can: A) backoff, and effectively abandon the frequency to the new station, even though they are the one who QRM'd B) Try to signal the interfering station in the mode (cw/rtty/clover/ax.25/psk/etc) that the station is using hmm, but that assumes the station is listening, so you have to wait for that station to stop, and try to get a break in. Meanwhile, your sending station you were originally in qso with has timed out! C) Go ahead and transmit anyway, since it was in qso already. Which will still generate complaints, as most of the perceived qrm is really hidden terminal issues and unintentional For any of the busy detection schemes to work, all stations have to be using it, and it would need to a universal freq is in use signal honored by all. The only other alternative is for all stations/modes: - Listen for 2X the average transmission length for the slowest mode possibly in use on the frequency to eliminate the chance of hidden terminal. - For most frequencies/modes, that would be CW or RTTY, so you are looking at a listen period of a minute or more. - Have some algorithm that factors in if you are in QSO vs just starting a QSO My view: This is not a technology issue, it's an operator expectation issue. we could have the miracle BD (busy detection) widget. But until ops in all modes started respecting listening for other modes, it won't work. Ex: The rtty guy in the middle of a qso has a cw op break in. He can't answer in rtty, and his radio is in fsk or ssb mode. IE: He can't just send CW to tell the interloper the freq is in use. And if he answered in rtty, the cw op would not decode it. Same for RTTY/CW in psk. (even worse, due to the long psk transmissions). Shift to ALE/Pactor, and it's even less likely that the op is setup for the mode. So all that said, what are the odds that the homebrew cw op is going to have have the miracle BD? The RTTY op? Ah, so we have the miracle BD send CW (universal) when someone starts qrm'ing a transmission in progress. You just blew any chance of receiving the data being sent by the station you are in qso with. And what is that signal? And will majority of ops respect that? when less less hams even know CW? Remember, you are asking the newer modes to implement this, how will the legacy modes do it? Do you really expect winlink et al to implement a scheme that would allow anyone to pre-empt (hold-off) their traffic, while not doing the same in return? Again, when someone can show me a scheme that queries the freq prior to usage on psk, I'll be convinced. Anything else is still subject to hidden terminal interference, and will still generate complaints. IE: Solve the problem for a legacy mode, and then we'll talk. I'd love to do peer review for such a scheme. We'll get the ARRL to send it out as best practices. Right. Don't mean to be negative, but it's far more complex than JSMOP. (Just A Small Matter Of Programming) Meanwhile, I'll operate ALE occasionally P3 in the auto sub-bands. And bite my tongue when I am qrm'd by RTTY, CW, and other PSK ops in the PSK sub-band. Have fun, Alan km4ba Suggested frequencies for calling CQ with experimental digital modes = 3584,10147, 14074 USB on your dial plus 1000Hz on waterfall. Announce your digital presence via our Interactive Sked Pages at http://www.obriensweb.com/sked Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) * To change settings via email: digitalradio-dig...@yahoogroups.com digitalradio-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: digitalradio-unsubscr...@yahoogroups.com * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [digitalradio] Digital busy detect
re Problem is, just like other mode operators have found out, it's unworkable as the majority of legal, in progress qso's will be derailed by someone else firing up. Its only unworkable because the implementation of the busy frequency detector in question is obviously quite poor. re Since the CW op has no way to ask in ALE, PSK, whatever mode is the frequency in use, all they can do is interfere. so the mythical busy detection software would have to have a way to answer back sorry OM, the frequency is in use in every imaginable mode. No, an automatic station already in QSO need only respond with QRL in CW, which will be understood by the majority of attended stations. re Fact: Radio is vulnerable to hidden terminal effect like most shared media. We live in that world. And because of that, there will be some unintentional interference. This is rarely problem with attended stations; you might not hear one side of an in-progress QSO, but you will hear the other side, and be able to respond appropriately when the side you hear asks you to QSY. Only automated stations without busy frequency detectors suffer the vulnerability you describe here. Effective multi-mode busy frequency detection has been demonstrably feasible for years. Had a concerted effort been made to equip all automatic stations with competent busy frequency detectors, the rate of QSO breakage caused by such stations would have plummeted, the anger caused by this QSO breakage would have dissapated, and we'd be efficiently sharing spectrum in the pursuit of our diverse objectives. Instead, we've been treated to years of blatantly lame excuses as to why busy frequency detection either can't be designed, can't be implemented, can't be deployed, won't work, causes warts, causes cancer, causes global warming, or will cause the universe to expand forever. Few are fooled by this. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Tuesday, November 24, 2009 8:14 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect Charles Brabham wrote: Packet radio gets by with a simple carrier detect, PACTOR can only detect other PACTOR stations, and from what I can tell, ALE has no busy detection at all. Absolutely not the case. ALE listen's before transmit for other ALE by protocol. And the commonly used ham implementation has a busy detection mode that works for rtty, carrier, and most CW. Just does OK on voice, but that's less of an issue as any operation in the voice sub-bands are attended. Problem is, just like other mode operators have found out, it's unworkable as the majority of legal, in progress qso's will be derailed by someone else firing up. Since the CW op has no way to ask in ALE, PSK, whatever mode is the frequency in use, all they can do is interfere. so the mythical busy detection software would have to have a way to answer back sorry OM, the frequency is in use in every imaginable mode. I see this in the PSK bands by CW RTTY ops, and happens to pretty much any digi mode. It's not unique to ALE for sure. Fact: Radio is vulnerable to hidden terminal effect like most shared media. We live in that world. And because of that, there will be some unintentional interference. Regarding busy detection, I've posted youtube video's of ALE's busy detection in action. Packet's is not the most effective, by any means. All that said, until there is mutual respect of the digi modes right to exist, no one will widely use the busy detection as it's too easy to hold off or interfere with a station running it. see it happen every day on the busy ALE frequencies, and for sure this has soured winlink on busy detection. It's not technology, it's your fellow hams. When I see all psk ops wait for 2 complete transmission cycles to ensure there is no hidden terminal effect, then ask is the frequency in use before transmitting I'll concede. Same for RTTY. Until then, it's just one mode complaining about the other, and we won't see progress. Have fun, Alan km4ba
Re: [digitalradio] Digital busy detect
Scamp busy detector as used in Scamp at the time of the group testing I was part of, was NOT the end all of busy detectors. Finding a setting of the threshold was very difficult. Too sensitive and the throughput operation of Scamp was poor due to being held up by the threshold trigger. Not sensitive enough and it did not perform at times when you knew it should have. What worked for one type of band condition for awhile, did not work well during a different type of band condition. Personally witnessed operators that would intentionally come on frequency and put out signals solely for the purpose of triggering the busy detector to stop operations. When Scamp operations were not active, they didnt seem to be active on the frequency. Start Scamp activity and some of the same lids would start up again with just enough activity to activate the busy detector. End result was the agreement to not use it as it was not living up to expectations and stayed that way through the shut down of the group by the author. 73 from Bill - WD8ARZ
Re: [digitalradio] Digital busy detect -Winmor
At the moment it can be turned off, On Tue, Nov 24, 2009 at 9:46 PM, DANNY DOUGLAS n...@comcast.net wrote: My only question here: Is this a required part of the program, or can it be turned on and off? Danny Douglas N7DC ex WN5QMX ET2US WA5UKR ET3USA SV0WPP VS6DD N7DC/YV5 G5CTB All 2 years or more (except Novice). Short stints at: DA/PA/SU/HZ/7X/DU CR9/7Y/KH7/5A/GW/GM/F Pls QSL direct, buro, or LOTW preferred,
Re: [digitalradio] Digital busy detect
Dave AA6YQ wrote: Its only unworkable because the implementation of the busy frequency detector in question is obviously quite poor. Significantly more to it than that... unless *all* stations honor abide by common rules/tech, it simply won't work. This is true of just about any network, not just radio. (remember the FRACK wars back in packet days?) No, an automatic station already in QSO need only respond with QRL in CW, which will be understood by the majority of attended stations. With full respect: Yeah, right :-) You want me to hold off my transmissions automatically, but trust other ops (in other modes) to do the same. Voluntarily. Cross-mode. Right. Kindof like asking all cellphone users to install a device that allows anyone to disable their ringtone. Just what do you think the compliance on that would be? I agree CW QRL is probably the most universal approach, but you'd have to match the exact beat frequency of the cw sig for them to hear it. And be able to decode CW on the fly (CWget in all busy detectors) to honor it from others. This is rarely problem with attended stations; you might not hear one side of an in-progress QSO, but you will hear the other side, and be able to respond appropriately when the side you hear asks you to QSY. Only automated stations without busy frequency detectors suffer the vulnerability you describe here. Only true if you listen for 1-2X the average transmission length or do a ? query. Voice ops do that, because it's not cross mode, and transmission times are shorter. Digi modes do not do that by practice (even RTTY), the transmission times are longer, and the price of an interuptted transmission higher. (resend) And it's not rarely a problem in attended modes, I see it daily on PSK. Effective multi-mode busy frequency detection has been demonstrably feasible for years. Had a concerted effort been made to equip all automatic stations with competent busy frequency detectors, the rate of QSO breakage caused by such stations would have plummeted, the anger caused by this QSO breakage would have dissapated, and we'd be efficiently sharing spectrum in the pursuit of our diverse objectives. Instead, we've been treated to years of blatantly lame excuses as to why busy frequency detection either can't be designed, can't be implemented, can't be deployed, won't work, causes warts, causes cancer, causes global warming, or will cause the universe to expand forever. Few are fooled by this. OK, here's the challenge: Demonstrate it's feasibility if it's JSMOP. Implement one that balances the right of the sending station not to be QRM'd VS the expectation not to QRM. Publish an API a spec (turnaround times, etc). IE: Not a passive (hold off) detector Make it open source so that all coders can leverage refine it. Windows assumption is OK, but we could probably find a lock/semaphore system that is multiplatform. But a windows DLL API would satisfy 90% of the commonly used digi programs. Will have to codify a standard that would allow any program to grab soundcard resources (to monitor as well as send the qrl) along with any cat/ptt required. Or maybe you let the digi program figure out how to send CW QRL, that would be close enough. Do so and I bet we could get the major coders (Certainly DXlab's coder) to roll it in. I'll commit to influencing the major ALE coders to try to integrate. (Steve/Charles/Patrick) We could get Simon on board. Rick is already mostly there. I won't commit for CJX/winlink, as he's been burned by BD more than once. RTTY will be more difficult, but will come with time. Lot's of legacy users of mmtty! Can't just be a passive (hold off) detector, needs to signal QRL and honor QRL signals from others. Independent of your filter that of the other station. (IE: interfering CW op using 500hz filter, you'll have to match his freq pretty darn close) Meanwhile, I'll be in the 7102 bedlam with the rest of the users. Have fun, Alan km4ba
RE: [digitalradio] Digital busy detect- it's not a technology issue
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Tuesday, November 24, 2009 9:57 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect- it's not a technology issue Andy obrien wrote: FYI, the author of Winmor advised me that 3rd party busy detect IS part of Winmor. so what does it do when it's already involved in a qso, waiting to ack or transmit, and someone starts transmitting? That's the core issue, not detecting that a frequency is in use. Not many options, it can: A) backoff, and effectively abandon the frequency to the new station, even though they are the one who QRM'd There is no reason to do this, presuming that the frequency was clear before your QSO began B) Try to signal the interfering station in the mode (cw/rtty/clover/ax.25/psk/etc) that the station is using hmm, but that assumes the station is listening, so you have to wait for that station to stop, and try to get a break in. Meanwhile, your sending station you were originally in qso with has timed out! Wait until the offending signal dissappears, send QRL QRL in CW, and either initiate reconnection or await connection as dictated by the protocol. C) Go ahead and transmit anyway, since it was in qso already. Which will still generate complaints, as most of the perceived qrm is really hidden terminal issues and unintentional No, most of the perceived QRM is not the result of attended stations breaking in on an on-going QSO in which one of the stations is automatic. Several years ago, I monitored WinLink PMBOs with my SCS PTC-IIe. In every case where QRM occured, it was the result of a PMBO responding to a connection request on a frequency that was already in use. For any of the busy detection schemes to work, all stations have to be using it, and it would need to a universal freq is in use signal honored by all. No, only unattended automatic stations need include a busy frequency detector. As suggested earlier, QRL is a universal freq in use signal that will be honored by most attended stations. As long as an unattended automatic station never initiates transmission on a frequency that is in use, then it will rarely QRM an on-going QSO, and thus need not have the means to detect a QRL sent by an attended station. The only collision scenario that is not covered is change in propagation, where two QSOs that were initially sharing a frequency without interfering with each other begin hearing each other because propagation has changed; if one of these QSOs involves an unattended automatic station, it will by the above rules either complete its QSO (if the QRM doesn't prevent it), or break off (if the QRM impedes communication). The only other alternative is for all stations/modes: - Listen for 2X the average transmission length for the slowest mode possibly in use on the frequency to eliminate the chance of hidden terminal. - For most frequencies/modes, that would be CW or RTTY, so you are looking at a listen period of a minute or more. When not in QSO, an automatic station monitors its frequency continuously, so it very well knows whether or not another QSO is in progress on that frequency, even if it can only copy one side of that QSO. - Have some algorithm that factors in if you are in QSO vs just starting a QSO Obviously. My view: This is not a technology issue, it's an operator expectation issue. we could have the miracle BD (busy detection) widget. But until ops in all modes started respecting listening for other modes, it won't work. The scheme described above is straightforward to implement and will prevent QRM most of the time. As I pointed out to Rick KN6KB while attempting to persuade him to implement a busy frequency detector in Scamp, a scheme that's only 80% effective would reduce the incidence of QSOs broken by automatic stations by a factor of 5. Ex: The rtty guy in the middle of a qso has a cw op break in. He can't answer in rtty, and his radio is in fsk or ssb mode. IE: He can't just send CW to tell the interloper the freq is in use. Certainly he can; I have done so. This is easier in FSK where the transceiver is displaying the mark frequency; digital mode apps could easily be extended to automate this operation. Same for RTTY/CW in psk. (even worse, due to the long psk transmissions). Shift to ALE/Pactor, and it's even less likely that the op is setup for the mode. Saving your PSK frequency, changing mode to CW, sending QRL, and returning to PSK is just not that difficult. It certainly beats losing your PSK QSO. So all that said, what are the odds that the homebrew cw op is going to have have the miracle BD? The RTTY op? There is no reason for an attended station to have a busy frequency detector; the operator's ears are generally sufficient. Only unattended automatic stations require a busy frequency detector. Ah, so we have the miracle BD send CW
RE: [digitalradio] Digital busy detect
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of WD8ARZ Sent: Tuesday, November 24, 2009 10:06 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect Scamp busy detector as used in Scamp at the time of the group testing I was part of, was NOT the end all of busy detectors. Correct. It was a first attempt somewhat reluctantly taken by the author with encouragement from me and several others. Finding a setting of the threshold was very difficult. Too sensitive and the throughput operation of Scamp was poor due to being held up by the threshold trigger. Not sensitive enough and it did not perform at times when you knew it should have. What worked for one type of band condition for awhile, did not work well during a different type of band condition. There were quite a few more positive reports from Scamp beta testers posted on this forum at the time. Personally witnessed operators that would intentionally come on frequency and put out signals solely for the purpose of triggering the busy detector to stop operations. When Scamp operations were not active, they didnt seem to be active on the frequency. Start Scamp activity and some of the same lids would start up again with just enough activity to activate the busy detector. This hardly a good reason to not move forward with a mechanism that would reduce the ill-will responsible for these actions. End result was the agreement to not use it as it was not living up to expectations and stayed that way through the shut down of the group by the author. Scamp was terminated because the RDFT protocol on which it was based performed poorly under typical band conditions. Rick KN6KB evidently reached a different conclusion than you did regarding the efficacy of busy frequency detection, as he included busy frequency detection in Winmor. 73, Dave, AA6YQ
RE: [digitalradio] Digital busy detect
+++ AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Tuesday, November 24, 2009 10:30 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect Dave AA6YQ wrote: Its only unworkable because the implementation of the busy frequency detector in question is obviously quite poor. Significantly more to it than that... unless *all* stations honor abide by common rules/tech, it simply won't work. This is true of just about any network, not just radio. (remember the FRACK wars back in packet days?) +++The rules to be honored by all stations are: 1. if you're not yet in QSO, don't transmit on a frequency that is already in use (meaning that signals have been detected during the past 5 minutes) 2. if you're in QSO and signal other than that of your QSO partner appears (the busy frequency detector indicates the presence of signal, but you aren't decoding your QSO partner), wait for that signal to disappear, send QRL QRL in CW, and resume your QSO +++There is nothing complicated about this. Automation is only required in unattended automatic stations. No, an automatic station already in QSO need only respond with QRL in CW, which will be understood by the majority of attended stations. With full respect: Yeah, right :-) You want me to hold off my transmissions automatically, but trust other ops (in other modes) to do the same. Voluntarily. Cross-mode. Right. +++Amateur radio operators have been trusting each other to mutually obey these rules since the service began. On what possible basis can you claim exemption? Kindof like asking all cellphone users to install a device that allows anyone to disable their ringtone. Just what do you think the compliance on that would be? +++No, its not remotely like asking cellphone users to install such a device; there is no parallel whatsoever. I agree CW QRL is probably the most universal approach, but you'd have to match the exact beat frequency of the cw sig for them to hear it. And be able to decode CW on the fly (CWget in all busy detectors) to honor it from others. +++Only attended stations need detect the QRL; if automatic stations never transmit on a frequency that is in use, then they will rarely QRM an ongoing QSO, and so have no need of automatic QRL detection. This is rarely problem with attended stations; you might not hear one side of an in-progress QSO, but you will hear the other side, and be able to respond appropriately when the side you hear asks you to QSY. Only automated stations without busy frequency detectors suffer the vulnerability you describe here. Only true if you listen for 1-2X the average transmission length or do a ? query. Voice ops do that, because it's not cross mode, and transmission times are shorter. Digi modes do not do that by practice (even RTTY), the transmission times are longer, and the price of an interuptted transmission higher. (resend) +++When not in QSO, automatic stations can easily monitor the frequency to determine whether a QSO is in progress, even if they are only hearing one of the stations involved; this is easily implemented. If an automatic station receives a connection request and its busy frequency detector has seen no activity for the past 5 minutes, it can respond to the request without compunction. If its busy frequency detector has been intermittently reporting signals over the past 5 minutes, it should not respond. And it's not rarely a problem in attended modes, I see it daily on PSK. +++I didn't say it rarely occurs, I said its rarely a problem -- because attended stations can communicate with each other and resolve the conflict, thereby preserving the QSO in progress. Unattended automatic stations are incapable of doing this. Effective multi-mode busy frequency detection has been demonstrably feasible for years. Had a concerted effort been made to equip all automatic stations with competent busy frequency detectors, the rate of QSO breakage caused by such stations would have plummeted, the anger caused by this QSO breakage would have dissapated, and we'd be efficiently sharing spectrum in the pursuit of our diverse objectives. Instead, we've been treated to years of blatantly lame excuses as to why busy frequency detection either can't be designed, can't be implemented, can't be deployed, won't work, causes warts, causes cancer, causes global warming, or will cause the universe to expand forever. Few are fooled by this. OK, here's the challenge: Demonstrate it's feasibility if it's JSMOP. Implement one that balances the right of the sending station not to be QRM'd VS the expectation not to QRM. Publish an API a spec (turnaround times, etc). IE: Not a passive (hold off) detector Make it open source so that all coders can leverage refine it. Windows assumption is OK, but we could probably find a lock/semaphore system that is multiplatform
RE: [digitalradio] Digital busy detect
To be clear, an attended station need not wait for 5 minutes of clear frequency before transmitting; 30 seconds of no signals (meaning no automatic station is QRV) followed by a QRL? sent in mode with no response should be sufficient. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Dave AA6YQ Sent: Wednesday, November 25, 2009 2:29 AM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] Digital busy detect +++ AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Tuesday, November 24, 2009 10:30 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect Dave AA6YQ wrote: Its only unworkable because the implementation of the busy frequency detector in question is obviously quite poor. Significantly more to it than that... unless *all* stations honor abide by common rules/tech, it simply won't work. This is true of just about any network, not just radio. (remember the FRACK wars back in packet days?) +++The rules to be honored by all stations are: 1. if you're not yet in QSO, don't transmit on a frequency that is already in use (meaning that signals have been detected during the past 5 minutes) 2. if you're in QSO and signal other than that of your QSO partner appears (the busy frequency detector indicates the presence of signal, but you aren't decoding your QSO partner), wait for that signal to disappear, send QRL QRL in CW, and resume your QSO +++There is nothing complicated about this. Automation is only required in unattended automatic stations. No, an automatic station already in QSO need only respond with QRL in CW, which will be understood by the majority of attended stations. With full respect: Yeah, right :-) You want me to hold off my transmissions automatically, but trust other ops (in other modes) to do the same. Voluntarily. Cross-mode. Right. +++Amateur radio operators have been trusting each other to mutually obey these rules since the service began. On what possible basis can you claim exemption? Kindof like asking all cellphone users to install a device that allows anyone to disable their ringtone. Just what do you think the compliance on that would be? +++No, its not remotely like asking cellphone users to install such a device; there is no parallel whatsoever. I agree CW QRL is probably the most universal approach, but you'd have to match the exact beat frequency of the cw sig for them to hear it. And be able to decode CW on the fly (CWget in all busy detectors) to honor it from others. +++Only attended stations need detect the QRL; if automatic stations never transmit on a frequency that is in use, then they will rarely QRM an ongoing QSO, and so have no need of automatic QRL detection. This is rarely problem with attended stations; you might not hear one side of an in-progress QSO, but you will hear the other side, and be able to respond appropriately when the side you hear asks you to QSY. Only automated stations without busy frequency detectors suffer the vulnerability you describe here. Only true if you listen for 1-2X the average transmission length or do a ? query. Voice ops do that, because it's not cross mode, and transmission times are shorter. Digi modes do not do that by practice (even RTTY), the transmission times are longer, and the price of an interuptted transmission higher. (resend) +++When not in QSO, automatic stations can easily monitor the frequency to determine whether a QSO is in progress, even if they are only hearing one of the stations involved; this is easily implemented. If an automatic station receives a connection request and its busy frequency detector has seen no activity for the past 5 minutes, it can respond to the request without compunction. If its busy frequency detector has been intermittently reporting signals over the past 5 minutes, it should not respond. And it's not rarely a problem in attended modes, I see it daily on PSK. +++I didn't say it rarely occurs, I said its rarely a problem -- because attended stations can communicate with each other and resolve the conflict, thereby preserving the QSO in progress. Unattended automatic stations are incapable of doing this. Effective multi-mode busy frequency detection has been demonstrably feasible for years. Had a concerted effort been made to equip all automatic stations with competent busy frequency detectors, the rate of QSO breakage caused by such stations would have plummeted, the anger caused by this QSO breakage would have dissapated, and we'd be efficiently sharing spectrum in the pursuit of our diverse objectives. Instead, we've been treated to years of blatantly lame excuses as to why busy frequency detection either can't be designed, can't be implemented, can't be deployed, won't work, causes warts, causes cancer, causes
RE: [digitalradio] Digital busy detect
Did you evaluate the busy frequency detector in Scamp, Charles? Have you evaluated the busy frequency detector in Winmor? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Charles Brabham Sent: Monday, November 23, 2009 9:55 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Digital busy detect Packet radio gets by with a simple carrier detect, PACTOR can only detect other PACTOR stations, and from what I can tell, ALE has no busy detection at all. Several years ago I took a serious look at automated busy detection, and always ran across the same stone wall: A more sophisticated busy detect that can usually tell the difference between noise and a human activity like speech or digital transmissions is possible - BUT - only after the software has a fairly long audio sample to work with, and can look back upon that sample. It can't do this instantly, or even very quickly unless you have a supercomputer to work with. If it listens to a long sample and a new signal comes in toward the end of that sample, that new signal may or may not end up being identified. This is a terrible thing to have to report, but Packet's carrier detect is the most effective and sophisticated automatic signal detection scheme we currently have at our disposal. - It detects more kinds of activity *right then* than anything else that hams are currently using. There are lots of signals that carrier detect will not detect - but it is still the best thing out there, that can automatically detect and act in ( more or less ) real-time. The human ear works better, detecting signal intelligence and differentiating it from noise far better than any automated detection system. Period. Better still is the human eye, looking at a properly set up waterfall display that will show you recognizable patterns in the waterfall image that you may not be able to register just by listening. One thing to ponder is why carrier detect, developed over twenty-five years ago is not utilized by PACTOR or ALE, both allegedly more advanced than Packet. My feeling on this is that if they cannot detect signals as well as Packet does, then which mode is more advanced, more suitible for use on the ham bands? That is really an unfair question in the case of PACTOR III and ALE, niether one of which was designed or ever intended for use within shared amateur radio spectrum, in the first place. It is not the square peg's fault that it will not fit in the round hole. In the end, if we are not operating an automated station, then a waterfall display in combination with speaker audio is the most effective and useful busy detection system we have at our disposal, and this will almost certainly continue to be the case for a very long time. For real-time automated busy detection, carrier detect is highly likely to be the best thing at our disposal - again for a very long time. The Reed-Soloman ID system is a great step ahead for digital operation. It is not really useful as a real-time busy-detect, but it does give us a first step on something that may eventually take us there. As standards and hardware evolve over the years, we may eventually embed information into our data streams that can be instantly recognized as 'busy' by our software. - It may even approach the speed of carrier detect, and work with all modes. But don't hold your breath, it's not right around the corner. 73 DE Charles Brabham, N5PVL Prefer to use radio for your amateur radio communications? - Stop by at HamRadioNet.Org ! http://www.hamradionet.org
