RE: [digitalradio] Need new emergency communications mode
They probably can't afford Pactor TNCs. 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Howard Brown Sent: Thursday, October 18, 2007 8:50 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Need new emergency communications mode Dave, you are exactly correct. Can you explain why the FCC does not cite these stations and cause them to cease the QRM? I certainly do not understand that. Howard K5HB - Original Message From: Dave AA6YQ <[EMAIL PROTECTED]> To: digitalradio@yahoogroups.com Sent: Thursday, October 18, 2007 5:22:18 PM Subject: RE: [digitalradio] Need new emergency communications mode I have suggested that automatic busy detection be disabled on unattended stations handling during emergencies. This has nothing to do with preferring the human factor, whatever that might be. It has to do with optimizing for the transport of messages during an emergency situation. Your overall argument seems to be that QRM between amateur stations can't be entirely eliminated, so it's okay if unattended stations QRM existing signals. Keep in mind that 97.101(d) prohibits *willful* interference. If stations A calls CQ and in the process QRMs station B, but station A cannot hear station B, then the interference is by definition not willful. However if station A can hear station B but calls anyway, then the interference is willful and station A is in violation of 97.101(d). This does happen, but it's very infrequent; any ham would refer to A as a lid in these circumstances. Unattended stations behave exactly like station A above. When initiated by a remote station, they transmit whether they will QRM a station or not. This behavior is unacceptable whether or not there's a technical solution that can prevent it much of the time. It's double unacceptable when the solution is not incorporated. I am disappointed that someone as comfortable with digital technology as you are would offer up a continuous stream of lame excuses for not deploying this solution (or a better one, if you have one in mind). 73, Dave, AA6YQ From: digitalradio@ yahoogroups. com [mailto:digitalradi [EMAIL PROTECTED] com] On Behalf Of Steve Hajducek Sent: Thursday, October 18, 2007 10:02 AM To: digitalradio@ yahoogroups. com Subject: RE: [digitalradio] Need new emergency communications mode Hi Dave, Thanks for jumping in here with Rick and I, if you read my reply that I just sent in response to Rick I feel you will see that I pretty much already touched on your points, I see that you would personally turn off automatic frequency detection as you prefer the human factor, no surprises there. /s/ Steve, N2CKH At 12:22 AM 10/18/2007, you wrote: >>>AA6YQ comments below From: digitalradio@ yahoogroups. com [ mailto:digitalradio <mailto:digitalradio@yahoogroups.com> @yahoogroups. com] On Behalf Of Steve Hajducek >snip< 2. With respect to Remote User to Automatic Station communications, the human operator initiates the communications and its all up to them to decide the coast is clear to do so or not and if they need to stop because they screwed up and did not listen long enough ( how long is long enough? >>>The hidden transmitter effect means that the remote initiator cannot reliably ensure that the coast is clear. >>>If we're on the telephone from California and say "14180 is clear here, give me a call there", can you transmit on 14180 from your QTH on the east coast without first listening to see if 14180 is clear there? Of course not; doing so might QRM a station in Florida that you hear 59 but I don't hear at all. Now consider your station to be an unattended server and my station in California to be the remote initiator. Your unattended server will QRM the station in Florida. be it human operator or computer software there is not now and never will be any perfect means of busy detection in my opinion) to detect that the frequency was indeed in use due either propagation or just plain long pauses between transmissions of the 3rd party stations. >>>"Perfect" is unnecessary. It is clearly possible to build busy frequency detectors that are at least 80% effect, since such a busy detector was demonstrated years ago. Applying such an imperfect busy detector to unattended stations would reduce their QRM by a factor of 5. >>>This "it's impossible to build a perfect busy detector" argument reminds me of Xeno's paradox, in which he proves that all motion is impossible. In closing, you and everyone else on this frequency busy detection quest just don't seem to grasp the realities the shared aspects of the Amateur Radio bands and tolerance for co-frequency levels of interference and just what it is that you are proposing with your frequency bu
RE: [digitalradio] Need new emergency communications mode
The development of soundcard-based panoramic PSK31 applications attracted a many new digital mode users. Soundcard RTTY software rekindled interest in that mode, and the plethora of new and improved digital modes has further stimulated interest. As a result, there are many more digital mode QSOs today. The probability that an unattended stations transmission will QRM an ongoing QSO has thus increased and with it the reports of this QRM. 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of "John Becker, WØJAB" Sent: Thursday, October 18, 2007 6:52 PM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] Need new emergency communications mode This is not a new problem. It goes back to the early 1970's that I know of. When RTTY had WRU's. Packet, Amtor and, as most like to pick on, the Pactor stations. even keyboard to keyboard just because they hear a pactor station. But it seems to me that nobody complained like this till the PSK group moved into what at one time was called " pactor ally ". Is this right? And I agree with you Dave 1000 per cent. So I guess I said it again also. John, W0JAB At 05:24 PM 10/18/2007, you wrote: >I have said before that the problem is unattended stations initiated by remote stations, and have made it clear that this is independent of the mode being used. Consider me to have said it again.
RE: [digitalradio] Need new emergency communications mode
If you can convince the FCC to adopt separate sub-bands, fine. Until then, US operators of unattended stations are required to prevent those stations from transmitting over existing QSOs. Whether you do that with a busy frequency detector, a squad of high-school students hired to monitor your station 24x7, or some new technique of your invention is fine; allowing your unattended station to QRM others is violation of 97.101(d); worse, in my opinion, it violates the basic respect that each amateur is expected to grant his or her peers. In your statement below, you make clear that your problem with busy frequency detectors is not that they can't be implemented, or that they won't achieve their purpose, but rather that they would "hinder timely access to automated communications". By this you are saying that traffic handled by unattended stations is more important than other amateur QSOs. You are saying that it's OK to keep QRMing ongoing QSOs because the alternative -- a busy frequency detector - might occasionally delay an unattended station's ability to transfer messages. This is incredibly arrogant, and again violates a basic principle of amateur radio - that no one has more rights to a frequency than anyone else (emergency conditions excepted). At least you have the courage to clearly state your position. Perhaps the discussion can now focus on the root cause of the conflict, rather than all this chaff about busy frequency detectors not being possible to implement. 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Steve Hajducek Sent: Thursday, October 18, 2007 7:09 PM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] Need new emergency communications mode Dave, As simple as I can put it for you, it is my opinion that the better solution is separation into sub bands is the only logical solution to your perceived issues with automated stations triggered by remote users as technology as we know it now (and likely for a very long time to come) does not offer a workable frequency busy detection solution that would not hinder timely access to automated communications in my opinion. /s/ Steve, N2CKH At 06:22 PM 10/18/2007, you wrote: I have suggested that automatic busy detection be disabled on unattended stations handling during emergencies. This has nothing to do with preferring the human factor, whatever that might be. It has to do with optimizing for the transport of messages during an emergency situation. Your overall argument seems to be that QRM between amateur stations can't be entirely eliminated, so it's okay if unattended stations QRM existing signals. Keep in mind that 97.101(d) prohibits *willful* interference. If stations A calls CQ and in the process QRMs station B, but station A cannot hear station B, then the interference is by definition not willful. However if station A can hear station B but calls anyway, then the interference is willful and station A is in violation of 97.101(d). This does happen, but it's very infrequent; any ham would refer to A as a lid in these circumstances. Unattended stations behave exactly like station A above. When initiated by a remote station, they transmit whether they will QRM a station or not. This behavior is unacceptable whether or not there's a technical solution that can prevent it much of the time. It's double unacceptable when the solution is not incorporated. I am disappointed that someone as comfortable with digital technology as you are would offer up a continuous stream of lame excuses for not deploying this solution (or a better one, if you have one in mind). 73, Dave, AA6YQ
Re: [digitalradio] Need new emergency communications mode
Dave, you are exactly correct. Can you explain why the FCC does not cite these stations and cause them to cease the QRM? I certainly do not understand that. Howard K5HB - Original Message From: Dave AA6YQ <[EMAIL PROTECTED]> To: digitalradio@yahoogroups.com Sent: Thursday, October 18, 2007 5:22:18 PM Subject: RE: [digitalradio] Need new emergency communications mode I have suggested that automatic busy detection be disabled on unattended stations handling during emergencies. This has nothing to do with preferring the human factor, whatever that might be. It has to do with optimizing for the transport of messages during an emergency situation. Your overall argument seems to be that QRM between amateur stations can’t be entirely eliminated, so it’s okay if unattended stations QRM existing signals. Keep in mind that 97.101(d) prohibits *willful* interference. If stations A calls CQ and in the process QRMs station B, but station A cannot hear station B, then the interference is by definition not willful. However if station A can hear station B but calls anyway, then the interference is willful and station A is in violation of 97.101(d). This does happen, but it’s very infrequent; any ham would refer to A as a lid in these circumstances. Unattended stations behave exactly like station A above. When initiated by a remote station, they transmit whether they will QRM a station or not. This behavior is unacceptable whether or not there’s a technical solution that can prevent it much of the time. It’s double unacceptable when the solution is not incorporated. I am disappointed that someone as comfortable with digital technology as you are would offer up a continuous stream of lame excuses for not deploying this solution (or a better one, if you have one in mind). 73, Dave, AA6YQ From: digitalradio@ yahoogroups. com [mailto:digitalradi [EMAIL PROTECTED] com] On Behalf Of Steve Hajducek Sent: Thursday, October 18, 2007 10:02 AM To: digitalradio@ yahoogroups. com Subject: RE: [digitalradio] Need new emergency communications mode Hi Dave, Thanks for jumping in here with Rick and I, if you read my reply that I just sent in response to Rick I feel you will see that I pretty much already touched on your points, I see that you would personally turn off automatic frequency detection as you prefer the human factor, no surprises there. /s/ Steve, N2CKH At 12:22 AM 10/18/2007, you wrote: >>>AA6YQ comments below From: digitalradio@ yahoogroups. com [ mailto:digitalradio @yahoogroups. com] On Behalf Of Steve Hajducek >snip< 2. With respect to Remote User to Automatic Station communications, the human operator initiates the communications and its all up to them to decide the coast is clear to do so or not and if they need to stop because they screwed up and did not listen long enough ( how long is long enough? >>>The hidden transmitter effect means that the remote initiator cannot reliably ensure that the coast is clear. >>>If we’re on the telephone from California and say “14180 is clear here, give me a call there”, can you transmit on 14180 from your QTH on the east coast without first listening to see if 14180 is clear there? Of course not; doing so might QRM a station in Florida that you hear 59 but I don’t hear at all. Now consider your station to be an unattended server and my station in California to be the remote initiator. Your unattended server will QRM the station in Florida. be it human operator or computer software there is not now and never will be any perfect means of busy detection in my opinion) to detect that the frequency was indeed in use due either propagation or just plain long pauses between transmissions of the 3rd party stations. >>>”Perfect” is unnecessary. It is clearly possible to build busy frequency detectors that are at least 80% effect, since such a busy detector was demonstrated years ago. Applying such an imperfect busy detector to unattended stations would reduce their QRM by a factor of 5. >>>This “it’s impossible to build a perfect busy detector” argument reminds me of Xeno’s paradox, in which he proves that all motion is impossible. In closing, you and everyone else on this frequency busy detection quest just don't seem to grasp the realities the shared aspects of the Amateur Radio bands and tolerance for co-frequency levels of interference and just what it is that you are proposing with your frequency busy detection dream. >>>To what “realities” are you referring? Amateur radio bands are certainly shared, but that gives no station the right to QRM existing signals. Also you seem to think the issue is with Automatic Stations, when in fact it is really with Human operated stations. If there i
RE: [digitalradio] Need new emergency communications mode
Dave, As simple as I can put it for you, it is my opinion that the better solution is separation into sub bands is the only logical solution to your perceived issues with automated stations triggered by remote users as technology as we know it now (and likely for a very long time to come) does not offer a workable frequency busy detection solution that would not hinder timely access to automated communications in my opinion. /s/ Steve, N2CKH At 06:22 PM 10/18/2007, you wrote: I have suggested that automatic busy detection be disabled on unattended stations handling during emergencies. This has nothing to do with preferring the human factor, whatever that might be. It has to do with optimizing for the transport of messages during an emergency situation. Your overall argument seems to be that QRM between amateur stations can't be entirely eliminated, so it's okay if unattended stations QRM existing signals. Keep in mind that 97.101(d) prohibits *willful* interference. If stations A calls CQ and in the process QRMs station B, but station A cannot hear station B, then the interference is by definition not willful. However if station A can hear station B but calls anyway, then the interference is willful and station A is in violation of 97.101(d). This does happen, but it's very infrequent; any ham would refer to A as a lid in these circumstances. Unattended stations behave exactly like station A above. When initiated by a remote station, they transmit whether they will QRM a station or not. This behavior is unacceptable whether or not there's a technical solution that can prevent it much of the time. It's double unacceptable when the solution is not incorporated. I am disappointed that someone as comfortable with digital technology as you are would offer up a continuous stream of lame excuses for not deploying this solution (or a better one, if you have one in mind). 73, Dave, AA6YQ
RE: [digitalradio] Need new emergency communications mode
This is not a new problem. It goes back to the early 1970's that I know of. When RTTY had WRU's. Packet, Amtor and, as most like to pick on, the Pactor stations. even keyboard to keyboard just because they hear a pactor station. But it seems to me that nobody complained like this till the PSK group moved into what at one time was called " pactor ally ". Is this right? And I agree with you Dave 1000 per cent. So I guess I said it again also. John, W0JAB At 05:24 PM 10/18/2007, you wrote: >I have said before that the problem is unattended stations initiated by remote >stations, and have made it clear that this is independent of the mode being >used. Consider me to have said it again.
RE: [digitalradio] Need new emergency communications mode
I have suggested that automatic busy detection be disabled on unattended stations handling during emergencies. This has nothing to do with preferring the human factor, whatever that might be. It has to do with optimizing for the transport of messages during an emergency situation. Your overall argument seems to be that QRM between amateur stations can't be entirely eliminated, so it's okay if unattended stations QRM existing signals. Keep in mind that 97.101(d) prohibits *willful* interference. If stations A calls CQ and in the process QRMs station B, but station A cannot hear station B, then the interference is by definition not willful. However if station A can hear station B but calls anyway, then the interference is willful and station A is in violation of 97.101(d). This does happen, but it's very infrequent; any ham would refer to A as a lid in these circumstances. Unattended stations behave exactly like station A above. When initiated by a remote station, they transmit whether they will QRM a station or not. This behavior is unacceptable whether or not there's a technical solution that can prevent it much of the time. It's double unacceptable when the solution is not incorporated. I am disappointed that someone as comfortable with digital technology as you are would offer up a continuous stream of lame excuses for not deploying this solution (or a better one, if you have one in mind). 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Steve Hajducek Sent: Thursday, October 18, 2007 10:02 AM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] Need new emergency communications mode Hi Dave, Thanks for jumping in here with Rick and I, if you read my reply that I just sent in response to Rick I feel you will see that I pretty much already touched on your points, I see that you would personally turn off automatic frequency detection as you prefer the human factor, no surprises there. /s/ Steve, N2CKH At 12:22 AM 10/18/2007, you wrote: >>>AA6YQ comments below From: digitalradio@yahoogroups.com [ mailto:digitalradio@yahoogroups.com <mailto:digitalradio@yahoogroups.com> ] On Behalf Of Steve Hajducek >snip< 2. With respect to Remote User to Automatic Station communications, the human operator initiates the communications and its all up to them to decide the coast is clear to do so or not and if they need to stop because they screwed up and did not listen long enough ( how long is long enough? >>>The hidden transmitter effect means that the remote initiator cannot reliably ensure that the coast is clear. >>>If we're on the telephone from California and say "14180 is clear here, give me a call there", can you transmit on 14180 from your QTH on the east coast without first listening to see if 14180 is clear there? Of course not; doing so might QRM a station in Florida that you hear 59 but I don't hear at all. Now consider your station to be an unattended server and my station in California to be the remote initiator. Your unattended server will QRM the station in Florida. be it human operator or computer software there is not now and never will be any perfect means of busy detection in my opinion) to detect that the frequency was indeed in use due either propagation or just plain long pauses between transmissions of the 3rd party stations. >>>"Perfect" is unnecessary. It is clearly possible to build busy frequency detectors that are at least 80% effect, since such a busy detector was demonstrated years ago. Applying such an imperfect busy detector to unattended stations would reduce their QRM by a factor of 5. >>>This "it's impossible to build a perfect busy detector" argument reminds me of Xeno's paradox, in which he proves that all motion is impossible. In closing, you and everyone else on this frequency busy detection quest just don't seem to grasp the realities the shared aspects of the Amateur Radio bands and tolerance for co-frequency levels of interference and just what it is that you are proposing with your frequency busy detection dream. >>>To what "realities" are you referring? Amateur radio bands are certainly shared, but that gives no station the right to QRM existing signals. Also you seem to think the issue is with Automatic Stations, when in fact it is really with Human operated stations. If there is going to be frequency busy detection in digital mode communications software ( and hardware where all that is not so equipped would need to be banned from use to make your dream a reality) than it needs to be in the Remote User's software to second guess the human factor at all times and not in the Automatic Station side as its the human operator that initiates the communications, for any Automatic Station Forward
RE: [digitalradio] Need new emergency communications mode
I have said before that the problem is unattended stations initiated by remote stations, and have made it clear that this is independent of the mode being used. Consider me to have said it again. 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of "John Becker, WØJAB" Sent: Thursday, October 18, 2007 10:39 AM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] Need new emergency communications mode Would "you" say this is true with any " Automatic Station " ? RTTY - Amtor as well as Pactor or even PSK mail. The reason I ask is I was reading the mail up on 7103.5 last evening between 2 pactor station, when someone on packet called up another packet station right on top of them. I really fail to see how anyone would not know the frequency was already in use by a AQR mode. Since one should hear one if not both sides of the QSO. I dislike the bad rap that just one mode is getting when in fact it's all of them. At 11:22 PM 10/17/2007, you wrote: >>>>AA6YQ comments below >>snip< > >2. With respect to Remote User to Automatic Station communications, >the human operator initiates the communications and its all up to >them to decide the coast is clear to do so or not and if they need to >stop because they screwed up and did not listen long enough ( how >long is long enough? > >>>>The hidden transmitter effect means that the remote initiator cannot reliably ensure that the coast is clear. > >>>>If were on the telephone from California and say 14180 is clear here, give me a call there, can you transmit on 14180 from your QTH on the east coast without first listening to see if 14180 is clear there? Of course not; doing so might QRM a station in Florida that you hear 59 but I dont hear at all. Now consider your station to be an unattended server and my station in California to be the remote initiator. Your unattended server will QRM the station in Florida. > > > > be it human operator or computer software there >is not now and never will be any perfect means of busy detection in >my opinion) to detect that the frequency was indeed in use due either >propagation or just plain long pauses between transmissions of the >3rd party stations. > >>>>Perfectis unnecessary. It is clearly possible to build busy frequency detectors that are at least 80% effect, since such a busy detector was demonstrated years ago. Applying such an imperfect busy detector to unattended stations would reduce their QRM by a factor of 5. > >>>>This its impossible to build a perfect busy detectorargument reminds me of Xenos paradox, in which he proves that all motion is impossible. > > >In closing, you and everyone else on this frequency busy detection >quest just don't seem to grasp the realities the shared aspects of >the Amateur Radio bands and tolerance for co-frequency levels of >interference and just what it is that you are proposing with your >frequency busy detection dream. > >>>>To what realitiesare you referring? Amateur radio bands are certainly shared, but that gives no station the right to QRM existing signals. > >Also you seem to think the issue is >with Automatic Stations, when in fact it is really with Human >operated stations. If there is going to be frequency busy detection >in digital mode communications software ( and hardware where all that >is not so equipped would need to be banned from use to make your >dream a reality) than it needs to be in the Remote User's software to >second guess the human factor at all times and not in the Automatic >Station side as its the human operator that initiates the >communications, for any Automatic Station Forwarding between like >stations then and only then would frequency busy detection apply to >the Automated Station initiating the connection. > >>>> What are you talking about? The issue is preventing an unattended station from transmitting on a frequency that is already in use. > > Also, to be as >complete and concise as possible, such frequency busy detection needs >to be applied to all known and legal for use digital modes around the >world and not just detection of RF energy period ( else your station >may never go into TX ). Doing so would force all human users to be >courteous and standby when any real digital mode signal that is >within their passband from any source, which will force the use of >narrower filters for given modes or cause stations to yield to wider >band mode operations and narrow bandwidth modes operations will have >to steer clear of wider mode operations. Then, depending on the >timing of who transmits first and what the forced upon you timing >constraints of
Re: [digitalradio] Need new emergency communications mode
Rick, At 03:21 PM 10/18/2007, you wrote: >Steve, > >This is not a dream of mine. This is what eventually will have to be if >automatic operation is to continue to be permitted on amateur >frequencies. Its just a dream on your part and other until such time rules ever require it Rick. > This attitude that the automatic stations are more >important than human operated stations is simply not a wise position to >take on a shared service such as we have in amateur radio. Show me any Amateur Radio operation that is manned 24/7 ready, willing and able to accept traffic for relay Rick and I will then look upon that operation as having the same level of importance to the Amateur Radio Service. As far as I am concerned Amateur Radio Operators and Automated Amateur Radio Systems ( HF and above ) that are positioned to provide and support Emergency Communications is the basis for the continued existence of the Amateur Radio Service in this country and most countries in the world. >No one has to learn any new coding. It has already been invented. Nothing exists that is not ripe with issues anyway you look at it Rick. > The >issue of busy frequency detection may have been around a long time (and >rightfully so considering the interference problem from automatic >stations) and the conventional wisdom was that automatic detection could >not be done. I don't know if you have used this software, but I >certainly have used it and it does work. > >I will say this, with the comments made by an increasing number of hams >like yourself, who either lack technical understanding of hidden >transmitters or who want to ignore the problem, that I, and also an >increasing number of hams are becoming less supportive of any automatic >stations on the congested HF bands. Think about the direction you are >taking with this anti technology approach and the long term >ramifications that may come your way in the future. Rick, think about the direction that you are calling for and the ramification that may come your way in the future with such a proposition, there you are with important traffic to pass and you can't get connected to move it due to some daily QSO going on or whatever that either your station or the other station detects ( that you may not even hear with your ears) and where they don't hear either you or the station that you are looking to work, be it attended or not, but where you frequency busy detection that you are dreaming about holds off your communications. That's the future that you dreaming about my friend, to me, its nothing more than a potential nightmare. You and everyone else should be calling for separate traffic lanes (similar to driving down the highway) for Amateur Radio Service Traffic Automation if you feel the existence of such systems co-mingled with peer-to-peer traffic is such an issue as separation and not dreams of busy detection is the only logical answer to your complaints. /s/ Steve, N2CKH >73, > >Rick, KV9U
Re: [digitalradio] Need new emergency communications mode
Steve, This is not a dream of mine. This is what eventually will have to be if automatic operation is to continue to be permitted on amateur frequencies. This attitude that the automatic stations are more important than human operated stations is simply not a wise position to take on a shared service such as we have in amateur radio. No one has to learn any new coding. It has already been invented. The issue of busy frequency detection may have been around a long time (and rightfully so considering the interference problem from automatic stations) and the conventional wisdom was that automatic detection could not be done. I don't know if you have used this software, but I certainly have used it and it does work. I will say this, with the comments made by an increasing number of hams like yourself, who either lack technical understanding of hidden transmitters or who want to ignore the problem, that I, and also an increasing number of hams are becoming less supportive of any automatic stations on the congested HF bands. Think about the direction you are taking with this anti technology approach and the long term ramifications that may come your way in the future. 73, Rick, KV9U Steve Hajducek wrote: > Rick, > > I don't share your dream Rick, sorry that you did not like that > description, but I was trying to be polite about it. I am not here to > stop you or anyone from pursuing your dreams, go learn C++ or Ada and > start coding it up into your dream communications software. However I > am a realist and as I don't share your dream, I see it for what it > really is, a potential nightmare that would hinder communications > rather than actually improving it. I won't be pursuing your dream > with my valuable time available to me for code development unless a > dreamer manages to get such a requirement into the rules which govern > the Amateur Radio Service, which I don't see happening anytime soon, > if ever, as those in charge of the rules are also realists, at least > at present. > > The issue you are talking about has been around since day one and > always will be in all forms of RF communications, the answer to the > issue is a level of tolerance, its that simple. Just because one > station of two ( regardless if one is unattended ) can hear a 3rd > station does not even mean that the 3rd station can hear either of > the two in question. As a matter of fact the 3rd station may be > hearing the that station which does not hear them rather than the > scenario that you paint, which means that it would be the attended > station that is offending the 3rd station and not the unattended > station in your scenario. > > In actual operation the dream scenario that you are proposing be it > for Attended, Unattended or at all emitter locations, which is what > I would want to see, would not make the Amateur Radio Service > better, it would actually only hinder communications. You would still > have the same issue that you are complaining about happening as you > already realize from your comments, but just about as often if you > ask me and if the algorithms were ratcheted up to the point really > making a dent in the issue, then we are talking about holding off TX > whenever enough RF signal is detected in the pass band over x amount > of time that the algorithm qualifies as a true digital mode signal > from somewhere and unless the band in question is dead, that is > pretty much all the time. What will you will have then, almost no > communications taking place would be the result as there is almost > always a signal being heard from somewhere. Granted, you and many > others would love to see almost no communications taking place WRT > automated stations as you and others think they should not exist > except when you feel they are needed for an ECOM event only, well I > don't share that view, my view is just the opposite, automated > systems are very important to the Amateur Radio Service, as they > serve everyone and not just the individuals pursuit, they exist for > the benefit of all Radio Amateurs communications needs 24/7, which > means they can be relied upon by ECOM first responders in the middle > or the day or night when needed. I fully understand why you and > others would never want what you are preaching for in automated > system to be in the systems that you use for digital communications > and if it were to be why you would want the option to turn it off, > however an unattended station can not just decide to turn it off, > human intervention would be required and for the first ECOM > responders trying to use the system that intervention would likely > not come fast enough. > > I had stated on this forum a while ago that the only way to make you > and others with your opinions of as you call it "on going problems" > with automated stations is to have all such stations in sub bands > where no other operations are conducted, that
Re: [digitalradio] Need new emergency communications mode: Server
Rick said: "I have followed the Aplink/Winlink/ Netlink/Winlink 2000 progression over a period of well over 20 years and have used the Aplink and Winlink systems when they were operational." Rick, I think it is worth noting that the old Winlink BBS system is still operational on AF MARS. IMO one of the reasons for this is they have not worked out some details, like how to handle bulletins. One other point, Rud said: "A PBMO is an RF, or internet, message collection and delivery point. The servers are Internet computers that store messages and determine the routing through the network." Rud, I am sure you know this but the PMBOs do use the internet for everything except the actual transfer of emails from the sender and to the receiver. I believe the Winlink 2000 system works pretty well for MARS operations where it has dedicated channels. There are some areas where it can be improved and I believe those areas are being addressed (at least for MARS). Personally, I do not attempt to use WL2K for ham purposes because I only have Pactor 1 and because it does not listen before transmitting on shared frequencies. I do not plan to purchase an expensive modem so let's get something going that works like Pactor 2 in software. Howard K5HB - Original Message From: Rick <[EMAIL PROTECTED]> To: digitalradio@yahoogroups.com Sent: Thursday, October 18, 2007 7:48:15 AM Subject: Re: [digitalradio] Need new emergency communications mode: Server Rud, Many, many incredibly successful projects use open source. In fact, many large projects could never have been developed any other way since they were otherwise not financially viable. Enough said. Now about the server vs Winlink 2000. A PMBO is a server to the RF side of the system as well as interfacing with the next level server(s) at the CMS level. FThis is the achilles heel of the Winlink 2000 system with several layers of servers and back out again. On VHF a Telpac server does the interfacing to RF side, everything else is done via the internet. My understanding is that the Telpac connects to a PMBO which connects to a CMS, then back to a PMBO and back to a Telpac. This is true, even if it is the same Telpac. A PMBO can be set up to locally handle connections, similar to a repeater, but this is yet another single point failure model that I want to avoid in any local networking. If there are instant PMBOs, it is not something openly discussed or made available. I have followed the Aplink/Winlink/ Netlink/Winlink 2000 progression over a period of well over 20 years and have used the Aplink and Winlink systems when they were operational. 73, Rick, KV9U Rud Merriam wrote: > Rick, > > I am not commenting on the validity of your point about PSKMail. > > Your comment is exactly the problem with an open project. As is your > observation about Winlink 2000. An open project gets continuously > sidetracked into explanations of why the technique of some other project is > not being used. This can be months after the group doing the work made a > series of rational decisions about the technique being used. > > More specifically, you have confused the PMBO and server issues in your > point about Winlink. They are two different entities in that system. A PBMO > is an RF, or internet, message collection and delivery point. The servers > are Internet computers that store messages and determine the routing through > the network. Only an EmComm PBMO provides routing when the Internet is not > available. The general PBMO must have an Internet connection. You are > correct that a PBMO must be set up. There are supposed to be portable EmComm > PBMOs ready for deployment if one is not in the area. > >
RE: [digitalradio] Need new emergency communications mode
Would "you" say this is true with any " Automatic Station " ? RTTY - Amtor as well as Pactor or even PSK mail. The reason I ask is I was reading the mail up on 7103.5 last evening between 2 pactor station, when someone on packet called up another packet station right on top of them. I really fail to see how anyone would not know the frequency was already in use by a AQR mode. Since one should hear one if not both sides of the QSO. I dislike the bad rap that just one mode is getting when in fact it's all of them. At 11:22 PM 10/17/2007, you wrote: AA6YQ comments below >>snip< > >2. With respect to Remote User to Automatic Station communications, >the human operator initiates the communications and its all up to >them to decide the coast is clear to do so or not and if they need to >stop because they screwed up and did not listen long enough ( how >long is long enough? > The hidden transmitter effect means that the remote initiator cannot reliably ensure that the coast is clear. > If were on the telephone from California and say 14180 is clear here, give me a call there, can you transmit on 14180 from your QTH on the east coast without first listening to see if 14180 is clear there? Of course not; doing so might QRM a station in Florida that you hear 59 but I dont hear at all. Now consider your station to be an unattended server and my station in California to be the remote initiator. Your unattended server will QRM the station in Florida. > > > > be it human operator or computer software there >is not now and never will be any perfect means of busy detection in >my opinion) to detect that the frequency was indeed in use due either >propagation or just plain long pauses between transmissions of the >3rd party stations. > Perfectis unnecessary. It is clearly possible to build busy frequency detectors that are at least 80% effect, since such a busy detector was demonstrated years ago. Applying such an imperfect busy detector to unattended stations would reduce their QRM by a factor of 5. > This its impossible to build a perfect busy detectorargument reminds me of Xenos paradox, in which he proves that all motion is impossible. > > >In closing, you and everyone else on this frequency busy detection >quest just don't seem to grasp the realities the shared aspects of >the Amateur Radio bands and tolerance for co-frequency levels of >interference and just what it is that you are proposing with your >frequency busy detection dream. > To what realitiesare you referring? Amateur radio bands are certainly shared, but that gives no station the right to QRM existing signals. > >Also you seem to think the issue is >with Automatic Stations, when in fact it is really with Human >operated stations. If there is going to be frequency busy detection >in digital mode communications software ( and hardware where all that >is not so equipped would need to be banned from use to make your >dream a reality) than it needs to be in the Remote User's software to >second guess the human factor at all times and not in the Automatic >Station side as its the human operator that initiates the >communications, for any Automatic Station Forwarding between like >stations then and only then would frequency busy detection apply to >the Automated Station initiating the connection. > What are you talking about? The issue is preventing an unattended station from transmitting on a frequency that is already in use. > > Also, to be as >complete and concise as possible, such frequency busy detection needs >to be applied to all known and legal for use digital modes around the >world and not just detection of RF energy period ( else your station >may never go into TX ). Doing so would force all human users to be >courteous and standby when any real digital mode signal that is >within their passband from any source, which will force the use of >narrower filters for given modes or cause stations to yield to wider >band mode operations and narrow bandwidth modes operations will have >to steer clear of wider mode operations. Then, depending on the >timing of who transmits first and what the forced upon you timing >constraints of the algorithms used end up being, you just sit and >wait for an opportunity to transmit, you may get out a CQ or other >call but then your system detects another signal and puts you into a >holding pattern again, should it be just any signal detected at any >time? Should be only when both sides of signal exchange are heard so >that your station isn't just making you wait due to another station >CQing etc., if not full QSO detection in the given mode of operation >then what about that "hidden transmitter" effect?. Oh, I can see it >now, a lot more listening for everyone, the early bird gets the >frequency for the QSO, gee what a dreamy situation, but when an ECOM >event comes about, will
RE: [digitalradio] Need new emergency communications mode
All, Why not use spread spectrum approach? 73 Leo (AA2AJ) Steve Hajducek <[EMAIL PROTECTED]> wrote: Hi Dave, Thanks for jumping in here with Rick and I, if you read my reply that I just sent in response to Rick I feel you will see that I pretty much already touched on your points, I see that you would personally turn off automatic frequency detection as you prefer the human factor, no surprises there. /s/ Steve, N2CKH At 12:22 AM 10/18/2007, you wrote: >>>AA6YQ comments below From: digitalradio@yahoogroups.com [ mailto:[EMAIL PROTECTED] On Behalf Of Steve Hajducek >snip< 2. With respect to Remote User to Automatic Station communications, the human operator initiates the communications and its all up to them to decide the coast is clear to do so or not and if they need to stop because they screwed up and did not listen long enough ( how long is long enough? >>>The hidden transmitter effect means that the remote initiator cannot >>>reliably ensure that the coast is clear. >>>If were on the telephone from California and say 14180 is clear here, give >>>me a call there, can you transmit on 14180 from your QTH on the east coast >>>without first listening to see if 14180 is clear there? Of course not; doing >>>so might QRM a station in Florida that you hear 59 but I dont hear at all. >>>Now consider your station to be an unattended server and my station in >>>California to be the remote initiator. Your unattended server will QRM the >>>station in Florida. be it human operator or computer software there is not now and never will be any perfect means of busy detection in my opinion) to detect that the frequency was indeed in use due either propagation or just plain long pauses between transmissions of the 3rd party stations. >>>Perfect is unnecessary. It is clearly possible to build busy frequency >>>detectors that are at least 80% effect, since such a busy detector was >>>demonstrated years ago. Applying such an imperfect busy detector to >>>unattended stations would reduce their QRM by a factor of 5. >>>This its impossible to build a perfect busy detector argument reminds me >>>of Xenos paradox, in which he proves that all motion is impossible. In closing, you and everyone else on this frequency busy detection quest just don't seem to grasp the realities the shared aspects of the Amateur Radio bands and tolerance for co-frequency levels of interference and just what it is that you are proposing with your frequency busy detection dream. >>>To what realities are you referring? Amateur radio bands are certainly >>>shared, but that gives no station the right to QRM existing signals. Also you seem to think the issue is with Automatic Stations, when in fact it is really with Human operated stations. If there is going to be frequency busy detection in digital mode communications software ( and hardware where all that is not so equipped would need to be banned from use to make your dream a reality) than it needs to be in the Remote User's software to second guess the human factor at all times and not in the Automatic Station side as its the human operator that initiates the communications, for any Automatic Station Forwarding between like stations then and only then would frequency busy detection apply to the Automated Station initiating the connection. >>> What are you talking about? The issue is preventing an unattended station >>> from transmitting on a frequency that is already in use. Also, to be as complete and concise as possible, such frequency busy detection needs to be applied to all known and legal for use digital modes around the world and not just detection of RF energy period ( else your station may never go into TX ). Doing so would force all human users to be courteous and standby when any real digital mode signal that is within their passband from any source, which will force the use of narrower filters for given modes or cause stations to yield to wider band mode operations and narrow bandwidth modes operations will have to steer clear of wider mode operations. Then, depending on the timing of who transmits first and what the forced upon you timing constraints of the algorithms used end up being, you just sit and wait for an opportunity to transmit, you may get out a CQ or other call but then your system detects another signal and puts you into a holding pattern again, should it be just any signal detected at any time? Should be only when both sides of signal exchange are heard so that your station isn't just making you wait due to another station CQing etc., if not full QSO detection in the given mode of operation then what about that "hidden transmitter" effect?. Oh, I can see it now, a lot more listening for everyone, the early bird gets the frequency for the QSO, gee what a dreamy situation, but when an ECOM event comes about, will they ever get a chance to send that health and welfar
RE: [digitalradio] Need new emergency communications mode
Hi Dave, Thanks for jumping in here with Rick and I, if you read my reply that I just sent in response to Rick I feel you will see that I pretty much already touched on your points, I see that you would personally turn off automatic frequency detection as you prefer the human factor, no surprises there. /s/ Steve, N2CKH At 12:22 AM 10/18/2007, you wrote: >>>AA6YQ comments below From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Steve Hajducek >snip< 2. With respect to Remote User to Automatic Station communications, the human operator initiates the communications and its all up to them to decide the coast is clear to do so or not and if they need to stop because they screwed up and did not listen long enough ( how long is long enough? >>>The hidden transmitter effect means that the remote initiator cannot reliably ensure that the coast is clear. >>>If we're on the telephone from California and say "14180 is clear here, give me a call there", can you transmit on 14180 from your QTH on the east coast without first listening to see if 14180 is clear there? Of course not; doing so might QRM a station in Florida that you hear 59 but I don't hear at all. Now consider your station to be an unattended server and my station in California to be the remote initiator. Your unattended server will QRM the station in Florida. be it human operator or computer software there is not now and never will be any perfect means of busy detection in my opinion) to detect that the frequency was indeed in use due either propagation or just plain long pauses between transmissions of the 3rd party stations. >>>"Perfect" is unnecessary. It is clearly possible to build busy frequency detectors that are at least 80% effect, since such a busy detector was demonstrated years ago. Applying such an imperfect busy detector to unattended stations would reduce their QRM by a factor of 5. >>>This "it's impossible to build a perfect busy detector" argument reminds me of Xeno's paradox, in which he proves that all motion is impossible. In closing, you and everyone else on this frequency busy detection quest just don't seem to grasp the realities the shared aspects of the Amateur Radio bands and tolerance for co-frequency levels of interference and just what it is that you are proposing with your frequency busy detection dream. >>>To what "realities" are you referring? Amateur radio bands are certainly shared, but that gives no station the right to QRM existing signals. Also you seem to think the issue is with Automatic Stations, when in fact it is really with Human operated stations. If there is going to be frequency busy detection in digital mode communications software ( and hardware where all that is not so equipped would need to be banned from use to make your dream a reality) than it needs to be in the Remote User's software to second guess the human factor at all times and not in the Automatic Station side as its the human operator that initiates the communications, for any Automatic Station Forwarding between like stations then and only then would frequency busy detection apply to the Automated Station initiating the connection. >>> What are you talking about? The issue is preventing an unattended station from transmitting on a frequency that is already in use. Also, to be as complete and concise as possible, such frequency busy detection needs to be applied to all known and legal for use digital modes around the world and not just detection of RF energy period ( else your station may never go into TX ). Doing so would force all human users to be courteous and standby when any real digital mode signal that is within their passband from any source, which will force the use of narrower filters for given modes or cause stations to yield to wider band mode operations and narrow bandwidth modes operations will have to steer clear of wider mode operations. Then, depending on the timing of who transmits first and what the forced upon you timing constraints of the algorithms used end up being, you just sit and wait for an opportunity to transmit, you may get out a CQ or other call but then your system detects another signal and puts you into a holding pattern again, should it be just any signal detected at any time? Should be only when both sides of signal exchange are heard so that your station isn't just making you wait due to another station CQing etc., if not full QSO detection in the given mode of operation then what about that "hidden transmitter" effect?. Oh, I can see it now, a lot more listening for everyone, the early bird gets the frequency for the QSO, gee what a dreamy situation, but when an ECOM event comes about, will they ever get a chance to send that health and welfare traffic in a timely manor or at all? Hopefully some of this has assisted you in seeing more of the complexity and down sides of this busy frequency detection dream Rick. >>>Attended stations
Re: [digitalradio] Need new emergency communications mode
Rick, I don't share your dream Rick, sorry that you did not like that description, but I was trying to be polite about it. I am not here to stop you or anyone from pursuing your dreams, go learn C++ or Ada and start coding it up into your dream communications software. However I am a realist and as I don't share your dream, I see it for what it really is, a potential nightmare that would hinder communications rather than actually improving it. I won't be pursuing your dream with my valuable time available to me for code development unless a dreamer manages to get such a requirement into the rules which govern the Amateur Radio Service, which I don't see happening anytime soon, if ever, as those in charge of the rules are also realists, at least at present. The issue you are talking about has been around since day one and always will be in all forms of RF communications, the answer to the issue is a level of tolerance, its that simple. Just because one station of two ( regardless if one is unattended ) can hear a 3rd station does not even mean that the 3rd station can hear either of the two in question. As a matter of fact the 3rd station may be hearing the that station which does not hear them rather than the scenario that you paint, which means that it would be the attended station that is offending the 3rd station and not the unattended station in your scenario. In actual operation the dream scenario that you are proposing be it for Attended, Unattended or at all emitter locations, which is what I would want to see, would not make the Amateur Radio Service better, it would actually only hinder communications. You would still have the same issue that you are complaining about happening as you already realize from your comments, but just about as often if you ask me and if the algorithms were ratcheted up to the point really making a dent in the issue, then we are talking about holding off TX whenever enough RF signal is detected in the pass band over x amount of time that the algorithm qualifies as a true digital mode signal from somewhere and unless the band in question is dead, that is pretty much all the time. What will you will have then, almost no communications taking place would be the result as there is almost always a signal being heard from somewhere. Granted, you and many others would love to see almost no communications taking place WRT automated stations as you and others think they should not exist except when you feel they are needed for an ECOM event only, well I don't share that view, my view is just the opposite, automated systems are very important to the Amateur Radio Service, as they serve everyone and not just the individuals pursuit, they exist for the benefit of all Radio Amateurs communications needs 24/7, which means they can be relied upon by ECOM first responders in the middle or the day or night when needed. I fully understand why you and others would never want what you are preaching for in automated system to be in the systems that you use for digital communications and if it were to be why you would want the option to turn it off, however an unattended station can not just decide to turn it off, human intervention would be required and for the first ECOM responders trying to use the system that intervention would likely not come fast enough. I had stated on this forum a while ago that the only way to make you and others with your opinions of as you call it "on going problems" with automated stations is to have all such stations in sub bands where no other operations are conducted, that is the logical answer, any such "on going problems" would then related to only a remote user of an automated system, which by their decision to do so means they accept. /s/ Steve, N2CKH At 08:33 AM 10/18/2007, you wrote: >Steve, > >I am surprised that you do not understand the basic technical issues >here since you appear to be claiming that there is no such thing as the >hidden transmitter. > >A human operator can not determine the paths present at the remote >automatically controlled station. That is why there is such concern >about this on-going problem. >>SNIP<<
Re: [digitalradio] Need new emergency communications mode: Server
Rud, Many, many incredibly successful projects use open source. In fact, many large projects could never have been developed any other way since they were otherwise not financially viable. Enough said. Now about the server vs Winlink 2000. A PMBO is a server to the RF side of the system as well as interfacing with the next level server(s) at the CMS level. FThis is the achilles heel of the Winlink 2000 system with several layers of servers and back out again. On VHF a Telpac server does the interfacing to RF side, everything else is done via the internet. My understanding is that the Telpac connects to a PMBO which connects to a CMS, then back to a PMBO and back to a Telpac. This is true, even if it is the same Telpac. A PMBO can be set up to locally handle connections, similar to a repeater, but this is yet another single point failure model that I want to avoid in any local networking. If there are instant PMBOs, it is not something openly discussed or made available. I have followed the Aplink/Winlink/Netlink/Winlink 2000 progression over a period of well over 20 years and have used the Aplink and Winlink systems when they were operational. 73, Rick, KV9U Rud Merriam wrote: > Rick, > > I am not commenting on the validity of your point about PSKMail. > > Your comment is exactly the problem with an open project. As is your > observation about Winlink 2000. An open project gets continuously > sidetracked into explanations of why the technique of some other project is > not being used. This can be months after the group doing the work made a > series of rational decisions about the technique being used. > > More specifically, you have confused the PMBO and server issues in your > point about Winlink. They are two different entities in that system. A PBMO > is an RF, or internet, message collection and delivery point. The servers > are Internet computers that store messages and determine the routing through > the network. Only an EmComm PBMO provides routing when the Internet is not > available. The general PBMO must have an Internet connection. You are > correct that a PBMO must be set up. There are supposed to be portable EmComm > PBMOs ready for deployment if one is not in the area. > >
Re: [digitalradio] Need new emergency communications mode
Steve, I am surprised that you do not understand the basic technical issues here since you appear to be claiming that there is no such thing as the hidden transmitter. A human operator can not determine the paths present at the remote automatically controlled station. That is why there is such concern about this on-going problem. Based on the tone of your comments, claiming that busy frequency detection is a "dream." A few years ago it was considered technically impossible and then it was actually invented and worked very well. It does not have to be a perfect system, but it certainly can go a long ways to preventing illegal transmissions of automatic stations. Remember, Steve, all amateur radio stations require a control operator, even if not present at the control point. As Riley Hollingsworth has said, there is no such thing as unattended operation. Your license is always on the line when operating in automatic status. It is precisely because amateur frequencies are not channelized (except 60 meters where digital can not even be used) and that we operate in a shared environment, that automatic operation needs to be tempered with technology that will prevent as much interference to others as is possible. What we can do today may be 80% reduction, tomorrow maybe even better. Reasonable people would want to do everything they can to prevent intentional interference to other stations from automatic operation. The more that comes out of all this is that after inventing the technology, Winlink 2000 decided they did not want to support such technology and now a new group using older ALE and related technology wants to use this on the ham bands as well and does not want to support busy channel detection either. This is very dangerous thinking! You need to set the example. You really ought to be planning to do everything you can to prevent interference, because in the final analysis, when the bands become very busy again as the sunspots cooperate, there may be a groundswell from the huge majority of hams to discontinue all automatic operation on the ham bands. 73, Rick, KV9U Steve Hajducek wrote: > Hi Rick, > > I feel compelled once again to make some statements on the subject of > frequency busy detection. > > 1. Item 5 makes no sense to this station unless you have Automatic > Station initiating contacts to forward traffic, whereas Automatic > Station A has 1 to number of messages queued and needs to hand those > off to Automatic Station B in the scheme of things via HF due to any > other forwarding methods ( if any) being down. In such a scenario > then and only then does busy detection on the part of the automatic > station make any sense as it needs the ability to replace the ears > and brain of the human operator. > > 2. With respect to Remote User to Automatic Station communications, > the human operator initiates the communications and its all up to > them to decide the coast is clear to do so or not and if they need to > stop because they screwed up and did not listen long enough ( how > long is long enough? be it human operator or computer software there > is not now and never will be any perfect means of busy detection in > my opinion) to detect that the frequency was indeed in use due either > propagation or just plain long pauses between transmissions of the > 3rd party stations. > > In closing, you and everyone else on this frequency busy detection > quest just don't seem to grasp the realities the shared aspects of > the Amateur Radio bands and tolerance for co-frequency levels of > interference and just what it is that you are proposing with your > frequency busy detection dream. Also you seem to think the issue is > with Automatic Stations, when in fact it is really with Human > operated stations. If there is going to be frequency busy detection > in digital mode communications software ( and hardware where all that > is not so equipped would need to be banned from use to make your > dream a reality) than it needs to be in the Remote User's software to > second guess the human factor at all times and not in the Automatic > Station side as its the human operator that initiates the > communications, for any Automatic Station Forwarding between like > stations then and only then would frequency busy detection apply to > the Automated Station initiating the connection. Also, to be as > complete and concise as possible, such frequency busy detection needs > to be applied to all known and legal for use digital modes around the > world and not just detection of RF energy period ( else your station > may never go into TX ). Doing so would force all human users to be > courteous and standby when any real digital mode signal that is > within their passband from any source, which will force the use of > narrower filters for given modes or cause stations to yield to wider > band mode operations and narrow bandwidth modes operations
Re: [digitalradio] Need new emergency communications mode: Project Management
Probably the best question is how much experience have you had with open source. I can only go by what actually is taking place every day with major programs that have been built and maintained by large numbers of volunteers and paid staff. Firefox, Apache, Thunderbird, Linux versions, the whole GNU system with GPL'd software. 73, Rick, KV9U Rud Merriam wrote: > Rick, I wrote my first Fortran IV program in 1968. I have been doing > software ever since on multiple platforms. I have managed many software > projects. > > How much software development experience do you have? >
Re: [digitalradio] Need new emergency communications mode: Project Management
Rud, Running Linux in an old box requires an old version of Linux, matched to the box contents. I used RedHat 5.2 on a 486, and 6.2 on a P1. Mostly, text mode, with a CGA or the older and less voracious GUI, with 1 MB RAM video cards. The BBS's ran happy with it, and I even did ftp and http using text mode with those boxes. I usually ran ax.25, a node, FBB, JNOS with net2kiss, DXNET, a slip link, apache, wuftpd or vsftpd, etc. But since Linux has gone to please the GUI lovers, the resource requirements are about the same or maybe even higher. I also like the pretty colored screens, but really enjoyed surfing the net with a text screen faster than the old boxes running Win95. Nowadays is less probable that I will be running a 486, but I still keep the old disks. I had a hard to forget, nice experience with a few "no good for Windows" boxes. I really enjoyed the challenge, which was not a vain one, as the BBS's gave a good service to the user community. I kept a 1991 vintage 486DX2/66 running until 2004 in text mode. I hardly reset it, mostly the power company did not allow the uptimes to exceed 30 to 40 days, with power cuts for manteinance or failures during thunderstorms. 73, Jose, CO2JA Linux User 91155 http://counter.li.org > Heck, even the old > adage about Linux running on older boxes is no longer true. I went to > install a version only to find it would not run on a box from '99. > > > Rud Merriam K5RUD > ARES AEC Montgomery County, TX > http://TheHamNetwork.net __ Participe en Universidad 2008. 11 al 15 de febrero del 2008. Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.universidad2008.cu
RE: [digitalradio] Need new emergency communications mode: Project Management
I am an active proponent of open source development. I brought Rational Software's development tools to Linux in the late 90s. I also established the Eclipse Foundation, which oversees the development of the Eclipse Programming Environment - the dominant open source programming environment. Whether working on open source or closed source, the orchestration of multiple geographically-distributed developers requires intense effort. For me, amateur radio is a hobby. I enjoy DXing, and I enjoy programming, but the last thing I need is another project to manage. So the amateur radio software I write is closed source; I am its only software developer and documentation writer. I get plenty of input and feedback from the user community, and I provide public programmatic interfaces so that others can build on my work, and/or connect it to other applications. 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Rick Sent: Wednesday, October 17, 2007 6:07 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Need new emergency communications mode: Project Management I am curious as to the negative attitude of ham developers toward open source development. Many successful applications programs have been open source have they not? These include very complicated and advanced programs that are better than some of the commercial developed closed source programs. Even if a developer works alone or in a closed group, they not only are going to have questions raised eventually as to why something was done a certain way, but they lose the earlier input from other programmers who might catch an oversight well before it is has to be changed later on. 73, Rick, KV9U Rud Merriam wrote: > My web site, see signature, is for the development of such a network. Anyone > who wants to work collaboratively on a network is invited to let me know of > their interest. > > There is another mailing list where I have discussed the development of a > network. They say managing software developers is like trying to herd cats. > Getting a bunch of hams to agree on network issues is even worse. I do not > think development can be accomplished in a totally open venue, although I am > willing to participate if that is the only way of working. Instead, I think > a group needs to work privately and then suffer the slings and arrows of the > "Why didn't you do XYZ?" that will come later. > > > Rud Merriam K5RUD > ARES AEC Montgomery County, TX > http://TheHamNetwork.net > > > > Announce your digital presence via our Interactive Sked Page at > http://www.obriensweb.com/drsked/drsked.php > > Yahoo! Groups Links > > > > > > >
RE: [digitalradio] Need new emergency communications mode
>>>AA6YQ comments below From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Steve Hajducek >snip< 2. With respect to Remote User to Automatic Station communications, the human operator initiates the communications and its all up to them to decide the coast is clear to do so or not and if they need to stop because they screwed up and did not listen long enough ( how long is long enough? >>>The hidden transmitter effect means that the remote initiator cannot reliably ensure that the coast is clear. >>>If we're on the telephone from California and say "14180 is clear here, give me a call there", can you transmit on 14180 from your QTH on the east coast without first listening to see if 14180 is clear there? Of course not; doing so might QRM a station in Florida that you hear 59 but I don't hear at all. Now consider your station to be an unattended server and my station in California to be the remote initiator. Your unattended server will QRM the station in Florida. be it human operator or computer software there is not now and never will be any perfect means of busy detection in my opinion) to detect that the frequency was indeed in use due either propagation or just plain long pauses between transmissions of the 3rd party stations. >>>"Perfect" is unnecessary. It is clearly possible to build busy frequency detectors that are at least 80% effect, since such a busy detector was demonstrated years ago. Applying such an imperfect busy detector to unattended stations would reduce their QRM by a factor of 5. >>>This "it's impossible to build a perfect busy detector" argument reminds me of Xeno's paradox, in which he proves that all motion is impossible. In closing, you and everyone else on this frequency busy detection quest just don't seem to grasp the realities the shared aspects of the Amateur Radio bands and tolerance for co-frequency levels of interference and just what it is that you are proposing with your frequency busy detection dream. >>>To what "realities" are you referring? Amateur radio bands are certainly shared, but that gives no station the right to QRM existing signals. Also you seem to think the issue is with Automatic Stations, when in fact it is really with Human operated stations. If there is going to be frequency busy detection in digital mode communications software ( and hardware where all that is not so equipped would need to be banned from use to make your dream a reality) than it needs to be in the Remote User's software to second guess the human factor at all times and not in the Automatic Station side as its the human operator that initiates the communications, for any Automatic Station Forwarding between like stations then and only then would frequency busy detection apply to the Automated Station initiating the connection. >>> What are you talking about? The issue is preventing an unattended station from transmitting on a frequency that is already in use. Also, to be as complete and concise as possible, such frequency busy detection needs to be applied to all known and legal for use digital modes around the world and not just detection of RF energy period ( else your station may never go into TX ). Doing so would force all human users to be courteous and standby when any real digital mode signal that is within their passband from any source, which will force the use of narrower filters for given modes or cause stations to yield to wider band mode operations and narrow bandwidth modes operations will have to steer clear of wider mode operations. Then, depending on the timing of who transmits first and what the forced upon you timing constraints of the algorithms used end up being, you just sit and wait for an opportunity to transmit, you may get out a CQ or other call but then your system detects another signal and puts you into a holding pattern again, should it be just any signal detected at any time? Should be only when both sides of signal exchange are heard so that your station isn't just making you wait due to another station CQing etc., if not full QSO detection in the given mode of operation then what about that "hidden transmitter" effect?. Oh, I can see it now, a lot more listening for everyone, the early bird gets the frequency for the QSO, gee what a dreamy situation, but when an ECOM event comes about, will they ever get a chance to send that health and welfare traffic in a timely manor or at all? Hopefully some of this has assisted you in seeing more of the complexity and down sides of this busy frequency detection dream Rick. >>>Attended stations already have effective (though imperfect) busy frequency detectors: their operators. The problem is unattended stations, which do not. >>>As has been suggested many times, during emergency conditions an unattended station would disable its busy frequency detector. 73, Dave, AA6YQ
RE: [digitalradio] Need new emergency communications mode: Project Management
Rick, I wrote my first Fortran IV program in 1968. I have been doing software ever since on multiple platforms. I have managed many software projects. How much software development experience do you have? Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Rick Sent: Wednesday, October 17, 2007 9:40 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Need new emergency communications mode: Project Management The reason for the open source concept in my mind is to insure continuity of a project in case of death or disinterest by the initial developers. I don't buy the too many cooks analogy in any way. Completely wrong metaphor for software development. No one is in the way of another, rather they are collaborating. They are not necessarily even involving the end user any differently than you would with a close project. 73, Rick, KV9U
Re: [digitalradio] Need new emergency communications mode: Project Management
The reason for the open source concept in my mind is to insure continuity of a project in case of death or disinterest by the initial developers. I don't buy the too many cooks analogy in any way. Completely wrong metaphor for software development. No one is in the way of another, rather they are collaborating. They are not necessarily even involving the end user any differently than you would with a close project. When Linus Torvalds began writing the Linux kernal, there was minimal support for open source. It was not until it was used as the kernal for the GNU system that had most of the other pieces already developed or in the process of being developed that the GNU/Linux system was functional. And then you have protection from anyone trying to take your ideas and claim them as their own because you will likely select the GPL or other copyright protection and if they do further development, they have to share their work with everyone else, including you. I agree that having 100's of versions of Linux is not always productive because it dilutes the energy of the untold thousands of volunteers as well as the commercial Linux developers. If they could focus on fewer versions, then they would have more time to correct shortcomings. But that assumes that they want to work on a specific niche area and they may not be interested. So in the long run, having the many versions does more good than harm since only a few versions are really all that popular. And you also have country and language specific versions that may be a better fit for those users. It is unfortunate if developers do not want to write cross platform code, but it is their prerogative to do what they think is best for themselves. They may find that in the future someone could eclipse them, but then again it depends on many factors such as licensing issues for code that they may be using in their program. The mythology that Linux can run on old equipment depends upon the version of Linux. Some are designed to use lesser hardware, such as Puppy Linux or Vector Linux, but the leading edge versions do not. But even Vector Linux (as an example) keeps advancing whereas old Windows versions are not. 73, Rick, KV9U Rud Merriam wrote: > Note I did not say the work would not be open source, i.e. available to all > eventually. > > You know the old saying, "To many cooks spoil the broth". It applies to the > development process. The "negative attitude" comes from experience. > > The trick is to have enough people contributing to catch oversights but also > to limit the tension that pulls the project in multiple directions. The > project needs non-programmers also to provide end user input. The > participants also need to agree to disagree when appropriate and continue > making progress. > > For example, one group I know of is insisting their project be done in > Linux. Okay, but that discounts the mass of hams who are only using Windows. > Now I am perfectly willing to write portable code but that is not enough for > that group. > > Let me point out that Linux was not an open source project. The main work > was done by an individual. Even after he opened it he still retained a large > degree of control of what could done to the system. Now it is totally open > and look at the profusion of versions. To a point that is great. But after a > point it just becomes mind numbing. Now you cannot be sure that an > application will run on a specific version of Linux. Heck, even the old > adage about Linux running on older boxes is no longer true. I went to > install a version only to find it would not run on a box from '99. > > > Rud Merriam K5RUD > ARES AEC Montgomery County, TX > http://TheHamNetwork.net > >
RE: [digitalradio] Need new emergency communications mode: Server
Rick, I am not commenting on the validity of your point about PSKMail. Your comment is exactly the problem with an open project. As is your observation about Winlink 2000. An open project gets continuously sidetracked into explanations of why the technique of some other project is not being used. This can be months after the group doing the work made a series of rational decisions about the technique being used. More specifically, you have confused the PMBO and server issues in your point about Winlink. They are two different entities in that system. A PBMO is an RF, or internet, message collection and delivery point. The servers are Internet computers that store messages and determine the routing through the network. Only an EmComm PBMO provides routing when the Internet is not available. The general PBMO must have an Internet connection. You are correct that a PBMO must be set up. There are supposed to be portable EmComm PBMOs ready for deployment if one is not in the area. Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Rick Sent: Wednesday, October 17, 2007 5:21 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Need new emergency communications mode: Server Isn't this exactly what can be accomplished with open source collaboration? How does it work now with PSKmail? The main thing is to insure that no additional complications are needed that can be yet another failure point. This is one of my criticisms of Winlink 2000 and why I don't consider it to be a good design for emergency communications. It is fine for casual use, and may be useful in some emergency situations, but it is much less dependable than other methods since you need to access it through a PMBO of which there are very few and may not work well for your situation. If you want to set up a PMBO, it is not your decision to do so. And it has to be set up and configured long before any emergencies occur. If a PMBO happens to be allowed for your immediate area you could use it as a mail server without the internet, but only a few places can have a PMBO and most local traffic can be handled with Airmail 2000 or packet connections if that is available yet in your area. 73, Rick, KV9U
RE: [digitalradio] Need new emergency communications mode: Project Management
Note I did not say the work would not be open source, i.e. available to all eventually. You know the old saying, "To many cooks spoil the broth". It applies to the development process. The "negative attitude" comes from experience. The trick is to have enough people contributing to catch oversights but also to limit the tension that pulls the project in multiple directions. The project needs non-programmers also to provide end user input. The participants also need to agree to disagree when appropriate and continue making progress. For example, one group I know of is insisting their project be done in Linux. Okay, but that discounts the mass of hams who are only using Windows. Now I am perfectly willing to write portable code but that is not enough for that group. Let me point out that Linux was not an open source project. The main work was done by an individual. Even after he opened it he still retained a large degree of control of what could done to the system. Now it is totally open and look at the profusion of versions. To a point that is great. But after a point it just becomes mind numbing. Now you cannot be sure that an application will run on a specific version of Linux. Heck, even the old adage about Linux running on older boxes is no longer true. I went to install a version only to find it would not run on a box from '99. Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Rick Sent: Wednesday, October 17, 2007 5:07 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Need new emergency communications mode: Project Management I am curious as to the negative attitude of ham developers toward open source development. Many successful applications programs have been open source have they not? These include very complicated and advanced programs that are better than some of the commercial developed closed source programs. Even if a developer works alone or in a closed group, they not only are going to have questions raised eventually as to why something was done a certain way, but they lose the earlier input from other programmers who might catch an oversight well before it is has to be changed later on. 73, Rick, KV9U Rud Merriam wrote: > My web site, see signature, is for the development of such a network. > Anyone who wants to work collaboratively on a network is invited to > let me know of their interest. > > There is another mailing list where I have discussed the development > of a network. They say managing software developers is like trying to > herd cats. Getting a bunch of hams to agree on network issues is even > worse. I do not think development can be accomplished in a totally > open venue, although I am willing to participate if that is the only > way of working. Instead, I think a group needs to work privately and > then suffer the slings and arrows of the "Why didn't you do XYZ?" that > will come later. > > > Rud Merriam K5RUD > ARES AEC Montgomery County, TX > http://TheHamNetwork.net > > > > 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
Re: [digitalradio] Need new emergency communications mode: Server
It's the programmers choice to make it open But it seems to me that some feel cheated if it's not. Either way I can live with it. John, W0JAB
Re: [digitalradio] Need new emergency communications mode: Server
Isn't this exactly what can be accomplished with open source collaboration? How does it work now with PSKmail? The main thing is to insure that no additional complications are needed that can be yet another failure point. This is one of my criticisms of Winlink 2000 and why I don't consider it to be a good design for emergency communications. It is fine for casual use, and may be useful in some emergency situations, but it is much less dependable than other methods since you need to access it through a PMBO of which there are very few and may not work well for your situation. If you want to set up a PMBO, it is not your decision to do so. And it has to be set up and configured long before any emergencies occur. If a PMBO happens to be allowed for your immediate area you could use it as a mail server without the internet, but only a few places can have a PMBO and most local traffic can be handled with Airmail 2000 or packet connections if that is available yet in your area. 73, Rick, KV9U Rud Merriam wrote: > Before you can say anything about setting up a server you need to determine > what the "server" is to do. > > The primary purpose of the Winlink servers is to route messages to their > destination. However, the Emcomm PMBOs can provide local routing of messages > when needed, i.e. an area is isolated from the Internet. > > My study of the problems associated with an RF network always comes back to > this one issue: If A sends a message to B how does the network know where B > is located? The solutions seem to either require (1) an tremendous amount of > traffic on the network to convey location information, (2) a "centralized" > processing that handles all messages, or (3) a geographic or geopolitical > locator included in messages that can easily be out of date. > > I put "centralized" in quotes because I wonder if something like BOINC, that > is used for SETI at Home, might not be usable for this processing, i.e. > distributed on a large number of Internet connected PCs. > > > Rud Merriam K5RUD > ARES AEC Montgomery County, TX > http://TheHamNetwork.net > > > -Original Message- > From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of Rick > Sent: Wednesday, October 17, 2007 8:57 AM > To: digitalradio@yahoogroups.com > Subject: [digitalradio] Need new emergency communications mode > > > 4. Insure that the "server" that connects to the internet can be set up > on an ad hoc basis and can be placed where needed. We never know where > the emergency situation will be and how widespread, but having the > capability to quickly position internet access points to reach a > disaster area is a killer ap that is not available with any other HF > systems. > > Other thoughts? > > 73, > > Rick, KV9U > > > > Announce your digital presence via our Interactive Sked Page at > http://www.obriensweb.com/drsked/drsked.php > > Yahoo! Groups Links > > > > > > >
Re: [digitalradio] Need new emergency communications mode: Project Management
I am curious as to the negative attitude of ham developers toward open source development. Many successful applications programs have been open source have they not? These include very complicated and advanced programs that are better than some of the commercial developed closed source programs. Even if a developer works alone or in a closed group, they not only are going to have questions raised eventually as to why something was done a certain way, but they lose the earlier input from other programmers who might catch an oversight well before it is has to be changed later on. 73, Rick, KV9U Rud Merriam wrote: > My web site, see signature, is for the development of such a network. Anyone > who wants to work collaboratively on a network is invited to let me know of > their interest. > > There is another mailing list where I have discussed the development of a > network. They say managing software developers is like trying to herd cats. > Getting a bunch of hams to agree on network issues is even worse. I do not > think development can be accomplished in a totally open venue, although I am > willing to participate if that is the only way of working. Instead, I think > a group needs to work privately and then suffer the slings and arrows of the > "Why didn't you do XYZ?" that will come later. > > > Rud Merriam K5RUD > ARES AEC Montgomery County, TX > http://TheHamNetwork.net > > > > Announce your digital presence via our Interactive Sked Page at > http://www.obriensweb.com/drsked/drsked.php > > Yahoo! Groups Links > > > > > > >
RE: [digitalradio] Need new emergency communications mode: Server
Before you can say anything about setting up a server you need to determine what the "server" is to do. The primary purpose of the Winlink servers is to route messages to their destination. However, the Emcomm PMBOs can provide local routing of messages when needed, i.e. an area is isolated from the Internet. My study of the problems associated with an RF network always comes back to this one issue: If A sends a message to B how does the network know where B is located? The solutions seem to either require (1) an tremendous amount of traffic on the network to convey location information, (2) a "centralized" processing that handles all messages, or (3) a geographic or geopolitical locator included in messages that can easily be out of date. I put "centralized" in quotes because I wonder if something like BOINC, that is used for SETI at Home, might not be usable for this processing, i.e. distributed on a large number of Internet connected PCs. Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Rick Sent: Wednesday, October 17, 2007 8:57 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Need new emergency communications mode 4. Insure that the "server" that connects to the internet can be set up on an ad hoc basis and can be placed where needed. We never know where the emergency situation will be and how widespread, but having the capability to quickly position internet access points to reach a disaster area is a killer ap that is not available with any other HF systems. Other thoughts? 73, Rick, KV9U
RE: [digitalradio] Need new emergency communications mode: Project Management
My web site, see signature, is for the development of such a network. Anyone who wants to work collaboratively on a network is invited to let me know of their interest. There is another mailing list where I have discussed the development of a network. They say managing software developers is like trying to herd cats. Getting a bunch of hams to agree on network issues is even worse. I do not think development can be accomplished in a totally open venue, although I am willing to participate if that is the only way of working. Instead, I think a group needs to work privately and then suffer the slings and arrows of the "Why didn't you do XYZ?" that will come later. Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net
RE: [digitalradio] Need new emergency communications mode
Rud Merriam K5RUD ARES AEC Montgomery County, TX http://TheHamNetwork.net -Original Message- From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Rick Sent: Wednesday, October 17, 2007 8:57 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Need new emergency communications mode I concur with many of Howard's suggestions. Here are some of the criteria that I think will insure success of a new emergency communications mode, not in any special order: 1. Open source so that many can help with developing and even tweaking the program. We have seen how successful major programs such as Firefox browser, Thunderbird e-mail, Open Office suite can be built with open source, and anything we do in amateur radio can as well. 2. Modularized design so that the interface to the operator can be changed without affecting the modes used on the RF connection. Protocols can then be "bolted on" and changed as technology advances without a loss of the programming effort that occurs with many other amateur radio software. 3. For the short term (the next 5 to 10 years) it must operate on MS Windows OS since that is what the great majority of us use for ham radio. Cross platform is to be encouraged. 4. Insure that the "server" that connects to the internet can be set up on an ad hoc basis and can be placed where needed. We never know where the emergency situation will be and how widespread, but having the capability to quickly position internet access points to reach a disaster area is a killer ap that is not available with any other HF systems. As a comparison, Winlink2000 servers (PMBO) are strictly controlled and programmed by the central administrator and are not possible to set up and configure by individual hams. A new paradigm should return control to the amateur community and away from a centralized failure point. Recent comments suggest that the HFLink system will not have ad hoc quick installation, but we don't have the information to fully understand how this will be done. Perhaps the HFLink developers will fill us in on their vision. 5. For any automatic station, busy frequency detection is a must, however during emergency situations, you will often have human operators at both ends insuring that the frequency is being monitored. 6. As narrow bandwidths as possible. E-mail is not used for extreme time value traffic as is tactical communications that has paramount requirements for an immediate contact and immediate acknowledgement. Other thoughts? 73, Rick, KV9U Howard Brown wrote: > Dave, > > What about building a replacement now? It would be good for Emcomm > (ARES & MARS) to have a package that would support high speed without > a high price. > > For my two cents, I would like a non-ARQ mode to run a net and then > the package would use ARQ to transfer messages. > > It seems the PSKmail guys can adapt quickly to different modems. They > also have the advantage that you can quickly set up a new post office > sort of ad hoc. > > Howard K5HB Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/drsked/drsked.php Yahoo! Groups Links
Re: [digitalradio] Need new emergency communications mode
Hi Rick, I feel compelled once again to make some statements on the subject of frequency busy detection. 1. Item 5 makes no sense to this station unless you have Automatic Station initiating contacts to forward traffic, whereas Automatic Station A has 1 to number of messages queued and needs to hand those off to Automatic Station B in the scheme of things via HF due to any other forwarding methods ( if any) being down. In such a scenario then and only then does busy detection on the part of the automatic station make any sense as it needs the ability to replace the ears and brain of the human operator. 2. With respect to Remote User to Automatic Station communications, the human operator initiates the communications and its all up to them to decide the coast is clear to do so or not and if they need to stop because they screwed up and did not listen long enough ( how long is long enough? be it human operator or computer software there is not now and never will be any perfect means of busy detection in my opinion) to detect that the frequency was indeed in use due either propagation or just plain long pauses between transmissions of the 3rd party stations. In closing, you and everyone else on this frequency busy detection quest just don't seem to grasp the realities the shared aspects of the Amateur Radio bands and tolerance for co-frequency levels of interference and just what it is that you are proposing with your frequency busy detection dream. Also you seem to think the issue is with Automatic Stations, when in fact it is really with Human operated stations. If there is going to be frequency busy detection in digital mode communications software ( and hardware where all that is not so equipped would need to be banned from use to make your dream a reality) than it needs to be in the Remote User's software to second guess the human factor at all times and not in the Automatic Station side as its the human operator that initiates the communications, for any Automatic Station Forwarding between like stations then and only then would frequency busy detection apply to the Automated Station initiating the connection. Also, to be as complete and concise as possible, such frequency busy detection needs to be applied to all known and legal for use digital modes around the world and not just detection of RF energy period ( else your station may never go into TX ). Doing so would force all human users to be courteous and standby when any real digital mode signal that is within their passband from any source, which will force the use of narrower filters for given modes or cause stations to yield to wider band mode operations and narrow bandwidth modes operations will have to steer clear of wider mode operations. Then, depending on the timing of who transmits first and what the forced upon you timing constraints of the algorithms used end up being, you just sit and wait for an opportunity to transmit, you may get out a CQ or other call but then your system detects another signal and puts you into a holding pattern again, should it be just any signal detected at any time? Should be only when both sides of signal exchange are heard so that your station isn't just making you wait due to another station CQing etc., if not full QSO detection in the given mode of operation then what about that "hidden transmitter" effect?. Oh, I can see it now, a lot more listening for everyone, the early bird gets the frequency for the QSO, gee what a dreamy situation, but when an ECOM event comes about, will they ever get a chance to send that health and welfare traffic in a timely manor or at all? Hopefully some of this has assisted you in seeing more of the complexity and down sides of this busy frequency detection dream Rick. Sincerely, /s/ Steve Hajducek, N2CKH At 09:56 AM 10/17/2007, you wrote: >5. For any automatic station, busy frequency detection is a must, >however during emergency situations, you will often have human operators >at both ends insuring that the frequency is being monitored.
