[digitalradio] Busy frequency detector (process definition).
Folks, I really don't know if I am failing to understand the problem, or underestimating the complexity of the solution, but I'd like to propose at least a dialog here of what it would take to implement a busy frequency detector. I'm not at all interested in discussing systems that may or may not use such a detector, or the politics / etc. involved. I am interested in at least defining the process of how a busy frequency detector should work, and defining some base requirements for how well it would need to work to be considered 'adequate' for use in amateur radio. My idea is to first define what the system should do, then define how well it would have to work to be considered successful or useful, and finally to consider the technical details required to implement such a system. To that end, the following to which I am inviting comments from this group, is my first pass at defining what a busy frequency detector should do (please hold comments on how well it would have to work, and how to implement it for follow-up threads, for now lets focus on getting the process definition refined): General process flow for a signal detector / frequency busy detector implemented as a part of a semi-automated RF based client server message transport system. - A server (semi-automated which will respond to a request) is listening on a fixed frequency and 'sampling' a given range of its audio passband at a given sample rate. At this time is is listening to 'noise', and remembering what noise 'probably' sounds like. - The server learns and continuously refines its model for what noise has sounded like recently, and 'predicts' what noise is likely to sound like in the very near future, adapting to minor changes in noise. - The server 'hears' a client request. The client is not automated, and a human listened to the frequency to determine it was not in use (it is possible for this process to be replaced by the same black box used on the server side to determine if the frequency is in use). The clients request to the server should serve as a QRL? to all stations on frequency that can hear it. If the client receives a QRL (i.e. any signal that isn't an ACK from the server), it sends a CANCEL to the server. If the client doesn't get an ACK from the server, it will assume the server has detected the frequency is busy on its end, and wait a reasonable period of time before retrying to connect to the server. - If the server doesn't 'think' there is any other signal in its pass band, the server waits a given period of time, 'listening' for a QRL from any stations that may have heard the client request or a CANCEL from the client. If it doesn't hear a QRL (which for our purposes would be any signal that isn't a client request), or a CANCEL from the client, the server will ACK the client request, the ACK will function as the servers QRL?. If the server 'thought' there was already a signal in its passband, it would ignore the clients request outright. - The server listens for a given period of time for a response to its ACK/QRL?, if it doesn't hear one, it 'decides' the frequency is clear and responds to the client request. - So what do you folks think, is this a reasonable process for an rf based client / server busy frequency detection system? 73, Erik N7HMS PS. Everyone knows a software project will never be successful without a catchy acronym or code name... if this ever becomes a real software product / project, lets NOT use the acronym BFD!
[digitalradio] Busy detector
Dave Bernstein wrote: As is often the case in engineering, Jose, perfect is the enemy of good. What Rick KN6KB discovered while developing SCAMP's busy detector was that he could detect CW, PSK, Pactor, and SSB at an ~80% confidence level without enormous difficulty. SCAMP beta testers were amazed by the effectiveness of this first iteration. Pushing the confidence level from 80% to 100%, however, would take years -- if its even possible. But a busy detector that works 80% of the time would cut QRM from unattended automated stations (like WinLink PMBOs) by a factor of 5! Your comment that many think it is simpler than it really is to do it WELL is frankly moot; Rick demonstrated two years ago that useful busy frequency detection was implementable on a PC and soundcard. 73, Dave, AA6YQ I understand that 80% is fairly good. Hope the long standing anti-automatic stations lobby sees it as acceptable as well. What is seemingly left, then, is to simply push the busy detector into practice and 24/7 service. Who will get the task done? 73, Jose __ V Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética. 22 al 25 de mayo de 2007 Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.cujae.edu.cu/eventos/cier
Re: Obstination (was Re: [digitalradio] Re: 3580kHz-3600kHz FreqCoordination Info)
Ah so it's now time to pick on us stateside operators. Maybe if those in the rest of the world who are having the same problem would speak up(wait John I think I remember seeing you complain some), then this problem could worked out to the best of ALL. Kurt K8YZK - Original Message - From: John Bradley To: digitalradio@yahoogroups.com Sent: Friday, March 09, 2007 9:54 PM Subject: Re: Obstination (was Re: [digitalradio] Re: 3580kHz-3600kHz FreqCoordination Info) Amen Jose; Seems all the stateside operators want to do is argue. Is the plan to go back to the fundementals of this group, or do we set up a new one where policy arguments would be punted? John VE5MU No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.8/714 - Release Date: 3/8/2007 10:58 AM
Re: [digitalradio] Busy frequency detector (process definition).
General process flow for a signal detector / frequency busy detector implemented as a part of a semi-automated RF based client server message transport system. - A server (semi-automated which will respond to a request) is listening on a fixed frequency and 'sampling' a given range of its audio passband at a given sample rate. At this time is is listening to 'noise', and remembering what noise 'probably' sounds like. This is the first problem. In EU you won't find any 'noise' on an open HF band, just 'qrm', from stations X kmiles away. You would have to define what level of 'qrm' defines a clear frequency. And you would have to define what 'bandwidth' should be clear. E.g. should I have 3 kHz of clear frequency to run a pskmail server which needs only 200 Hz + 100 Hz guard band? I can put a few waterfall pics up on the pskmail wiki which show a 'clear' frequency on 30m. - The server learns and continuously refines its model for what noise has sounded like recently, and 'predicts' what noise is likely to sound like in the very near future, adapting to minor changes in noise. Minor changes in noise won't do, the qrm will change drastically from second to second. One example would be the harmonics of the APRS packet frequency on 30m which spread 3kHz, and certainly should not trigger 'busy'. - The server 'hears' a client request. The client is not automated, and a human listened to the frequency to determine it was not in use (it is possible for this process to be replaced by the same black box used on the server side to determine if the frequency is in use). The clients request to the server should serve as a QRL? to all stations on frequency that can hear it. Again,you should define what is a 'signal' here. This could be anything including the neighbour's kitchen sink. If the client receives a QRL (i.e. any signal that isn't an ACK from the server), it sends a CANCEL to the server. If the client doesn't get an ACK from the server, it will assume the server has detected the frequency is busy on its end, and wait a reasonable period of time before retrying to connect to the server. How should the server know if it is a client request? Is the criterium a fully decoded connect request in the mode which the server is runiing? Can it also be anything the server can decode in the mode it is operating in? 1 dB S/N can make the difference between decoding and not decoding and QSB can be 80 dB. The connect sequence is the most vulnerable in the whole arq procedure. Once the connect is done the arq can do its job. In my experience sometimes it is necessary to send 5 connect requests to set up the session, which does not have any problem to get the job done. In my opinion this step is too complicated. - If the server doesn't 'think' there is any other signal in its pass band, the server waits a given period of time, 'listening' for a QRL from any stations that may have heard the client request or a CANCEL from the client. If it doesn't hear a QRL (which for our purposes would be any signal that isn't a client request), or a CANCEL from the client, the server will ACK the client request, the ACK will function as the servers QRL?. If the server 'thought' there was already a signal in its passband, it would ignore the clients request outright. Is a QRL something the server decodes in its present mode, or is it any signal in the passband, like the switching charger in the next camper or the fan in the chicken farm next door? Why should the server wait after a connect request? It did listen on the frequency all the time so it knows if it is busy or not... - The server listens for a given period of time for a response to its ACK/QRL?, if it doesn't hear one, it 'decides' the frequency is clear and responds to the client request. This step is not necessary in my opinion. It is enough if the server has an idea if the qrg was 'busy' before the connect request. If it thinks the fequency is busy it can send a 'cancel' or a 'reject' to the client. In general think the procedure is too complicated. My 2cts Rein EA/PA0R/P (You could of course ask the client to give a 'QRL?' in CW before pushing the 'ON' switch, preferably with a 3 kHz wide signal so everybody can hear it within the span of his filters). - So what do you folks think, is this a reasonable process for an rf based client / server busy frequency detection system? 73, Erik N7HMS PS. Everyone knows a software project will never be successful without a catchy acronym or code name... if this ever becomes a real software product / project, lets NOT use the acronym BFD! Announce your digital presence via our DX Cluster telnet://cluster.dynalias.org Our other groups: http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/themixwgroup http://groups.yahoo.com/group/contesting
[digitalradio] Bad PSK signals ?
I was watching a bad PSK31 signal on 40M this morning, an IMD of -6 and harmonic waterfall 'trails all over my 3 Khz wide display. Do official observers ever get involved in these cases ? Seems that friendly pink slips might be useful here . -- Andy K3UK Skype Me : callto://andyobrien73 www.obriensweb.com
Re: Obstination (was Re: [digitalradio] Re: 3580kHz-3600kHz Freq Coordination Info)
And I think that Rick, KN6KB, was being modest about the 80% detection. I did not find that the software would ever transmit on what I, as a human, would have considered a busy frequency. However, there were times that it did not want to transmit because of what it perceived as a busy frequency, but I would have. The one thing that may have to be improved is the ability for the software to ignore a continuous carrier caused by a local internal or external birdie as it is extremely sensitive to the slightest carrier, even ones you can barely see on the screen. Even fleeting carriers. It seems to me that if you can detect SSB, then you can pretty much detect most modulation. The software had the ability to be adjusted by the operator for the level of detected signal by x dB using an on screen slider. I hope others will suggest to Paul Rinaldo, when they submit their recommendations for an HF digital mode, (or maybe an addendum?), that this software is already invented and ideally should be used, rather than having to reinvent it. Rick seems like a very reasonable person to me and not quite as much into the politics of the Winlink 2000 systems as the main owner/administrator. And remember that that ARRL may be able to provide some input into this considering that they so strongly supported Winlink 2000 with a stacked committee that insured a particular outcome in the decision making to support this kind of activity. Based upon the overall attitudes one gets from the Winlink 2000 administrator and his supporters, I would expect that the last thing they would want is to have a competitive system, that builds upon other systems, such as PSKmail, and incorporates some of the SCAMP software components, run at a moderate to high speed, and do it on the MS OS (Microsoft Operating System) platform. And yet, that has to be what will eventually evolve if we are able to set up truly robust and decentralized systems wherever we want them and need them and not be under the control of a central group. 73, Rick, KV9U Dave Bernstein wrote: As is often the case in engineering, Jose, perfect is the enemy of good. What Rick KN6KB discovered while developing SCAMP's busy detector was that he could detect CW, PSK, Pactor, and SSB at an ~80% confidence level without enormous difficulty. SCAMP beta testers were amazed by the effectiveness of this first iteration. Pushing the confidence level from 80% to 100%, however, would take years -- if its even possible. But a busy detector that works 80% of the time would cut QRM from unattended automated stations (like WinLink PMBOs) by a factor of 5! Your comment that many think it is simpler than it really is to do it WELL is frankly moot; Rick demonstrated two years ago that useful busy frequency detection was implementable on a PC and soundcard. 73, Dave, AA6YQ
[digitalradio] Re: Busy frequency detector (process definition).
Just a few thoughts: * A busy detector is not a panacea for all qrm, especially as you look at the lower bands. I can easily lay out a scenario for 80 meters or daytime on 40m where the PMBO should transmit when the freq is busy. This scenario happens less as you expand the skip zones on the higher bands. But it needs to be included. * The possibility of killing a system like winlink needs to be assessed also. This could be done by folks qrming it with periodic transmissions. * One of the big problems with pactor is its proclivity to expand its bandwidth regardless of who is operating close to the frequency. You can hear a 5 minute session at 500 Hz in p2, figure you can start up a psk31 qso as far away as 500 Hz, and ZAP, the pactor session moves to p3 and wipes you out. To prevent this, any new protocol needs to have a process built in that it will never expand once a session is set up. Going more narrow is no problem, but once done, you can't go back to a wider bandwidth. Pactor was designed to work in a commercial channelized system not a shared frequency system. It was set up so that once you claimed a channel, what you do with it is up to you. This just doesn't work in a shared freq environment like amateur radio. * While busy detection may help, it won't be a total solution. The FCC had a big process a couple of years ago on Cognitive Radio utilizing Software Defined Radios. The best minds in the business couldn't come up with an adequate solution that could be applied in just a transmitter that would prevent interference. The 'hidden' transmitter problem would still occur. * A new protocol really needs to utilize some kind of control link and/or stacking of client requests so that a single frequency can handle multiple requests on a queued basis. This will prevent the need for horizontal frequency spreading of servers (PMBO's) and achieve mazimum spectrum efficiency. * The protocol needs to be general in scope, like AX25, and not tied to just one operating system. Someone mentioned in another message here that it should work on Windows. The protocol should NOT be tied to anything Windows specific. It should be implementable on windows, linux. mac, etc. or even in a TNC like box. The software that uses it can then be written on whatever system the programmer so chooses. Thanks for the bandwidth. I had some other thoughts too, but these are the most important. Jim WA0LYK --- In digitalradio@yahoogroups.com, list email filter [EMAIL PROTECTED] wrote: Folks, I really don't know if I am failing to understand the problem, or underestimating the complexity of the solution, but I'd like to propose at least a dialog here of what it would take to implement a busy frequency detector. I'm not at all interested in discussing systems that may or may not use such a detector, or the politics / etc. involved. I am interested in at least defining the process of how a busy frequency detector should work, and defining some base requirements for how well it would need to work to be considered 'adequate' for use in amateur radio. My idea is to first define what the system should do, then define how well it would have to work to be considered successful or useful, and finally to consider the technical details required to implement such a system. To that end, the following to which I am inviting comments from this group, is my first pass at defining what a busy frequency detector should do (please hold comments on how well it would have to work, and how to implement it for follow-up threads, for now lets focus on getting the process definition refined): snip So what do you folks think, is this a reasonable process for an rf based client / server busy frequency detection system? 73, Erik N7HMS PS. Everyone knows a software project will never be successful without a catchy acronym or code name... if this ever becomes a real software product / project, lets NOT use the acronym BFD!
Re: [digitalradio] Bad PSK signals ?
Suggestion: Don't wait for an OO. Look up his call at QRZ.com, get his phone number, give him a call and talk to him about the problem. The op probably does not know that he is over-driving his audio. Chuck AA5J At 08:00 AM 3/10/2007, Andrew O'Brien wrote: I was watching a bad PSK31 signal on 40M this morning, an IMD of -6 and harmonic waterfall 'trails all over my 3 Khz wide display. Do official observers ever get involved in these cases ? Seems that friendly pink slips might be useful here . -- Andy K3UK
Re: Obstination (was Re: [digitalradio] Re: 3580kHz-3600kHz Freq Coordination Info)
It sounds to me that a confidence level like that simply means it knows what signal mode it is hearing. Personally, it would appear to me that the question is :Is there another signal of ANY kind on the frequency? If there is, it should NOT attempt to use the frequency, unless it is the SAME mode it itself is using, and then, only if it recognizes it is being called - or the other end is CQing, should it then attempt a contact. It would be nice to be able to tell what mode is operating on a frequency, and have our own software switch to that mode. If I remember correctly, LanLink had similar capability back in the 80s, and was available for some TNCs, including the MFJ 1278b. But, this is not the primary reason, as I now see it, for the auto digital modes to need to insure that other signals are not on a frequency, before transmitting. ANY activity on a frequency should prohibit the auto modes from transmitting unless they recognize it is a signal for them, and that would apparently be an easier programming step, than having them recognize all the other modes. Danny Douglas N7DC ex WN5QMX ET2US WA5UKR ET3USA SV0WPP VS6DD N7DC/YV5 G5CTB all DX 2-6 years each . QSL LOTW-buro- direct As courtesy I upload to eQSL but if you use that - also pls upload to LOTW or hard card. moderator [EMAIL PROTECTED] moderator http://groups.yahoo.com/group/DXandTalk - Original Message - From: Dave Bernstein [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Saturday, March 10, 2007 1:02 AM Subject: Obstination (was Re: [digitalradio] Re: 3580kHz-3600kHz Freq Coordination Info) As is often the case in engineering, Jose, perfect is the enemy of good. What Rick KN6KB discovered while developing SCAMP's busy detector was that he could detect CW, PSK, Pactor, and SSB at an ~80% confidence level without enormous difficulty. SCAMP beta testers were amazed by the effectiveness of this first iteration. Pushing the confidence level from 80% to 100%, however, would take years -- if its even possible. But a busy detector that works 80% of the time would cut QRM from unattended automated stations (like WinLink PMBOs) by a factor of 5! Your comment that many think it is simpler than it really is to do it WELL is frankly moot; Rick demonstrated two years ago that useful busy frequency detection was implementable on a PC and soundcard. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Jose A. Amador [EMAIL PROTECTED] wrote: Then, we need a codesmith that does away with those inaccurate assertions. The bona fide attempts of Rick with SCAMP has opened a can of worms... I don't even think he foresaw this, as many think it is simpler than it really is to do it WELL. It is no kids play. Let's wait for the magic code. Jose, CO2JA Dave Bernstein wrote: AA6YQ comments below --- In digitalradio@yahoogroups.com, Jose A. Amador amador@ wrote: Seems I did not make my point. A large portion of Winlinks popping out of nowhere is because some H I D D E N (in the skip zone) user has triggered it. That's exactly right, Jose. But if WinLink properly included a busy frequency detector, then it would refrain from responding to that H I D D E N user -- as would a human operator under the same circumstances. But since WinLink doesn't include a busy frequecy detector, and since WinLink doesn't respond to an operator sending QRL, please QSY, it blasts away, QRMing the pre-existing QSO. Andy, wasn't there another list to discuss this I hate Winlink stuff? There is indeed another list for discussing policy. Addressing inaccurate technical assertions seems in-scope for this list. 73, Dave, AA6YQ __ V Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética. 22 al 25 de mayo de 2007 Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.cujae.edu.cu/eventos/cier Announce your digital presence via our DX Cluster telnet://cluster.dynalias.org Our other groups: http://groups.yahoo.com/group/dxlist/ http://groups.yahoo.com/group/themixwgroup http://groups.yahoo.com/group/contesting http://groups.yahoo.com/group/wnyar http://groups.yahoo.com/group/Omnibus97 Yahoo! Groups Links -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.8/716 - Release Date: 3/9/2007 6:53 PM
[digitalradio] Re: Bad PSK signals ?
--- In digitalradio@yahoogroups.com, Chuck Mayfield [EMAIL PROTECTED] wrote: Suggestion: Don't wait for an OO. Look up his call at QRZ.com, get his phone number, give him a call and talk to him about the problem. The op probably does not know that he is over-driving his audio. I've done this maybe a dozen times in the past few years, though I don't call on the phone, just email when I can find it. I always include a polite note and a MixW screenshot of the offending signal, and make sure to indicate other good signals in the passband, so it can't be just put down to line level issues, etc. I think I've actually gotten a Thanks! I'll drop my drive level down next time maybe twice. A few never responded back, and the remainder were of the F-you, there's nothing wrong with my signal or equipment style. Needless to say, you can recognize the same guys over and over again in the passband without even clicking on their trace to decode them, like a certain kt4* who doesn't seem capable of ever turning his amp off. - Rich
Re: [digitalradio] Re: Busy frequency detector (process definition).
jgorman01 wrote: Just a few thoughts: * A busy detector is not a panacea for all qrm, especially as you look at the lower bands. I can easily lay out a scenario for 80 meters or daytime on 40m where the PMBO should transmit when the freq is busy. This scenario happens less as you expand the skip zones on the higher bands. But it needs to be included. I would say that it happens on any band. On 20, I am in skip with southern W4 land, they become the hidden stations for me. * The possibility of killing a system like winlink needs to be assessed also. This could be done by folks qrming it with periodic transmissions. Agreed. I foresaw the same possibilities when I wrote about Obstination. * One of the big problems with pactor is its proclivity to expand its bandwidth regardless of who is operating close to the frequency. You can hear a 5 minute session at 500 Hz in p2, figure you can start up a psk31 qso as far away as 500 Hz, and ZAP, the pactor session moves to p3 and wipes you out. To prevent this, any new protocol needs to have a process built in that it will never expand once a session is set up. Going more narrow is no problem, but once done, you can't go back to a wider bandwidth. Pactor was designed to work in a commercial channelized system not a shared frequency system. It was set up so that once you claimed a channel, what you do with it is up to you. This just doesn't work in a shared freq environment like amateur radio. Not a big problem if the activity detector senses the maximum possible bandwidth to be possibly used. P3 exchanges are full bandwidth for the server (some 2.4 kHz) and P2 bandwidth (500 Hz) for the ARQ responses. Making the activity detector to hold it only to P2 level would raise the level of complexity and would quite likely deemed not acceptable on channels designated as #P3 by the Winlink network. * While busy detection may help, it won't be a total solution. The FCC had a big process a couple of years ago on Cognitive Radio utilizing Software Defined Radios. The best minds in the business couldn't come up with an adequate solution that could be applied in just a transmitter that would prevent interference. The 'hidden' transmitter problem would still occur. I am sure of that. Identifying arbitrary intelligent signals out of noise is not trivial. A sort of software antivox based on energy is far simpler and also, far less reliable. * A new protocol really needs to utilize some kind of control link and/or stacking of client requests so that a single frequency can handle multiple requests on a queued basis. This will prevent the need for horizontal frequency spreading of servers (PMBO's) and achieve mazimum spectrum efficiency. It did not work well on packet. The choice of 300 baud and shared frequencies (which is not provided on Pactor, that works as a peer to peer link) were the causes I see as main technically based reasons for the HF packet demise. I kept my BBS fwd link on pactor for at least 6 years with far better results and thruput than I had in AX.25 packet. Unless a new protocol is devised (seemingly what the ARRL is seeking) that addresses the shared frequency limitations that packet had. Sharing is not a bad idea, but may be abused with long flags, agressive p-persist and slottime parameters, as happened on HF packet. I saw systems using BPQ set so aggresively that did not allow time for the ARQ reply to arrive and resent the same again before allowing the confirmation to arrive. A few more milliseconds (500 to 1000 milliseconds perhaps) would have avoided massive repeats and used the channel more efficiently. * The protocol needs to be general in scope, like AX25, and not tied to just one operating system. Someone mentioned in another message here that it should work on Windows. The protocol should NOT be tied to anything Windows specific. It should be implementable on windows, linux. mac, etc. or even in a TNC like box. The software that uses it can then be written on whatever system the programmer so chooses. Seems reasonable...algorithms may be conditioned to, but do not need to be tied to development environments or operating systems. Thanks for the bandwidth. I had some other thoughts too, but these are the most important. Jim WA0LYK Something that was discussed before is using the maximum bandwidth allowable the least time as possible. It helps to squeeze the juice out of small propagation windows. It is what P3 allows, and seemingly was one of the goals of SCAMP. I understand that all channels may not be wide channels, but at least one or two per band (like 7103.5 on 40 m ) seem desirable. 73, Jose, CO2JA __ V Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética. 22 al 25 de mayo de 2007 Palacio de las Convenciones, Ciudad de la Habana, Cuba
Re: Obstination (was Re: [digitalradio] Re: 3580kHz-3600kHz FreqCoordination Info)
Seems all the stateside operators want to do is argue. Is the plan to go back to the fundementals of this group, or do we set up a new one where policy arguments would be punted? John VE5MU Fellows, injecting national slurs into *any* ham radio discussion is a spectacularly bad idea. Please, let us not travel even one step down that road. This is an international fraternity. Let us keep it that way. de Roger W6VZV
Re: [digitalradio] Re: Bad PSK signals ?
them, like a certain kt4* who doesn't seem capable of ever turning his amp off. - Rich Ive done it with several ops also. 1 has said thanks, most say F you :D. And ya the KT4 doesnt seem to understand PSK31 is just fine without running full gallon ... and sounding like crap. Don't pick lemons. See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html
[digitalradio] Re: Busy detector
I have been lobbying the WinLink team to do this for years, without success. You are more than welcome to try, Jose. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Jose A. Amador [EMAIL PROTECTED] wrote: Dave Bernstein wrote: As is often the case in engineering, Jose, perfect is the enemy of good. What Rick KN6KB discovered while developing SCAMP's busy detector was that he could detect CW, PSK, Pactor, and SSB at an ~80% confidence level without enormous difficulty. SCAMP beta testers were amazed by the effectiveness of this first iteration. Pushing the confidence level from 80% to 100%, however, would take years -- if its even possible. But a busy detector that works 80% of the time would cut QRM from unattended automated stations (like WinLink PMBOs) by a factor of 5! Your comment that many think it is simpler than it really is to do it WELL is frankly moot; Rick demonstrated two years ago that useful busy frequency detection was implementable on a PC and soundcard. 73, Dave, AA6YQ I understand that 80% is fairly good. Hope the long standing anti-automatic stations lobby sees it as acceptable as well. What is seemingly left, then, is to simply push the busy detector into practice and 24/7 service. Who will get the task done? 73, Jose __ V Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética. 22 al 25 de mayo de 2007 Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.cujae.edu.cu/eventos/cier
[digitalradio] Re: Bad PSK signals ?
I would just tell the operator directly; in my experience, they're usually appreciative, and can't wait to race off and fix the problem. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Andrew O'Brien [EMAIL PROTECTED] wrote: I was watching a bad PSK31 signal on 40M this morning, an IMD of -6 and harmonic waterfall 'trails all over my 3 Khz wide display. Do official observers ever get involved in these cases ? Seems that friendly pink slips might be useful here . -- Andy K3UK Skype Me : callto://andyobrien73 www.obriensweb.com
[digitalradio] Re: Busy frequency detector (process definition).
AA6YQ comments below --- In digitalradio@yahoogroups.com, jgorman01 [EMAIL PROTECTED] wrote: Just a few thoughts: * A busy detector is not a panacea for all qrm, especially as you look at the lower bands. I can easily lay out a scenario for 80 meters or daytime on 40m where the PMBO should transmit when the freq is busy. This scenario happens less as you expand the skip zones on the higher bands. But it needs to be included. Please describe the scenario that would justify transmitting on a busy frequency during non-emergency conditions * The possibility of killing a system like winlink needs to be assessed also. This could be done by folks qrming it with periodic transmissions. Busy detection should be disabled during emergency conditions. If someone builds an automatic station capable of QRMing WinLink 24x7, it will be easy to track down. * One of the big problems with pactor is its proclivity to expand its bandwidth regardless of who is operating close to the frequency. You can hear a 5 minute session at 500 Hz in p2, figure you can start up a psk31 qso as far away as 500 Hz, and ZAP, the pactor session moves to p3 and wipes you out. To prevent this, any new protocol needs to have a process built in that it will never expand once a session is set up. Going more narrow is no problem, but once done, you can't go back to a wider bandwidth. Pactor was designed to work in a commercial channelized system not a shared frequency system. It was set up so that once you claimed a channel, what you do with it is up to you. This just doesn't work in a shared freq environment like amateur radio. Agreed, though expansion would be okay if one first verified that the expanded frequency range was not busy. Instead of simply expanding, the station must first acquire the expanded bandwidth (by verifying it to be clear). * While busy detection may help, it won't be a total solution. The FCC had a big process a couple of years ago on Cognitive Radio utilizing Software Defined Radios. The best minds in the business couldn't come up with an adequate solution that could be applied in just a transmitter that would prevent interference. The 'hidden' transmitter problem would still occur. Perfect is the enemy of good, etc. SCAMP has already demonstrated that a first iteration implemented two years ago would have a huge positive impact if deployed today. * A new protocol really needs to utilize some kind of control link and/or stacking of client requests so that a single frequency can handle multiple requests on a queued basis. This will prevent the need for horizontal frequency spreading of servers (PMBO's) and achieve mazimum spectrum efficiency. In the current situation, divide and conquer is a better strategy than boil the ocean. Lets make a big dent in the QRM problem first; we can then use that momentum to address other opportunities, like improved efficiency. * The protocol needs to be general in scope, like AX25, and not tied to just one operating system. Someone mentioned in another message here that it should work on Windows. The protocol should NOT be tied to anything Windows specific. It should be implementable on windows, linux. mac, etc. or even in a TNC like box. The software that uses it can then be written on whatever system the programmer so chooses. I agree with these points, but lets not overreach. Step by step... 73, Dave, AA6YQ
Re: [digitalradio] Re: Bad PSK signals ?
mulveyraa2 wrote: I think I've actually gotten a Thanks! I'll drop my drive level down next time maybe twice. A few never responded back, and the remainder were of the F-you, there's nothing wrong with my signal or equipment style. Needless to say, you can recognize the same guys over and over again in the passband without even clicking on their trace to decode them, like a certain kt4* who doesn't seem capable of ever turning his amp off. - Rich That is certainly disappointing. What software do you use to take a screenshot? Will it work with MixW? de Roger W6VZV
[digitalradio] Re: Bad PSK signals ?
Striking your keyboard's PrintScreen button will place an image of the entire screen in the Windows Clipboard. Depressing the Alt key while striking PrintScreen will place an image of the currently- active window in the Windows Clipboard; this is the recommended approach. PrintScreen is often abbreviated on keytops; on my IBM T42 laptop, the label is PrtSc. Once you have an image in the Windows Clipboard, you can open MS Paint, and select the Edit:Paste menu item to create a bitmap image that you can save to a .bmp file. Place that .bmp file in a zip archive (bitmaps are big, but compress well), and email. If you have PhotoShop or some other image editing application installed, you can instead paste the image there, and directly generate a JPEG file (with appropriate compression), which can be directly attached to an email message. There's a nice application called SnagIt that combines the screen shot capture and image saving process, but it costs a few $. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Roger J. Buffington [EMAIL PROTECTED] wrote: mulveyraa2 wrote: I think I've actually gotten a Thanks! I'll drop my drive level down next time maybe twice. A few never responded back, and the remainder were of the F-you, there's nothing wrong with my signal or equipment style. Needless to say, you can recognize the same guys over and over again in the passband without even clicking on their trace to decode them, like a certain kt4* who doesn't seem capable of ever turning his amp off. - Rich That is certainly disappointing. What software do you use to take a screenshot? Will it work with MixW? de Roger W6VZV
Re: Obstination (was Re: [digitalradio] Re: 3580kHz-3600kHz FreqCoordination Info)
Hey I'm one of the first to complain about WINLINK knocking out a QSO, and it is usually during a DX contact that it happens What I can't understand is the constant complaining about big bad old winlink, with the arguments going around and around. I don't have to operate in the middle of the automatic stations. I have a VFO and can go down below 3590, and find good QSO's between 3580 and 3590, or go to a different band. I know that I have the right to operate digital modes where I please, but common sense also says why fight QRM? WINLINK is not going to disappear, and any new ARQ mode to replace Pactor 2 and 3 will have to supported by the WINLINK folks Nobody really seems to know what happened to SCAMP, maybe the P3 modem builders made him an offer he couldn't refuse? There are authors out there quietly woking away on new stuff, like 141A and RFSM2400 which show some promise and deserve support from the digital community. If I were a US ham right now I would want to do several things: * Instead of trying to burn winlink at the stake, work from within the organization to try and reduce the frequencies used on 80M Honey always works better than vinegar. * Mount a concerted campaign with local Homeland Security offices, talking about the lack of data frequencis for emergency use, especially for all those fancy P3 modems that they bought. Point out how much better it would be with another 25 or 50 kHz of bandwidth to 3650. * Another campaign with the politicians, same argument, but pointing out how the federal bureaucrats (FCC) have put the US at risk. *ARRL? they know not what they do. Not much to do except plot a revolution and/or run for office. The thought crossed my mind as I went through the 75 or so emails over the past few days as to how many of the authors actually use digital modes on the air... John VE5MU -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.8/714 - Release Date: 3/8/2007 10:58 AM
Re: [digitalradio] Re: Bad PSK signals ?
Roger J. Buffington wrote: That is certainly disappointing. What software do you use to take a screenshot? Will it work with MixW? de Roger W6VZV You could try with a simple Print Screen dump to the clipboard, and then paste it to Paint, Photoshop or whatever. I use Gadwin Print Screen 2.6, and Irfanview 3.99 is also capable of screen grabs. MultiPSK by itself can do screen dumps to a graphic file. 73, Jose CO2JA __ V Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética. 22 al 25 de mayo de 2007 Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.cujae.edu.cu/eventos/cier
Obstination (was Re: [digitalradio] Re: 3580kHz-3600kHz FreqCoordination Info)
The WinLink folks have run a long and effective campaign of disinformation. They claim that most of the QRM caused by WinLink PMBOs either is the fault of a WinLink user who called on a busy frequency, or isn't really QRM because the victim was running panoramic reception and thus had his or her RX filters set too wide. Because few hams own Pactor modems, its very difficult to prove that you were QRM'd by a WinLink PMBO; even when you have one, as I do, you must move pretty quickly from whatever mode you were using to capture the offender's callsign -- and that means abandoning your QSO, which many are reluctant to do even in the face of a Pactor signal blasting away. The hidden transmitter effect -- which causes WinLink PMBOs to QRM ongoing QSOs even when its users are scrupulous about only making requests on clear frequencies -- is not intuitively obvious to most amateurs. Every few months, someone starts a thread here along the lines of lets allocate more space to automatic operations or WinLink is fine, why is there a problem. Allowing such statements to stand would reinforce the WinLink disinformation campaign, which is why I and others so assiduously rebut them on the spot. You may find that annoying, John, but the alternative -- wideband WinLink anywhere on the bands -- would be far more annoying, I assure you. So why don't we just not operate in the middle of automatic stations and shut up, as you suggest? Two reasons: 1. unattended automatic stations with a bandwidth of 500 hz or less can run anywhere in the data bands, so there is no safe frequency 2. failing to vociferously object to WinLink's QRM generation will make it easier for the ARRL to convince the FCC to enact its bandwidth-based frequency allocation proposal, which as a side effect would greatly expand the frequencies available to 3 khz WinLink PMBOs. My belief is that the more amateurs -- everywhere in the world -- that understand the problem, the more pressure will be brought to bear on the ARRL leadership to a. modify its frequency allocation proposal b. pressure the WinLink team to re-engineer WinLink to acceptable operational standards If you haven't sent email to Dave Sumner (ARRL CEO) expressing your concern with the ARRL's support for WinLink, I encourage you to do so; you need not be an ARRL member or US citizen to do this! Dave's email address is [EMAIL PROTECTED] . 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, John Bradley [EMAIL PROTECTED] wrote: Hey I'm one of the first to complain about WINLINK knocking out a QSO, and it is usually during a DX contact that it happens What I can't understand is the constant complaining about big bad old winlink, with the arguments going around and around. I don't have to operate in the middle of the automatic stations. I have a VFO and can go down below 3590, and find good QSO's between 3580 and 3590, or go to a different band. I know that I have the right to operate digital modes where I please, but common sense also says why fight QRM? WINLINK is not going to disappear, and any new ARQ mode to replace Pactor 2 and 3 will have to supported by the WINLINK folks Nobody really seems to know what happened to SCAMP, maybe the P3 modem builders made him an offer he couldn't refuse? There are authors out there quietly woking away on new stuff, like 141A and RFSM2400 which show some promise and deserve support from the digital community. If I were a US ham right now I would want to do several things: * Instead of trying to burn winlink at the stake, work from within the organization to try and reduce the frequencies used on 80M Honey always works better than vinegar. * Mount a concerted campaign with local Homeland Security offices, talking about the lack of data frequencis for emergency use, especially for all those fancy P3 modems that they bought. Point out how much better it would be with another 25 or 50 kHz of bandwidth to 3650. * Another campaign with the politicians, same argument, but pointing out how the federal bureaucrats (FCC) have put the US at risk. *ARRL? they know not what they do. Not much to do except plot a revolution and/or run for office. The thought crossed my mind as I went through the 75 or so emails over the past few days as to how many of the authors actually use digital modes on the air... John VE5MU -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.8/714 - Release Date: 3/8/2007 10:58 AM
Re: Obstination (was Re: [digitalradio] Re: 3580kHz-3600kHz FreqCoordination Info)
Dave Bernstein wrote: .. So why don't we just not operate in the middle of automatic stations and shut up, as you suggest? Two reasons: 1. unattended automatic stations with a bandwidth of 500 hz or less can run anywhere in the data bands, so there is no safe frequency 2. failing to vociferously object to WinLink's QRM generation will make it easier for the ARRL to convince the FCC to enact its bandwidth-based frequency allocation proposal, which as a side effect would greatly expand the frequencies available to 3 khz WinLink PMBOs. My belief is that the more amateurs -- everywhere in the world -- that understand the problem, the more pressure will be brought to bear on the ARRL leadership to a. modify its frequency allocation proposal b. pressure the WinLink team to re-engineer WinLink to acceptable operational standards If you haven't sent email to Dave Sumner (ARRL CEO) expressing your concern with the ARRL's support for WinLink, I encourage you to do so; you need not be an ARRL member or US citizen to do this! Dave's email address is [EMAIL PROTECTED] mailto:k1zz%40arrl.net . 73, Dave, AA6YQ Best post on this awful problem I have seen in years. Good job Dave. de Roger W6VZV
Re: Obstination (was Re: [digitalradio] Re: 3580kHz-3600kHz FreqCoordination Info)
John, We have gone over some of this a number of times, but perhaps you missed it. The Winlink 2000 programmer abandoned further work on the SCAMP mode because there is mostly one programmer as they don't work with many other hams on this. The have a closed view of the system and has been told to me, they can not allow others to know too much of the details because a malicious person could take the whole system down. Thus the security. The programmer had to work on the huge job of redoing the CMBO (Central Mail Box Office) into the new CMS (Central Message Server) to increase the redundancy of the system from two in the U.S. to two in the U.S. and one in some other country with a potential for a total of 8 CMS's worldwide. Now they are redoing the PMBO (Participating Mail Box Office)'s into RMS (Radio Message Servers) but I am not sure how things are going on that change. The programmer did indicate that he planned to release SCAMP as a GPL. It appears that he is legally bound to do so two years ago, but I hope that he will want to do this to advance the radio art, rather than keep this away from others. The main issue is to replace or add to the RDFT protocol with another protocol that can run well for different conditions. The SSTV folks abandoned RDFT after OFDM modes were developed as they work slightly better, perhaps 3 db or so with similar throughput. If you are on 3585, you are in the automatic area of the band, so you might expect some competition there. Even if a SCAMP replacement is developed for Winlink 2000, it is not going to replace P modes any time soon, since P modes are still likely to outcompete anything that can be developed by the amateur programming community. And there is a huge investment of $1000 modems that are not going to be abandoned unless something else proves to be better. There is no Winlink 2000 organization that you can work from within. It is basically a closed group of maybe half a dozen (at most) owners. They dictate all the terms to the amateur community and tell us how we are to use their system, who can have a CMS or PMBO, etc. There aren't that many SCS modems around. Some areas have invested in them, but most have not. P1 can be used for emergency use with some HF PMBO's and they will lift the 30 minute time limit for using their system in some cases. The ARRL proposal was not accepted by the FCC. For some reason, there are folks like you who seem to suggest that ARRL was behind the recent FCC changes. They were not. Their proposal was much more modest than the bizarre decision by the FCC to make things worse for the new modes. Hope to work you again on the digital frequencies if and when I get my Linux system running anything digital:( 73, Rick, KV9U John Bradley wrote: Hey I'm one of the first to complain about WINLINK knocking out a QSO, and it is usually during a DX contact that it happens What I can't understand is the constant complaining about big bad old winlink, with the arguments going around and around. I don't have to operate in the middle of the automatic stations. I have a VFO and can go down below 3590, and find good QSO's between 3580 and 3590, or go to a different band. I know that I have the right to operate digital modes where I please, but common sense also says why fight QRM? WINLINK is not going to disappear, and any new ARQ mode to replace Pactor 2 and 3 will have to supported by the WINLINK folks Nobody really seems to know what happened to SCAMP, maybe the P3 modem builders made him an offer he couldn't refuse? There are authors out there quietly woking away on new stuff, like 141A and RFSM2400 which show some promise and deserve support from the digital community. If I were a US ham right now I would want to do several things: * Instead of trying to burn winlink at the stake, work from within the organization to try and reduce the frequencies used on 80M Honey always works better than vinegar. * Mount a concerted campaign with local Homeland Security offices, talking about the lack of data frequencis for emergency use, especially for all those fancy P3 modems that they bought. Point out how much better it would be with another 25 or 50 kHz of bandwidth to 3650. * Another campaign with the politicians, same argument, but pointing out how the federal bureaucrats (FCC) have put the US at risk. *ARRL? they know not what they do. Not much to do except plot a revolution and/or run for office. The thought crossed my mind as I went through the 75 or so emails over the past few days as to how many of the authors actually use digital modes on the air... John VE5MU No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.8/714 - Release Date: 3/8/2007 10:58 AM
Re: [digitalradio] Re: 3580kHz-3600kHz Freq Coordination Info
- Original Message - From: John Becker [EMAIL PROTECTED] To: digitalradio@yahoogroups.com Sent: Thursday, March 08, 2007 6:01 PM Subject: Re: [digitalradio] Re: 3580kHz-3600kHz Freq Coordination Info After looking at the winlink position report page there must be 50 or so hams at sea. Now why in the world would anyone not want them to be able to send a message back to home. Why in the world would hams want non-hams to use amateur frequencices for email? Why in the world would some hams desire to give up THEIR frequenices to email? Just a thought, Buddy WB4M
[digitalradio] Re: Bad PSK signals ?
--- In digitalradio@yahoogroups.com, Andrew O'Brien [EMAIL PROTECTED] wrote: I was watching a bad PSK31 signal on 40M this morning, an IMD of -6 and harmonic waterfall 'trails all over my 3 Khz wide display. Do official observers ever get involved in these cases ? Seems that friendly pink slips might be useful here . -- Andy K3UK Skype Me : callto://andyobrien73 www.obriensweb.com In the past, I have taken a screen shot of signals like this, which will identify the station from the text, the frequency, time of day, it's all there, then emailed it off to their qrz.com listed address. I have included a friendly note suggesting that they may not be aware of their signal, and have received thanks in return. Brad VK2QQ
[digitalradio] Re: Bad PSK signals ?
--- In digitalradio@yahoogroups.com, Roger J. Buffington [EMAIL PROTECTED] wrote: mulveyraa2 wrote: That is certainly disappointing. What software do you use to take a screenshot? Will it work with MixW? de Roger W6VZV Click ALT-PRTSCREEN and then click Paste directly into your email program. Easy. I've even done this while the offending ZL was on air and he received the email between transmissions, called me on psk and asked for advice. Instant results! Brad VK2QQ
Re: Obstination (was Re: [digitalradio] Re: 3580kHz-3600kHz FreqCoordination Info)
Sorry to hear about your system being on a holiday from digital radio. There is no Winlink 2000 organization that you can work from within. It is basically a closed group of maybe half a dozen (at most) owners. They dictate all the terms to the amateur community and tell us how we are to use their system, who can have a CMS or PMBO, etc. In my limited dealings with winlink, looking at it as a gateway for emergency comms for us where we do not have any other service, the folks running the PMBO's are like any other Ham , interested in the hobby and reasonable people. So, ignoring the owners for a moment, what about appealing to the volunteer PMBO operators scattered around the country and outline the problems we are having with Pactor? for the most part they are interested in digi stuff as we are, the downside is that most have invested in a fancy modem as opposed to using nothing more than a sound card. It's easy to figure out who the public ones are, since they are listed on the software downloadable from the winlink site. The more difficult PMBO's to track down are the non-published ARES and other sites, but maybe a little CSI work would pay off. I am not suggesting flaming these operators in any way , but politely pointing out what theyare doing to the rest of the hobby. what may to them appear to be a public service is actually a disservice to the hobby. I know that there will be a predictable response from some pactor operators, telling us something to do with sex and travel. But for every one of these operators that we can convince to either quit or modify their operations, that would be one less source of QRM. Even if we convinced them to drop their 80M operations would be better than nothing. As for the ARRL, from what I have read it appears that the ARRL bowed to the requests of the SSB operators to push the SSB segment down to 3600, and lobbied the FCC accordingly. when the FCC acted, and there was a backlash from other users of 80M, then the ARRL said oops and changed their tune. I don't think we can wait for some new mode with anti QRM features, rather we have to be proactive in other ways John VE5MU -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.446 / Virus Database: 268.18.8/717 - Release Date: 3/10/2007 2:25 PM
[digitalradio] Re: Busy frequency detector (process definition).
--- In digitalradio@yahoogroups.com, Jose A. Amador [EMAIL PROTECTED] wrote: Not a big problem if the activity detector senses the maximum possible bandwidth to be possibly used. P3 exchanges are full bandwidth for the server (some 2.4 kHz) and P2 bandwidth (500 Hz) for the ARQ responses. Making the activity detector to hold it only to P2 level would raise the level of complexity and would quite likely deemed not acceptable on channels designated as #P3 by the Winlink network. I suspect an activity detector IS going to have a problem knowing if there is another close by signal while the auto station is tranmsitting. In fact, so will a client, while it is transmitting. If, while transmitting, the busy detector would prevent expanding the bandwidth if there is a close by signal, then I see no reason this why this wouldn't prevent qrm'ing of other nearby qso's. It did not work well on packet. The choice of 300 baud and shared frequencies (which is not provided on Pactor, that works as a peer to peer link) were the causes I see as main technically based reasons for the HF packet demise. I kept my BBS fwd link on pactor for at least 6 years with far better results and thruput than I had in AX.25 packet. Unless a new protocol is devised (seemingly what the ARRL is seeking) that addresses the shared frequency limitations that packet had. Sharing is not a bad idea, but may be abused with long flags, agressive p-persist and slottime parameters, as happened on HF packet. I saw systems using BPQ set so aggresively that did not allow time for the ARQ reply to arrive and resent the same again before allowing the confirmation to arrive. A few more milliseconds (500 to 1000 milliseconds perhaps) would have avoided massive repeats and used the channel more efficiently. I wasn't really really talking about interleaving sessions. I was talking about using an interval of say 3 minutes where the server tells the current client, hold on, we're going to accept new requests that will be put into queue. At this point, a broadcast would be made, a CQ if you will, and clients would use a random timing like ethernet to determines who goes first. That next client would place a call to whatever server it wants that is on the freq. and the request would be put into queue. Since, in winlinks case, the pmbo's are connected to the internet, they could interactively build a queue list to determine what server/client goes next after the current session. Something that was discussed before is using the maximum bandwidth allowable the least time as possible. It helps to squeeze the juice out of small propagation windows. It is what P3 allows, and seemingly was one of the goals of SCAMP. I understand that all channels may not be wide channels, but at least one or two per band (like 7103.5 on 40 m ) seem desirable. I have heard the winlink folks spout this and it may be the case, but winlink at least, doesn't practice what they preach. If this was really true, they wouldn't need to have so many different pmbo's on different frequencies. They would have a lot of them on just one frequency. Instead, they have set their system up so that there is immediate access by clients by using horizontal frequency spreading rather than asking them to monitor a frequency until it clears. With this type of operation, the speed makes no difference. 73, Jose, CO2JA __ V Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética. 22 al 25 de mayo de 2007 Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.cujae.edu.cu/eventos/cier
[digitalradio] Re: Busy detector
Ask yourself why scamp died. Do you really think the winlink users who have spent a thousand dollars or more on pactor modems are going to relish throwing that investment away because the winlink admin's have decided to go to a soundcard mode? Jim WA0LYK --- In digitalradio@yahoogroups.com, Dave Bernstein [EMAIL PROTECTED] wrote: I have been lobbying the WinLink team to do this for years, without success. You are more than welcome to try, Jose. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Jose A. Amador amador@ wrote: Dave Bernstein wrote: As is often the case in engineering, Jose, perfect is the enemy of good. What Rick KN6KB discovered while developing SCAMP's busy detector was that he could detect CW, PSK, Pactor, and SSB at an ~80% confidence level without enormous difficulty. SCAMP beta testers were amazed by the effectiveness of this first iteration. Pushing the confidence level from 80% to 100%, however, would take years -- if its even possible. But a busy detector that works 80% of the time would cut QRM from unattended automated stations (like WinLink PMBOs) by a factor of 5! Your comment that many think it is simpler than it really is to do it WELL is frankly moot; Rick demonstrated two years ago that useful busy frequency detection was implementable on a PC and soundcard. 73, Dave, AA6YQ I understand that 80% is fairly good. Hope the long standing anti-automatic stations lobby sees it as acceptable as well. What is seemingly left, then, is to simply push the busy detector into practice and 24/7 service. Who will get the task done? 73, Jose __ V Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética. 22 al 25 de mayo de 2007 Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.cujae.edu.cu/eventos/cier
Re: [digitalradio] Re: Bad PSK signals ?
On 3/10/07, Brad [EMAIL PROTECTED] wrote: while the offending ZL was on air and he received the email between transmissions, called me on psk and asked for advice. Instant results! Brad VK2QQ A ZL called a VK for advice ! What is the world coming to ? Andy K3UK (from near Thirlmere)
Re: [digitalradio] Re: Busy detector
Guys, Like I have said before, the only way to solve this is to designate a certain portion on each band just for this type of communications. I just don't understand anyone would spend thousand of dollars on radios, antennas, computers and other related hardware just to pass email. Joe W4JSI - Original Message - From: jgorman01 To: digitalradio@yahoogroups.com Sent: Saturday, March 10, 2007 6:07 PM Subject: [digitalradio] Re: Busy detector Ask yourself why scamp died. Do you really think the winlink users who have spent a thousand dollars or more on pactor modems are going to relish throwing that investment away because the winlink admin's have decided to go to a soundcard mode? Jim WA0LYK --- In digitalradio@yahoogroups.com, Dave Bernstein [EMAIL PROTECTED] wrote: I have been lobbying the WinLink team to do this for years, without success. You are more than welcome to try, Jose. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Jose A. Amador amador@ wrote: Dave Bernstein wrote: As is often the case in engineering, Jose, perfect is the enemy of good. What Rick KN6KB discovered while developing SCAMP's busy detector was that he could detect CW, PSK, Pactor, and SSB at an ~80% confidence level without enormous difficulty. SCAMP beta testers were amazed by the effectiveness of this first iteration. Pushing the confidence level from 80% to 100%, however, would take years -- if its even possible. But a busy detector that works 80% of the time would cut QRM from unattended automated stations (like WinLink PMBOs) by a factor of 5! Your comment that many think it is simpler than it really is to do it WELL is frankly moot; Rick demonstrated two years ago that useful busy frequency detection was implementable on a PC and soundcard. 73, Dave, AA6YQ I understand that 80% is fairly good. Hope the long standing anti-automatic stations lobby sees it as acceptable as well. What is seemingly left, then, is to simply push the busy detector into practice and 24/7 service. Who will get the task done? 73, Jose __ V Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética. 22 al 25 de mayo de 2007 Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.cujae.edu.cu/eventos/cier
[digitalradio] Re: Busy detector
I agree with your point, Jim. However, it doesn't explain the failure of the WinLink organization to incorporate the SCAMP busy detector in each of their PMBOs. This would have no impact on WinLink users, and minimal $ impact on PMBO operators. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, jgorman01 [EMAIL PROTECTED] wrote: Ask yourself why scamp died. Do you really think the winlink users who have spent a thousand dollars or more on pactor modems are going to relish throwing that investment away because the winlink admin's have decided to go to a soundcard mode? Jim WA0LYK --- In digitalradio@yahoogroups.com, Dave Bernstein aa6yq@ wrote: I have been lobbying the WinLink team to do this for years, without success. You are more than welcome to try, Jose. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Jose A. Amador amador@ wrote: Dave Bernstein wrote: As is often the case in engineering, Jose, perfect is the enemy of good. What Rick KN6KB discovered while developing SCAMP's busy detector was that he could detect CW, PSK, Pactor, and SSB at an ~80% confidence level without enormous difficulty. SCAMP beta testers were amazed by the effectiveness of this first iteration. Pushing the confidence level from 80% to 100%, however, would take years -- if its even possible. But a busy detector that works 80% of the time would cut QRM from unattended automated stations (like WinLink PMBOs) by a factor of 5! Your comment that many think it is simpler than it really is to do it WELL is frankly moot; Rick demonstrated two years ago that useful busy frequency detection was implementable on a PC and soundcard. 73, Dave, AA6YQ I understand that 80% is fairly good. Hope the long standing anti-automatic stations lobby sees it as acceptable as well. What is seemingly left, then, is to simply push the busy detector into practice and 24/7 service. Who will get the task done? 73, Jose __ V Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética. 22 al 25 de mayo de 2007 Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.cujae.edu.cu/eventos/cier
[digitalradio] Re: Busy detector
Other folks would say I just don't understand anyone would spend thousand of dollars on radios, antennas, computers and other related hardware just to exchange signal reports with someone you could more easily talk to on Skype. Other than keeping it non-commerical, we should avoid any attempt to legislate content. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Joe Ivey [EMAIL PROTECTED] wrote: Guys, Like I have said before, the only way to solve this is to designate a certain portion on each band just for this type of communications. I just don't understand anyone would spend thousand of dollars on radios, antennas, computers and other related hardware just to pass email. Joe W4JSI - Original Message - From: jgorman01 To: digitalradio@yahoogroups.com Sent: Saturday, March 10, 2007 6:07 PM Subject: [digitalradio] Re: Busy detector Ask yourself why scamp died. Do you really think the winlink users who have spent a thousand dollars or more on pactor modems are going to relish throwing that investment away because the winlink admin's have decided to go to a soundcard mode? Jim WA0LYK --- In digitalradio@yahoogroups.com, Dave Bernstein aa6yq@ wrote: I have been lobbying the WinLink team to do this for years, without success. You are more than welcome to try, Jose. 73, Dave, AA6YQ --- In digitalradio@yahoogroups.com, Jose A. Amador amador@ wrote: Dave Bernstein wrote: As is often the case in engineering, Jose, perfect is the enemy of good. What Rick KN6KB discovered while developing SCAMP's busy detector was that he could detect CW, PSK, Pactor, and SSB at an ~80% confidence level without enormous difficulty. SCAMP beta testers were amazed by the effectiveness of this first iteration. Pushing the confidence level from 80% to 100%, however, would take years -- if its even possible. But a busy detector that works 80% of the time would cut QRM from unattended automated stations (like WinLink PMBOs) by a factor of 5! Your comment that many think it is simpler than it really is to do it WELL is frankly moot; Rick demonstrated two years ago that useful busy frequency detection was implementable on a PC and soundcard. 73, Dave, AA6YQ I understand that 80% is fairly good. Hope the long standing anti-automatic stations lobby sees it as acceptable as well. What is seemingly left, then, is to simply push the busy detector into practice and 24/7 service. Who will get the task done? 73, Jose __ V Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética. 22 al 25 de mayo de 2007 Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.cujae.edu.cu/eventos/cier
[digitalradio] Re: Bad PSK signals linears
Ok, here's a question I don't know how to answer since I don't have the experience. Let's say I am running my IC-746PRO on PSK31 and passing disaster relief traffic in and out of a disaster area. If the station I am working on the other end can't decode me and I am also having trouble decoding his signal due to a weak signal, if I turn on my linear is that Ok or should I just give up and wait for better conditions? And my assumption is that the linear is properly tuned to amplify a PSK31 signal and my antenna and band is optimum for the working path. 73, Walt/K5YFW
[digitalradio] Re: Bad PSK signals linears
--- In digitalradio@yahoogroups.com, Walt DuBose [EMAIL PROTECTED] wrote: if I turn on my linear is that Ok or should I just give up and wait for better conditions? Walt/K5YFW K5? Sure, crank it up.
Re: [digitalradio] Re: Bad PSK signals linears
During an emergency you can pretty much do whatever it takes to get your message through. But if you can't decode him turning up your power won't help. - Original Message - From: Walt DuBose To: digitalradio@yahoogroups.com Sent: Saturday, March 10, 2007 8:10 PM Subject: [digitalradio] Re: Bad PSK signals linears Ok, here's a question I don't know how to answer since I don't have the experience. Let's say I am running my IC-746PRO on PSK31 and passing disaster relief traffic in and out of a disaster area. If the station I am working on the other end can't decode me and I am also having trouble decoding his signal due to a weak signal, if I turn on my linear is that Ok or should I just give up and wait for better conditions? And my assumption is that the linear is properly tuned to amplify a PSK31 signal and my antenna and band is optimum for the working path. 73, Walt/K5YFW
RE: [digitalradio] Re: Bad PSK signals ?
_ From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Andrew O'Brien A ZL called a VK for advice ! What is the world coming to ? Just some big brotherly advice. Andy K3UK (from near Thirlmere) Hmm, I would expect better signals from you! Brad VK2QQ actually in Thirlmere. _,_._,___
[digitalradio] What's with Boulder?
Hmm, not really ham radio related but my atomic clock just leap forward an hour at 11.30PM Eastern Time (USA). Did WWV not have the patience to wait until the official date and time ? -- Andy K3UK Skype Me : callto://andyobrien73 www.obriensweb.com
[digitalradio] Fwd: [tapr-announce] Join Us at the First TAPR/AMSAT Joint Hamvention Banquet
Joint TAPR/AMSAT Banquet at Dayton 2007 For many years, AMSAT and TAPR have held competing Hamvention dinners on Friday evening. Given the tremendous overlap in membership and interest between the two groups, this has always required tough choices. We're pleased to announce that this year, AMSAT and TAPR will be holding a joint dinner, and it will be at a great venue -- the Air Force Museum. Here are the details: Dinner Under the Wings will be held Friday evening May 18,2007 at the Air Force Museum in Dayton, OH in conjunction with the 2007 Dayton Hamvention. The doors open at 18:00 with a cash bar and appetizers in the Air Power Gallery (World War II). The buffet dinner will be served at 19:00 in the Cold War area. Following a few announcements and a short presentation you will be free to roam the museum. Price for the dinner is $35.00 per person and includes appetizers, salad, meal, dessert, coffee, iced tea, tax and gratuity. See http://afmuseum.com/ or http://www.nationalmuseum.af.mil/ for information about the museum. The museum will close at 22:00 and everyone must be out of the museum by then. Reservations are required and can be purchased from TAPR -- go to http://www.tapr.org/dayton.html for more details. There will be no ticket sales at the TAPR booth this year, and sales will close on Monday night, May 14, 2007 to allow us to give the museum a count on Tuesday. There may also be a special showing of the IMAX movie Space Station at 5:00 PM prior to the banquet. See below for details. Banquet Menu Roll and Butter Salad with choice of Ranch, French or Italian Dressing Top Round of Beef w/carver Classic Sautéed Chicken Breast in a Sun Dried Tomato Cream Sauce Grilled Salmon Blackened with Jack Daniel's BBQ Sauce Roasted Red Skin Potatoes Rice Pilaf w/ Pine Nuts and Thyme Prince Edward Blend w/ Yellow Wax Beans, Green Beans and Baby Carrots Sugar Snap Peas w/ Red and Yellow Peppers Chocolate Chocolate Espresso Torte w/ berries and Melba Sauce NOTE: A vegetarian meal choice is available; if you would like this, please let us know when you order your tickets. -- At 5:00 PM on Friday afternoon there will be a special showing of the IMAX movie Space Station. This movie is approximately 47 minutes long and contains about 4 minutes of amateur radio contacts between school children and the International Space Station. The IMAX theater is located in the museum building off the main lobby area. Attendees at the movie will be able to go to the banquet at 6:00 PM when the doors open about 10 minutes after the movie is over. The lobby contains restrooms, telephones and some seating. At least 50 people must sign up for the movie in advance. Reservations are required -- to place yours, call the museum IMAX theater on (937)-253-IMAX. Adults are $6.00, seniors are $5.50, and students 8 through college 22 (student ID required) are $4.50. ___ tapr-announce mailing list NOTE: This list includes all addresses currently subscribed to any TAPR mailing list. Please don't try to manually unsubscribe from this list; it won't work. If you unsubscribe from all other TAPR mailing lists, you will automatically be unsubscribed from this one. The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php---BeginMessage--- Joint TAPR/AMSAT Banquet at Dayton 2007 For many years, AMSAT and TAPR have held competing Hamvention dinners on Friday evening. Given the tremendous overlap in membership and interest between the two groups, this has always required tough choices. We're pleased to announce that this year, AMSAT and TAPR will be holding a joint dinner, and it will be at a great venue -- the Air Force Museum. Here are the details: Dinner Under the Wings will be held Friday evening May 18,2007 at the Air Force Museum in Dayton, OH in conjunction with the 2007 Dayton Hamvention. The doors open at 18:00 with a cash bar and appetizers in the Air Power Gallery (World War II). The buffet dinner will be served at 19:00 in the Cold War area. Following a few announcements and a short presentation you will be free to roam the museum. Price for the dinner is $35.00 per person and includes appetizers, salad, meal, dessert, coffee, iced tea, tax and gratuity. See http://afmuseum.com/ or http://www.nationalmuseum.af.mil/ for information about the museum. The museum will close at 22:00 and everyone must be out of the museum by then. Reservations are required and can be purchased from TAPR -- go to http://www.tapr.org/dayton.html for more details. There will be no ticket sales at the TAPR booth this year, and sales will close on Monday night, May 14, 2007 to allow us to give the museum a count on Tuesday. There may also be a special showing of the IMAX movie Space
[digitalradio] 2007 ARRL/TAPR Digital Communications Conference issues call for papers
* 2007 ARRL/TAPR Digital Communications Conference issues call for papers: Technical papers are solicited for presentation at the 26th annual ARRL/TAPR Digital Communications Conference (DCC), Friday-Sunday, September 28-30, in Hartford, Connecticut. Papers will also be published in the Conference Proceedings. Authors do not need to attend the conference to have their papers included in the Proceedings. The submission deadline is July 31. The ARRL/TAPR Digital Communications Conference is an international forum for technically minded radio amateurs to meet and present new ideas and techniques. Paper/presentation topic areas include -- but are not limited to -- software defined radio (SDR), digital voice, digital satellite communication, digital signal processing (DSP), HF digital modes, adapting IEEE 802.11 systems for Amateur Radio, Global Positioning System (GPS), Automatic Position Reporting System (APRS), Linux in Amateur Radio, AX.25 updates and Internet operability with Amateur Radio networks. Submit papers to Maty Weinberg, KB1EIB, ARRL, 225 Main St, Newington, CT 06111 or viae-mail [EMAIL PROTECTED]. Papers will be published exactly as submitted, and authors will retain all rights. ARRL will provide additional information on the 2007 DCC as it becomes available. It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/
Re: [digitalradio] Re: Bad PSK signals ?
I from the original Thirlmere area. On 3/10/07, Brad [EMAIL PROTECTED] wrote: -- *From:* digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] *On Behalf Of *Andrew O'Brien A ZL called a VK for advice ! What is the world coming to ? Just some big brotherly advice. Andy K3UK (from near Thirlmere) Hmm, I would expect better signals from you! Brad VK2QQ actually in Thirlmere. _,_._,___ -- Andy K3UK Skype Me : callto://andyobrien73 www.obriensweb.com
RE: [digitalradio] Re: Bad PSK signals ?
And I will be visiting that QTH in about 6 weeks! _ From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Andrew O'Brien Sent: Sunday, 11 March 2007 3:43 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Bad PSK signals ? I from the original Thirlmere area. On 3/10/07, Brad thirlmereflyer@ mailto:[EMAIL PROTECTED] exemail.com.au wrote: _ From: digitalradio@ mailto:digitalradio@yahoogroups.com yahoogroups.com [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] com] On Behalf Of Andrew O'Brien A ZL called a VK for advice ! What is the world coming to ? Just some big brotherly advice. Andy K3UK (from near Thirlmere) Hmm, I would expect better signals from you! Brad VK2QQ actually in Thirlmere. _,_._,___ -- Andy K3UK Skype Me : callto://andyobrien73 www.obriensweb. http://www.obriensweb.com com
