RE: [digitalradio] Re: ROS back bigger and better !
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of k4cjx Sent: Sunday, August 29, 2010 2:12 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: ROS back bigger and better ! Amazing that one thinks that 1 percent can cause any type of difference, anywhere, especially on the Phone bands. When that 1 percent deploys unattended stations that transmit without first checking to see if the frequency is in use, they can create havoc far out of proportion to their fraction of ham community. Regulation by bandwidth and not by mode seems to be working everywhere that it is allowed. under a bandwidth regulatory environment, there is no phone band. True, if ops generally have the courtesy to not QRM existing QSOs. Those who rudely deploy unattended stations without competent busy frequency detectors are what make regulation by bandwith unacceptable. BTW, it wasn't winlink that wanted anything, it was the ARRL who wrote the proposal. There were flaws in it, but it was headed in the proper direction. it will return as we move toward a digital future. The ARRL withdrew its regulation by bandwidth proposal because it had no effective response to the factual assertions that this proposal would greatly expand the frequency range accessible to unattended stations without providing any means of ensuring that such stations would not QRM existing QSOs. When those who deploy unattended stations upgrade them to rarely QRM existing QSOs (emergency conditions excepted), regulation by bandwidth will become possible. 73, Dave, AA6YQ
RE: [digitalradio] Re: ROS back bigger and better !
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of John B. Stephensen Sent: Sunday, August 29, 2010 4:29 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: ROS back bigger and better ! The ARRL response was that the final proposal retained the existing automatic subands. My recollection is that a flurry of desperate activity preceded the ARRL's retracting its proposal; if part of that flurry included a modification that would have retained the automatic sub-bands, I don't recall seeing it. 73, Dave, AA6YQ - Original Message - When that 1 percent deploys unattended stations that transmit without first checking to see if the frequency is in use, they can create havoc far out of proportion to their fraction of ham community. Regulation by bandwidth and not by mode seems to be working everywhere that it is allowed. under a bandwidth regulatory environment, there is no phone band. True, if ops generally have the courtesy to not QRM existing QSOs. Those who rudely deploy unattended stations without competent busy frequency detectors are what make regulation by bandwith unacceptable. BTW, it wasn't winlink that wanted anything, it was the ARRL who wrote the proposal. There were flaws in it, but it was headed in the proper direction. it will return as we move toward a digital future. The ARRL withdrew its regulation by bandwidth proposal because it had no effective response to the factual assertions that this proposal would greatly expand the frequency range accessible to unattended stations without providing any means of ensuring that such stations would not QRM existing QSOs. When those who deploy unattended stations upgrade them to rarely QRM existing QSOs (emergency conditions excepted), regulation by bandwidth will become possible. 73, Dave, AA6YQ
RE: [digitalradio] TAPR/ARRL DCC conference.
Will there be a session on retrofitting WINMOR's excellent busy frequency detector into Winlink PMBOs? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Rick Muething Sent: Thursday, August 19, 2010 10:06 AM To: win...@yahoogroups.com; winlink_programs_gr...@yahoogroups.com; mars_winl...@yahoogroups.com; digitalradio@yahoogroups.com Cc: 'Steven Bible'; 'Victor Poor' Subject: [digitalradio] TAPR/ARRL DCC conference. All, Just a reminder to those interested in digital radio and WINMOR. Vic Poor, W5SMM and I will be giving papers on RMS Express and WINMOR at this year's TAPR/ARRL DCC conference http://www.tapr.org/dcc.html Sept 24-26 in Portland, OR. I will also be giving a 4 hour short course tutorial Sunday morning on DSP which includes a CD handout (PowerPoint and .pdf), sample DSP software and evaluation DSP tools. I believe TAPR/ARRL also plan to make the CD available after the conference. I look forward to meeting any of you that are attending and put a face to the emails we've exchanged! Vic and I plan to have some demo's set up for RMS Express, WINMOR and a new keyboard QSO protocol V4. I have attended many of the DCC conferences and always found them interesting and a great source of information, inspiration and ideas. 73, Rick Muething, KN6KB
RE: [digitalradio] TAPR/ARRL DCC conference.
I suggested this to Rick a few months ago; he thought it worthy of consideration. 73, Dave, AA6YQ -Original Message- From: Victor Poor [mailto:vp...@att.net] Sent: Thursday, August 19, 2010 5:02 PM To: 'Dave AA6YQ'; digitalradio@yahoogroups.com; win...@yahoogroups.com; winlink_programs_gr...@yahoogroups.com; mars_winl...@yahoogroups.com Cc: 'Steven Bible' Subject: RE: [digitalradio] TAPR/ARRL DCC conference. Dave. We haven't used PMBOs in years. Perhaps you are thinking of RMS Pactor? Using the WINMOR busy detector with Pactor seems unlikely but we can talk about it at the conference if you are going to be there. Vic, W5SMM From: Dave AA6YQ [mailto:aa...@ambersoft.com] Sent: Thursday, August 19, 2010 4:48 PM To: digitalradio@yahoogroups.com; win...@yahoogroups.com; winlink_programs_gr...@yahoogroups.com; mars_winl...@yahoogroups.com Cc: 'Steven Bible'; 'Victor Poor' Subject: RE: [digitalradio] TAPR/ARRL DCC conference. Will there be a session on retrofitting WINMOR's excellent busy frequency detector into Winlink PMBOs? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Rick Muething Sent: Thursday, August 19, 2010 10:06 AM To: win...@yahoogroups.com; winlink_programs_gr...@yahoogroups.com; mars_winl...@yahoogroups.com; digitalradio@yahoogroups.com Cc: 'Steven Bible'; 'Victor Poor' Subject: [digitalradio] TAPR/ARRL DCC conference. All, Just a reminder to those interested in digital radio and WINMOR. Vic Poor, W5SMM and I will be giving papers on RMS Express and WINMOR at this year's TAPR/ARRL DCC conference http://www.tapr.org/dcc.html Sept 24-26 in Portland, OR. I will also be giving a 4 hour short course tutorial Sunday morning on DSP which includes a CD handout (PowerPoint and .pdf), sample DSP software and evaluation DSP tools. I believe TAPR/ARRL also plan to make the CD available after the conference. I look forward to meeting any of you that are attending and put a face to the emails we've exchanged! Vic and I plan to have some demo's set up for RMS Express, WINMOR and a new keyboard QSO protocol V4. I have attended many of the DCC conferences and always found them interesting and a great source of information, inspiration and ideas. 73, Rick Muething, KN6KB
RE: [digitalradio] sound card manager software
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Hal Sent: Tuesday, August 10, 2010 9:10 PM To: DigitalRadio Subject: [digitalradio] sound card manager software To The Group: The sound card manager software is about all I can think to call this program. It would allow you to set up different settings for each program you use with your soundcard and not have to constantly change mixer settings. For an example, you run Echolink,click this program and the Echolink settings come up. You run MultiPsk and those preset settings were saved and named and your ready to run the MultiPsk program. Ect etc. I have a new AMD/Dual Core Desktop machine running XP Pro. 3GB ram,1GB Radeon Card, 2.7 speed, 500 GB HD,multi-monitor set up. I run DxLab suite,N1MM/Mtty,MultiPsk,Echolink and work SSB on morning chats. I have a AFSK interface for my digital modes and logging. Why, you ask? Because several weeks ago on 40 meter chat the group said you have a Bad Feed back in the audio. I was at a loss. I had been running two NetVista desktops. One for digital programs, the other for SSB and Echolink. It was no problem because they ran independent of one another. Now I have a Workhorse AMD Machine and it won't function the way I want it to. I learned that by disconnecting the speaker line from the new AMD machine, no feedback into SSB chats.I could mute the line-out, no feedback. Now I go into to set up the Multipsk and I have to reset the soundcard settings. If I want to play music on the New machine the same thing occurs. That is the problem. It may have been on one of the other digital groups , but I can't find the source for this. A Ham suggested this and another program or two to a digital group ( I am on most of them). I had it saved but took a hit on the Laptop/Vista machine and had to rebuild it from scratch and cannot find the replies(late last year) that were sent. Nor can I find it by researching the groups. I know, from watching this reflector that many of you run the same programs I run. So I thought I would start here. A Ham will know what I need and why I need it to function in a certain way. I hope you can help. Any help or suggested programs would be appreciated. Thanks, 73 Try QuickMix: http://www.ptpart.co.uk/quickmix/ 73, Dave, AA6YQ
RE: [digitalradio] Re: Direct RTTY Generation
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of IMR Sent: Thursday, August 05, 2010 6:04 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Direct RTTY Generation In your MMTTY folder (the one that contains the file mmtty.exe), is the file extfsk.dll present? No. n fact that file is nowhere to be found on the machine at all :-( The standard MMTTY installation package includes EXTFSK.dll So guess I need to go back to your download page and find it. I sent you a copy via email. Its all getting too complicated - the design was a request for a simple Tx for beginners that wasn't yet another CW QRP transmitter - and I was hoping RTTY would be as dead-simple to get going as it used to be back in the days of yore. Clearly not. It might even be easier to wrirte my own simple RTTY Tx terminal in VB6. Waggling the TXD line using the MSComm1.Break = True/False function will do the job if timing can be assured. Travelling to Alpha Centauri will be easy if the Warp Drive can be assured. 73, Dave, AA6YQ
RE: [digitalradio] Re: Direct RTTY Generation
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of IMR Sent: Wednesday, August 04, 2010 9:09 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Direct RTTY Generation OK Tnx... found the COM port output facility and got it working on a Desktop with a proper COM1. But when I tried a USB COM port - as suspected it wouldn't work directly. On trying the EXTFSK option, it just comes back with a message that says Can't Configure EXTFSK Downloaded the latest MMTTY version 1.66G, just to make sure. In your MMTTY folder (the one that contains the file mmtty.exe), is the file extfsk.dll present? What I'm not sure about, if EXTFSK is set as the data output option, how does the software know which USB Comport is to be used for its output of the data - if that makes sense :-) When you configure MMTTY to use EXTFSK for FSK output, an EXTFSK window appears that lets you select the serial port, as well as the serial port pin (TxD, RTS, DTR) that will be used to generate the FSK signal. 73, Dave, AA6YQ
RE: [digitalradio] Direct RTTY Generation
AA6YQ comments below. -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of AC TALBOT Sent: Tuesday, August 03, 2010 5:46 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Direct RTTY Generation A back-to-basics question for once... Is there any modern RTTY datacomms software that gives a single wire digital output for driving an FSK transmitter? Looked in the MultiPSK and MMTTY setup menus and nothing. MMTTY provides this FSK signal via the TxD pin of the serial port specified in the PTT FSK panel on the Setup MMTTY window's TX tab. Since using this signal requires a serial port capable of 45 baud operation, which some USB-to-serial-port-adaptors can't do, you can set the PTT FSK panel's port selector to EXTFSK, which displays a window that lets you configure the generation of an FSK signal on a serial port's RTS or DTR pins. In this latter configuration, the timing of the FSK signal is software-generated, and thus less accurate than that generated by a 45 baud serial port. Digital mode applications that use MMTTY as their RTTY Engine -- WinWarbler, HamScope, etc. -- thus offer this capability. While I realise there may be little call for such a one-wire drive now Not true! Modern transceivers provide RX filtering for RTTY that is only availalble when the transceiver is operated in RTTY mode, thus requiring the FSK signal when transmitting. Icom's ic-7200, ic-7600, ic-7700, and ic-7800 all provide a very nice twin-peak filter that is only available in RTTY mode. 73, Dave, AA6YQ
RE: AW: AW: AW: [digitalradio] ROS v 4.8.X not spamming cluster
Thanks, Laurie. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Laurie, VK3AMA Sent: Sunday, July 25, 2010 3:08 AM To: digitalradio@yahoogroups.com Subject: Re: AW: AW: AW: [digitalradio] ROS v 4.8.X not spamming cluster Yes Dave, Apart from my test PC virus/malware protection, whenever there is a change in an executable or dll I run them through an online scanner (20MB file limit) here http://virusscan.jotti.org/en/ It runs the submitted file through 19 different scanners, with the occasional false-positive on one or two. Results of the scans are shared with the anti-virus companies. The site generates a permalink for each file that allows you to distribute the scanning results to whomever. Just ran the 3 executables through the site Cluster.exe http://virusscan.jotti.org/en/scanresult/7142b3c4c3e3076d5f55aa826a272678a67d1cbb PSKReporter.exe http://virusscan.jotti.org/en/scanresult/b8e275b738f1634bcc24fa081b1a83eb27e1289c ROS v4.8.4 Beta.exe http://virusscan.jotti.org/en/scanresult/e6e6238fb976a46d4db4dae564d59c5f2757ab73 de Laurie, VK3AMA On 25/07/2010 1:29 PM, Dave AA6YQ wrote: Has anyone checked to see whether the ROS code contains a keylogger, trojans, or a rootkit? 73, Dave, AA6YQ
RE: AW: AW: AW: [digitalradio] ROS v 4.8.X not spamming cluster
Has anyone checked to see whether the ROS code contains a keylogger, trojans, or a rootkit? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of KH6TY Sent: Saturday, July 24, 2010 7:37 PM To: digitalradio@yahoogroups.com Subject: Re: AW: AW: AW: [digitalradio] ROS v 4.8.X not spamming cluster Jose uses Cluster Auto-Spots to advertise his software. The more spots, the more it appears to be a popular mode to the uninformed Cluster User. To me, this attempted deception has been obvious ever since the issue of any auto-spots came up. Isn't there any honesty at all possible with this author! :-( This wholesale abuse of ham radio traditions and spamming clusters, etc. by this author, is just not acceptable, and to my knowledge has never been done before. 73, Skip KH6TY
QRE: AW: AW: [digitalradio] Operating ROS In USA
The ARRL withdrew its regulation by bandwidth instead of mode proposal before the FCC responded. This proposal generated a lot of commentary from the US amateur community, all of which remains available online. If you review these, you will find that most comments opposing the proposal cited the QRM caused by unattended digital stations, whose permitted range would have been dramatically increased had the proposal been adopted. Opposition to this proposal was anti-QRM, not anti-wide. An unattended station running a narrow mode without an effective busy frequency detector is as offensive as an unattended station running a wide mode without an effective busy frequency detector; neither belongs on the amateur bands. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of John Becker, WOJAB Sent: Tuesday, July 20, 2010 2:10 PM To: digitalradio@yahoogroups.com Subject: Re: AW: AW: [digitalradio] Operating ROS In USA At 12:19 PM 7/20/2010, you wrote: Do you know if any US amateurs are raising a Petition for Rulemaking to move to regulation by bandwidth instead of mode ? Trevor, We in the USA have been down this path before. And every time the FCC has said the same thing. I really don't know just where you are trying to go but it seems that it is again an anti wide rant. If it is you can save the rest of us from it. John, W0JAB
RE: [digitalradio] Re: ROS back bigger and better !
Enough of this juvenile garbage. Amateur radio in the US is governed by regulations to which we agree to abide when we are granted a license. These regulations are particularly important in amateur radio because we all share one set of frequencies. These regulations are not perfect; in particular, the regulation constraining Spread Spectrum usage is insufficiently precise, and as a result precludes the use of techniques on HF that the FCC would likely approve given a competent exposition. In this situation, an amateur radio operator interested in using these techniques on HF should hold off until the regulation has been changed to permit their use, contributing to or leading the effort to change the regulation if capable. There is absolutely nothing wrong with asking the FCC for their view of whether a particular mode or technique is legal under the current regulations. The knowledge that many amateurs are confused about what constitutes Spread Spectrum should if anything make the FCC more receptive to a proposal to clarify the regulation. The claim that asking the FCC a question can kill amateur radio is amazingly ridiculous; asking the FCC a question is more likely to teleport the Loch Ness Monster into your swimming pool than kill amateur radio. Unlike broadcast television stations, amateur radio operators don't individually negotiate their licenses with the FCC. Thus the comments below regarding regulations being trumped by station permits negotiated by attorneys is completely irrelevant. The nasty name-calling that appears below and in previous posts today is flat-out unacceptable. Were I moderator of this group, the offending parties would be long gone. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of W2XJ Sent: Monday, July 19, 2010 10:10 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: ROS back bigger and better ! Skip if you call this a regulation, I agree with Garret. It is a misguided one and a victim of unintended consequences. The whole discussion is stupid and you, Skip, are too anal retentive. I work in broadcast and there are many un-updated FCC regulations that the commission subsequently licenses in a manner contrary to their own rules. Look at the FCC definition of translator and then tell me how under the letter of the law how AM and HD-2 and HD-3 stations can legally use that service. Regardless stations get legal permits every day. Washington is a town of double and denial speak, the rules mean next to nothing in many cases. What your communications attorney can wring out of them is all that counts. It is whiners like you that damage the system. Ham radio is supposed to be self regulating which means please do not disturb the FCC. I guess you still do not get it. People like you will kill this hobby. On 7/19/10 8:56 PM, KH6TY kh...@comcast.net wrote: Just use common sense.. Garrett / AA0OI Common sense says follow the regulations, because they were made for the benefit of everyone, and not just for what a few who would like to do what they wish without regard for others that want to use the bands. Regulations are not guide lines - they are LAW for the benefit of all. Band plans are guide lines, not regulations. What may seen nit picking to you may seem necessary to others. The regulations are a great balancing act to both protect and enable as many users to be treated as fairly as possible. 73, Skip KH6TY On 7/19/2010 8:42 PM, AA0OI wrote: The rules and regulations are a guide line they were never meant to be written on 2 stone tablets and prayed to on the seventh day.. if everyone followed every little nit picking rule and regulation the world would come to a stand still.. (the government told Wilbur and Orville that they were forbidden to fly) I'm sure everyone drives the speed limit too.. Just use common sense.. Garrett / AA0OI From: John Becker, WØJAB w0...@big-river.net To: digitalradio@yahoogroups.com Sent: Mon, July 19, 2010 6:03:07 PM Subject: Re: [digitalradio] Re: ROS back bigger and better ! The hell with the rules and law, right Garrett? John, W0JAB At 05:48 PM 7/19/2010, you wrote: What is absurd is that its a fight in the first place.. do you ever just back up and look at what is being said?? Your all acting like this is life or death..ITS NOT..I have been using it all along... NO FCC at my door,, NO FBI,, NO KGB.. You are all fighting for something that no one cares about.. Cross all the T's and Dot all the I's--- but the key is NO ONE is looking to see if its been done.. And ANYONE who puts Our Freedom and Absurd in the same sentence needs to move to Iraq.. see if they agree with you ! Garrett / AA0OI12c1104.jpg
RE: [digitalradio] RE-NEW LICENSE
I just renewed my license via ULS, as described below. I had an FRN, but no password, so I requested a password on Monday 7/12 and received one immediately via email. After logging in, I applied for renewal, which took less than a minute. Yesterday morning, I logged in to check the status of my renewal, and found that it had been issued on 7/13; a hardcopy arrived by postal mail yesterday afternoon. I don't see how this process could be any simpler... 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of J. Moen Sent: Saturday, July 17, 2010 1:30 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] RE-NEW LICENSE John, There is an FCC Registration Number (FRN) associated with your call. You need the FRN and a password to logon to FCC's Universal Licensing System (ULS). Go to http://wireless2.fcc.gov/UlsApp/UlsSearch/searchLicense.jsp and search for your callsign. It's there, of course, and so is your FRN. Write that down. Before you go any farther, you should know the FCC database says your call expires 7/31/2011. So you have a year to do this, and as I recall, you cannot renew until there are 90 days to go. When you do the renewal process next year , you'll need your password. If you've done this before in the past, it may be burried in your files. However, it is more likely that when you got your license, the VE did all the FCC paperwork for you, and you were automatically assigned an FRN but you never set up a password. So you will need to set one up. Go to https://wireless2.fcc.gov/UlsEntry/licManager/login.jsp - enter your FRN and click on Forgot your password? Contact Tech Support. First you'll need to Set Personal Security Question. I'd recommend you get all that set up now, including a password, then save the FRN and password in your files so it will be easy to log on and renew when it is time. There's a simpler alternative. The major VECs like ARRL and W5YI Group offer renewal services for a small fee. ARRL's is described at http://www.arrl.org/call-sign-renewals-or-changes The W5YI Group's process is at http://www.w5yi.org/page.php?id=87 You've got plenty of time, the way I read the FCC database. Jim - K6JM - Original Message - From: Chris Robinson To: digitalradio@yahoogroups.com Sent: Saturday, July 17, 2010 9:28 AM Subject: Re: [digitalradio] RE-NEW LICENSE I use the free method of the FCC.http://wireless.fcc.gov/uls/index.htm?job=home On Sat, Jul 17, 2010 at 11:18 AM, John Becker, WØJAB w0...@big-river.net wrote: What does one have to do to re-new their ticket on-line now? Been so lone I forgot http://www.obriensweb.com/digispotter.html Chat, Skeds, and Spots all in one (resize to suit) Facebook= http://www.facebook.com/pages/digitalradio/123270301037522 Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) * To change settings via email: digitalradio-dig...@yahoogroups.com digitalradio-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: digitalradio-unsubscr...@yahoogroups.com * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [digitalradio] Re: Random data vs Spread Spectrum
The definition of Spread Spectrum in 97.3(c)8 rests on the phrase using bandwidth-expansion modulation emissions. This clearly lacks the technical precision required - for digital mode developers to know what techniques can and can not be incorporated in modes used by US stations (e.g. pseudo-random coding, as Alan points out below) - for US digital mode users to determine if and on what frequencies an accurately-documented mode can be used A constructive response to the Ros debacle would be to propose improved language for 97.3(c)8 that is clear and unambiguous. Assuming the proposed definition does not increase the likelihood of causing harmful interference or permit encrypted communications (concerns implicit in 97.311), the FCC would likely welcome a change that improves our ability to abide by the regulations without consuming their scarce resources. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Tuesday, July 13, 2010 1:22 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Random data vs Spread Spectrum graham787 wrote: So, if bits are added to the transmit waveform that are not performing a function of helping to re-create an error free replication of the input data, it meets my test as spread spectrum. If the symbols in the transmit waveform cannot be predicted by the previous sequence of bits over time at the input, it also would meet my test as spread spectrum. To reiterate on this point, just because the symbols of the transmit waveform are changing during an unchanging input, does not imply spread spectrum. Instead, they may well be the result of a defined randomizer process followed by multiple layers of FEC and modulation coding. While I do not support ROS in any form, I think the group is on a very slippery slope here with well intentioned but misinformed definitions tests that may haunt us in the future! Just the fact that data is randomized does not define SS. There has to be a spreading factor, which has some rough definitions based on practical applications, but is not addressed in any FCC definitions. Skip's well intentioned but overly simplistic test of looking at the bit stream is not enough to define SS. There are many legitimate reasons to code data resulting in a pseudo-random fashion that have nothing to do with SS! The most common is coding so the transitions between bit's can easily be detected even in noise. It's a problem when sequential bits look the same. You can also factor in FEC. There are many, many writeups on convolutional encoding that go into this. (Viterbi reed-solomon are in wide usage) But it's also useful to spread the energy out in the bandwidth and avoid sidebands created by single tones of long duration. There are multiple modem/modes which do this, some in very wide usage. So yes, SS (really DSSS) is pseudo-random. But not all pseudo-random coding is SS, and we should not be proposing that as a litmus test! The real test should be: - direct or BPSK modulation via a pseudo-random code in addition to any coding for FEC (convolutional, etc) - A spreading factor significantly higher than the original data rate The 2nd item is the key part, and it's listed but virtually never quoted in this group, but is listed in nearly all the SS definitions. Nor is it addressed in the FCC part 97 rules. It's not enough that the bandwidth is higher than the data rate would imply, as nearly all modes with FEC would fail that by definition. The key is the significantly wider aspect, also referred to in ITU/IEEE definitions as typically orders of magnitude greater than the data rate. And this is why many engineers question whether any SSB generated mode could be real SS. ROS only did it by having the original data rate lower than the SSB bandwidth. About the lowest commercial DSSS implementations use a spreading factor of 16:1, and that's for consumer grade without noise performance concerns. Most DSSS implementations in the real world use spreading factors of 100 or greater, as that's when you start seeing significant noise recovery improvements. In DSSS, the processor gain which improves noise resilience is directly related to the spreading factor. I've posted multiple definitions from the ITU IEEE in the past for DSSS. Wikipedia, which has some good information, does not constitute a formal definition like the ITU IEEE references do. (Part of the reason that wikipedia is not admissible as sources for college research papers). There is no shortage of formal definitions, we should not have to invent our own. There are also some very readable definitions from mfg's for their DSSS components. Like this one: http://www.maxim-ic.com/app-notes/index.mvp/id/1890 So ROS (RIP) is very odd in this aspect, as it's nowhere near conventional DSSS implementations in it's spreading factor, yet is higher than the spreading seen
RE: [digitalradio] Re: [digital radio] Re: Random data vs Spread Spectrum
When a regulation is based on a vague phrase like using bandwidth-expansion modulation emissions, the FCC should *expect* to hear from amateurs trying to determine whether or not a mode is legal. There are certainly many situations where amateurs can indeed be expected to sort it out themselves; this isn't one of them. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of W2XJ Sent: Tuesday, July 13, 2010 4:35 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: [digital radio] Re: Random data vs Spread Spectrum The creator of ROS does not present himself as a very nice or honest person but I also believe there are cultural and language issues that add to the problem. Before all this started several months ago, I did not believe the initial presentation that it was really spread spectrum but rather something written by someone with a bad grasp of the English language. That being said, Skip, you are also misrepresenting the situation by stating the FCC made an analysis. Read the documentation and it is clear they made a fairly non committal statement based on the published material. The FCC does not like being involved in such matters. This is like the Dstar controversy a few years back when an FCC official publicly told hams at Dayton that if they were qualified to hold a license they should be able to sort it out themselves. The commission will not do the thinking that hams themselves should be doing for them selves. Please keep the sandbox fights away from the FCC it will ultimately destroy the hobby. With the hunt for more spectrum to sell be careful or there may not be any frequencies above 222 MHZ to even worry about spread spectrum. On 7/13/10 3:23 PM, KH6TY kh...@comcast.net wrote: Rein, I said I would not comment further on ROS, but look at it in perspective. The author defined ROS as spread spectrum and produced a two page document to that effect. He is the only one who knows for sure if it is spread spectrum or not. When it was posted that spread spectrum was not legal below 222 Mhz, he conveniently (for his benefit) tried to redefine ROS as FSK, in an apparent attempt to change the FCC opinion, which originally was based on his own two-page declaration, which he wanted us to believe. The FCC then made their own analysis and concluded it was not FSK but truly spread spectrum. This was communicated to us by the ARRL as is usually the case. The author, if he would have disclosed his code, could have proven whether or not the randomization is for spread spectrum purposes or for some other reason, but he steadfastly refused to disclose the code, which would either have resulted in it being OK for us to use, or prove it was truly FHSS. Perhaps he decided to try and bluff the FCC because it would be determined, on the basis of his code, to really be FHSS, in agreement with his first description, and in disagreement with the second description he wrote, obviously just to try to get approval. It is just not reasonable to think that a person of his ability, as the author of the software, could make such a huge mistake in his first characterization of ROS as spread spectrum and then completely revise the characterization as something else which he knew would be usable by US hams. You can imagine how the FCC feels about that attempted deception, and to top it off, he posts a phoney statement of FCC approval besides! I seriously doubt that the FCC is going to want to revisit the question, since the author simply cannot be believed. I met Dan Henderson at a hamfest right after all this happened and he had been in contact the FCC, and opined that it was highly doubtful that any further reconsideration would be done. The ONLY way for us to ever use ROS on HF is to petition the FCC to amend the rules to allow limited spread spectrum below 222 Mhz, citing enough good reasons why it will not harm existing operations of lesser bandwidth. Instead of constantly arguing that the FCC made a mistake, or we should interpret the rules as we wish they were, I suggest that either a petition be filed, or the code released to prove the author's contention that it is not spread spectrum. Of course the submitted code would have to be recompiled and tested to prove it is really the original code, and another attempted deception by the author. Understand that I am NOT against ROS, and never have been, even though I strongly dislike the author's behavior and suspect his motives. I would keep using it on HF if it were legal for me to do so. I do respect the FCC regulations, even those that I do not like, and follow them as best I can, because in the overall picture, they protect the weak from the strong for the benefit of everyone, until revised in a non-harmful way. This will be my (final) final word on this subject, so please do not ask me to comment any further. If you want
RE: [digitalradio] ROS are sending data from your PC
US operators that avoid ROS because it is illegal in the US are not zombies, they are simply abiding by the regulations that govern amateur radio operation here and thus protecting their licenses. The immature antics of Jose Ros are most likely the result of an over-driven ego untempered by any understanding of the social aspects of amateur radio. Hopefully, some wise Elmer will take Jose in hand and help him grow up to more constructively apply his obvious technical talent. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of rein...@ix.netcom.com Sent: Friday, July 09, 2010 2:59 PM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] ROS are sending data from your PC John, Why not give it a serious try? It's is worth getting to the bottom of this or perhaps not, Are we all becoming zombies? You are sort of accusing the author without really trying or proof. Some 3000 People on this reflector. Silence, silence. There has to be many on this board that can answer that question. If you do not want to show who you are. contact me of the reflector I will keep your input just between you and me. Don't want to be involved. Please let me just play. I am tired, don't bother me 73 Rein W6SZ -Original Message- From: John Becker, WØJAB w0...@big-river.net Sent: Jul 9, 2010 2:18 PM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] ROS are sending data from your PC I think many would like to have a answer once and for all on this issue if some have been banned from using the software. John, W0JAB digitalradio co moderator At 12:54 PM 7/9/2010, you wrote: Could this ROS discussion be taken offline or elsewhere? I expect others, like I, are sick of the rehashing. (And if you are sick please don't reply in support of this message - that would be as bad as the rehashing.) Andy?? - 73 - Rud Merriam K5RUD http://mysticlakesoftware.com/ http://www.obriensweb.com/digispotter.html Chat, Skeds, and Spots all in one (resize to suit) Facebook= http://www.facebook.com/pages/digitalradio/123270301037522 Yahoo! Groups Links
RE: [digitalradio] ROS are sending data from your PC
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of John Becker, WOJAB Sent: Friday, July 09, 2010 3:01 PM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] ROS are sending data from your PC And many are still looking for an answer of why some (at one point or another) was banned from using the program. John, no one but Jose knows why specific ops were banned from using his application. Empirically, one ham was added to the persona non grata list shortly after posting that he had asked the FCC whether or not ROS was legal. My callsign appeared on the list after I sought to verify with FCC personnel the claim on Jose's blog that the FCC had approved ROS for use by US amateurs -- a claim the FCC characterizes as both false and fabricated. Perhaps my promotion was motivated by some earlier perceived infraction, but its entirely irrelevant because ROS is not legal for use by US operators; it's like being put on the no use of aviation frequencies list. 73, Dave, AA6YQ
RE: [digitalradio] ROS are sending data from your PC
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of rein...@ix.netcom.com Sent: Friday, July 09, 2010 4:31 PM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] ROS are sending data from your PC Hi Dave, Let me ask your a question after assuring that the use of ROS world wide is increasing rapidly. We can ignore that, as most do, we can be mad about it, we can as US licensed radio amateurs say it does not concern us,it is not fair, etc etc. If there is such a list, I plan to make a real big stink about it. I am disappointed that John as a potential member on the list, does not want to research that. But then I can't force people. Have plenty idea;'s about doing that. But before starting such an action I like to know whether such a list still exists or not. Is that unreal? I don't know what you mean by unreal, but it's certainly a waste of time as far as you, W0JAB, or I am concerned. US operators can't use ROS on HF whether they're on the list or not. I tried to contact the ARRL just a few minutes ago and was given a go around, from one phone number to another, 20 minutes waiting. Friday afternoon in CT, with the Executive Chief Officer out of the country? Given that it represents the interests of US operators, you'll have a difficult time convincing the ARRL to do anything about a mode that US operators can't use on HF anyway. The IARU would be the more appropriate organization with which to raise this issue. Do not want to start here a flame war on the ARRL. But is this not the place to discuss issues related to digital modes? Yes it is. A digital mode with a list of banned calls? Certainly, though of course Andy K3UK has the last word on this. 73, Dave, AA6YQ
RE: [digitalradio] Busy detect screenshot for Winmor
I disagree. Being able to operate outside the automatic sub-bands is an incentive for operators to preferentially choose servers that include an effective automatic busy frequency detector and to keep that busy frequency detector enabled. We're in a deep hole dug by those who ran (and continue to run) servers (e.g. WinLink PMBOs) without busy frequency detectors. This has generated enormous frustration over the years, to the point where some operators now intentionally QRM such servers. This intentional QRM is as disgusting as running a server without a busy frequency detector, and provides a convenient excuse for server operators to continue avoiding or disabling busy frequency detectors. The first step in escaping from a deep hole is to stop digging. In our case, this means that 1. servers with effective busy frequency detectors enabled should be welcome across the full range of frequencies available to them as specified in the applicable regulations 2. the intentional QRM must stop 3. servers without busy frequency detectors (e.g. WinLink PMBOs) should immediately be retrofitted with effective busy frequency detectors -- a possibility that Rick KN6KB stated here a few months ago that he would investigate 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of KH6TY Sent: Sunday, June 27, 2010 9:25 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Busy detect screenshot for Winmor Thanks, Andy. Unless it is not impossible to disable busy detect, to answer your previous question about where to operate with Winmor, I personally think that Winmor frequencies should ALL be kept within the automatic subbands, since the tendency is going to be to disable it due to the uncertainty if there is malicious blocking or not. This way, busy detect can still be useful in enabling frequency sharing with other Winmor stations, and if someone disables busy detect, the effect on the rest of the hams will not be significant. This brings to mind the edict by Winlink that busy detect must not be enabled because of others trying to harm Winlink. It is highly unlikely that any malicious blocking will be done in the automatic subbands, because there is no reason to do so. The only blocking will be if the frequency is already in use by another mailbox. The recently reported problem with a PSKmail server still interfering with JT65 points up to another reason that ALL mailbox stations need to be in the same area, regardless of bandwidth. The more narrow the bandwidth, the easier it is to find a clear frequency there, so there is still an advantage to using a more narrow bandwidth. The frustration of being blocked too often if operating in the general use areas is, sooner or later, going to result in operator deactivation of the busy detection, especially as more and more Winmor mailboxes are set up. Before things get to that point, I think that it would be wise for early adopters, such as yourself, to set a good example by operating Winmor only in the automatic subbands and using the busy detection feature to more efficiently share frequencies there. 73, Skip KH6TY On 6/27/2010 8:46 AM, Andy obrien wrote: Skip (and anyone else interested), see the attached screenshot showing the Winmor server busy detect Andy K3UK
RE: [digitalradio] Busy detect screenshot for Winmor
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of KH6TY Sent: Sunday, June 27, 2010 2:07 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Busy detect screenshot for Winmor Dave, I realize you have championed the idea of a busy detector for a long time, but unless it cannot be switched off, it will eventually be switched off, and those mailboxes will be spread over the bands, since they are allowed to go anywhere RTTY can. I would be happy to see servers incorporate busy frequency detectors that cannot be disabled. However, adoption by server operators will require the elimination of intentional QRM. What is wrong with keeping narrow bandwidth servers with busy detectors operating at the high end of Winlink Pactor-III channels, since Pactor-III seldom reaches the highest speed level for very long and decreases bandwidth to suit the lower speeds? There are two reasons to encourage servers with effective busy frequency detectors to utilize available frequencies: 1. it provides an incentive for server operators to incorporate busy frequency detectors 2. it demonstrates to the broader community that servers with busy frequency detectors are as polite as human operators, which should reduce the rate of intentional QRM If a server operator is not yet confident in the effectiveness of the busy frequency detector included in his or her server, then using frequencies within the automatic sub-bands is good way to monitor the busy frequency detector's effectiveness and either gain the confidence that the detector works well enough to operate outside those sub-bands, or not. Your assumption is that Winmor servers and clients will always keep busy detect activated, but it has been shown that mailbox operators grow impatient to retrieve email, and if a channel is busy too often, will transmit anyway in an attempt to override the traffic already on the channel, even among servers of like kind. As I've said, it would be best if busy frequency detectors were permanently enabled -- but there will likely need to be progress on all sides before this happens. Just getting an effective busy frequency detector into every WinLink PMBO would be a huge positive step. Why not try the busy detector/busy operators in a place designed for other automatic stations and see how well the whole system works. That is my suggestion. Its my impression that the WinMOR busy frequency detector has been well-characterized as effective (going back to its original deployment in SCAMP), so its not clear to me why more evaluation is required. The longer we keep digging our hole deeper, the longer it will take to escape. 73, Dave, AA6YQ
RE: [digitalradio] Busy detect screenshot for Winmor
+++ More AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of KH6TY Sent: Sunday, June 27, 2010 7:02 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Busy detect screenshot for Winmor Its my impression that the WinMOR busy frequency detector has been well-characterized as effective (going back to its original deployment in SCAMP), so its not clear to me why more evaluation is required. More evaluation is required simply because it has not been tested in general use, so it may have been characterized as effective, but a full-blown use (in the subbands) will confirm that is characterization is correct. It will also show if there are people disabling the busy detector for reasons they deem necessary or convenient. +++ in the subbands is by definition not full-blown use. The safest way to find that out is to use it in the automatic subbands. This way, if it needs improvement, or people are disabling it, the least amount of harm to the busy detector reputation will be incurred, and potentially many less people will be angered that might otherwise retaliate and intentionally block. +++ WinMOR servers have been operational for months; not a single report of a WinMOR busy frequency detector failure has appeared here. Contrast that with ROS. There is no incentive NOT to keep the Winmor busy detector active - yet. +++ Are you saying that there has been no intentional QRM of WinMOR servers? If so, does the WinMOR community agree with you? So, there is no need to demonstrate to the broader community that it is already safe. PROVE that it is safe first, with a wider use (in the subbands), and if it is, then turn it loose into the wild. Just characterizing it as such on a limited beta test program with a few beta testers does not prove what will happen with wider usage. Keeping it in the unattended subbands can serve just as well as having Winmor mailboxes everywhere immediately, and if it turns out it truly is a good neighbor, then the use can be wider. I think Andy also feels it is too soon to operate his Winmor mailbox outside the unattended subbands. +++ As I've already said, individual operators should apply their good judgement; if they aren't yet confident in the busy frequency detector's effectiveness, then running their server within the automatic subbands is entirely appropriate. But when experience leads such operators to become confident, they should be free to venture out onto other frequencies to which they are by regulation entitled to use. 73, Dave, AA6YQ
RE: [digitalradio] Re: Individual software programs for various digital modes????
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of g4ilo Sent: Wednesday, June 16, 2010 11:47 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Individual software programs for various digital modes The disadvantage of using different programs instead of standardizing on one is that you lose the benefits of computer logging. I guess the OP maintains a paper log so he isn't concerned with that aspect. You can make digital mode QSOs with DM780, FLDigi, MixW, MMSSTV, MMTTY, MMVARI, MultiPSK or WinWarbler while logging QSOs to DXKeeper, using either Commander or HRD for transceiver control. See http://www.dxlabsuite.com/download.htm#Bridges, Gateways, and Extenders 73, Dave, AA6YQ
[digitalradio] RE: [SDRlist] Digital ID Skimmer mock-up
http://www.dxlabsuite.com/winwarbler/Heard.jpg Entries can be sorted by clicking a column header (like a spreadsheet). - Add a column to indicate mode. - Provide filtering by mode (e.g. only show Olivia and Contestia entries) 73, Dave, AA6YQ -Original Message- From: sdrl...@yahoogroups.com [mailto:sdrl...@yahoogroups.com]on Behalf Of Andy obrien Sent: Wednesday, May 12, 2010 6:37 AM To: digitalradio; sdrl...@yahoogroups.com Subject: [SDRlist] Digital ID Skimmer mock-up See http://www.obriensweb.com/digidskimmer.htm for a crude mock-up of how a digital mode skimmer could look , The concept would be ... digital mode applications that already use RS ID detect (Fldigi, Multipsk, DM780, Pocketdigi) expand their current displays of received RS IDs in to something that provides more interactive information that is clickable so you can QSY to the particular frequency, sortable by mode of frequency, and color coded for easier visual reference. Call ID (a very useful feature within Multipsk) could also be part of this and , when used, the call sign of the station that ID's would be displayed. This concept would support wider range frequencies provided by an SDR, just as CW Skimmer does. Anyone have any improvements on this idea ?
RE: [digitalradio] Re: Opposing 60M proposal
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of David Little Sent: Tuesday, May 11, 2010 8:35 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Opposing 60M proposal You further reinforce my position; the amateur radio service is not going to support long haul emcomm infrastructure. It doesn't matter what color you paint it. If the amout of wasted envy spent on lamenting P3 was devoted to promoting the Amateur Radio Service; then it may have a chance of surviving a few more decades. The others who take a serious look at your stance, and the credibility the ARS stands to lose have a good idea about who is destroying the villiage. Of course I have heard the same complaints about WINMOR; I live on planet Earth. I have not seen a single complaint about WinMor on this reflector, or anywhere else on the internet. If you have, please post a couple of URLs. By the same token, if we had to resort to smoke signals, the same group would be protesting unattended operation of fire. To me, the discussion is a passing amusement. I don't anticipate the need to generally waste time or effort trying to use Amateur Radio Service spectrum for any useful long haul communications in an emergency; except voice when I may need a larger audience in an affected area. The SATERN nets in the first week of the Haiti response brought out the jammers. They had the same hatred for sustained net operations as the anti P3 crowd have for effective emcomm infrastructure. The end result is the same; ineffective interference... Long Haul Emcomm has migrated to NTIA spectrum. I am reaping a great crop of effective communications there. How well did your crop come in?? Quite well, thanks: some new ones on 160m and 80m, 3500+ QSOs in 2 weeks as 8P9RY, some great digital-mode rag chews, a post here from Rick KN6KB saying that he'd consider backfitting the WinMor busy frequency detector into WinLink PMBOs, and lots of fun adding SDR Console support to DXLab. 73, Dave, AA6YQ .
RE: [digitalradio] Why does the ARRL continue to push for Pactor III support...
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of John Becker, WOJAB Sent: Monday, May 10, 2010 12:50 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Why does the ARRL continue to push for Pactor III support... I can clearly see that this anti Pactor rant will Never end. It's an anti-Winlink without busy frequency detection rant, John. 73, Dave, AA6YQ
RE: [digitalradio] Re: Unattended narrow mode transmission protection
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Rick Muething Sent: Sunday, April 11, 2010 7:11 AM To: digitalradio@yahoogroups.com Cc: 'Vic Poor' Subject: [digitalradio] Re: Unattended narrow mode transmission protection Dave, Using the WINMOR busy detector for Pactor sounds like a workable idea. The WINMOR busy detector hasn't yet been integrated into other WL2K Pactor Servers but it could be. The basic WINMOR TNC application (the virtual TNC) has the function but would need to be integrated into the Pactor driver for the SCS. When Vic gets back from vacation I'll talk to him about this and when we might be able to do that. Rick and Vick, that would be a huge positive step. If there is any way I can help with this, please let me know. 73, Dave, AA6YQ .
RE: [digitalradio] Re: Unattended narrow mode transmission protection
Thanks, Rick. I have suggested in the past that your SCAMP/WINMOR channel busy detector could be inexpensively back-fit into WinLink PMBOs. Has anyone taken a look at this? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Rick Muething Sent: Saturday, April 10, 2010 8:30 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Unattended narrow mode transmission protection All, I have been busy with WINMOR but do monitor the group and thought it might add some balance to put forth some facts and observations. 1) The majority of WL2K users are not 30 day wonder hams on expensive yachts. Marine mobile users are probably 20% of all registered WL2K users (about 15,000 total current active users). 2) Those that are Marine Mobile have (on average) the same radio skills as the average ham.some much better. Getting digital radio to work at all on a small sailboat (most MM users are not wealthy and have yachts of 35 feet) when you are sitting in a plastic boat inside the antenna near field is a challenge. I have seen and helped set up over 100 such installations. 3) Certainly there are a number of operators that fail to listen first or don't use the tools and procedures recommended to connect. E.g. AirMail limits the calling cycle to normally 20 seconds for most stations. Unfortunately bad operators and procedures exist in ham radio in every mode. 4) Marinas by and large don't do or sell radio installations (I have NEVER seen even one). They sell GAS/Diesel, dockage, supplies, beer and bait. In fact most marine radio service companies have minimal experience with ham radios or HF digital modes. 5) Scanning has been used in the past to improve the utilization of HF Pactor server stations but can be an issue. Pactor has some but limited busy channel detection capability. WL2K is now looking at and testing alternatives to the conventional scanning used in Pactor. The new WINMOR protocol allows more options and experimentation. a. RMS WINMOR server stations [Beta operation started in January 2010] operate on ONE frequency which can be changed (on the hour) during the day (most use 1 - 3 frequencies over a 24 hour day). The frequency list clients use indicate which frequency is in use on which UTC hour. The client software (RMS Express) shows users ONLY those frequencies in current use along with the propagation prediction to the remote server stations. Users can refresh their server station list over the air or over the internet if available. b. WINMOR uses an effective channel busy detector to warn users if a channel appears busy in the bandwidth of interest. The detector isn't perfect (neither is the human ear!) but it can detect most modes even in weak conditions (SSB, CW, PSK, Pactor, Olivia, WINMOR etc). c. The RMS WINMOR stations (servers) also have a similar DSP based detector which can block a reply to a connect request. This will prevent for example answering a connect request over an existing session/QSO not audible to the station originating the connect request (hidden transmitter situation). We're still experimenting and refining this but it definitely helps avoid accidental interference. To summarize: Painting all Winlink users with a broad brush of wealthy yachties with limited radio skills is no where near the truth and is an obvious attempt distort the facts to promote some agenda. If given the flexibility to work on and experiment with these digital modes it is possible to address issues and make progress improving our hobby. If we try and legislate every detail we end up generating rules or band plans that become obsolete quickly. This discourages experimentation (I still hope that is part of our hobby.) and progress. I don't have the time to get into flame wars or extended blogging ..If you have a legitimate technical question on WINMOR or a question about WL2K I will try and answer it with accurate facts. 73, Rick Muething, KN6KB
RE: [digitalradio] Unattended narrow mode transmission protection
If there were no means for such stations to avoid transmitting atop detectable on-going QSOs, I might consider supporting such a proposal. Busy frequency detection, however, is demonstrably feasible and practical. Rewarding the long-term rude behavior of ops running unattended semi-automatic and automatic stations without busy detection by giving them dedicated sub-bands would send a very clear message: the way to obtain dedicated frequencies is to unrelentingly drive everyone else out of them. Appeasement never works. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Andy obrien Sent: Thursday, April 08, 2010 7:50 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Unattended narrow mode transmission protection Let me drill down on this some more to find out the prevailing view... Would those that object to Bonnie's idea, also object if the wide modes were not part of the issue?. How about these objections if there was a digital mode under 500 Hz that transmitted unattended under automatic control? It seems to me, that after years of complaints that PACTOR, ALE, and CW (W1AW) just fire up in the middle of a on-going QSO, that having an area designated for automatic unattended operations makes sense. Then, if we operate there, we do so knowing that W1AW or a WINMOR server may activate at any moment? (actually W1AW has a schedule , but you get my drift). A 500 Hz sliver of spectrum in 80, 60 (yes) 30, 17, and 10M would be all that is needed. The current ALE, Winmor, Pactor, operators (there really are only about 200 in the world , TOTAL ) would then use narrow forms of their mode to achieve their aims . coordinate schedules between them, and have 2500 Hz where their operations are primary, and other hams communications in these segments would be secondary. Andy K3UK On Wed, Apr 7, 2010 at 10:50 PM, n9dsj n9...@comcast.net wrote: --- In digitalradio@yahoogroups.com, Andy obrien k3uka...@... wrote: Andy K3UK Personalities aside, the proposed bandplan is a bad idea. I cannot think of a present or future mode that could be better served by this. ROS has its own problems and standard ALE and PactorIII presently have areas they can reside. Neither are new or advancing the state of art. Even Winmor, which is relatively recent, can not co-exist with existing Winlink PactorIII; is why they were told to stay out of the wide bandwidth automatic sub-bands. I have not found ALE to be a problem as they stay on pre-determined frequencies and actually have little traffic (no offense intended). The prospect of wide bandwidth Winlink bots being able to operate on the suggested frequencies is problematic and antithetical to the need for frequency conservation. Bill N9DSJ
RE: [digitalradio] Unattended narrow mode transmission protection
Rick KN6KB developed an effective busy frequency detector that he included with his implementation of the SCAMP protocol several years ago. A high-level description of SCAMP is available via http://www.eham.net/articles/9785 RIck was initially reluctant to develop a busy-frequency detector because he couldn't make it perfect. My contribution was to help him understand that in this domain, perfect is the enemy of good; the resulting effectiveness of his busy frequency detector surprised Rick, as well as the SCAMP beta testers. My understanding is that WINMOR, which Rick characterizes as a descendent of SCAMP, incorporates a descendent of SCAMP's busy frequency detector. I have not seen a technical paper describing Rick's busy frequency detector, much less code that you could borrow, but based on my experience I suspect that Rick would be happy to discuss it with you. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Simon HB9DRV Sent: Thursday, April 08, 2010 2:30 PM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] Unattended narrow mode transmission protection I've seen (but not yet read) references to this in the SDR world. Out of interest what would you have in mind? Simon Brown, HB9DRV http://sdr-radio.com From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Dave AA6YQ Busy frequency detection, however, is demonstrably feasible and practical.
RE: [digitalradio] Unattended narrow mode transmission protection
AA6YQ comments below -Original Message- From: Jaak Hohensee [mailto:jaak.hohen...@eesti.ee] Sent: Thursday, April 08, 2010 2:50 PM To: digitalradio@yahoogroups.com Cc: Dave AA6YQ Subject: Re: [digitalradio] Unattended narrow mode transmission protection Busy detection in case of QRP Olivia 500/32 signals about snr -17dB is myth. One could include an Olivia decoder in one's busy frequency detector. A busy detector need not detect all possible digital modes simultaneously; it could continuously reconfigure. And as I said, perfect is the enemy of good (with apologies to Voltaire). A busy detector that is only 80% effective would reduce QRM rates from unattended stations by a factor of 5. 73, Dave, AA6YQ 8.04.2010 19:41, Dave AA6YQ kirjutas: If there were no means for such stations to avoid transmitting atop detectable on-going QSOs, I might consider supporting such a proposal. Busy frequency detection, however, is demonstrably feasible and practical. Rewarding the long-term rude behavior of ops running unattended semi-automatic and automatic stations without busy detection by giving them dedicated sub-bands would send a very clear message: the way to obtain dedicated frequencies is to unrelentingly drive everyone else out of them. Appeasement never works. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Andy obrien Sent: Thursday, April 08, 2010 7:50 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Unattended narrow mode transmission protection Let me drill down on this some more to find out the prevailing view... Would those that object to Bonnie's idea, also object if the wide modes were not part of the issue?. How about these objections if there was a digital mode under 500 Hz that transmitted unattended under automatic control? It seems to me, that after years of complaints that PACTOR, ALE, and CW (W1AW) just fire up in the middle of a on-going QSO, that having an area designated for automatic unattended operations makes sense. Then, if we operate there, we do so knowing that W1AW or a WINMOR server may activate at any moment? (actually W1AW has a schedule , but you get my drift). A 500 Hz sliver of spectrum in 80, 60 (yes) 30, 17, and 10M would be all that is needed. The current ALE, Winmor, Pactor, operators (there really are only about 200 in the world , TOTAL ) would then use narrow forms of their mode to achieve their aims . coordinate schedules between them, and have 2500 Hz where their operations are primary, and other hams communications in these segments would be secondary. Andy K3UK On Wed, Apr 7, 2010 at 10:50 PM, n9dsj n9...@comcast.net wrote: --- In digitalradio@yahoogroups.com, Andy obrien k3uka...@... wrote: Andy K3UK Personalities aside, the proposed bandplan is a bad idea. I cannot think of a present or future mode that could be better served by this. ROS has its own problems and standard ALE and PactorIII presently have areas they can reside. Neither are new or advancing the state of art. Even Winmor, which is relatively recent, can not co-exist with existing Winlink PactorIII; is why they were told to stay out of the wide bandwidth automatic sub-bands. I have not found ALE to be a problem as they stay on pre-determined frequencies and actually have little traffic (no offense intended). The prospect of wide bandwidth Winlink bots being able to operate on the suggested frequencies is problematic and antithetical to the need for frequency conservation. Bill N9DSJ -- Kirjutas ja tervitab Jaak Hohensee
RE: [digitalradio] SS definitions
8P9RY comments below From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Trevor . Sent: Wednesday, March 10, 2010 3:21 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] SS definitions --- On Wed, 10/3/10, KH6TY kh...@comcast.net mailto:kh6ty%40comcast.net wrote: Alan, though we may disagree as to the amount or nature of FHSS in ROS, the bottom line is that the FCC engineers, as well as the ARRL engineers, reviewed both the documentation and the signal footprint, and have concluded it is FHSS. Who are these FCC Engineers ? All we've has is a response from someone that may be assumed to be an office clerk who simply quoted back the words in Part 97. What a convenient assumption. Have you spoken with the agent in question, assessed her technical skills, and inquired as to what effort went into the response she conveyed? 73, Dave, 8P9RY
RE: [digitalradio] Re: 1976 FCC - Delete all Emission Types from Part 97
EPC runs a PSK63 contest, and the mode works quite well. Panoramic reception and broadband decoding are a potent combination. It's the only contest I've ever entered, and I took first place in NA, hi. 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of KH6TY Sent: Tuesday, March 09, 2010 1:40 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: 1976 FCC - Delete all Emission Types from Part 97 The hope was that PSK63 could replace RTTY, being both spectrally more efficient, and more usable for a panoramic presentation for contesters to see who is on the band, but it never came about. Too bad, I think, because it would help reduce congestion during contests. PSK63's overall time to complete an exchange is roughly equal to RTTY (twice as fast as PSK31), which is considered too slow for RTTY contesting, but I don't understand why it has not been adopted. I even wrote an article on PSK63 for the National Contest Journal, but there appeared to be little interest and few comments. 73 - Skip KH6TY g4ilo wrote: I don't think digital voice will ever replace SSB, any more than PSK31 and other spectrally more efficient modes will replace RTTY. Radios have a long lifetime. But unlike digital modes whose bandwidth is fixed, phone can communicate using reduced bandwidth. Look what happens in a contest. Julian, G4ILO
RE: [digitalradio] Re: 1976 FCC - Delete all Emission Types from Part 97
The advantage of using FSK is that one can take advantage of the excellent RTTY filters built into some transceivers. These filters are generally not available when operating in USB/LSB. This is particularly important to contesters operating in a crowded environment and DXers dealing with weak signals. 73, Dave, 8P9RY From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of g4ilo Sent: Tuesday, March 09, 2010 1:54 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: 1976 FCC - Delete all Emission Types from Part 97 It also doesn't suffer from the ridiculous printing up garbage because a shift character was lost. If there ever was an outdated mode, it's RTTY. Unfortunately logic or technical arguments play very little part in the reason why people choose to use particular modes. Many RTTY operators insist on actually FSK-ing their radios instead of using AFSK, even though it means they have to accurately tune in every signal instead of just clicking on a waterfall, which would surely be quicker. Julian, G4ILO --- In digitalradio@yahoogroups.com mailto:digitalradio%40yahoogroups.com , KH6TY kh...@... wrote: The hope was that PSK63 could replace RTTY, being both spectrally more efficient, and more usable for a panoramic presentation for contesters to see who is on the band, but it never came about. Too bad, I think, because it would help reduce congestion during contests. PSK63's overall time to complete an exchange is roughly equal to RTTY (twice as fast as PSK31), which is considered too slow for RTTY contesting, but I don't understand why it has not been adopted. I even wrote an article on PSK63 for the National Contest Journal, but there appeared to be little interest and few comments. 73 - Skip KH6TY
RE: [digitalradio] Re: 1976 FCC - Delete all Emission Types from Part 97
Yes, lots of modern transceivers have a dedicated data mode, but they're generally too wide for optimal RTTY reception. In contrast, consider the Twin Peak filter available on recent Icom transceivers, for example; it's only available with the transceiver's mode set to RTTY. 73, Dave, 8P9RY From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of g4ilo Sent: Tuesday, March 09, 2010 6:59 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: 1976 FCC - Delete all Emission Types from Part 97 I've heard this argument many times, Dave, but whilst it was probably true 10 or more years ago, surely all decent modern transceivers have a dedicated data mode that allows the use of narrow filters? Heck, even the humble FT-817 has one. Julian, G4ILO --- In digitalradio@yahoogroups.com mailto:digitalradio%40yahoogroups.com , Dave AA6YQ aa...@... wrote: The advantage of using FSK is that one can take advantage of the excellent RTTY filters built into some transceivers. These filters are generally not available when operating in USB/LSB. This is particularly important to contesters operating in a crowded environment and DXers dealing with weak signals.
RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97
Unless you can convince the transceiver manufacturers to include the capability in each unit, someone operating without a computer connected to his transceiver – e.g. a phone operator -- will be unable to generate the “universal QRL” signal. 73, Dave, 8P9RY From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Warren Moxley Sent: Monday, March 08, 2010 11:36 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97 Skip, since there is no way to cross-communicate to resolve mutual interference. This is a very interesting topic. I have been a software engineer for over 35 years and have heard there is no way a lot of times only to come up with a solution a few days later either by myself or others on my team. It seems to me that the problem of cross-communication can be solved by using an already used technique via RSID. RSID is fast becoming a defacto standard. Maybe we can solve this by modifying the RSID protocol. Currently we are using it to just let others know what mode we are in. Maybe more information can be put in the the RSID packet, for example, Call sign and some reserved bits for the purpose of QSY. Like codes that mean, please QSY, this frequency is already in use and many other codes that can be expanded for this use. Hey guys, come on, there are a lot of smart people and great problem solvers on this reflector who can expand this protocol or come up with a solution. Let's use our brains and solve this problem for the good of the hobby. I am ONLY making and example for the purpose of brain storming. RSID expansion may or may not be a good idea. Do not take my RSID packet expansion as what we should do but as a point of discussion on how to solve a problem. That's the real point here. Let's take my simplistic example as start and let's go from here. Let's not get bogged down on who is right and who is wrong, who has the better mode and it is just too hard of a problem to solve. Warren - K5WGM --- On Mon, 3/8/10, KH6TY kh...@comcast.net wrote: From: KH6TY kh...@comcast.net Subject: Re: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97 To: digitalradio@yahoogroups.com Date: Monday, March 8, 2010, 8:14 AM Trevor, The problem with such a regulation is that, unless CW is required as a common mode, there is no way for a phone QSO, being able to request an interfering digital signal to QSY. Our frequencies are shared, and accidental transmission on existing QSO's in unavoidable, but the mitigation is the ability for the user of one mode to be able to communicate with the user of another mode. The problem already exists between digital operators, but the regulations were written long ago when essentially there was only phone and CW and everyone was required to know CW. I don't know what the solution to the current problem is, but the problem with solely regulation by bandwidth is NOT a solution, especially between phone and digital, since there is no way to cross-communicate to resolve mutual interference. This is why the ARRL regulation by bandwidth petition to the FCC was withdrawn after already once being denied by the FCC. There have been arguments that bandwidth-only regulation works in other countries (perhaps with less ham population density), but it definitely will not work here. That is why legal separation between data and phone has been maintained at all costs, and data kept separate from phone. CW usage may be declining, and therefore using less space, leaving more for digital modes to use, but use of digital modes is still very small compared to CW and phone. Since it is possible to create a digital mode that is very spectrum inefficient for the benefit it brings, there will probably have to be a future restriction of digital mode bandwidths in proportion to the need and benefits of the mode. Digital modes will probably have to restricted by bandwidth in the future, but there still needs to be a common language for frequency use mitigation. 73 - Skip KH6TY Trevor . wrote: Following the recent discussions about the US license restrictions I was looking through the archive of QST mags at www.arrl.org On April 22, 1976 the FCC introduced Docket 20777, the QST report (page June 1976) says Rather than further complicate the present rules, the Commission said, with additional provisions to accomodate the petitioners' requests, we are herein proposing to delete all references to specific emission types in Part 97 of the Rules. We propose, instead, the Commission continued, to replace the present provisions with limitations on the permissible bandwidth which an amateur signal may occupy in the various amateur frequency bands. Within the authorised limitations any emission would be permitted. It would seem that deletion of emission types from Part 97 is exactly what is needed now to
RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97
(unless the “Universal QRL signal” is something simple like “QRL” in CW, or 3-seconds of carrier at ~1 khz.) 73, Dave, 8P9RY From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Dave AA6YQ Sent: Monday, March 08, 2010 11:55 AM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97 Unless you can convince the transceiver manufacturers to include the capability in each unit, someone operating without a computer connected to his transceiver – e.g. a phone operator -- will be unable to generate the “universal QRL” signal. 73, Dave, 8P9RY From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Warren Moxley Sent: Monday, March 08, 2010 11:36 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97 Skip, since there is no way to cross-communicate to resolve mutual interference. This is a very interesting topic. I have been a software engineer for over 35 years and have heard there is no way a lot of times only to come up with a solution a few days later either by myself or others on my team. It seems to me that the problem of cross-communication can be solved by using an already used technique via RSID. RSID is fast becoming a defacto standard. Maybe we can solve this by modifying the RSID protocol. Currently we are using it to just let others know what mode we are in. Maybe more information can be put in the the RSID packet, for example, Call sign and some reserved bits for the purpose of QSY. Like codes that mean, please QSY, this frequency is already in use and many other codes that can be expanded for this use. Hey guys, come on, there are a lot of smart people and great problem solvers on this reflector who can expand this protocol or come up with a solution. Let's use our brains and solve this problem for the good of the hobby. I am ONLY making and example for the purpose of brain storming. RSID expansion may or may not be a good idea. Do not take my RSID packet expansion as what we should do but as a point of discussion on how to solve a problem. That's the real point here. Let's take my simplistic example as start and let's go from here. Let's not get bogged down on who is right and who is wrong, who has the better mode and it is just too hard of a problem to solve. Warren - K5WGM --- On Mon, 3/8/10, KH6TY kh...@comcast.net wrote: From: KH6TY kh...@comcast.net Subject: Re: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97 To: digitalradio@yahoogroups.com Date: Monday, March 8, 2010, 8:14 AM Trevor, The problem with such a regulation is that, unless CW is required as a common mode, there is no way for a phone QSO, being able to request an interfering digital signal to QSY. Our frequencies are shared, and accidental transmission on existing QSO's in unavoidable, but the mitigation is the ability for the user of one mode to be able to communicate with the user of another mode. The problem already exists between digital operators, but the regulations were written long ago when essentially there was only phone and CW and everyone was required to know CW. I don't know what the solution to the current problem is, but the problem with solely regulation by bandwidth is NOT a solution, especially between phone and digital, since there is no way to cross-communicate to resolve mutual interference. This is why the ARRL regulation by bandwidth petition to the FCC was withdrawn after already once being denied by the FCC. There have been arguments that bandwidth-only regulation works in other countries (perhaps with less ham population density), but it definitely will not work here. That is why legal separation between data and phone has been maintained at all costs, and data kept separate from phone. CW usage may be declining, and therefore using less space, leaving more for digital modes to use, but use of digital modes is still very small compared to CW and phone. Since it is possible to create a digital mode that is very spectrum inefficient for the benefit it brings, there will probably have to be a future restriction of digital mode bandwidths in proportion to the need and benefits of the mode. Digital modes will probably have to restricted by bandwidth in the future, but there still needs to be a common language for frequency use mitigation. 73 - Skip KH6TY Trevor . wrote: Following the recent discussions about the US license restrictions I was looking through the archive of QST mags at www.arrl.org On April 22, 1976 the FCC introduced Docket 20777, the QST report (page June 1976) says Rather than further complicate the present rules, the Commission said, with additional provisions to accomodate the petitioners' requests, we are herein proposing to delete all references to specific
RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97
It’s more easily decoded than two handclaps in front of the microphone… 73, Dave, 8P9RY From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Warren Moxley Sent: Monday, March 08, 2010 2:25 PM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97 something simple like “QRL” in CW, or 3-seconds of carrier at ~1 khz.) At least this is an idea. Let's here more brain storming, even ones that sound silly at first might or can be modified to a solution or cause someone else to think in an entirely new way. --- On Mon, 3/8/10, Dave AA6YQ aa...@ambersoft.com wrote: From: Dave AA6YQ aa...@ambersoft.com Subject: RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97 To: digitalradio@yahoogroups.com Date: Monday, March 8, 2010, 9:58 AM (unless the “Universal QRL signal” is something simple like “QRL” in CW, or 3-seconds of carrier at ~1 khz.) 73, Dave, 8P9RY From: digitalradio@ yahoogroups. com [mailto:digitalradi o...@yahoogroups. com] On Behalf Of Dave AA6YQ Sent: Monday, March 08, 2010 11:55 AM To: digitalradio@ yahoogroups. com Subject: RE: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97 Unless you can convince the transceiver manufacturers to include the capability in each unit, someone operating without a computer connected to his transceiver – e.g. a phone operator -- will be unable to generate the “universal QRL” signal. 73, Dave, 8P9RY From: digitalradio@ yahoogroups. com [mailto:digitalradi o...@yahoogroups. com] On Behalf Of Warren Moxley Sent: Monday, March 08, 2010 11:36 AM To: digitalradio@ yahoogroups. com Subject: Re: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97 Skip, since there is no way to cross-communicate to resolve mutual interference. This is a very interesting topic. I have been a software engineer for over 35 years and have heard there is no way a lot of times only to come up with a solution a few days later either by myself or others on my team. It seems to me that the problem of cross-communication can be solved by using an already used technique via RSID. RSID is fast becoming a defacto standard. Maybe we can solve this by modifying the RSID protocol. Currently we are using it to just let others know what mode we are in. Maybe more information can be put in the the RSID packet, for example, Call sign and some reserved bits for the purpose of QSY. Like codes that mean, please QSY, this frequency is already in use and many other codes that can be expanded for this use. Hey guys, come on, there are a lot of smart people and great problem solvers on this reflector who can expand this protocol or come up with a solution. Let's use our brains and solve this problem for the good of the hobby. I am ONLY making and example for the purpose of brain storming. RSID expansion may or may not be a good idea. Do not take my RSID packet expansion as what we should do but as a point of discussion on how to solve a problem. That's the real point here. Let's take my simplistic example as start and let's go from here. Let's not get bogged down on who is right and who is wrong, who has the better mode and it is just too hard of a problem to solve. Warren - K5WGM --- On Mon, 3/8/10, KH6TY kh...@comcast. net wrote: From: KH6TY kh...@comcast. net Subject: Re: [digitalradio] 1976 FCC - Delete all Emission Types from Part 97 To: digitalradio@ yahoogroups. com Date: Monday, March 8, 2010, 8:14 AM Trevor, The problem with such a regulation is that, unless CW is required as a common mode, there is no way for a phone QSO, being able to request an interfering digital signal to QSY. Our frequencies are shared, and accidental transmission on existing QSO's in unavoidable, but the mitigation is the ability for the user of one mode to be able to communicate with the user of another mode. The problem already exists between digital operators, but the regulations were written long ago when essentially there was only phone and CW and everyone was required to know CW. I don't know what the solution to the current problem is, but the problem with solely regulation by bandwidth is NOT a solution, especially between phone and digital, since there is no way to cross-communicate to resolve mutual interference. This is why the ARRL regulation by bandwidth petition to the FCC was withdrawn after already once being denied by the FCC. There have been arguments that bandwidth-only regulation works in other countries (perhaps with less ham population density), but it definitely will not work here. That is why legal separation between data and phone has been maintained at all costs, and data kept separate from phone. CW usage may be declining, and therefore using less space, leaving more for digital modes to use, but use of digital modes
RE: [digitalradio] Re: ARRL/FCC Announcement about ROS
AA6YQ comments below From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of rein...@ix.netcom.com Sent: Saturday, March 06, 2010 5:50 AM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] Re: ARRL/FCC Announcement about ROS Hi Dave, ( AA6YQ ) Thanks. I might just do that next Monday. I understand it to be, some help/emergency phone line? It’s not an emergency phone line. I Lost the number, so if you have it, please send it to me. call (877) 480-3201, choose option #2, and when a person answers ask for “Dawn” (agent 3820). I am also very much interested in your definition of ss. I have not been able to find anything, Wikipedia really does not count in this case. I don’t have a definition, Rein; I agree with you that the Wikipedia entry is not authoritative. The fact that part 97 references spread spectrum without defining it is one of the root causes of this controversy, leaving us to make “individual decisions” in the absence of decision criteria. Transparency (ability for anyone to copy without a private key) and spreading factor are clearly important factors, but to what does the spreading factor apply? Information content? Bandwidth of the signal being spread? Mike N4QLB claims in a post on the ROS reflector that “it’s not spread spectrum if the resulting bandwidth is 3 khz”. Is that true? If so, why 3 khz, as opposed to, say, 3.1 khz? While the assessment of a digital mode’s legality in the US is left to the operator, the decision to impose a penalty in an operator for using an illegal mode lies with the FCC. Given the FCC’s declaration that “ROS is viewed as spread spectrum” and the ARRL’s similar public announcement, I would be hard-pressed to explain why my use of ROS should not result in a serious fine or loss of license. Thus I am not using ROS on HF bands. Said another way, US amateurs can decide to use ROS, but they’d best have a killer technical argument for its legality at the ready. 73, Dave, AA6YQ
RE: [digitalradio] FCC on ROS post on ARRL website!
AA6YQ comments below. From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Dave Ackrill Sent: Friday, March 05, 2010 3:14 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] FCC on ROS post on ARRL website! Dave AA6YQ wrote: However the source of this proof would have to come from someone other than the ROS developer, who now has no credibility with the FCC whatsoever. Is that what the FCC said, or is that just your opinion, Dave? My opinion, Dave. My posts have been explicit when attributing comments or positions to FCC personnel. Dave
RE: [digitalradio] Re: Statement on Withdrawal of Support for ROS (K3UK Sked Pages)
AA6YQ comments below From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of J. Moen Sent: Friday, March 05, 2010 10:11 PM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] Re: Statement on Withdrawal of Support for ROS (K3UK Sked Pages) Dave, You make good points, and you've already hugely contributed and continue to contribute to Ham Radio, so I don't mean to question you. The fact that I write free software for the amateur community doesn’t mean my posts are beyond question. I make mistakes just like everyone else does, and don’t mind being called on them. But if the FCC agent does not consider us Hams a bunch of squabbling children, I guess we are lucky. We sure look that way to me. I am deeply disappointed about this ROS affair. The major parties in the conflict did not conduct themselves well. As a citizen of the US, it is embarassing the FCC rules don't take bandwidth into account when defining what modes are legal on what bands, and they don't, as you point out, technically define spread spectrum. This probably does not look good to most of the rest of the ham radio world. But given the FCC's statement about each amateur radio operator being responsbile for determining what a mode is and where, therefore, it can be legally operated, I suspect the ham community in the US would have been better off letting each amateur make that determination. I don't think it was wise to immediately contact FCC and ask them, given the givens. This is usually true in every general situation like this, until all the facts can be gathered. At the same time, we have to admit that the author or ROS, similar to FCC's lack of clarity in their rules, has not technically defined ROS very well so far. I hope that changes. Overall, these past weeks have not been amateur radio's finest hours. It has been a bit of a perfect storm: attractive new mode, described as spread spectrum by its developer, US hams unable to use spread spectrum on HF, but no clear definition of what constitutes spread spectrum. 73, Dave, AA6YQ
RE: [digitalradio] What is SS?
Mike N4QLB's claims that A frequency in Ham radio consist of a 3kh wide channel. Ros does not signal a receiver to hop outside of that channel (3 Khz) therefore it is not SS and is just like anyother FSK mode used in the amatuer radio service. are incorrect, in my opinion. Amateur radio frequencies on HF bands are not channelized at 3 khz or any other bandwidth (with the exception of 60m). I have asked Mike to cite justification for his claim on the ROS reflector that spreading a ~50 hz signal across 3 khz using classic spread spectrum techniques (e.g. a pseudo-random sequence) isn't spread spectrum. 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Rein A Sent: Friday, March 05, 2010 3:16 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] What is SS? Hello All, I have been trying to understand from the very beginning of this circus what the real problem was and where I could read about it, from 3d independant sources. Jose the programmer has done a poor job in pinning down the core of the problem. Here is a reprint that for my limited mental capacities defines the core quite well. I have asked Mike the author for some references, no lack of trust though. In my searches on the internet I had seen pieces directing to Mike's arguments but never connected the dots. After checking with Mike N4QLB, he has been able to hear me on ROS with a couple of hundred mW, he allowed me to post it here. - -Original Message- From: n4qlb n4...@... Sent: Mar 5, 2010 1:15 PM To: rosdigitalmodemgr...@yahoogroups.com mailto:ROSDIGITALMODEMGROUP%40yahoogroups.com Subject: [ROSDIGITALMODEMGROUP] Re: How do you like ROS Now? Thank You for your comments Sig. Let me explain what SS is. Spread spectrum is a method by which a bank of channels (Frequencies)are designated between a Transmitter and Receiver and are shared or (Frequency Hopped) to facilitate a clear Transmisson. The Transmitter actually signals the Receiver to Hop from one frequency to another. A good example is a 900mhz digital cordless telephone or a 800Mhz digital radio truncking system. (Motorla Astro). A frequency in Ham radio consist of a 3kh wide channel. Ros does not signal a receiver to hop outside of that channel (3 Khz) therefore it is not SS and is just like anyother FSK mode used in the amatuer radio service. The ease of obtaining a License in the U.S. by people that are not technically qualified to hold one is the main culprit regarding the controversy over new modes such as ROS. I am confident that all variations of ROS are perfectly legal in the U.S. Mike N4QLB -- Hope this is a positive contribution to the ongoing discussions. 73 Rein W6SZ
RE: [digitalradio] Re: Statement on Withdrawal of Support for ROS (K3UK Sked Pages)
I disagree. We are required to determine whether a mode is legal before using it. The author initially described ROS as being spread spectrum. Part 97 precludes the use of spread spectrum on HF, but gives no clear definition of spread spectrum. The FCC bears responsibility for this lack of clarity, and so cannot blame amateurs who seek their help in determining whether ROS is legal on HF. They do work for us, after all. In my conversation with Dawn (FCC agent 3820), there was not a whiff of why are you guys annoying us with this nonsense?. She wasn't happy about having her words publicly twisted into ROS is legal on HF, though. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of J. Moen Sent: Wednesday, March 03, 2010 1:04 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Statement on Withdrawal of Support for ROS (K3UK Sked Pages) And think real hard next time before calling the FCC. Ham radio was the net loser in this episode. We are already viewed as squabbling children at the FCC, and this type of episode just reinforces that view of amateur radio. AMEN. Jim - K6JM - Original Message - From: Alan Barrow To: digitalradio@yahoogroups.com Sent: Wednesday, March 03, 2010 8:06 AM Subject: Re: [digitalradio] Re: Statement on Withdrawal of Support for ROS (K3UK Sked Pages) pd4u_dares wrote: ... considering legal action ... has an apparent plan ... may have understandably frustrated Jose I really have mixed feelings about how this all played out as well. While I don't agree with ban lists, I can see where the software author could get very frustrated at what could be perceived as an attempt to get a new mode banned. My observation is that when an arms length ham goes to the ARRL/FCC with an is this legal it nearly always results in a at first glance we do not think so. Historically, this is nearly always done by people opposed to the new mode, and looking to see it banned. Having seen this happen more than once, and having detailed information on two of those cases, it's the wrong way to handle such a query, even if done in good faith. And like most times this occurs, with more detail, and maybe a bit more objective presentation (like making it clear it's ssb bandwidth with an audio sample), the FCC Input is reversed. (it was never a decision, just an opinion based on the facts at hand) In this particular case it's made much worse by the sparse, poor wording in the fcc regs. The issue was not that ROS technically used SS type techniques. Or even could clearly be called SS using the ITU definition. Instead, the core issue was: did ROS behave like traditional SS in a way that would cause interference and thus was banned under 220 mhz. And the answer to that is clearly no. It behaves like many other AFSK'ish modes that use an SSB bandwidth. Other legal modes use randomization in a way that by very strict interpretation could be called SS. Had it hopped across 100khz, using vco rf stages, it'd clearly be illegal. Personally, I think it's unfair to compare to the other authors, as they have never had such a (real or perceived) attack on their software, the product of many hours of work. And we had cross language/culture issues at play here as well. This was not an I don't like it, or it does not work well, all authors have to deal with that. It was a we don't think it should be used debate. And much more personal and at risk. So my view is that we should all learn from this, put the swords back in the scabbards, and not alienate someone who took the time to create something innovative, and made it available for use. For free. And think real net loser hard next time before calling the FCC. Ham radio was the in this episode. We are already viewed as squabbling children at the FCC, and this type of episode just reinforces that view of amateur radio. Sincerely, Alan km4ba
RE: [digitalradio] FCC on ROS post on ARRL website!
The FCC said 'ROS' is viewed as 'spread spectrum,' and the creator of the system describes it as that. We assume that he knows what he created. This is unequivocal. However, the FCC also says The Commission does not determine if a particular mode 'truly' represents spread spectrum as it is defined in the rules. The licensee of the station transmitting the emission is responsible for determining that the operation of the station complies with the rules. Thus if someone were to convince the FCC that ROS is in fact not spread spectrum, then ROS could be used on HF by US operators. However the source of this proof would have to come from someone other than the ROS developer, who now has no credibility with the FCC whatsoever. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Rik van Riel Sent: Thursday, March 04, 2010 5:54 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] FCC on ROS post on ARRL website! On 03/04/2010 02:02 PM, Alan wrote: http://www.arrl.org/news/stories/2010/03/04/11377/?nc=1 So we can forget about here in the US...too bad it looked really nice...73, Alan I don't read it like that. The FCC just says that: 1) spread spectrum is not allowed on HF, and 2) The Commission does not determine if a particular mode 'truly' represents spread spectrum, and 3) The licensee of the station transmitting the emission is responsible for determining that the operation of the station complies with the rules. Once Jose publishes a full specification for ROS (one that is complete enough to create an interoperable alternative implementation), US hams will be able to make the technical determination that the FCC requires us to make. Until then, there is no way to be sure whether or not ROS is legal to use in the US. We simply do not have enough info to make the determination. I expect that cautious US hams will avoid ROS until there is certainty that ROS is in fact legal. -- All rights reversed.
[digitalradio] ROS
Earlier this morning, I called the FCC to confirm the FCC: ROS LEGAL IN USA assertion made in http://rosmodem.wordpress.com/ I asked for confirmation that the FCC had deemed ROS legal for use on HF by US amateurs. When asked for a case number, I provided the case number given on the above web page -- but was informed that this case number refers to a password reset request, not ROS. I asked if I could speak with agent 3820, and was immediately connected; her name is Dawn. I gave Dawn the above URL, and read her the salient paragraph. She said that the information about ROS legality posted on the above web site was not accurate. Dawn went on to say that FCC staff members were working on this issue, and asked me to not make public comments until further progress had been made. She offered to call me at that time. Dawn called me a few minutes ago, and stated that FCC staff consider the information on the above web page to be out of context and misleading. She further stated that FCC staff is working with the ARRL on this issue, and that the outcome will be publicized by the ARRL. Dawn expects this to happen soon; there is nothing related to ROS posted on http://www.arrl.org/ as of a few minutes ago. Note that all telephone conversations with FCC personnel are recorded. 73, Dave, AA6YQ
[digitalradio] RE: ROS
For the record, I have no problem with the ROS mode whatsoever. Soon after its announcement, I emailed the developer offering interoperation with DXLab -- an offer that stands. Developing a great new mode or application does not entitle one to threaten, belittle, or mock those who respond with scathing criticism, much less those who simply ask questions. I strongly disagree with attempts to position legitimate concerns about ROS legality on the part of US amateurs as evidence of a bias against innovation in amateur radio. In response to such a claim on the ROS reflector yesterday, I posted the message below. 73, Dave, AA6YQ From: rosdigitalmodemgr...@yahoogroups.com On Behalf Of Dave AA6YQ Sent: Tuesday, March 02, 2010 4:08 PM To: rosdigitalmodemgr...@yahoogroups.com Subject: RE: [ROSDIGITALMODEMGROUP] Experimentation and Amateur Radio 1. The author publicly described ROS as spread spectrum 2. Hams in the US are required to determine whether a mode is legal in the US before using it 3. In the US, spread spectrum is not legal on HF bands #1 was an egregious technical error. A engineer making a mistake of this magnitude should exhibit contrition and patience, not belligerance and outrage. Threatening legal action against a ham attempting in good faith to fulfil obligation #2 was far outside the spirit of amateur radio -- and from a legal perspective, ridiculous. Framing the amateur community's reaction as anti-innovation is disingenuous; we've seen many new digital modes from all quarters over the years, and none produced anything close to this situation. Had the author correctly described ROS from the outset, or had he forthrightly corrected his error without lashing out at everyone who sought to understand what technology ROS actually employs so they could confidently use this attractive new mode, this teapot tempest would never have occurred. You reap what you sow. 73, Dave, AA6YQ
RE: [digitalradio] Calculating CPU use for multiple applications?
my pleasure, Rick. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Rick Westerfield Sent: Monday, March 01, 2010 9:11 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Calculating CPU use for multiple applications? Hello Dave, This is awesome. A real keeper of an e-mail. I am not in the market for a computer but this is still excellent knowledge to have and I do not have to buy a bunch of magazines or join another Yahoo group to get it. Again, thank you. Rick - KH2DF Sent from my iPhone On Feb 28, 2010, at 9:10 PM, Dave AA6YQ aa...@ambersoft.com wrote: CPU capability is but one set of dimensions (clock speed, instruction issue rate, cache size, cache organization) in a multi-dimensional problem that includes motherboard capabilities (CPU-memory interface, GPU organization and interface, memory organization and speed), disk capabilities (rotational latency, track-to-track seek time, transfer rate), and Windows configuration (settings on Performance Options window's Advanced tab, and a bunch more accessible via a Registry Editor). If you monitor the excellent FlexRadio reflector, you'll see how challenging it is to compute a hardware configuration for optimized for just one application; building and evaluating multiple configurations was required to find the sweet spot. Computing an optimal configuration to host 12 applications is hopeless; this requires the application of general principles, not a spreadsheet. The most critical decision should be made up front: do all of the applications you need run correctly in a 64-bit environment? If so, then plan on building a 64-bit system (Windows 7, if your applications will all run there correctly); I wouldn't choose a motherboard that supports less than 16 GB of RAM, but you can start out by populating it with 2GB or 4GB as your budget allows (don't start with an initial increment that's would have to be discarded to utilize the maximum memory capacity, however). A 64-bit operating system does reduce the choice of serial port interfaces; see http://www.dxlabsuite.com/dxlabwiki/Win7VistaHardware As far as I know, none of the applications on your list can exploit more than one processor core, so you should choose a dual-core processor (Windows will run on one core, and your applications will compete for the second core); if PhotoShop were on you list, you'd reach a different conclusion. Spend some time on Intel's and AMD's web sites looking at the desktop processor comparison charts, e.g. http://www.intel.com/consumer/products/processors/corei7-specs.htm Dvorak's old rule of third best is a good starting point, as companies charge big premiums for their most-powerful CPUs. CPU selection should also consider cache size and architecture (bigger, with more sets is better). Also don't buy a CPU built with an older production process. From Intel, you want 32 nm lithography, not 45 nm; smaller transistors run faster and generate less heat. In choosing a GPU, pick one that offloads all graphics processing, and will handle the screen resolution you'll likely be using over the next couple of years (taking multiple monitors into account, if that's a possibility). This will be an add-in card that can later be upgraded, so tradeoffs can be made. Alternatively, you can save some money by starting with the GPU from your current PC, assuming its above the bar and will run under the new PC's version of Windows. With hard drives, its tempting to buy the biggest disk you can afford, but those spacious 1+TB drives are relatively slow, and a PC with one hard drive is slower than a PC with two hard drives. If you can, go with two hard drives - a ~100 GB device with fast track-to-track times and low rotational latency to host the operating system, and a larger slower drive for your applications and data. Western Digital's Velociraptor family is a good candidate for the small/fast C: drive; you could consider a solid state drive for this role, but I have no personal experience with them. Choose a motherboard that supports a 3 GB SATA interface, and choose hard drives that exploit this interface. Again, you can save some money up front by starting with your current PC's hard drive in your new system, and upgrade later. All DXLab applications run correctly under 64-bit XP, Vista, and Windows 7. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Andy obrien Sent: Sunday, February 28, 2010 7:17 PM To: digitalradio Subject: [digitalradio] Calculating CPU use for multiple applications? I like to multitask, and I am greedy... I like to keep an eye on several things at once. I am thinking about a better PC, one with enough CPU capability to run many tasks at the same time
RE: [digitalradio] Calculating CPU use for multiple applications?
CPU capability is but one set of dimensions (clock speed, instruction issue rate, cache size, cache organization) in a multi-dimensional problem that includes motherboard capabilities (CPU-memory interface, GPU organization and interface, memory organization and speed), disk capabilities (rotational latency, track-to-track seek time, transfer rate), and Windows configuration (settings on Performance Options window's Advanced tab, and a bunch more accessible via a Registry Editor). If you monitor the excellent FlexRadio reflector, you'll see how challenging it is to compute a hardware configuration for optimized for just one application; building and evaluating multiple configurations was required to find the sweet spot. Computing an optimal configuration to host 12 applications is hopeless; this requires the application of general principles, not a spreadsheet. The most critical decision should be made up front: do all of the applications you need run correctly in a 64-bit environment? If so, then plan on building a 64-bit system (Windows 7, if your applications will all run there correctly); I wouldn't choose a motherboard that supports less than 16 GB of RAM, but you can start out by populating it with 2GB or 4GB as your budget allows (don't start with an initial increment that's would have to be discarded to utilize the maximum memory capacity, however). A 64-bit operating system does reduce the choice of serial port interfaces; see http://www.dxlabsuite.com/dxlabwiki/Win7VistaHardware As far as I know, none of the applications on your list can exploit more than one processor core, so you should choose a dual-core processor (Windows will run on one core, and your applications will compete for the second core); if PhotoShop were on you list, you'd reach a different conclusion. Spend some time on Intel's and AMD's web sites looking at the desktop processor comparison charts, e.g. http://www.intel.com/consumer/products/processors/corei7-specs.htm Dvorak's old rule of third best is a good starting point, as companies charge big premiums for their most-powerful CPUs. CPU selection should also consider cache size and architecture (bigger, with more sets is better). Also don't buy a CPU built with an older production process. From Intel, you want 32 nm lithography, not 45 nm; smaller transistors run faster and generate less heat. In choosing a GPU, pick one that offloads all graphics processing, and will handle the screen resolution you'll likely be using over the next couple of years (taking multiple monitors into account, if that's a possibility). This will be an add-in card that can later be upgraded, so tradeoffs can be made. Alternatively, you can save some money by starting with the GPU from your current PC, assuming its above the bar and will run under the new PC's version of Windows. With hard drives, its tempting to buy the biggest disk you can afford, but those spacious 1+TB drives are relatively slow, and a PC with one hard drive is slower than a PC with two hard drives. If you can, go with two hard drives - a ~100 GB device with fast track-to-track times and low rotational latency to host the operating system, and a larger slower drive for your applications and data. Western Digital's Velociraptor family is a good candidate for the small/fast C: drive; you could consider a solid state drive for this role, but I have no personal experience with them. Choose a motherboard that supports a 3 GB SATA interface, and choose hard drives that exploit this interface. Again, you can save some money up front by starting with your current PC's hard drive in your new system, and upgrade later. All DXLab applications run correctly under 64-bit XP, Vista, and Windows 7. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Andy obrien Sent: Sunday, February 28, 2010 7:17 PM To: digitalradio Subject: [digitalradio] Calculating CPU use for multiple applications? I like to multitask, and I am greedy... I like to keep an eye on several things at once. I am thinking about a better PC, one with enough CPU capability to run many tasks at the same time. Is there a way to calculate the total CPU demands of severall applications. Here is a list of what I often run at the same time (or wish i could) Commander (or HRD) Winwarbler (or Multipsk) DX Keeper Spotcollector Pathfinder DX View Weather Watcher Firefox Spectravue or SDR-RADIO Console Fldigi WSJT/JT65-HF Dimension 4 Andy K3UK
RE: [digitalradio] BREAKING NEWS. ARRL: ROS is SS and NOT legal on HF in USA
You were right, Skip. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Andy obrien Sent: Tuesday, February 23, 2010 11:53 AM To: 30...@yahoogroups.com; digitalradio Subject: [digitalradio] BREAKING NEWS. ARRL: ROS is SS and NOT legal on HF in USA FYI From: Henderson, Dan N1ND Subject: RE: Spread Spectrum To: Carol Fred deleted for privacy. Date: Tuesday, February 23, 2010, 7:13 AM Hi Fred: I ran this by our technical experts. They concur that ROS is a spread spectrum mode and as such is not allowed by the FCC on bands below 222 MHz. Remember that approved emissions vary from IARU Region at times as well as between countries. So while the IARU Band Plan for Region 2 would allow it, SS is not permitted on the HF bands by the FCC/ Thanks and 73 Dan Henderson, N1ND Regulatory Information Manager ARRL, the national association for Amateur Radio™ 860-594-0236 dhender...@arrl.org Try Hamspots, PSKreporter, and K3UK Sked Page http://www.obriensweb.com/skedpskr4.html Yahoo! Groups Links No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.730 / Virus Database: 271.1.1/2704 - Release Date: 02/23/10 02:34:00 Try Hamspots, PSKreporter, and K3UK Sked Page http://www.obriensweb.com/skedpskr4.html Suggesting calling frequencies: Modes 500Hz 3583,7073,14073,18103, 21073,24923, 28123 . Wider modes e.g. Olivia 32/1000, ROS16, ALE: 14109.7088. Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) * To change settings via email: digitalradio-dig...@yahoogroups.com digitalradio-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: digitalradio-unsubscr...@yahoogroups.com * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [digitalradio] Re: PSK SPOTS in DXLAB
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Tuesday, February 23, 2010 11:57 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: PSK SPOTS in DXLAB obrienaj wrote: Thanks Dave, Although I use Winwarbler and Spot Collector a lot, I have never really tried clicking on PSK31 spots . I will have to give that a try. Very useful. I wonder if this is the only application that does work well with PSK31 spots? The issue is not generating spots, it's the fact that very few psk spots are done in a fashion that when clicked, you are on the frequency decoding. I use DXLabs, great program (Thanks Dave!). I suspect if all used dxlabs we would not have this problem. But it appears that different programs spot the psk in different fashions. Some do an exact frequency spot, others a base frequency plus an offset (+1k) in the note, etc. This would be an opportunity for someone to develop a standard approach align. But if dx4win, and logger32 don't do it, you'll miss most of the dx'ers. Users of these applications could request that PSK spot generation be automated to post the correct frequency (rig frequency +/- audio offset). Likewise, some of us use multipsk, and other digi programs instead of the suite program. So it needs to play in that regard as well. I see roughly a ten percent success rate clicking on psk spots, with rtty sstv being in the high 90% range. I don't lose sleep over this problem, but I have hardcore contester dxer friends (yes, I admit it) who like psk, but never use it for dx. And that's the reason when asked. And based on my experience, it's an opportunity for standardization. During my occasional holiday-style DX operations, the primary impediment to using PSK has been the slow QSO rate caused by macro-itis. It needs to be a dial frequency type thing, not a get close hunt if you want to see more psk usage by that crowd. But there's another side of it. I kindof like not having contesters major dx chasers on psk! Maybe not being clickable is a good thing? Broadband decoding has the potential of making pileups much more efficient. XF4DL made ~1000 PSK QSOs (out of 58K total) over the course of 10 days; perhaps Juergen DL8LE can share his perspective. 73, Dave, AA6YQ
RE: [digitalradio] Winlink and Regulation by Bandwidth
The issue is not the protocol, but rather automatic operation without a busy frequency detector. An operator invokes a remote automatic station, whose subsequent transmissions QRM an ongoing QSO that the operator doesn't hear (but would hear clearly if he or she were monitoring the remote station's receiver). Participants in the ongoing QSO have no way convey QRL to the automatic station. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of John B. Stephensen Sent: Monday, February 22, 2010 3:47 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Winlink and Regulation by Bandwidth Pactor was FSK with a 100% duty cycle (or peak to average power ratio - PAPR), but Pactor-III is OFDM which has a PAPR similar to SSB and much less than SSB with RF clipping so I don't see how its any worse than digital voice or SSTV. Were the two stations in the automated segments fighting or just transferring data in both directions? I just don't see the threat from automated Pactor stations as they are legal on every amateur frequency outside the U.S. and they haven't taken over there. 73, John KD6OZH - Original Message - From: KH6TY To: digitalradio@yahoogroups.com Sent: Monday, February 22, 2010 00:04 UTC Subject: Re: [digitalradio] A closer look at ROS]] John, The principle of regulation by bandwidth that was fostered by Winlink through the ARRL was that any mode would be allowed in a particular segment of bandwidths as long as the bandwidth was the same or similar. No restriction on content or operating methods.This would have meant that the messaging stations would have full access to all of the phone bands with no restrictions. For example, Pactor-III which has about 100% duty cycle (modulation), compared to 30% average for uncompressed phone, could easily displace any phone QSO and the phone operator would not even be able to identify the interfering station because he would not be operating Pactor-III. The result would have been dominance by messaging systems with no place left to have phone QSO's without the possiblity of being interfered with by an automatic messaging station. Messaging stations are run with ARQ so they fear competition of their own kind and you can often see two automatic stations battling automatically for a frequency. As a result they want to spread out over the band as much as possible to avoid interference from each other instead of sharing frequencies on a first-come-first-served basis like everyone else.
RE: [digitalradio] Re: Curious sound card modes question -
re PSK31 accomplishes the same typing speed in a bandwidth of 31 Hz, instead of in 2000 Hz, so ROS is probably truly spread-spectrum. Applying this logic to RTTY, which employs ~10X the bandwidth employed by PSK31, would lead us to conclude that RTTY is also spread spectrum. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of KH6TY Sent: Monday, February 22, 2010 8:30 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Curious sound card modes question - It will be spread spectrum if the tone frequencies are controlled by a code as explained in the ROS documentation: A system is defined to be a spread-spectrum system if it fulfills the following requirements: 1. The signal occupies a bandwidth much in excess of the minimum bandwidth necessary to send the information. 2. Spreading is accomplished by means of a spreading signal, often called a code signal, which is independent of the data. 3. At the receiver, despreading (recovering the original data) is accomplished by the correlation of the received spread signal with a synchronized replica of the spreading signal used to spread the information. Standard modulation schemes as frequency modulation and pulse code modulation also spread the spectrum of an information signal, but they do not qualify as spread-spectrum systems since they do not satisfy all the conditions outlined above. Note that all three conditions must be met to be considered spread spectrum. I don;t know if it would be possible to send the data in less bandwidth, but, for example, PSK31 accomplishes the same typing speed in a bandwidth of 31 Hz, instead of in 2000 Hz, so ROS is probably truly spread-spectrum. Remember that spread spectrum was conceived as a way of coding transmissions so they could not be intercepted and decoded. In fact actress Hedy Lamarr invented spread spectrum, and you can read that here: http://en.wikipedia.org/wiki/Hedy_Lamarr. The difference is the use of a code to spread the data and signals to avoid detection and monitoring by those without the same code. Download the documentation from www. rosmodem.wordpress.com and read about spread spectrum and the ROS implementation. That will make it clear I think. Remembering that a single tone creates a single RF carrier makes it easy to see how just about anything can be done with tones, including sending data over several tones at once so if one carrier is lost, others carry the same data, or using a psuedo-random code to determine the carrier frequencies, as I think is done in ROS. That documentation also explains the difference between FHSS and modes like MFSK16. However, a main point is that the data does not have to be scattered over such a wide bandwidth to achieve communication, but ROS does, so it qualifies as spread spectrum. If you have a receive bandwith of 10,000 Hz, and you spread over that bandwidth, you really are using way more bandwidth than necessary to send the same data at a given speed. MT63 uses 64 carriers with the data divided among the carriers for redundancy and about 40% of the signal can be obilterated by QRM and still produce good copy. I think the difference with ROS is that the carrier frequencies are varied according to a code, instead of being at a fixed position, but I am no expert on modes, so someone else can probably explain it better and with more accuracy. Generally it is qualifies as spread spectrum if a code is used for the spreading, and in military communications (and even cell phones, I think) the code prevents anyone else from reconstructing the signal so that the intelligence can be recovered if they do not possess the same code. 73 - Skip KH6TY John wrote: Thanks Skip, Unfortunately, this really does not get to the crux of my question(s). I understand how an SSB transmitter works, but that is not really what I am after. What I am driving at is if like this. If I use DM780 to run some version of digital mode via an SSB transceiver, it uses a tone or series of tone modulation/shifting to create the output of the transmitter, and not one single mode is called spread spectrum output, but is called FSK or PSK, etc. Now, we get into the aforementioned discussion regarding ROS, and suddenly, still via the microphone input of the same transmitter, those shifted frequencies are now called spread spectrum instead. I am having a great deal of difficulty understanding, other than the author happened to call his scheme spread spectrum in his technical documentation. Thanks John KE5HAM --- In digitalradio@yahoogroups.com, KH6TY kh...@... wrote: John, Given sufficient carrier suppression, any tone inputed to the microphone makes the transmitter output a pure RF carrier at a frequency of the suppressed carrier frequency plus the tone frequency for USB, or minus the tone frequency for LSB. Whatever you do with the tones
RE: [digitalradio] A closer look at ROS]]
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of John B. Stephensen Sent: Sunday, February 21, 2010 6:14 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] A closer look at ROS]] The current restrictions on automatic stations can stay in place with regulation by bandwidth so this shouln't be an impediment. In the ARRL's proposal to regulate by bandwidth (RM-11306), the current restrictions on semi-automatic stations would have been eliminated. This and other aspects of the ARRL's proposal generated a large negative reaction, which resulted in the ARRL retracting its proposal before the FCC acted upon it. 73, Dave, AA6YQ
RE: [digitalradio] Multipsk- CPU tests with SDR-IQ Direct active.
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Patrick Lindecker Sent: Sunday, January 31, 2010 5:30 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Multipsk- CPU tests with SDR-IQ Direct active. Hello Tony, Would it be possible for me to run the SDR feature without actually having and SDR rig attached? If so, how can I activate it? The SDR feature in Multipsk is only doing a I/Q processing, shifting in base band, in USB or LSB, a selected band (inside the 48, 96 or 192 KHz SdR band). Now as I discovered, thanks to Andy, is that professional SdR are controlled through a defined protocol, something as a Cat system protocol. Perhaps, Dave (AA6YQ) will add, in the future, through Commander, the necessary commands to control the different SdR... Commander has long been able to control PowerSDR. If you send me the protocols you need supported, Patrick, I will extend Commander to support them. 73, Dave, AA6YQ
RE: [digitalradio] Future of ALE and HF Link.
Re the control is to prevent ALE bashing Across a broad range of technical offerings, organizations that actively solicit criticism and respond constructively tend to flourish, whereas organizations focused on protecting their baby often fail to gain traction, despite expending a comparable amount of energy. The open approach motivates users to help - in reporting defects, suggesting enhancements, and spreading the word - and naturally leads to a enthusiastic user community. The defensive approach drives off everyone but the true believers; only something incredibly valuable can survive this. 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Andy obrien Sent: Sunday, January 24, 2010 8:24 PM To: digitalradio; alera...@yahoogroups.com Subject: [digitalradio] Future of ALE and HF Link. I have decided that I will not be a part of HF Link, in the formal sense. Many members of the Yahoo group HFlink have been helpful over the years and Steve especially has been of tremendous help to all. However, I have concluded that the rigid control and moderation of that group, have contributed to the failure of ALE to take hold as an effective method of amateur radio communication. Despite years of efforts, ALE remains perhaps the least used method of ham radio contact management, and is regularly used by less than 75 hams world-wide. I know of no other amateur radio method that is dependent solely on one group , and that one group has such prohibitive practices that it essentially dictates terms. The copyright policy of the HF Link group is directly contributing to a lack of openness that is rarely seen in the amateur radio world. PSK and digital modes have many organizations and email lists, CW has lots of groups, SSB-phone a zillion clubs, RACES/ARES accepts a wider choices of systems, weak signals modes like JT65A have varying groups, but ALE on hams bands remains centralized via HF link. Winmor has tight control on the software but is generally open to input and openly allows dissent. ALE should be allowed to flourish in an open market where hams take the idea and help it evolve and succeed. Steve and Charles Brain have made huge contributions but the warehousing of it via HF link have reduced it to a little understood concept . I will continue to use ALE both PC-ALE and Multipsk . but no longer associate with HF Link. I have raised this matter before , and have received constructive comments the suggest that the control is to prevent ALE bashing . I think that there is not a lot to bash about ALE...it is a very effective system, However the protectionism exhibited by HF Link has harmed ALE more than the occasional ALE bashing would ever do. So, the problems of busy detect and unattended operation notwithstanding, I will remain an advocate of ALE and hope others will help it get rid of its shackles. Heck , lets get rid of ALE as an emcomm concept , it isn't really (it could be , one day). ALE might be more sellable as a DXing method or net control software! Andy K3UK No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.730 / Virus Database: 271.1.1/2636 - Release Date: 01/24/10 03:33:00
RE: [digitalradio] Re: Comparison of RTTY software sensitivity
MMTTY provides a choice of three different RTTY decoders, with the ability to shape the filters for each. There is also an optional bandpass filter and an optional notch filter, with user control of shape for each. As a first step in improving MMTTY's RTTY decoding performance, I am determining how to optimize performance given the capabilities Mako-san JE3HHT has already provided, using a setup similar to what Alex VE3NEA and Wes WZ7I have used. Note that on the chart Wes posted, WinWarbler running the HyperSensitive profile with both the bandpass and notch filters enabled yields sensitivity close to that of TrueTTY. WinWarbler uses MMTTY as its RTTY engine, so this performance is possible with MMTTY alone. By synchronous detection, Vojtech, do you mean treating the first start bit as the beginning of a synchronous multi-character sequence, thereby providing some protection against broken start and stop bits within that sequence? Brian K6STI referred to his decoding technique as employing a flywheel, which I interpreted as a means of adjusting the synchronous timing with high-quality start bits decoded within the sequence. 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Vojtech Sent: Friday, January 22, 2010 8:27 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Comparison of RTTY software sensitivity Here is another, similar chart: http://www.dxatlas.com/RttyCompare/ I was comparing MMTTY with MultiPSK and gMFSK against RTTY in white noise. Interesting observation was that MMTTY was better than MultiPSK at better than marginal SNR, but MultiPSK was slightly better than MMTTY at very low SNR. My best bet is that MMTTY is doing some kind of signal processing after detector, which fixes some errors, but makes things worse in very low SNR. Both yours and Alex's graphs show superiority of TrueRTTY and MixW. I wonder whether TrueRTTY is doing synchronous detection. This is what I plan to try when I retire, hi. 73, Vojtech OK1IAK No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.730 / Virus Database: 271.1.1/2636 - Release Date: 01/21/10 15:34:00
RE: [digitalradio] Comparison of RTTY software sensitivity
Thanks Wes. WinWarbler uses MMTTY as its RTTY engine; thus MMTTY can be configured to achieve the same performance as that shown for WinWarbler. 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Wes Cosand Sent: Wednesday, January 20, 2010 7:02 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Comparison of RTTY software sensitivity Recently during a QSO a ham said the software I was using was not very sensitive. I decided I needed to collect some data to make an informed decision about which software I should be using. I ran several of the RTTY software packages through the AWGN function of PathSim and used RttyCompare to calculate the percentage of errors in the resulting text. The data can be found at http://mysite.verizon.net/wz7i/RTTY.html This is not meant to be a polemical posting. I may well have made less than optimal choices in setting program parameters and I am anxious to receive suggestions about how the testing could be improved. Also, I am aware that sensitivity is only one factor in choosing what communications software to use. Wes, WZ7I www.wz7i.com CW Skimmer CQ spots: cw.wz7i.com:7300 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.730 / Virus Database: 270.14.150/2632 - Release Date: 01/20/10 05:12:00
RE: [digitalradio] Clublogs... see standings versus others
There have been several reports on the DXLab reflector that Club Log ignores the DXCC entity uploaded with each QSO, attempts to determine the DXCC entity itself from its database, and sometimes gets it wrong. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Andy obrien Sent: Monday, January 11, 2010 8:35 AM To: digitalradio Subject: [digitalradio] Clublogs... see standings versus others -- Forwarded message -- From: Rob - G4LMW g4...@btconnect.com Date: Mon, Jan 11, 2010 at 8:26 AM Subject: Re: [skcc] SKCC Now Listed at Clublogs... see standings versus others To: s...@yahoogroups.com Thanks Andy Can I correct the URL: http://www.clublog.org ClubLog is a GREAT facility. The best bit is that it helps you to correct the actual DXCC entity that you have worked. There is a massive database of callsign sitting behind it that tells you if the VP8 that you worked was in the Falklands or Antarctica etc. 73, Rob G4LMW http://www.G4LMW.co.uk
RE: [digitalradio] Nominations for 2009 Digitalradio Awards needed
Patrick, F6CTE. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Andy obrien Sent: Sunday, December 06, 2009 11:11 AM To: digitalradio Subject: [digitalradio] Nominations for 2009 Digitalradio Awards needed It is that time again, as we approach our 10th January in existence it is time to seek you nominations for the Annual Digitalradio Awards. The 2008 winners are listed below. Send your suggestions to me by December 30th 2009. , I make the final determination... Andy K3UK -- (2008) Digitalradio Awards : Best new Digital Mode : WSPR by Joe Taylor , K1JT . . Very useful and robust super low power digital mode . Best New Software: FL-Digi with NBEMS , great work from Dave and Skip. The new aspect refers to the Windows version. Should be standard for any RACES/ARES op. Windows version was on our wish list for 2008, nice to see it arrive early in the year. Best Logging Software: DX Keeper by Dave AA6YQ, , again ! Many emails received from people again nominating this software. May have some competition from the new logger in Ham Radio Deluxe in 2009 Biggest Surprise Of The Year: 1 . ALE. Yep, I thought it might suffer death in 2008 but users actually increased and some interesting innovations from the folks at HFN. ALE in Multipsk helped a lot. 2. A updated version of MixW, Nick lives! 3. Much needed new touches to MMTTY, thanks to Dave AA6YQ. MMTTY has come a long way from the days when I wrote the first English help file! MMTTY, Winwarbler and FSK RTTY make great music together. Digital Innovations Award 2008 : Patrick Lindecker F6CTE and Multipsk, many innovations in 2008 and plenty of unique capabilities. The serious app for the digital mode enthusiast. Biggest Disappointments Of The Year : 1. PSK31 Contests: Over driven signals makes such events intolerable. Maybe we have this group to blame since we promoted and organized most of the first PSK contests back when PSK31 was new. 2. The demise of Olivia as a routinely heard digital mode.. 3. WSPR QSO Mode. Not much activity. The Picaso Award: Simon Brown HB9DRV . The addition of SSTV applications to DM780 and Satellite Tracker to Ham Radio Deluxe are works of art. Best Digital Mode Website : KE7HPV's Digital spotting page, now moved to http://www.hamspots.net/30m/ . Well organized , great auto spots system, . Digital Mode Aid - Innovation of the Year : Philip Gladstone's PSK Reporter . Integrated with DM780, this tool is one of the most useful for those days when you wonder if you are getting out! Find it at http://www.hamspots.net/30m/ or within DM780. Experimenter Of The Year : Tony K2MO : Still playing with digital voice and finding time to test path simulations for all common digital modes. Lost in 2008 Cesco HB9TLK , where is this key digital mode developer? Oddest Mode in 2008: MFTTY . Phone freaking back in vogue? Needs Inventing in 2009 : 1. Windows Version of PSKmail 2. New codec for FDMDV 3 Easy to use/build software based automatic over driven signal control . PSK bands are painful to listen to ! Most Anticipated Event in 2009: Release of WINMOR These annual awards are based on suggestions from the over 3000 members of Digitalradio , the world's leading digital mode discussion group (http://groups.yahoo.com/group/digitalradio/ ) since 2000. The final awards are determined by Andy K3UK
RE: [digitalradio] Contesters and DXers should use busy detectors
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of expeditionradio Sent: Wednesday, November 25, 2009 4:29 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Contesters and DXers should use busy detectors All contesters and DX pileup participants should use busy detectors! All contesters and DX pileup participants *have* busy frequency detectors: their ears. This is quite evident since it has been proven that such types of operation are the source of 99% of harmful interference and intentional interference on the HF ham bands. Please provide or cite this proof. Manual methods of busy detection have been proven to be devoid of merit. Contesters and DX pileup technologists can start developing the DX/Contest Busy Detector with SSB and PSK and RTTY and CW, the most common modes. When they have a busy detector that is proven to work during contests and pileups, then the remaining 1% of rare other modes and other types of operation that are normally the recipient of harmful interference and intentional interference can consider adopting the tried and proven DX/contest Busy Detector. The 1% rare mode operators should continue to use the present methods that have proven to have a high probability of not causing harmful or intentional interference. Put your money where your mouth is. Develop a busy detector for DX/contesters. If your busy detector is successful in preventing the vast majority of harmful and intentional interference of contests and DX pileups, then the rest of the ham community can widely adopt it. The above is one more instance of a bogus argument you and others have long made: because some contesters and DXers cause QRM, all unattended automatic stations are entitled to cause QRM. By the same logic, you could claim that because some contesters and DXers splatter, all unattended automatic stations are entitled to splatter. Or that all unattended automatic stations are entitled to operate with 5 KW, or are entitled to operate out of their licensed band segments. This attitude is cynical and destructive. Amateur radio involves the shared use of limited spectrum among users with diverse interests. This has worked through a combination of sensible rules, useful guidelines, and generally good judgment on the part of individual operators. However, when one group decides that their interest is superior to all others, and that they are therefore free to ignore the rules and guidelines, the result is chaos and frustration -- as we've seen over the past several years. You have made it clear that you consider the use of amateur radio to make random contacts to be archaic. That's fine; you are entitled to you use our shared spectrum however you see fit -- as long as you obey the rules and guidelines so that you do not prevent those with different interests and perspectives from using that same spectrum. Deploying unattended automatic stations that cannot determine whether or not they will QRM an on-going QSO before transmitting is a blatant violation of our service's rules, guidelines and ethics; justifying this behavior by arguing that some human operators violate these rules is the antithesis of the principles underlying amateur radio. As I'm sure you know, two wrongs do not make a right. 73, Dave, AA6YQ
RE: [digitalradio] Digital busy detect
+++ AA6YQ responses below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Wednesday, November 25, 2009 8:12 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect Dave AA6YQ wrote: To be clear, an attended station need not wait for 5 minutes of clear frequency before transmitting; 30 seconds of no signals (meaning no automatic station is QRV) followed by a QRL? sent in mode with no response should be sufficient. What does in mode mean on shared frequencies? The interfering station could be packet, pactor 2-3, ALE, whatever. +++If you're about to send CQ in PSK, you send QRL? in PSK; if you're about to send CQ in RTTY, you send QRL? in RTTY. This concept demonstrably does not work even in attended mode ops, like in PSK. RTTY ops do not honor a QRL in psk, same for CW. +++If an operator sends QRL? in PSK on a frequency being used by a RTTY QSO that he or she did not hear beforehand, one or both participants of that RTTY QSO can ask you to move by sending QRL QRL in CW; the participants don't need to know what the operator sent, they just need to respond with QRL QRL in CW. +++If an operator sends QRL? in PSK on a frequency being used by an unattended automatic station that he or she did not hear beforehand, the automatic station will respond by sending QRL QRL in CW (rule #1 from my previous post). +++In both cases, the operator should QSY on hearing the QRL QRL. Cross mode is the majority of the issue. Most of the protocols will hold off for their mode already. You are asking some modes to solve a problem that has not been addressed even in attended mode. (CW x PSK, RTTY x PSK, etc) +++ Listening for a clear frequency before transmitting QRL? has long been the recommended practice before calling CQ; sending QRL in-mode to a station that appears on your frequency mid-QSO is also standard practice. I agree that there has been no concerted effort to address cross-mode scenarios, but the use of QRL QRL in CW is quite straightforward. Yes, digital ops that didn't learn CW will have to recognize this signal, though if you call CQ in a digital mode and hear CW in response, the frequency is in use is all we'd really need to broadly syndicate. As I said before, I'd be happy to drive this effort. 73, Dave, AA6YQ
RE: [digitalradio] Digital busy detect
###AA6YQ responses below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Wednesday, November 25, 2009 8:34 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect Dave AA6YQ wrote: +++The rules to be honored by all stations are: 1. if you're not yet in QSO, don't transmit on a frequency that is already in use (meaning that signals have been detected during the past 5 minutes) 2. if you're in QSO and signal other than that of your QSO partner appears (the busy frequency detector indicates the presence of signal, but you aren't decoding your QSO partner), wait for that signal to disappear, send QRL QRL in CW, and resume your QSO OK so far ### Progress! +++Amateur radio operators have been trusting each other to mutually obey these rules since the service began. On what possible basis can you claim exemption? Here's where it falls apart. many, many digi ops neither copy CW even to understand QRL, or would not hear it. ### They need not copy it: they need only understand that CW in response to a CQ in any mode means frequency in use, please move elsewhere. ### There will be cases where asymmetry in equipment or propagation results in a station sending CQ not being able to hear either of the stations in an on-going QSO that are sending QRL in response, but this a fortunately infrequent occurrence that cannot be addressed by any technology. The fact that we can't prevent this is no excuse for not addresses the more common scenario that we can mitigate; as Voltaire said, the perfect is the enemy of the good. And another large percentage would not honor a QRL request, they don't in other situations for sure. ### I don't agree that this is a large percentage now, and believe that the amount of negative behavior would decrease as we eliminated the QRM. Kindof like asking all cellphone users to install a device that allows anyone to disable their ringtone. Just what do you think the compliance on that would be? +++No, its not remotely like asking cellphone users to install such a device; there is no parallel whatsoever. I'd be OK if all mfg's had such a device. But to selectively enforce it is unworkable. IE: Multipsk, others should have similar detect honor a QRL request. Recioprocity is part of being a good neighbor. MultiPSK only needs a busy frequency detector when its operating as an unattended automatic station. Attended stations can use their ears. +++ Only attended stations need detect the QRL; if automatic stations never transmit on a frequency that is in use, then they will rarely QRM an ongoing QSO, and so have no need of automatic QRL detection This does not deal with hidden terminal, ### I disagree. If an attended station obeys rule 1, the probability that the frequency was clear for 5 minutes before transmission and yet the attended station's transmission will QRM an on-going QSO is very low. Within that 5 minutes, the attended station's busy frequency detector would have heard one of the two participants in that QSO. A collision would only occur in the asymmetric equipment or propagation scenario. nor does it address the cases where attended mode ops interfere with non-attended ### I disagree. Rule 2 says that an unattended station in QSO that detects a signal not sent by its QSO partner should send QRL QRL in CW. The operator sending that signal would be governed by the if you hear CW in response to a CQ, the frequency is in use principle. Barring an asymmetric scenario, the unattended QSO would be preserved. +++When not in QSO, automatic stations can easily monitor the frequency to determine whether a QSO is in progress, even if they are only hearing one of the stations involved; this is easily implemented. If an automatic station receives a connection request and its busy frequency detector has seen no activity for the past 5 minutes, it can respond to the request without compunction. If its busy frequency detector has been intermittently reporting signals over the past 5 minutes, it should not respond. Unworkable on most auto sub-bands, there is just that much traffic. If you held off 5 minutes for many parts of the day you'd never, ever be able transmit. ### I have two reactions to this statement: 1. I'd like to see the statistics that back it up 2. if its true, you are acknowledging that unattended stations are QRMing a lot of on-going QSOs ### If what you say is true, the proper solution would be to widen the auto sub-bands; but this will only happen after its been demonstrated that unattended automatic stations cause no more QSO breakage than good human operators. Again, unequal standard, do CW/RTTY ops wait 5 minutes? They sure don't when interfering with PSK. ### Attended stations can listen for 30 seconds, send QRL?, interpret the result, and if negative proceed to call CQ. An unattended station with this same
RE: [digitalradio] Digital busy detect
I am fully aware of WinLink's political tactics, but the topic of this thread is busy frequency detection. Independently of why it might have been developed, the busy frequency detector in Scamp surprised many with its effectiveness, including its own developer. I'm assuming that Winmor's busy frequency detector is a descendent of Scamp's, as both were developed by Rick KN6KB. Hold your nose if you must, but I suggest that you evaluate Winmor's busy frequency detector before making additional claims about what is and is not possible. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Charles Brabham Sent: Tuesday, November 24, 2009 7:36 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect I knew one of the hams who first envisioned what would later end up being SCAMP, followed its development with interest, and was thoroughly disgusted at the way the WinLink group used those efforts as a cheap propaganda ploy instead of pursuing it honestly. SCAMP was at no point intended by the WinLink group to see actual use, its development was stretched out and used as a talking point for political purposes. As soon as its utility for that purpose became unsupportable, it was uncerimoniously killed. At no point did the WinLink group intend to phase out the use of the SCS harmful interference mills. This still holds true today. WinMore is just one more SCAMP, unfortunately. Knowing the level of character and intelligence to be found in the WinLink group, I have not followed WinMore's development. - I already know it's fate. After stretching out its supposed development for as long as possible, milking it for political traction ( We are working on ending our widespread inteference - honest! ) there will come the inevitable point where it is reluctantly admitted that WinMore just cannot do the job nearly as well as PACTOR III and then all of a sudden, you won't hear anything more about WinMore. The thing that the ARRL, the FCC, and all amateurs should understand is that WinLink will never be reformed. They hope to become so thoroughly established with delaying tactics like SCAMP and WinMore that eventually the FCC will throw up their hands and award them private spectrum of their own, or re-write PART97 so that we no longer enjoy the use of shared spectrum, thus bringing amateur radio to an end. They want a channelized, CB-like environment and the ARRL, to its discredit, is behind them 100%. As was the case with city and county entities forcing thier employees to get ham tickets as they pursued DHS grant money, and eventually starting to eye amateur radio spectrum as something to lobby for the possession of, our only real hope for a good outcome in this case is for the FCC to step in. We cannot hope for help or support from the ARRL, which again is part of the problem. So no, I have not followed WinMore's development at all, since I already know its fate. Note how WinMore is not open source but is strictly proprietary to the WinLink group, just like SCAMP was. They will be using this control to be sure that it is not developed further or used for any other purpose by anyone else. When they decide to kill it, they will want it to stay dead. - Just as dead as SCAMP is today. 73 DE Charles Brabham, N5PVL Prefer to use radio for your amateur radio communications? - Stop by at HamRadioNet.Org ! http://www.hamradionet.org - Original Message - From: Dave AA6YQ To: digitalradio@yahoogroups.com Sent: Monday, November 23, 2009 10:50 PM Subject: RE: [digitalradio] Digital busy detect Did you evaluate the busy frequency detector in Scamp, Charles? Have you evaluated the busy frequency detector in Winmor? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Charles Brabham Sent: Monday, November 23, 2009 9:55 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Digital busy detect Packet radio gets by with a simple carrier detect, PACTOR can only detect other PACTOR stations, and from what I can tell, ALE has no busy detection at all. Several years ago I took a serious look at automated busy detection, and always ran across the same stone wall: A more sophisticated busy detect that can usually tell the difference between noise and a human activity like speech or digital transmissions is possible - BUT - only after the software has a fairly long audio sample to work with, and can look back upon that sample. It can't do this instantly, or even very quickly unless you have a supercomputer to work with. If it listens to a long sample and a new signal comes in toward the end of that sample, that new signal may or may not end up being identified. This is a terrible thing to have to report, but Packet's carrier detect is the most effective
RE: [digitalradio] Disinformation about ALE by N5PVL Re: Getting serious about ALE / LID factor
re So you add a magic frequency is occupied device to your digi mode. You are legitimately on a frequency, in a digi qso. Yet someone who does not the remote station (hidden) fires up, and stays fired up. At that point, your anti-qrm tripped, and you just lost the frequency, and your qso is terminated. This would only be true of an extremely naive implementation of a busy frequency detector. The purpose of a busy frequency detector is to prevent an unattended station from initiating a QSO (or responding to a request to initiate a QSO) on a frequency that is already busy. If the unattended station is already in QSO, detection of a signal other than that of its QSO partner would not terminate the QSO. re Lot's of the (perceived) issue is the classic hidden terminal nature of radio you may think a frequency is clear because you hear nothing, but in fact, it's a qso in progress where you can only hear one end. You fire up, and turns out you just stomped on someone. Happens on voice, cw, psk, RTTY, it's equal opportunity. Yes, this does happen, but you neglected to describe the rest of the scenario. The end that you can hear says QRL, pse QSY, and most operators quickly oblige. In contrast, unattended automatic stations *cannot* oblige; they blithely QRM away. An unattended station with a proper busy frequency detector would have likely been monitoring the frequency long enough to detect the copiable half of the QSO already in progress, and thus would never have transmitted on the first place. re Happens all the time. Some versions of ALE software have reasonable busy freq detectors. Winkink has deployed tested busy detection. Yet in real life it's unusable, as it pretty much derails any legit qso in progress when other folks (cw, rtty, pactor, whatever) fire up. The naive busy frequency detector, again. re And when it's been deployed in the winlink world, there has clearly been intentional QRM to hold off the digi's Yes, Winlink has generated an enormous amount of ill will, to the point where some ops have become so angry that they will waste their time QRMing an automatic station. There is no excuse for this illegal behavior, but its *ludicrous* to use this as an excuse to avoid eliminating the problem by deploying busy frequency detectors. Once Winlink and other unattended automatic stations reduce their QRM rate to something approaching that of the average human operator, the anger will dissipate and the QRMing of automatic stations will dissappear. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Tuesday, November 24, 2009 7:14 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Disinformation about ALE by N5PVL Re: Getting serious about ALE / LID factor KH6TY wrote: Your prejudice is obviously showing! (Uh - long live HFlink and others that run unattended transmitters outside the beacon bands and transmit without checking for a clear frequency???) With tongue in cheek: your ignorance is showing (in the misinformed sense, no insult implied) All unattended ALE operation associated with HFLINK operates solely in the band segments set aside by the FCC for automatic operation, including unattended. It's a very narrow slice in each band, and quite full of packet BBS, winlink, and ALE. Given the huge (comparatively) segments where narrow modes (rtty, psk, etc) are allowed that are free from competition, I don't see just cause for complaint. You may not like it, but it's an allowed operation mode in an allowed band segment. ALE activity in other portions of the band is attended mode, with the same guidelines/recommendations for listen before transmit. The point Charles is making is that transmitting without listening is simply exceptionally inconsiderate on shared frequencies by all widely accepted standards of behavior, but you obviously do not get it, and I guess you really don't want to, do you... Simply put, frequency sharing means not using a frequency unless you have made a reasonable attempt to verify it is not being used. There is no technology yet implemented that makes this possible for an unattended station. So help me out, how does the repeated rtty transmissions in contest weekends handle this? I see 100x the examples of xmit without listening during rtty contests then all the semi-auto modes put together? Lot's of the (perceived) issue is the classic hidden terminal nature of radio you may think a frequency is clear because you hear nothing, but in fact, it's a qso in progress where you can only hear one end. You fire up, and turns out you just stomped on someone. Happens on voice, cw, psk, RTTY, it's equal opportunity. BTW, no one asks in psk is the frequency in use?. So you add a magic frequency is occupied device to your digi mode. You are legitimately on a frequency, in a digi qso. Yet someone who does not the remote station (hidden
RE: [digitalradio] Digital busy detect
re Problem is, just like other mode operators have found out, it's unworkable as the majority of legal, in progress qso's will be derailed by someone else firing up. Its only unworkable because the implementation of the busy frequency detector in question is obviously quite poor. re Since the CW op has no way to ask in ALE, PSK, whatever mode is the frequency in use, all they can do is interfere. so the mythical busy detection software would have to have a way to answer back sorry OM, the frequency is in use in every imaginable mode. No, an automatic station already in QSO need only respond with QRL in CW, which will be understood by the majority of attended stations. re Fact: Radio is vulnerable to hidden terminal effect like most shared media. We live in that world. And because of that, there will be some unintentional interference. This is rarely problem with attended stations; you might not hear one side of an in-progress QSO, but you will hear the other side, and be able to respond appropriately when the side you hear asks you to QSY. Only automated stations without busy frequency detectors suffer the vulnerability you describe here. Effective multi-mode busy frequency detection has been demonstrably feasible for years. Had a concerted effort been made to equip all automatic stations with competent busy frequency detectors, the rate of QSO breakage caused by such stations would have plummeted, the anger caused by this QSO breakage would have dissapated, and we'd be efficiently sharing spectrum in the pursuit of our diverse objectives. Instead, we've been treated to years of blatantly lame excuses as to why busy frequency detection either can't be designed, can't be implemented, can't be deployed, won't work, causes warts, causes cancer, causes global warming, or will cause the universe to expand forever. Few are fooled by this. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Tuesday, November 24, 2009 8:14 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect Charles Brabham wrote: Packet radio gets by with a simple carrier detect, PACTOR can only detect other PACTOR stations, and from what I can tell, ALE has no busy detection at all. Absolutely not the case. ALE listen's before transmit for other ALE by protocol. And the commonly used ham implementation has a busy detection mode that works for rtty, carrier, and most CW. Just does OK on voice, but that's less of an issue as any operation in the voice sub-bands are attended. Problem is, just like other mode operators have found out, it's unworkable as the majority of legal, in progress qso's will be derailed by someone else firing up. Since the CW op has no way to ask in ALE, PSK, whatever mode is the frequency in use, all they can do is interfere. so the mythical busy detection software would have to have a way to answer back sorry OM, the frequency is in use in every imaginable mode. I see this in the PSK bands by CW RTTY ops, and happens to pretty much any digi mode. It's not unique to ALE for sure. Fact: Radio is vulnerable to hidden terminal effect like most shared media. We live in that world. And because of that, there will be some unintentional interference. Regarding busy detection, I've posted youtube video's of ALE's busy detection in action. Packet's is not the most effective, by any means. All that said, until there is mutual respect of the digi modes right to exist, no one will widely use the busy detection as it's too easy to hold off or interfere with a station running it. see it happen every day on the busy ALE frequencies, and for sure this has soured winlink on busy detection. It's not technology, it's your fellow hams. When I see all psk ops wait for 2 complete transmission cycles to ensure there is no hidden terminal effect, then ask is the frequency in use before transmitting I'll concede. Same for RTTY. Until then, it's just one mode complaining about the other, and we won't see progress. Have fun, Alan km4ba
RE: [digitalradio] Digital busy detect- it's not a technology issue
(universal) when someone starts qrm'ing a transmission in progress. You just blew any chance of receiving the data being sent by the station you are in qso with. Google Automatic Repeat Request. And what is that signal? And will majority of ops respect that? when less less hams even know CW? Learning a single CW Q-signal is hardly an impediment. Remember, you are asking the newer modes to implement this, how will the legacy modes do it? There are no legacy automatic modes. Do you really expect winlink et al to implement a scheme that would allow anyone to pre-empt (hold-off) their traffic, while not doing the same in return? Isn't this presumption the basis on which we've shared spectrum since the amateur radio service was born? Again, when someone can show me a scheme that queries the freq prior to usage on psk, I'll be convinced. Anything else is still subject to hidden terminal interference, and will still generate complaints. IE: Solve the problem for a legacy mode, and then we'll talk. Attended PSK stations should verify that the frequency is not in use before transmitting; this is accomplised by monitoring the tuning display for awhile before transmitting. No automation is required; the operator is responsible for this action. Automatic PSK stations are no different than automatic Pactor-3 or ALE stations -- they should include an effective busy frequency detector. I'd love to do peer review for such a scheme. We'll get the ARRL to send it out as best practices. Right. Don't mean to be negative, but it's far more complex than JSMOP. (Just A Small Matter Of Programming) Its not complicated at all, though you're trying very hard to make it seem complicated: 1. if not in QSO, don't transmit on a frequency that's already in use 2. if in QSO and a signal other than that of your QSO partner is detected, wait for the intruding signal to end, and send QRL QRL in CW. Meanwhile, I'll operate ALE occasionally P3 in the auto sub-bands. And bite my tongue when I am qrm'd by RTTY, CW, and other PSK ops in the PSK sub-band. There is no excuse for your signals being intentionally QRM'd, but as I've said before, the multi-year failure of WinLink and other unattended automatic stations to curb their breakage of on-going QSOs has generated a lot of anger; this won't end until the lame excuses are replaced by competent busy frequency detectors. 73, Dave, AA6YQ Suggested frequencies for calling CQ with experimental digital modes = 3584,10147, 14074 USB on your dial plus 1000Hz on waterfall. Announce your digital presence via our Interactive Sked Pages at http://www.obriensweb.com/sked Yahoo! Groups Links * To visit your group on the web, go to: http://groups.yahoo.com/group/digitalradio/ * Your email settings: Individual Email | Traditional * To change settings online go to: http://groups.yahoo.com/group/digitalradio/join (Yahoo! ID required) * To change settings via email: digitalradio-dig...@yahoogroups.com digitalradio-fullfeatu...@yahoogroups.com * To unsubscribe from this group, send an email to: digitalradio-unsubscr...@yahoogroups.com * Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
RE: [digitalradio] Digital busy detect
AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of WD8ARZ Sent: Tuesday, November 24, 2009 10:06 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect Scamp busy detector as used in Scamp at the time of the group testing I was part of, was NOT the end all of busy detectors. Correct. It was a first attempt somewhat reluctantly taken by the author with encouragement from me and several others. Finding a setting of the threshold was very difficult. Too sensitive and the throughput operation of Scamp was poor due to being held up by the threshold trigger. Not sensitive enough and it did not perform at times when you knew it should have. What worked for one type of band condition for awhile, did not work well during a different type of band condition. There were quite a few more positive reports from Scamp beta testers posted on this forum at the time. Personally witnessed operators that would intentionally come on frequency and put out signals solely for the purpose of triggering the busy detector to stop operations. When Scamp operations were not active, they didnt seem to be active on the frequency. Start Scamp activity and some of the same lids would start up again with just enough activity to activate the busy detector. This hardly a good reason to not move forward with a mechanism that would reduce the ill-will responsible for these actions. End result was the agreement to not use it as it was not living up to expectations and stayed that way through the shut down of the group by the author. Scamp was terminated because the RDFT protocol on which it was based performed poorly under typical band conditions. Rick KN6KB evidently reached a different conclusion than you did regarding the efficacy of busy frequency detection, as he included busy frequency detection in Winmor. 73, Dave, AA6YQ
RE: [digitalradio] Digital busy detect
+++ AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Tuesday, November 24, 2009 10:30 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect Dave AA6YQ wrote: Its only unworkable because the implementation of the busy frequency detector in question is obviously quite poor. Significantly more to it than that... unless *all* stations honor abide by common rules/tech, it simply won't work. This is true of just about any network, not just radio. (remember the FRACK wars back in packet days?) +++The rules to be honored by all stations are: 1. if you're not yet in QSO, don't transmit on a frequency that is already in use (meaning that signals have been detected during the past 5 minutes) 2. if you're in QSO and signal other than that of your QSO partner appears (the busy frequency detector indicates the presence of signal, but you aren't decoding your QSO partner), wait for that signal to disappear, send QRL QRL in CW, and resume your QSO +++There is nothing complicated about this. Automation is only required in unattended automatic stations. No, an automatic station already in QSO need only respond with QRL in CW, which will be understood by the majority of attended stations. With full respect: Yeah, right :-) You want me to hold off my transmissions automatically, but trust other ops (in other modes) to do the same. Voluntarily. Cross-mode. Right. +++Amateur radio operators have been trusting each other to mutually obey these rules since the service began. On what possible basis can you claim exemption? Kindof like asking all cellphone users to install a device that allows anyone to disable their ringtone. Just what do you think the compliance on that would be? +++No, its not remotely like asking cellphone users to install such a device; there is no parallel whatsoever. I agree CW QRL is probably the most universal approach, but you'd have to match the exact beat frequency of the cw sig for them to hear it. And be able to decode CW on the fly (CWget in all busy detectors) to honor it from others. +++Only attended stations need detect the QRL; if automatic stations never transmit on a frequency that is in use, then they will rarely QRM an ongoing QSO, and so have no need of automatic QRL detection. This is rarely problem with attended stations; you might not hear one side of an in-progress QSO, but you will hear the other side, and be able to respond appropriately when the side you hear asks you to QSY. Only automated stations without busy frequency detectors suffer the vulnerability you describe here. Only true if you listen for 1-2X the average transmission length or do a ? query. Voice ops do that, because it's not cross mode, and transmission times are shorter. Digi modes do not do that by practice (even RTTY), the transmission times are longer, and the price of an interuptted transmission higher. (resend) +++When not in QSO, automatic stations can easily monitor the frequency to determine whether a QSO is in progress, even if they are only hearing one of the stations involved; this is easily implemented. If an automatic station receives a connection request and its busy frequency detector has seen no activity for the past 5 minutes, it can respond to the request without compunction. If its busy frequency detector has been intermittently reporting signals over the past 5 minutes, it should not respond. And it's not rarely a problem in attended modes, I see it daily on PSK. +++I didn't say it rarely occurs, I said its rarely a problem -- because attended stations can communicate with each other and resolve the conflict, thereby preserving the QSO in progress. Unattended automatic stations are incapable of doing this. Effective multi-mode busy frequency detection has been demonstrably feasible for years. Had a concerted effort been made to equip all automatic stations with competent busy frequency detectors, the rate of QSO breakage caused by such stations would have plummeted, the anger caused by this QSO breakage would have dissapated, and we'd be efficiently sharing spectrum in the pursuit of our diverse objectives. Instead, we've been treated to years of blatantly lame excuses as to why busy frequency detection either can't be designed, can't be implemented, can't be deployed, won't work, causes warts, causes cancer, causes global warming, or will cause the universe to expand forever. Few are fooled by this. OK, here's the challenge: Demonstrate it's feasibility if it's JSMOP. Implement one that balances the right of the sending station not to be QRM'd VS the expectation not to QRM. Publish an API a spec (turnaround times, etc). IE: Not a passive (hold off) detector Make it open source so that all coders can leverage refine it. Windows assumption is OK, but we could probably find a lock/semaphore system that is multiplatform
RE: [digitalradio] Digital busy detect
To be clear, an attended station need not wait for 5 minutes of clear frequency before transmitting; 30 seconds of no signals (meaning no automatic station is QRV) followed by a QRL? sent in mode with no response should be sufficient. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Dave AA6YQ Sent: Wednesday, November 25, 2009 2:29 AM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] Digital busy detect +++ AA6YQ comments below -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alan Barrow Sent: Tuesday, November 24, 2009 10:30 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Digital busy detect Dave AA6YQ wrote: Its only unworkable because the implementation of the busy frequency detector in question is obviously quite poor. Significantly more to it than that... unless *all* stations honor abide by common rules/tech, it simply won't work. This is true of just about any network, not just radio. (remember the FRACK wars back in packet days?) +++The rules to be honored by all stations are: 1. if you're not yet in QSO, don't transmit on a frequency that is already in use (meaning that signals have been detected during the past 5 minutes) 2. if you're in QSO and signal other than that of your QSO partner appears (the busy frequency detector indicates the presence of signal, but you aren't decoding your QSO partner), wait for that signal to disappear, send QRL QRL in CW, and resume your QSO +++There is nothing complicated about this. Automation is only required in unattended automatic stations. No, an automatic station already in QSO need only respond with QRL in CW, which will be understood by the majority of attended stations. With full respect: Yeah, right :-) You want me to hold off my transmissions automatically, but trust other ops (in other modes) to do the same. Voluntarily. Cross-mode. Right. +++Amateur radio operators have been trusting each other to mutually obey these rules since the service began. On what possible basis can you claim exemption? Kindof like asking all cellphone users to install a device that allows anyone to disable their ringtone. Just what do you think the compliance on that would be? +++No, its not remotely like asking cellphone users to install such a device; there is no parallel whatsoever. I agree CW QRL is probably the most universal approach, but you'd have to match the exact beat frequency of the cw sig for them to hear it. And be able to decode CW on the fly (CWget in all busy detectors) to honor it from others. +++Only attended stations need detect the QRL; if automatic stations never transmit on a frequency that is in use, then they will rarely QRM an ongoing QSO, and so have no need of automatic QRL detection. This is rarely problem with attended stations; you might not hear one side of an in-progress QSO, but you will hear the other side, and be able to respond appropriately when the side you hear asks you to QSY. Only automated stations without busy frequency detectors suffer the vulnerability you describe here. Only true if you listen for 1-2X the average transmission length or do a ? query. Voice ops do that, because it's not cross mode, and transmission times are shorter. Digi modes do not do that by practice (even RTTY), the transmission times are longer, and the price of an interuptted transmission higher. (resend) +++When not in QSO, automatic stations can easily monitor the frequency to determine whether a QSO is in progress, even if they are only hearing one of the stations involved; this is easily implemented. If an automatic station receives a connection request and its busy frequency detector has seen no activity for the past 5 minutes, it can respond to the request without compunction. If its busy frequency detector has been intermittently reporting signals over the past 5 minutes, it should not respond. And it's not rarely a problem in attended modes, I see it daily on PSK. +++I didn't say it rarely occurs, I said its rarely a problem -- because attended stations can communicate with each other and resolve the conflict, thereby preserving the QSO in progress. Unattended automatic stations are incapable of doing this. Effective multi-mode busy frequency detection has been demonstrably feasible for years. Had a concerted effort been made to equip all automatic stations with competent busy frequency detectors, the rate of QSO breakage caused by such stations would have plummeted, the anger caused by this QSO breakage would have dissapated, and we'd be efficiently sharing spectrum in the pursuit of our diverse objectives. Instead, we've been treated to years of blatantly lame excuses as to why busy frequency detection either can't be designed, can't be implemented, can't be deployed, won't work, causes warts, causes cancer, causes
RE: [digitalradio] Dx pile ups..
In a DX pileup, calling on the same frequency that someone else is calling generally results in neither of you getting through, particularly if you are using a digital mode. The idea is to 1. understand the range of frequencies in which the DX station is listening 2. crop your callsign into a hole in this range so that it will more likely be heard clearly In lighter pileups, the DX station may exhibit a pattern -- .e.g. moving up 500 hz after each RTTY QSO. Astute DXers learn this pattern, anticipate the next frequency, and call there. However, this only works when there aren't too many astute DXers. Spectrum scopes have made it much easier to rapidly detect such patterns, turning the anticipated next frequency into a zoo. As a result, many DX stations have abandoned the pattern method; instead, they randomly look for stations in the clear across the range in which they are operating. No DXer should participate in a pileup if doing so would QRM an ongoing QSO. In my experience, politely asking the participants in the ongoing QSO to move almost always yields a polite and positive response. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of obrienaj Sent: Monday, November 23, 2009 9:17 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Dx pile ups.. Bonnie said the same goes for DX pileups. Basically, a pileup is simply a contest where the number of possible contacts is 1 and the number of possible multipliers is 1. Everyone who enters the pileup contest is trying to out-QRM the other entrants, or in FCC parlance... to harmfully interfere with, the other contestants in the pileup contest. They are trying to keep the other stations from working the target station, in favor of themselves. Louder, stronger, QRMer. Surely Bonnie is correct in this? Not ALL DXers , but the vast majority are doing what Bonnie describes when responding to a QRZ. If I hear P5DX QRZ?, then I hear November Seven Delta... starting a call and throw in Kilo Three Uniform Kilo on top of the 7 station (Danny) , Bonnie is correct that I have QRM'd him. I guess the difference is that this is accepted and actually encouraged. I still remember my utter shock when a new ham reading the ARRL handbook about DXing, and how a DX station would listen on incrementally different QRG and NOT tell you exactly where. The book explained that the art of DXing was to determine the DX station's methods and skillfully figure out where he would be listening. In Bonnie's context, this would be encouraging lots of QRM . Skip's earlier point would be that this still differs from unattendned transmissions but I think Bonnie's point is that the result is not that much difference. Cue Bonnie with comments about goose and gander... Andy K3UK
RE: [digitalradio] Digital busy detect
Did you evaluate the busy frequency detector in Scamp, Charles? Have you evaluated the busy frequency detector in Winmor? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Charles Brabham Sent: Monday, November 23, 2009 9:55 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Digital busy detect Packet radio gets by with a simple carrier detect, PACTOR can only detect other PACTOR stations, and from what I can tell, ALE has no busy detection at all. Several years ago I took a serious look at automated busy detection, and always ran across the same stone wall: A more sophisticated busy detect that can usually tell the difference between noise and a human activity like speech or digital transmissions is possible - BUT - only after the software has a fairly long audio sample to work with, and can look back upon that sample. It can't do this instantly, or even very quickly unless you have a supercomputer to work with. If it listens to a long sample and a new signal comes in toward the end of that sample, that new signal may or may not end up being identified. This is a terrible thing to have to report, but Packet's carrier detect is the most effective and sophisticated automatic signal detection scheme we currently have at our disposal. - It detects more kinds of activity *right then* than anything else that hams are currently using. There are lots of signals that carrier detect will not detect - but it is still the best thing out there, that can automatically detect and act in ( more or less ) real-time. The human ear works better, detecting signal intelligence and differentiating it from noise far better than any automated detection system. Period. Better still is the human eye, looking at a properly set up waterfall display that will show you recognizable patterns in the waterfall image that you may not be able to register just by listening. One thing to ponder is why carrier detect, developed over twenty-five years ago is not utilized by PACTOR or ALE, both allegedly more advanced than Packet. My feeling on this is that if they cannot detect signals as well as Packet does, then which mode is more advanced, more suitible for use on the ham bands? That is really an unfair question in the case of PACTOR III and ALE, niether one of which was designed or ever intended for use within shared amateur radio spectrum, in the first place. It is not the square peg's fault that it will not fit in the round hole. In the end, if we are not operating an automated station, then a waterfall display in combination with speaker audio is the most effective and useful busy detection system we have at our disposal, and this will almost certainly continue to be the case for a very long time. For real-time automated busy detection, carrier detect is highly likely to be the best thing at our disposal - again for a very long time. The Reed-Soloman ID system is a great step ahead for digital operation. It is not really useful as a real-time busy-detect, but it does give us a first step on something that may eventually take us there. As standards and hardware evolve over the years, we may eventually embed information into our data streams that can be instantly recognized as 'busy' by our software. - It may even approach the speed of carrier detect, and work with all modes. But don't hold your breath, it's not right around the corner. 73 DE Charles Brabham, N5PVL Prefer to use radio for your amateur radio communications? - Stop by at HamRadioNet.Org ! http://www.hamradionet.org
RE: [digitalradio] Re: Why would anyone
Had the ARRL's regulation by bandwidth proposal been accepted, the range of frequencies available to automatic stations without busy frequency detectors would have significantly increased, which was why so many amateurs opposed it, which was why the ARRL abandoned it. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of John B. Stephensen Sent: Friday, October 30, 2009 2:43 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Why would anyone The FCC could make part 97 more understandable if they adopted regulation by bandwidth but that effort died. EZPal on 14.233-14.237 MHz is OK as there are very few restrictions on image transmission. 73, John KD6OZH - Original Message - From: John To: digitalradio@yahoogroups.com Sent: Friday, October 30, 2009 02:21 UTC Subject: [digitalradio] Re: Why would anyone So sorry John . of course you are right . we were supposed to have read and understood the contents of part 97 . I guess I must have forgotten the part that demanded we also memorize it verbatim with all it's technical terms and specs. I must be the one to admit it, I am the one that forgot some pieces of it could you remind me again about where that rule was located? HiHi In all seriousness, I was simply trying to illustrate a point that seemed to be misleading in the discussion. As I read the discussion, and indeed I could have missed some posts, but it appeared some were alluding that the maximum baud rate was 300 PERIOD, which as you have so expertly pointed out is quite untrue . Thank you for the clarification, however these limits still seem to fly in the face of such things as EZPal and a few others, especially when operating on customary HF frequencies around 20 meters (14.233 - 14.237 khz) Thanks again
RE: [digitalradio] Re: Why would anyone
Your assertion below that current rules allow an automatic station to operate on any frequency is incorrect. See §97.221 http://www.arrl.org/FandES/field/regulations/news/part97/c.html#221 With a bandwidth of 500 hz or less, such stations can can only operate wherever RTTY or data emissions are authorized. With a bandwidth of more than 500 hz, such stations are limited to the sub-bands enumerated in §97.221(b). 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of John B. Stephensen Sent: Friday, October 30, 2009 4:30 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Why would anyone I just reread it and it seems to be more restrictive than the current rules. The current rules establish segments for automatic forwarding between digital stations on all HF bands and these were eliminated below 28 MHz in the ARRL proposal. The current rules allow for an automatic station that only responds to queries by a manually-controlled station to operate on any frequency and that was unchanged in the ARRL proposal. 73, John KD6OZH - Original Message - From: Dave AA6YQ To: digitalradio@yahoogroups.com Sent: Friday, October 30, 2009 07:48 UTC Subject: RE: [digitalradio] Re: Why would anyone Had the ARRL's regulation by bandwidth proposal been accepted, the range of frequencies available to automatic stations without busy frequency detectors would have significantly increased, which was why so many amateurs opposed it, which was why the ARRL abandoned it. 73, Dave, AA6YQ
RE: [digitalradio] Re: Why would anyone
I agree that there were positive aspects to the ARRL's regulation by bandwidth proposal. However, expanding the range of frequencies available to unattended stations without including a requirement that they verify their frequency to be clear before transmitting was a showstopper, in my opinion. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of John B. Stephensen Sent: Friday, October 30, 2009 11:47 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Why would anyone I meant any frequency where RTTY/data is allowed. The objection that people had then seems to be that a wider bandwidth was allowed for semi-automatic stations in the proposed 3 kHz bandwidth segments. However, the proposed rules would have pushed the wideband semi-automatic stations up in frequency and out of the areas where people were complaining of interference to narrowband RTTY/data QSOs. They also allowed RTTY/data QSOs to occur anywhere in the band which would seem to provide even more flexibility to avoid interference. I liked this feature of the proposal. 73, John KD6OZH - Original Message - From: Dave AA6YQ To: digitalradio@yahoogroups.com Sent: Friday, October 30, 2009 08:54 UTC Subject: RE: [digitalradio] Re: Why would anyone Your assertion below that current rules allow an automatic station to operate on any frequency is incorrect. See §97.221 http://www.arrl.org/FandES/field/regulations/news/part97/c.html#221 With a bandwidth of 500 hz or less, such stations can can only operate wherever RTTY or data emissions are authorized. With a bandwidth of more than 500 hz, such stations are limited to the sub-bands enumerated in §97.221(b). 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of John B. Stephensen Sent: Friday, October 30, 2009 4:30 AM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Re: Why would anyone I just reread it and it seems to be more restrictive than the current rules. The current rules establish segments for automatic forwarding between digital stations on all HF bands and these were eliminated below 28 MHz in the ARRL proposal. The current rules allow for an automatic station that only responds to queries by a manually-controlled station to operate on any frequency and that was unchanged in the ARRL proposal. 73, John KD6OZH - Original Message - From: Dave AA6YQ To: digitalradio@yahoogroups.com Sent: Friday, October 30, 2009 07:48 UTC Subject: RE: [digitalradio] Re: Why would anyone Had the ARRL's regulation by bandwidth proposal been accepted, the range of frequencies available to automatic stations without busy frequency detectors would have significantly increased, which was why so many amateurs opposed it, which was why the ARRL abandoned it. 73, Dave, AA6YQ
RE: [digitalradio] Throught of a Digital Propagation Tool
The is a worldwide network of 18 beacons operated by the Northern California DX Foundation and the International Amateur Radio Union on 5 HF bands from 20m through 10m: http://www.ncdxf.org/beacons.html At the moment, the beacons in Russia and Sri Lanka are down due to hardware problems; repairs are underway. Each beacon transmits for 10 seconds, giving its callsign in CW followed by four dashes: the first at 100 watts, the second at 10 watts, the third at 1 watt, and the fourth at 100 milliwatts: http://www.ncdxf.org/beacon/beaconschedule.html By monitoring a beacon frequency for 3 minutes, you can assess actual propagation from your QTH on that band. Alternatively, you can construct a beacon schedule to quickly determine what bands are open to a particular area of the world from your QTH. Syncing your PC's time-of-day clock with an internet-accessible time service is recommended. The freeware DXLab Suite's PropView component lets you specify a set of beacons you wish to monitor and will direct the Commander component to QSY your transceiver to monitor them. You can select beacons individually, by band, or by bearing (octant) from your QTH. The PropView component will also generate graphical propagation forecasts using the VOACAP or ICEPAC engines, and use the beacon network to calibrate these forecasts. See http://www.dxlabsuite.com/propview/ A list of other tools that can be used to monitor NCDXF/IARU beacons is provided in http://www.ncdxf.org/beacon/beaconprograms.html You can also assess propagation by using DXLab's WinWarbler component's broadband decoder to generate a stations heard list for all PSK31 transmissions heard on a particular band: http://www.dxlabsuite.com/winwarbler/Heard.jpg This approach depends on stations being QRV, which is not always the case when a band opening is underway. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Gmail - Kevin, Natalia, Stacey Rochelle Sent: Tuesday, October 20, 2009 4:05 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Throught of a Digital Propagation Tool Hi All, Just having a brain spark (not so many now-a-days) With all the new digital modes being devopled upto this date and the way some work; I was wondering if there could be some of propagation tool here? Thought would be some form of automation on spot frequecies on the different bands that cold record/monitor the propergation between continents. Of course this would require stations to dedicate their radio to this, but it could only be when the radio was not in operator use. I can remember quite a few years ago a ham friend who was a Amtor/Packet Sysop (using a PK-232) and he mentioned the band switching would allow him to get a good propagation view. But it was limited as it was setup for specific remote stations, he was not transferring to Asia or Europe, his hop was Austrailia and a couple of West Coast stations. It would require the software to control the scanning and switching of bands on the radio. Most radios that have scan functions, once switched to TX will not satrt scanning again. Thought would be to have the software scan each band at (say) 3 min intervals within a 30 min period, this would allow for slight differences in computer clocks. And then TX and monitor for 5 mins, recording any propergation traffic. Now I might be well off the mark here, just throwing something into the air for thoughts. Then the cycle woud start again. The data could then be uploaded to a central (online) monitoring database. The software could be configured to ignor certain calls for a band as this would swamp the reports. (I don't want to know ZL's (or even VK's) are being heard on 80 or 40mtrs, but I would like to know and report if Europe, Asia or the Americas are. Here is how I would see it mm - Band 00 - 160Mtrs 03 - 80Mtrs 06 - 40Mtrs 09 - 30Mtrs 12 - 20Mtrs 15 - 17Mtrs 18 - 15Mtrs 21 - 13Mtrs 24 - 10Mtrs 27 - 6Mtrs (Most new radios have this now) And then back to the top of the 30 min cycle again. I don't know what mode would be the best but I was thinking digital PSK31, but there could be a better digital mode. Anyway just some thoughts I had floating around and thought I would put it out there. I might be totally off the mark, but hey got to put things out there to think about. Thanks for Listening. Kevin, ZL1KFM.
RE: [digitalradio] Throught of a Digital Propagation Tool
In the post below, the sentence The PropView component will also generate graphical propagation forecasts using the VOACAP or ICEPAC engines, and use the beacon network to calibrate these forecasts. should have been The PropView component will also generate graphical propagation forecasts using the VOACAP or ICEPAC engines; you can use the beacon network to calibrate these forecasts. Automatically calibrating propagation forecasts based on actual beacon signal strength is not yet available... 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Dave AA6YQ Sent: Tuesday, October 20, 2009 10:00 PM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] Throught of a Digital Propagation Tool The is a worldwide network of 18 beacons operated by the Northern California DX Foundation and the International Amateur Radio Union on 5 HF bands from 20m through 10m: http://www.ncdxf.org/beacons.html At the moment, the beacons in Russia and Sri Lanka are down due to hardware problems; repairs are underway. Each beacon transmits for 10 seconds, giving its callsign in CW followed by four dashes: the first at 100 watts, the second at 10 watts, the third at 1 watt, and the fourth at 100 milliwatts: http://www.ncdxf.org/beacon/beaconschedule.html By monitoring a beacon frequency for 3 minutes, you can assess actual propagation from your QTH on that band. Alternatively, you can construct a beacon schedule to quickly determine what bands are open to a particular area of the world from your QTH. Syncing your PC's time-of-day clock with an internet-accessible time service is recommended. The freeware DXLab Suite's PropView component lets you specify a set of beacons you wish to monitor and will direct the Commander component to QSY your transceiver to monitor them. You can select beacons individually, by band, or by bearing (octant) from your QTH. The PropView component will also generate graphical propagation forecasts using the VOACAP or ICEPAC engines, and use the beacon network to calibrate these forecasts. See http://www.dxlabsuite.com/propview/ A list of other tools that can be used to monitor NCDXF/IARU beacons is provided in http://www.ncdxf.org/beacon/beaconprograms.html You can also assess propagation by using DXLab's WinWarbler component's broadband decoder to generate a stations heard list for all PSK31 transmissions heard on a particular band: http://www.dxlabsuite.com/winwarbler/Heard.jpg This approach depends on stations being QRV, which is not always the case when a band opening is underway. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Gmail - Kevin, Natalia, Stacey Rochelle Sent: Tuesday, October 20, 2009 4:05 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Throught of a Digital Propagation Tool Hi All, Just having a brain spark (not so many now-a-days) With all the new digital modes being devopled upto this date and the way some work; I was wondering if there could be some of propagation tool here? Thought would be some form of automation on spot frequecies on the different bands that cold record/monitor the propergation between continents. Of course this would require stations to dedicate their radio to this, but it could only be when the radio was not in operator use. I can remember quite a few years ago a ham friend who was a Amtor/Packet Sysop (using a PK-232) and he mentioned the band switching would allow him to get a good propagation view. But it was limited as it was setup for specific remote stations, he was not transferring to Asia or Europe, his hop was Austrailia and a couple of West Coast stations. It would require the software to control the scanning and switching of bands on the radio. Most radios that have scan functions, once switched to TX will not satrt scanning again. Thought would be to have the software scan each band at (say) 3 min intervals within a 30 min period, this would allow for slight differences in computer clocks. And then TX and monitor for 5 mins, recording any propergation traffic. Now I might be well off the mark here, just throwing something into the air for thoughts. Then the cycle woud start again. The data could then be uploaded to a central (online) monitoring database. The software could be configured to ignor certain calls for a band as this would swamp the reports. (I don't want to know ZL's (or even VK's) are being heard on 80 or 40mtrs, but I would like to know and report if Europe, Asia or the Americas are. Here is how I would see it mm - Band 00 - 160Mtrs 03 - 80Mtrs 06 - 40Mtrs 09 - 30Mtrs 12 - 20Mtrs 15 - 17Mtrs 18 - 15Mtrs 21 - 13Mtrs 24 - 10Mtrs 27 - 6Mtrs (Most new radios have this now) And then back to the top of the 30 min cycle again. I don't know what mode would be the best but I was thinking digital PSK31
RE: [digitalradio] Top Ten Tips For Hams New To Digital Modes ?
1. don't be afraid to ask for help 2. listen to a couple of QSOs in a mode before attempting to make your first one 3. if you must worry, worry about signal quality, not signal strength 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of obrienaj Sent: Thursday, October 01, 2009 10:59 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Top Ten Tips For Hams New To Digital Modes ? So, what would your top 3 TIPS be for someone new to digital modes be ? Andy K3UK
RE: [digitalradio] Callsign info Fill-in
DXKeeper will accept a DDE request to perform a callbook lookup, and places the results in a set of DDE-accessible textboxes. The user specifies which callbook to use on the Callbook tab of DXKeeper's Config window; the choices are 1. RAC CDROM 2. HamCall CDROM 3. HamCall online (subscription) 4. QRZ CDROM 5. QRZ.com subscription 6. QRZ.com via Pathfinder (free with advertisements) Patrick, let me know if you'd like to pursue this. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Patrick Lindecker Sent: Wednesday, September 09, 2009 2:08 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Callsign info Fill-in Hello Stan, I see the need, but up to now (and as far as I know), it is not possible from DXKeeper (through the standard DDE link proposed by Dave) to import Name, Locator, QTH, for a given call sign (if known by the DXKeeper log). The better would be to ask to the DXLabs group, for perhaps a future evolution. 73 Patrick - Original Message - From: mhz14071 n...@arrl.net To: digitalradio@yahoogroups.com Sent: Tuesday, September 08, 2009 9:16 PM Subject: [digitalradio] Callsign info Fill-in I am using Multipsk v 4.14 with DXLabs. Commander is Connected Spot C: Is ON. Initially I have Freq, Mode, Ur RST, My RST, R, S, filled in. When I click on a station in the rx window, The callsign is placed Under CALL. However Name, Locator, QTH. remain empty. Is there a way to get these fields populated from DXLabs? Items such as SEARCH , Number which could provide pertinent information about the present contact require additional intervention. 73 Stan N1ZX Announce your digital presence via our Interactive Sked Pages at http://www.obriensweb.com/sked Recommended digital mode software: Winwarbler, FLDIGI, DM780, or Multipsk Logging Software: DXKeeper or Ham Radio Deluxe. Yahoo! Groups Links
RE: [digitalradio] Fwd: [dxlab] DXKeeper 8.1.6 enhancement for LOTW and some digital modes
Thanks, Andy. For those not familiar with the term synchronizing with respect to LotW operations, it means automatically 1. updating QSOs uploaded to LotW to reflect their subsequent acceptance by LotW (setting LotW QSL Sent to 'Y' and recording the date in LotW QSL Sent Date) 2. updating QSOs uploaded uploaded to LotW to reflect their confirmation via LotW (setting LotW QSL Rcvd to 'Y' and recording the date in LotW QSL Rcvd Date) The first operation is typically initiated a few hours after uploading to LotW -- unless there's a contest in progress or just ending, in which case its best to wait a full day. The second operation is initiated whenever you want to check for new confirmations. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Andrew O'Brien Sent: Sunday, September 06, 2009 6:07 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Fwd: [dxlab] DXKeeper 8.1.6 enhancement for LOTW and some digital modes FYI -- Forwarded message -- From: aa6yq aa...@ambersoft.com Date: Sep 6, 2009 5:48 PM Subject: [dxlab] DXKeeper 8.1.6 is available To: dx...@yahoogroups.com This release - when synchronizing QSOs or QSLs with LotW, QSOs reported by LotW whose Mode is DATA are considered to match a logged QSO whose mode counts as RTTY for ARRL awards (tnx to Bob WU9Q) - updates the AwardInfo.htm, index.htm, Log.htm, LogCompletedMain.htm, LogNewCapture.htm, LogNewMain.htm, ModifyLog.htm, Progress.htm, QSL.htm, Scripts.htm, and ViewEditLog.htm documentation files If your are uploading digital mode QSOs to LotW where the digital mode is not yet supported by LotW (e.g. JT65A), configure TQSL to map these unsupported digital modes to DATA. The above enhancement allows DXKeeper to locate these QSOs in your log when directed to synchronize with LotW; previously, DXKeeper would report such QSOs as not matching any logged QSO because of the change in mode introduced by TQSL. DXKeeper 8.1.6 is available via the DXLab Launcher and via http://www.dxlabsuite.com/download.htm 73, Dave, AA6YQ -- Andy
[digitalradio] RE: [DigitalModes] ClusterClient
Re A netbook typically offers a low screen resolution so any fancy graphics, windows, tables and such would immediately make a bit of a mess on such a small screen. Not true. A Dell Mini 10V ($299) offers a screen resolution of 1024x600, an HP Mini 110 XP ($329) offers a screen resolution of 1024x576, and an Asus Eee PC 900HA ($250) offers a screen resolution of 1024 x 600. These units display 20+% more pixels than the 800x600 SVGA monitors still in use on desktops in the amateur community. 1024x768 was a standard laptop resolution not that long ago... 73, Dave, AA6YQ -Original Message- From: digitalmo...@yahoogroups.com [mailto:digitalmo...@yahoogroups.com]on Behalf Of Mark Thompson Sent: Sunday, August 09, 2009 8:15 PM To: illinoispacketra...@yahoogroups.com; in_pac...@yahoogroups.com Cc: m0...@m0pzt.net; hspac...@yahoogroups.com; digitalmo...@yahoogroups.com; digitalradio@yahoogroups.com; ps...@yahoogroups.com Subject: [DigitalModes] ClusterClient ClusterClient For many years, the DX Cluster network has been used to check for that elusive DX - in the hey-day of packet, cluster access was achieved via a TNC and a basic packet terminal (such as paKet62 or WinPack)... Nowadays, radio amateurs rely heavily on the internet to provide up-to-the-minute information on band conditions, beacon reports and activity. I like to operate /P from my village green (among other places) and often find the DX cluster a useful tool to see what's happening on the HF bands. With the advent of compact netbooks and USB broadband dongles, getting 'net access in the field has never been easier. A netbook typically offers a low screen resolution so any fancy graphics, windows, tables and such would immediately make a bit of a mess on such a small screen - In the absence of a simple DX cluster viewer, I wrote 'ClusterClient'. ClusterClient is a DX Cluster monitor application that connects via telnet to your favourite DX cluster. It offers a simple window with a spot counter (for each band) on the left-hand-side and a couple of text-boxes that permit easy spotting of stations heard/worked. The simple screen layout is thus ideal for laptops and can be re-sized to suit operating preferences. Spots can be filtered to display only the bands you're interested in - no complex cluster filter commands to worry about, just (un)tick the bands on the filter window! This software came about as a result of my work on a /P logging package called MiniLog (http://www.m0pzt.net/projects.php#MiniLog) and a few people asked if I could make the DX cluster window a standalone package... ClusterClient is a free application written by Charlie Davy, M0PZT and is available at: http://www.m0pzt.net/projects.php#ClusterClient [Non-text portions of this message have been removed]
[digitalradio] RE: [DigitalModes] ClusterClient
The $250 Asus price quoted below is incorrect; they're available new for $310. 73, Dave, AA6YQ -Original Message- From: digitalmo...@yahoogroups.com [mailto:digitalmo...@yahoogroups.com]on Behalf Of Dave AA6YQ Sent: Sunday, August 09, 2009 8:43 PM To: digitalmo...@yahoogroups.com; illinoispacketra...@yahoogroups.com; in_pac...@yahoogroups.com Cc: m0...@m0pzt.net; hspac...@yahoogroups.com; digitalradio@yahoogroups.com; ps...@yahoogroups.com Subject: RE: [DigitalModes] ClusterClient Re A netbook typically offers a low screen resolution so any fancy graphics, windows, tables and such would immediately make a bit of a mess on such a small screen. Not true. A Dell Mini 10V ($299) offers a screen resolution of 1024x600, an HP Mini 110 XP ($329) offers a screen resolution of 1024x576, and an Asus Eee PC 900HA ($250) offers a screen resolution of 1024 x 600. These units display 20+% more pixels than the 800x600 SVGA monitors still in use on desktops in the amateur community. 1024x768 was a standard laptop resolution not that long ago... 73, Dave, AA6YQ -Original Message- From: digitalmo...@yahoogroups.com [mailto:digitalmo...@yahoogroups.com]on Behalf Of Mark Thompson Sent: Sunday, August 09, 2009 8:15 PM To: illinoispacketra...@yahoogroups.com; in_pac...@yahoogroups.com Cc: m0...@m0pzt.net; hspac...@yahoogroups.com; digitalmo...@yahoogroups.com; digitalradio@yahoogroups.com; ps...@yahoogroups.com Subject: [DigitalModes] ClusterClient ClusterClient For many years, the DX Cluster network has been used to check for that elusive DX - in the hey-day of packet, cluster access was achieved via a TNC and a basic packet terminal (such as paKet62 or WinPack)... Nowadays, radio amateurs rely heavily on the internet to provide up-to-the-minute information on band conditions, beacon reports and activity. I like to operate /P from my village green (among other places) and often find the DX cluster a useful tool to see what's happening on the HF bands. With the advent of compact netbooks and USB broadband dongles, getting 'net access in the field has never been easier. A netbook typically offers a low screen resolution so any fancy graphics, windows, tables and such would immediately make a bit of a mess on such a small screen - In the absence of a simple DX cluster viewer, I wrote 'ClusterClient'. ClusterClient is a DX Cluster monitor application that connects via telnet to your favourite DX cluster. It offers a simple window with a spot counter (for each band) on the left-hand-side and a couple of text-boxes that permit easy spotting of stations heard/worked. The simple screen layout is thus ideal for laptops and can be re-sized to suit operating preferences. Spots can be filtered to display only the bands you're interested in - no complex cluster filter commands to worry about, just (un)tick the bands on the filter window! This software came about as a result of my work on a /P logging package called MiniLog (http://www.m0pzt.net/projects.php#MiniLog) and a few people asked if I could make the DX cluster window a standalone package... ClusterClient is a free application written by Charlie Davy, M0PZT and is available at: http://www.m0pzt.net/projects.php#ClusterClient [Non-text portions of this message have been removed] [Non-text portions of this message have been removed]
RE: [digitalradio] Re: Zapped PCs, data recovery, and Windows !
re Fast, effective, easy data and O/S moves is a bane for computer techs.
Are there alternatives someone can offer?.
Yes. I use StorageCraft's ShadowProctect for backup and recovery. Like
Norton Ghost, this creates disk images -- but with the ability to perform
hardware-independent recoveries, meaning that you can restore a saved drive
image from PC #1 onto PC #2 where PC #1 and PC #2 are not identical.
Usually, I'm restoring to the same PC that created the image, but on the
several occasions where I've restored an image to different hardware, its
worked flawlessly. PC Labs extensively tested this capability and was quite
impressed.
You can dramatically reduce the time required to recover from hard drive
crash by using StorageCraft or Ghost to create a disk image after you first
loaded your PC with Windows and your applications. Assuming that you
frequently backup your data (logs, scripts, code, whatever), then recovering
from a hard drive crash entails
-- wiping the hard drive
-- restoring the image
-- applying any application updates since the image was created
-- restoring the most recent data backup(s)
StorageCraft and Ghost can both be configured to make a weekly full backup
and a daily incremental backup to an external hard-drive or to a
network-accessible drive. This reduces recovery to a single automated
operation that takes about an hour for my XP systems.
After years of using Ghost (and hating its terrible UI and many defects), I
switched to StorageCraft after seeing some very positive reviews -- and have
been quite happy with it.
I have no relationship with any of the companies mentioned above, but do
have lots of friends in the mass storage business...
73,
Dave, AA6YQ
-Original Message-
From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on
Behalf Of frankk2ncc
Sent: Thursday, July 23, 2009 7:34 PM
To: digitalradio@yahoogroups.com
Subject: [digitalradio] Re: Zapped PCs, data recovery, and Windows !
Andy,
I often need to get the data off of a dead computer and move it to the new
one. The best way to do in my experience is simply to attach the old drive
as a slave to the new one and start draggin' and droppin'.
Once the old HDD detects in your new PC, go to the appropriate folders.
You'll probably want at least My Documents, Desktop, Favorites, email files,
and odd-n-ends laying around, like saved games.
Using programs to backup and restore (i.e. Files Settings Transfer
Wizard), or swapping old Windows HDD onto new PC, simply doesn't work as
well.
You can't move Windows over, as Microsoft deems that the license goes with
the machine ('specially OEM like Dell, etc.) And most programs have to be
installed and can't be moved. Too many files and registry entries to do so
safely. And honestly, if it's been a while since you've re-installed Windows
on the old PC, you're better off with a fresh one.
Fast, effective, easy data and O/S moves is a bane for computer techs. Are
there alternatives someone can offer?. (Something they've tried themselves,
no CNET reviews or GOOGLE search results please!)
Since this isn't a computer help forum, I'm wondering if we should take this
elsewhere?
f, k2ncc
RE: [digitalradio] Re: Zapped PCs, data recovery, and Windows !
I should have been more clear: there is nothing in the Windows EULA that precludes attaching a disk on which Windows has been installed as slave drive to another PC running Windows (or any other OS). Since Windows is not being run on the attached drive, there is no transfer of Windows. I used to buy Dells, but I've been assembling my own PCs for the past couple of years. Thus I don't use OEM Windows licenses. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of frankk2ncc Sent: Thursday, July 23, 2009 7:57 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Zapped PCs, data recovery, and Windows ! --- In digitalradio@yahoogroups.com, Dave AA6YQ aa...@... wrote: There is nothing in the Windows End User License Agreement that precludes attaching a disk on which Windows has been installed to another PC running Windows (or any other OS). You cannot do this with an OEM copy of Windows*. Which, unless you had it custom built, is likely what you have. If you own a Dell, HP, etc., it's OEM. That's the reason you have to re-activate Windows when you change enough hardware. Do enough changes and it's technically a new machine! That's also why OEM copies of Windows is less than half-price of the retail version, which you ARE license to move, so long as it's one PC (assuming 1 CPU license.) If you have frequent power outages, I recommend adding a UPS capable of Amen! 100 bucks will save you a thousand. Brown/black outs are potentially just as damaging as a surge. I recommend APC brand. Get at least a 750 in your model number. f *Current OEM licenses for all Microsoft operating system products are not transferable from one machine to another. http://download.microsoft.com/download/4/e/3/4e3eace0-4c6d-4123-9d0c-c804361 81742/OSLicQA.doc (No MS Word? Download openoffice.org or the DOC viewer here: http://tinyurl.com/docviewer2003 )
RE: [digitalradio] Zapped PCs, data recovery, and Windows !
You cannot replace the C drive of Windows PC #1 with the C drive of Windows PC #2 and expect the resulting machine to boot unless PC #1 and PC #2 use the same motherboard and peripherals. However, you can configure the C drive of PC #2 to be a secondary drive in PC #1 assuming that PC #1 supports the appropriate hardware interface -- e.g. if the PC #2's hard drive uses an IDE interface, then you'll need an IDE interface in PC #1. Addonics makes a product that lets you convert any IDE drive into an external USB drive. Access via USB is significantly slower than native IDE access, but you can connect to any PC with a USB interface; perhaps they have a USB 2.0 version by now: http://www.addonics.com/products/io/ While converters like these are somewhat slow, they allow you to connect a drive up to a running PC -- eliminating the need to power it down, open its chassis, and make the IDE or SATA connection -- which can be difficult in a smaller chassis stuffed with cables. I have occasionally moved IDE drives between PCs whose motherboards were manufactured by different companies, but never encountered a driver problem. When it doesn't work the right off the bat, its usually a master/slave configuration issue; I've also run into IDE cables with bad slave connectivity (cable or connector problems). There is nothing in the Windows End User License Agreement that precludes attaching a disk on which Windows has been installed to another PC running Windows (or any other OS). If you have frequent power outages, I recommend adding a UPS capable of powering your PC long enough to shut down Windows in an orderly fashion; otherwise, you are subjecting the data on your hard drive(s) to risk from both power surges and from being scribbled upon if the drive happens to be in the middle of write operation when the power fails. APC makes a nice product, but be sure to not buy one larger than is needed for ~5 minutes of operation. I have no relationship with any of the companies mentioned above... 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Andrew O'Brien Sent: Thursday, July 23, 2009 6:38 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Zapped PCs, data recovery, and Windows ! After years or running PC's without issues, I have had 4 go bad in 12 months. Two this week, 4 days apart via thunderstorms . One went today just an hour after I had fully reinstalled ham equipment on a new PC that arrived yesterday. The new one survived, I had unplugged it at the sound of thunder. I powered off the older one but forgot to remove the power cord, it got zapped. I put in a spare power supply that i had, that lasted 5 minutes and gave up the ghost. Maybe something else was weakened by the original zap and caused the second power supply to burn out. Anyway, my main issue is the frustrating fact that I have data on hard drives that seems ridiculously complex to retrieve when using Windows based PCs. My local computer store tells me that one cannot simply take a hard drive from a old Pc and place it in a new PC even if you have a Windows license disc for the new PC. Is this correct? In the past I have taken old drives and installed them in different PC's as slave drives. However this causes one to have to re-install many programs because they were originally installed to the registry on a C-drive. So what do I do with 5 hard drives laying around the shack ? In particular one two-drive system with 160 gigs of useful data on it (both have Windows OS on them since both are from different original PC systems!) . It would be nice to install in to a PC without having to get a HD with an OS on it. -- Andy
RE: [digitalradio] Re: Zapped PCs, data recovery, and Windows !
There is nothing legally or morally wrong with attaching a hard drive (as a secondary drive, not as the C: drive) to a PC running Windows in order to move data to or from that hard drive -- whether or not that hard drive has Windows installed (under any flavor of Microsoft license). 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of damienjorgensen Sent: Thursday, July 23, 2009 8:51 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Zapped PCs, data recovery, and Windows ! In that sense then there is no license to run it either, just as there is nothing saying you cannot do it, there is nothing saying you can Its morally wrong, you might not like paying for the correct license, but it doesnt make it any more right than borrwing some bread from a bakers when you're hungry without paying for it. There isnt a sign up saying no borrowing but that doesnt mean you can just go ahead and do it Pay for what you use, fine experement with something. But if you want windows then get the correct edition, with the correct license. OEM editions shouldnt be abused --- In digitalradio@yahoogroups.com, Dave AA6YQ aa...@... wrote: I should have been more clear: there is nothing in the Windows EULA that precludes attaching a disk on which Windows has been installed as slave drive to another PC running Windows (or any other OS). Since Windows is not being run on the attached drive, there is no transfer of Windows. I used to buy Dells, but I've been assembling my own PCs for the past couple of years. Thus I don't use OEM Windows licenses. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of frankk2ncc Sent: Thursday, July 23, 2009 7:57 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Zapped PCs, data recovery, and Windows ! --- In digitalradio@yahoogroups.com, Dave AA6YQ aa6yq@ wrote: There is nothing in the Windows End User License Agreement that precludes attaching a disk on which Windows has been installed to another PC running Windows (or any other OS). You cannot do this with an OEM copy of Windows*. Which, unless you had it custom built, is likely what you have. If you own a Dell, HP, etc., it's OEM. That's the reason you have to re-activate Windows when you change enough hardware. Do enough changes and it's technically a new machine! That's also why OEM copies of Windows is less than half-price of the retail version, which you ARE license to move, so long as it's one PC (assuming 1 CPU license.) If you have frequent power outages, I recommend adding a UPS capable of Amen! 100 bucks will save you a thousand. Brown/black outs are potentially just as damaging as a surge. I recommend APC brand. Get at least a 750 in your model number. f *Current OEM licenses for all Microsoft operating system products are not transferable from one machine to another. http://download.microsoft.com/download/4/e/3/4e3eace0-4c6d-4123-9d0c-c804361 81742/OSLicQA.doc (No MS Word? Download openoffice.org or the DOC viewer here: http://tinyurl.com/docviewer2003 )
RE: [digitalradio] Re: More RSID - PLEASE!
You don't know if an instantaneously empty spot on the waterfall is truly empty until you send QRL? and receive no response, or monitor it long enough to have heard both sides of a QSO if one were in progress. Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of aa777888athotmaildotcom Sent: Wednesday, July 22, 2009 10:34 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: More RSID - PLEASE! You know what's really exciting? We are a hop, skip and jump away from a powerful, lightweight ALE implementation that would probably outperform MIL-STD-188-141A by a large margin. Right now the code scans an entire 3KHz bandwidth for RSID (or more with SDR). When you add in the future, planned SELCAL feature the only things missing after that are scanning and an automated response. It also appears possible that the software would be capable of automatically choosing an empty spot on the waterfall to make the call. This would allow all calls to occur simultaneously and therefore I would suggest time synchronized scanning a la JT65 or WSPR in order to improve probability of intercept without long or repetitive RSID transmissions. Say 4 second dwell per band to allow a +/-1 second guard band on the timing (given a 2 second RSID transmission length). The occasional collision would be worth the simplicity and reliability. Thanks again, Simon! Scott k*b*l*0*0*q --- In digitalradio@yahoogroups.com, Simon \(HB9DRV\) simon.br...@... wrote: I think it'll take up to a year - then we'll be rocking. Also when we use SDR more there will be a big improvement. Simon Brown, HB9DRV www.ham-radio-deluxe.com - Original Message - From: Tony I think we're making progress with RSID Dave, it's just slow to catch on. Have a look at the RSID video in the file section of this reflector.
RE: [digitalradio] Re: Double Entries on Waterfall
If WinWarbler repeatedly decodes the same callsign on multiple frequencies, it compares signal strengths to identify the primary and suppresses the harmonics. Harmonics can be caused by stations generating PSK with modulated audio below 1500 Hz. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Andrew O'Brien Sent: Monday, July 13, 2009 7:40 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Double Entries on Waterfall --- In digitalradio@yahoogroups.com, Ralph Lambert ralph.lamb...@... wrote: Why do I sometimes see double entries for the same call sign in the waterfall. Is this some one working split? It seems like it is a duplex issue or am I way off the boat on this one? 73, Ralph (AJ4GR) How do you know they are doubles? You can expect to see doubles if using multiple decode options like those listed as stations heard in Winwarbler or in the panoramic view in Multipsk. In regular decode for BPSK31 you can also see a harmonic every 1000 Hz if a station is transmitting with a badly over driven signal. You may simply be seeing other close by signals, or possibly mistaking the two parallel vertical lines normally seen in BPSK31. Andy K3UK
RE: [digitalradio] MMTTY VS MMVARI, et al.
I have the source code to MMTTY, have updated MMTTY to enable operation under Vista (version 1.66G), and intend to improve its RTTY decoding capability. MMTTY can transmit via AFSK or FSK; as far as I know, MMVARI is limited to AFSK. 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Rick W Sent: Sunday, June 14, 2009 11:38 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] MMTTY VS MMVARI, et al. After all these years, I finally downloaded N1MM Logger and spent some time with it today. Even logged a few contacts during the ARRL June VHF Contest. Previously, I could not get it work with Vista. The web site might even lead to believe that it may not be supported on Vista. But after doing a search on Vista + N1MM, I found a detailed tutorial from Bob, W1QA, that showed that I was mostly doing things correctly ... except for one little security procedure that I have never had to do with any other program and would never have figured out on my own, HI. And it turns out that the program is not as complicated as I had thought. In fact, the interface can be kept quite simple for the entry window. From what I understand, N1MM requires either MMTTY or MMVARI if you wish to interface via a soundcard for RTTY and some digital modes. Apparently, other digital sound card programs, such as fldigi, can not work with this logger as it is tailored to the MM programs. I am not sure that there are any cross platform contest logging programs so it means you almost have to stay with MS Windows, especially for what I would consider to be ultra high end programs such as N1MM. Can anyone give us a comparison of MMTTY and MMVARI? I understand that Dave, AA6YQ, has been able to update MMTTY. But then I have read that some hams have found MMVARI to decode better under some conditions. And I get the impression that only MMTTY will be updated with MMVARI frozen in beta (but a pretty darn good beta from past experience). Also, does anyone have some first hand experiences with how the HRD Logging program will work as a contest logger compared with N1MM? Lots of questions, but I bet some of you have the answers, HI. 73, Rick, KV9U
RE: [digitalradio] MMTTY VS MMVARI, et al.
Thanks, Sholto, I'm aware of the results Alex has published and the tools he makes available. There are significant opportunities for improvement. 73, Dave, AA6YQ From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com] On Behalf Of Sholto Fisher Sent: Monday, June 15, 2009 12:13 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] MMTTY VS MMVARI, et al. Hi Dave, Alex, VE3NEA has an interesting page about MMTTY performance here: http://www.dxatlas.com/RttyCompare/ I completely agree with his results regarding the performance of TruTTY and has been my preferred RTTY program for while now. 73 Sholto K7TMG Dave AA6YQ wrote: I have the source code to MMTTY, have updated MMTTY to enable operation under Vista (version 1.66G), and intend to improve its RTTY decoding capability. MMTTY can transmit via AFSK or FSK; as far as I know, MMVARI is limited to AFSK. 73, Dave, AA6YQ *From:* digitalradio@ yahoogroups. com [mailto:digitalradi o...@yahoogroups. com] *On Behalf Of *Rick W *Sent:* Sunday, June 14, 2009 11:38 PM *To:* digitalradio@ yahoogroups. com *Subject:* [digitalradio] MMTTY VS MMVARI, et al. After all these years, I finally downloaded N1MM Logger and spent some time with it today. Even logged a few contacts during the ARRL June VHF Contest. Previously, I could not get it work with Vista. The web site might even lead to believe that it may not be supported on Vista. But after doing a search on Vista + N1MM, I found a detailed tutorial from Bob, W1QA, that showed that I was mostly doing things correctly ... except for one little security procedure that I have never had to do with any other program and would never have figured out on my own, HI. And it turns out that the program is not as complicated as I had thought. In fact, the interface can be kept quite simple for the entry window. From what I understand, N1MM requires either MMTTY or MMVARI if you wish to interface via a soundcard for RTTY and some digital modes. Apparently, other digital sound card programs, such as fldigi, can not work with this logger as it is tailored to the MM programs. I am not sure that there are any cross platform contest logging programs so it means you almost have to stay with MS Windows, especially for what I would consider to be ultra high end programs such as N1MM. Can anyone give us a comparison of MMTTY and MMVARI? I understand that Dave, AA6YQ, has been able to update MMTTY. But then I have read that some hams have found MMVARI to decode better under some conditions. And I get the impression that only MMTTY will be updated with MMVARI frozen in beta (but a pretty darn good beta from past experience). Also, does anyone have some first hand experiences with how the HRD Logging program will work as a contest logger compared with N1MM? Lots of questions, but I bet some of you have the answers, HI. 73, Rick, KV9U
RE: [digitalradio] Re: Who Is Where Now : Idea, needs inventor
If this gets off the ground, I will create a small application for DXLab users that conveys your transceiver frequency (from Commander), your operating mode (from WinWarbler if running, otherwise from Commander), and your location (from DXView) to the WWN network. It would do this whenever you make a change, e.g. QSY from 20m to 80m, or change operating modes from RTTY to Olivia; this will minimize the load on whatever mechanism is maintaining the data. To start, I suggest a simple web-based UI that allows filtering by band, operating mode, and location. Someone should also take a hard look at WOTA and understand why it failed to gain traction; there's no sense flying into the same mountain. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Bob Sent: Saturday, May 02, 2009 7:53 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: Who Is Where Now : Idea, needs inventor If I understand the concept correctly, this basically is self-spotting - which I believe to be a great idea. It certainly would not be allowed in contest scenarios, but for most users it would be a wonderful resource. I now use Dave's (AA6YQ) DXLab SpotCollector program for cluster management. It's an excellent program which allows you to view spots using almost any imaginable filter. You can see spots by band, counry, mode, callsign, state, LoTW, etc. - or any combination. A program or online page providing the capabilities of SpotColletor to filter results could really make the Who is Now Where application a powerful - and POPULAR - resource. Instead of spotting someone else, you are just spotting yourself either manually or (preferably) your logging program polls your rig and does it for you. Bob - K3MQ
RE: [digitalradio] Who Is Where Now : Idea, needs inventor
WOTA's failure to provide web access is likely why it never gained traction. If WWN becomes a huge success, then client applications with capabilities like SpotCollector's may appear, but you can't make this a pre-requisite. Without a web interrface, WWN would follow WOTA into the ground. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Alex V Flinsch Sent: Saturday, May 02, 2009 2:09 PM To: digitalradio@yahoogroups.com Subject: Re: [digitalradio] Who Is Where Now : Idea, needs inventor On May 2, 2009, at 7:07 AM, Andy obrien wrote: A good portion of the work is already done, take a look at Who's On The Air Database, all you would need to do is create the web end -- Alex/AB2RC Thanks Alex, I took a look at this and it indeed looks useful. However, I could not find a link to an actual web page that displays who is on the air, is it operational ? Currently there is no web access, just client software, that will connect to the wota server. There is a supported software link, take a look there. -- Alex/AB2RC
RE: [digitalradio] Re: The next big thing - Using Swarm Intelligence
Open interfaces can be as effective as open source. Look at what PSKCORE accomplished long before Moe AE4JY released it to open source. Mori-san JE3HHT's MMTTY has also been effective as a RTTY engine, and remains closed source but provides programmatic access to its functionality. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Vojtech Bubnik Sent: Friday, May 01, 2009 8:57 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re: The next big thing - Using Swarm Intelligence On the other hand I use free community software such a DotNetNuke where community collaboration has really worked I was a big proponent when I was a student. Now with more than 10 years in the industry writing customer specific software I realize how unrealistic is to want every piece of software to be free. Open source is a good model for products, that target vast number of users, so there will be large number of talented programmers in the target group able to participate and there will be some among them willing to participate and cooperate. If the target group is small like in the case of messaging digital modes for HF, the development will be either commercial or one man show at best as the reality has proven. And the target group for digital messaging is vastly smaller than of contesting or casual rag chewing. If Simon would release his DM780 source code (I know it is difficult because he is using some 3rd party commercial libraries), I bet there will be couple of programmers trying to tinker with it and probably there will be some doing contributing minor improvements. The same applies for the fldigi as it targets the second most HAM used operating system today. With pocketdigi I cannot expect much contribution even if I provided source code, because its target group is much smaller notwithstanding the fact, that the PDAs are often replaced by the tiny cheap diskless PCs. Actually, there seems to be a single contribution on the way for PocketDigi - one French sailor is fine tuning Amtor / NavTex. So there will be open source codec for flDigi and DM780, hi. 73, Vojtech
RE: [digitalradio] Re:Solar Cycle 23 Sunspot Group Re-emerges
I agree, Marc. While there are theories, our present knowledge of solar physics provides no solid ground for predicting what may or may not be happening. Extrapolating empirical observations taken over the past few hundred years is risky, since they literally represent a quark in the bucket with respect to the sun's lifetime: http://en.wikipedia.org/wiki/File:Sunspot_Numbers.png Longer reconstructions based on geologic evidence indicate that there's more at work than a simple 11-year cycle with sporadic minimums: http://en.wikipedia.org/wiki/File:Sunspots_11000_years.svg How 'bout that peak at 9000 BC? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Marc PD4U Sent: Friday, May 01, 2009 11:36 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] Re:Solar Cycle 23 Sunspot Group Re-emerges But is the solar minimum the (only necessary and sufficient) explaining factor for a global cooling? As we say in Holland One swallow doesn't make it summer meaning: one cannot 'jump to conclusions' based on unsufficient data, and beside that the swallow is not the explaining factor for summer to arise, but a result of it. Express yourself instantly with MSN Messenger! MSN Messenger
RE: [digitalradio] Who Is Where Now : Idea, needs inventor
I suggest that the Mode column contain the Operating Mode, e.g. CW, Olivia, RTTY, Pactor3. We don't really care what mode a user's transceiver is set to... Having the each user's grid square and region (SA, NA-E, NA-M, NA-W, EU-E, EU-W, AF-N, AF-S, AS, AN, OC) would be helpful for beam heading and propagation purposes. If successful, a simple listing of online participants would be overwhelming. The ability to easily filter the list is fundamental, e.g. show me everyone QRV Olivia on 20m. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Andy obrien Sent: Friday, May 01, 2009 7:00 PM To: digitalradio Subject: [digitalradio] Who Is Where Now : Idea, needs inventor Take at look at this fake web page http://www.obriensweb.com/whoiswhere.html I was thinking about the idea of a reverse DX cluster or an expansion of the concepts behind hrdlog.net . A plce to see who is QRV and where they are on the bands. Not DX spots, just who is where. I had some private emails with a few people about the varying ideas and one correspondent crystallized the thoughts by using the term who is where, now ? It was further suggested that what is needed to facilitate the concept is a very easy uncomplicated process that does not take a lots of resources or bandwidth. An idea that is easily enabled in most common log book software after one configures that software to interface with your rig. The idea would take the frequency/mode info that all moderns rigs send, and populate a webpage via use of TCP or UDP, possibly in to a XML format. I created the fake webpage in the link above to start the idea rolling, an idea of what it may look like . The page I put together is fairly crude, just something to start the idea cooking. This would be a idea that is free , no having to pay an annual fee like some logging programs already require. So, do we have any talent here that could take the idea and create it? Then we could host it (I would volunteer) and try to persuade popular logging/rig control software authors to support it by adding the ability to send the data strings from their software. Anyone take the idea further? Andy K3UK
RE: [digitalradio] The next big thing - Using Swarm Intelligence
The approach you're suggesting is referred to as crowdsourcing, not swarm intelligence. http://en.wikipedia.org/wiki/Swarm_intelligence http://en.wikipedia.org/wiki/Crowdsourcing We have been using a form of crowdsourcing to drive the development of DXLab for the last 9 years. It works well. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of David Sent: Thursday, April 30, 2009 11:21 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] The next big thing - Using Swarm Intelligence Excuse the newbie's lack of knowledge, but... Rapid expansion followed by slow consolidation. This is the way of business and technology. What we have been seeing over the last decade or so is the rapid expansion (diversity) of digital communications schemas. Eventually, market forces will prune the tree and only a few major branches will be left. Some minor branches will survive as museum pieces used by a small collector-antique community. Alternatively, a new digital mode that will either be superior to all others, or will dominate others, as to create a barrir to entry in the market. For example, when Windows and MAC took over the personal computer OS market. Where am I going with this? Why do we have to wait for someone to invent the better mouse trap? We can design it as a community. Perhaps its time for us as a community to develop the specifications for this next big thing. and send it out to the ether for programmers and technologist to build. Specifications: 1. Simple and easy to hook-up for the average computer user. Ideally only requires software, cables, and the Ham's existing transceiver. 2. Inexpensive 3. Open source code and documentation 4. Excellent documentation within source code and within manuals 5. Able scan beacon's and make suggestions for the best mode of operation given the users frequency. 6. Consists of a set of communications protocals and methods to enable it to determine the best format to use given bandwidth, power, band noise, information density, etc. 7. Uses low-bandwidth low baud rates for initial contact and then quickly shifts through machine-to-machine communication to establish the best connection using the best communications schema given the conditions. 8. Can repair bits. 9. Uses standardized tokens to send and recieve often used letters, words, or phrases between machines. 10. Can send any combination of text, images, and speech within the same transmission given enough bandwidth. 11. Can enable the connection of many different Hams in one call working at the same time. 12. Can interface with standard logging software. Well here are the first dozen from an inexperienced newbie that believes in Swarm Intelligence. Perhaps if we all write a solid Specifications document we could next pool money and create a prize to the group that can create the first robust solution for us. Well enough of my soapboxing. 73
RE: [digitalradio] Fwd: Another New Digital Mode!
Does it include a busy frequency detector? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Andrew O'Brien Sent: Wednesday, April 01, 2009 8:46 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Fwd: Another New Digital Mode! I thought I would re-post this from 4/1/06, it was fun. I even got asked to do a presenation on it. Andy--- In digitalradio@yahoogroups.com, Andrew J. O'Brien aobri...@... wrote: Just received this and thought I would pass it along, looks like a new one to play around with! Software is available from my site (see below). Announcing a new digital mode that uses the sound card of your PC. This one is DUSK-A1. developed by Walter DU1SK. DUSK has some fundamental differences from the other digital modes (PSK, MFSK Olivia, etc) in that this mode has been developed primarily for the low bands (80 and 160) with an emphasis on grey-line propagated signals. DUSK-AI takes advantage of AMI- Alternate Mark Inversion . Many digital hams will already be aware that AMI has a 12.5% density minimum. The reduced density minimum of DUSK-A1 creates a more tolerable AOA, or Angle of Arrival A position identification technology that detects the direction of a signal received from a transmitter at only one point. In this system, the transmitter's location is determined from the receivers' antenna position and the AOA of the signals that are from the antennas. In practical terms, grey-line like conditions are created regardless of the actual position of the sun. DUSK-A1 grey line performance, and sun position irrelevance , is also enhanced by the inclusion of CTA. Continuous Time Oversampling A technique that simplifies the job of synchronizing data generated from disparate sampling rates. The technique resamples and synchronizes audio data as needed, and it eliminates the substrate noise and feedthrough problems. The beta version of DUSK-A1 also includes Enhanced Data Rates for Global Evolution an enhanced radio modulation technique for GSM and TDMA (ANSI-136) networks that expands radio timeslots . The expanded time slots also factor in enhanced daylight propagation , especially on 160 meters. When combined with GPRS, it gives a maximum performance with narrow bandwidth. The software does not have full macro features or logging components as yet. Those wishing to test this new mode may download the free software at DUSK-A1 from http://www.obriensweb.com/dusk.htm --- End forwarded message ---
RE: [digitalradio] No FCC data bandwidth limit on HF Re: USA ham rules
re The Winmor implementation in PaclinkW (much to the dismay of the naysayers) has busy channel transmit control enabled. I and others strongly encouraged Rick KN6KB to provide a busy frequency detector in SCAMP. We were optimistic when he agreed to give it a shot, and thrilled by the effectiveness demonstrated during the SCAMP beta; even Rick was surprised by the results. When SCAMP disappeared and WinLink failed to upgrade its PMBOs with the SCAMP busy frequency detector, cynicism returned. Many concluded that the WinLink organization simply prefers to keep its PMBO frequencies clear by QRMing trespassers, rather than having to wait for the frequency to become available. WinMor's inclusion of a busy frequency detector -- hopefully one at least as effective as Scamp's -- is excellent. No knowledgeable amateur radio operator should be dismayed by this, though no one will declare victory until WinLink PMBOs stop QRMing ongoing QSOs -- either because they've been augmented with busy frequency detectors, or replaced by new servers that include busy frequency detection. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of David Little Sent: Thursday, March 26, 2009 10:03 PM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] No FCC data bandwidth limit on HF Re: USA ham rules Rick, I am excited about Winmor. I have been alpha testing PaclinkW, which incorporates Winmor, Packet, Pactor and Telnet. It provides rig control, accepts email from and ports email to Outlook or Outlook Express. The Winmor implementation in PaclinkW (much to the dismay of the naysayers) has busy channel transmit control enabled. I hope that the developer will start allowing connects in the near future. His decision to incorporate Trellis Coded Modulation, to me, seems a very good way to increase accuracy without sacrificing speed. I know it put US Robotics head and shoulders above the competition with 9600 bps in a 300 bps world. I had 3 of the USR HST Dual Standard modems when they were retailing at over $1100.00 each, and used them on a 5 node, 4 line dial up BBS with a gigabyte of storage in the late 1980s. I had to do battle with the telco, trying to convince them that dial-up could, in fact, support speeds above 300 BPS. Each Monday for over a year, I wrote to a different commissioner of the Georgia Public Service Commission until I got them to persuade the telco to replace a 1940s vintage switch with something from the previous decade. I finally succeeded. The switch (which was designed to service an Aircraft Carrier) was finally replaced with something designed for residential use. It was a long hard battle, but worth it in the long run. We face some of the same challenges today in the RF Digital arena. I don't think there is a limitation on Amateur radio for certain sound card modes. I believe the limitation is in acceptance of the bandwidth necessary to serve up email that is formatted and compressed. You may be better able to accept what I am saying if you look at the concept of horizontal and vertical chain of command and provision of service. For Ham to Ham, it is a horizontal plane. For Ham to served agency, it is more vertical. When you factor in NIMS, it gets much more specific. Where a text message that does not contain critical amounts, numbers, quantities, order amounts, audit info, etc... BPSK, RTTY, any of the non ARQ modes are fine; it is not critical info. For an IS-213 working through the system from request to supply to delivery, the ability to send compressed binary info in a formatted package requires a more serious protocol, with absolute error correction that doesn't rely on redundancy ( and the resulting decreased through put ) to get the info through. It takes a well planned and implemented transport layer to move that through the system, from RF to Internet and back to RF where internet infrastructure is damaged. I believe that Winmor may bring the sound card into this arena and make this a reality in a very cost efficient package. Perhaps this will attract more folks to give it a try, but it will always be greeted by some in the Amateur Radio Service as Automated and Common Carrier; even if it saves their Mother's life. This has more to do with being pragmatic than the complexity of the transport layer or protocol. That is the real downside of the entire discussion. We are seeing the stage set for a real battle in the economic universe for superiority of the world exchange choice. It was looking like the battle for the Dollar against the Euro would exert pressure from Governmental entities sole-sourcing the Pactor III protocol, with the revenue ultimately going to the Euro. With China and Russia loosing their appetite for American Debt, along with Opec willing to do anything possible to destabilize the American Dollar, the lines are being drawn.. Currently
RE: [digitalradio] SCAMP and Cynicism? - Nope, no way.
It is true that the long history of WinLink PMBOs QRMing in-progress QSOs has generated more than a little frustration and anger. Some small percentage of those so affected are alleged to have stooped to similar misconduct -- intentionally QRMing WinLink transmissions in revenge. Over the years, more than one WinLink proponent has stated here that given the anti-WinLink sentiment, that busy frequency detectors should not be incorporated in PMBOs because opponents would exploit them to impede WinLink operation. We must put an end to this situation, which means installing an effective busy frequency detector in each WinLink PMBO. Might this be exploited by WinLink opponents? Possibly, but only for a short while. An automatic station is far more patient than any human QRMer, and the elimination of perceived provocation will soon remove the motivation required to spend hours intermittently QRMing a frequency. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of WD8ARZ Sent: Thursday, March 26, 2009 11:11 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] SCAMP and Cynicism? - Nope, no way. Hello Dave, I was there during those scamp beta testing adventures too . and I remember that part of the evaluation. Various levels were played with, akin to a sensitivity level. Bottom line to me was that when the level made it 'work' ie, not transmit when the frequency was 'active', throughput dropped way back Remember those that would intentionally put 'activity' on the frequency to kick in the transmit control system so we had zero activity with scamp No cynicism involved at all, just the real world. 73 from Bill - WD8ARZ (Grateful for those who are doing for all of us what they do, giving us what we have today hi) - Original Message - From: Dave AA6YQ aa...@ambersoft.com To: digitalradio@yahoogroups.com Sent: Thursday, March 26, 2009 10:33 PM Subject: RE: [digitalradio] No FCC data bandwidth limit on HF Re: USA ham rules re The Winmor implementation in PaclinkW (much to the dismay of the naysayers) has busy channel transmit control enabled. I and others strongly encouraged Rick KN6KB to provide a busy frequency detector in SCAMP. We were optimistic when he agreed to give it a shot, and thrilled by the effectiveness demonstrated during the SCAMP beta; even Rick was surprised by the results. When SCAMP disappeared and WinLink failed to upgrade its PMBOs with the SCAMP busy frequency detector, cynicism returned. Many concluded that the WinLink organization simply prefers to keep its PMBO frequencies clear by QRMing trespassers, rather than having to wait for the frequency to become available. snip snip 73, Dave, AA6YQ
RE: [digitalradio] Phone/Image Band FCC bandwidth limit on HF Re: USA ham rules
The table in §97.305 (Authorized emission types) indicates that §97.307(f)(3) applies to all use of RTTY or data emission types in the amateur bands below 28 mhz. §97.307(f)(3) says Only a RTTY or data emission using a specified digital code listed in §97.309(a) of this Part may be transmitted. The symbol rate must not exceed 300 bauds, or for frequency-shift keying, the frequency shift between mark and space must not exceed 1 kHz. The table in §97.305 indicates that §97.307(f)(4) applies to all use of RTTY or data emission types on the 10 meter band; it expands the upper limit on symbol rate to 1200 baud, but retains the maximum FSK frequency shift of 1 kHz. See http://www.arrl.org/FandES/field/regulations/news/part97/d-305.html#307 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of expeditionradio Sent: Tuesday, March 24, 2009 6:44 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Phone/Image Band FCC bandwidth limit on HF Re: USA ham rules Frank k2ncc wrote: I think the confusion I have with quality phone transmission comment is the part that says ...of the same modulation type. Hi Frank, The FCC rule about HF signal bandwidth limit related to a phone emission of the same modulation type, applies mainly to Image signals within the HF Phone/Image sub-bands. That limit DOES NOT APPLY to Data/RTTY signals in the Data/RTTY sub-bands. Beware, there are a few narrow-minded hams continuing to spread disinformation about digital bandwidth limits. What motivates them to do so? Are they trying to scare us into self-inhibiting our freedoms? Or a desire to retard the advancement of radio technology? Whatever their reason is for using the Big Lie technique, it won't work in this case, because it is too easy now for USA hams to go to the source of true facts about bandwidth limits. That source is: the FCC rules on the web. The best way to understand the FCC rules about ham radio is to read the FCC rules, footnotes, tables, orders, definitions, specifications, and FCC opinions. I acknowledge that not everyone is quite as enthusiastic about reading this exciting material as I am. So, perhaps it will help to point out the parts of the tome that are pertinent to this discussion. Turn your hymnals to Part 97 :) - The FCC rules contain a table of frequency bands in paragraph (c) of §97.305 Authorized emission types. - In that §97.305 table, one can see Standards that apply to each sub-band or segment of a ham band. These little details are the key to understanding. Some Notes apply to certain sub-bands but not others. Here are the important things to look for: - Observe that Footnote (2) can be found in the Phone/Image sub-bands but Footnote(2) cannot be found in the Data/RTTY sub-bands! - The text of this important Standard (2) is found in: §97.307 Emission standards paragraph (f) . Here is the full text of §97.307 (f) (2) - No non-phone emission shall exceed the bandwidth of a communications quality phone emission of the same modulation type. The total bandwidth of an independent sideband emission (having B as the first symbol), or a multiplexed image and phone emission, shall not exceed that of a communications quality A3E emission. The main types of non-phone emissions this bandwidth limit applies to, only in the phone/image subbands are: 1. Image content (such as video or photo) 2. FAX image (such as drawings or documents) The FCC rules define what a Phone signal is. It includes speech and some other things, such as selective calling and controlling tones. The FCC definition of the word Phone can be found in §97.3(c)(5) Definitions of terms that are used in Part 97 to indicate emission types. So, everything in the Phone/Image sub-bands that is not Phone is considered Non-Phone. On an interesting side note, did you notice... there is no bandwidth limit for most common types of AM and SSB Phone signals in the HF bands? There is a non-specific limit for angle modulated signals such as FM voice... but that is a topic for another discussion. See you on 20 meters FM simplex! 73 Bonnie KQ6XA
RE: [digitalradio] Phone/Image Band FCC bandwidth limit on HF Re: USA ham rules
There is unquestionably a bandwidth restriction on HF for frequency-shift keying, though there could be debate about what mark and space mean for FSK modes with more than 2 tones; the intent, however, seems clear enough. Consuming 150 kHz of HF spectrum to convey 300 baud using something other than FSK is not precluded by §97.307(f)(3), but would we be happy if everyone started doing it? 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of Trevor Sent: Wednesday, March 25, 2009 5:30 PM To: digitalradio@yahoogroups.com Subject: RE: [digitalradio] Phone/Image Band FCC bandwidth limit on HF Re: USA ham rules FCC say a RTTY or data emission using a digital code specified in this paragraph may use any technique whose technical characteristics have been documented publicly I can't see that you've got any bandwidth restriction on HF subject to each individual carrier having a maximum symbol rate of 300 baud. That in itself is a pointless restriction but it doesn't stop you having wide B/W data transmission using multiple carriers. In the UK there are no restrictions on modulation techniques or the bandwidth subject to the transmission fitting within an Amateur band. 73 Trevor M5AKA --- On Wed, 25/03/09, Dave AA6YQ aa...@ambersoft.com wrote: From: Dave AA6YQ aa...@ambersoft.com Subject: RE: [digitalradio] Phone/Image Band FCC bandwidth limit on HF Re: USA ham rules To: digitalradio@yahoogroups.com Cc: Dave Bernstein AA6YQ aa...@ambersoft.com Date: Wednesday, 25 March, 2009, 2:09 AM The table in §97.305 (Authorized emission types) indicates that §97.307(f)(3) applies to all use of RTTY or data emission types in the amateur bands below 28 mhz. §97.307(f)(3) says Only a RTTY or data emission using a specified digital code listed in §97.309(a) of this Part may be transmitted. The symbol rate must not exceed 300 bauds, or for frequency-shift keying, the frequency shift between mark and space must not exceed 1 kHz. The table in §97.305 indicates that §97.307(f)(4) applies to all use of RTTY or data emission types on the 10 meter band; it expands the upper limit on symbol rate to 1200 baud, but retains the maximum FSK frequency shift of 1 kHz. See http://www.arrl.org/FandES/field/regulations/news/part97/d-305.html #307 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of expeditionradio Sent: Tuesday, March 24, 2009 6:44 PM To: digitalradio@yahoogroups.com Subject: [digitalradio] Phone/Image Band FCC bandwidth limit on HF Re: USA ham rules Frank k2ncc wrote: I think the confusion I have with quality phone transmission comment is the part that says ...of the same modulation type. Hi Frank, The FCC rule about HF signal bandwidth limit related to a phone emission of the same modulation type, applies mainly to Image signals within the HF Phone/Image sub-bands. That limit DOES NOT APPLY to Data/RTTY signals in the Data/RTTY sub-bands. Beware, there are a few narrow-minded hams continuing to spread disinformation about digital bandwidth limits. What motivates them to do so? Are they trying to scare us into self-inhibiting our freedoms? Or a desire to retard the advancement of radio technology? Whatever their reason is for using the Big Lie technique, it won't work in this case, because it is too easy now for USA hams to go to the source of true facts about bandwidth limits. That source is: the FCC rules on the web. The best way to understand the FCC rules about ham radio is to read the FCC rules, footnotes, tables, orders, definitions, specifications, and FCC opinions. I acknowledge that not everyone is quite as enthusiastic about reading this exciting material as I am. So, perhaps it will help to point out the parts of the tome that are pertinent to this discussion. Turn your hymnals to Part 97 :) - The FCC rules contain a table of frequency bands in paragraph (c) of §97.305 Authorized emission types. - In that §97.305 table, one can see Standards that apply to each sub-band or segment of a ham band. These little details are the key to understanding. Some Notes apply to certain sub-bands but not others. Here are the important things to look for: - Observe that Footnote (2) can be found in the Phone/Image sub-bands but Footnote(2) cannot be found in the Data/RTTY sub-bands! - The text of this important Standard (2) is found
RE: [digitalradio] No FCC data bandwidth limit on HF Re: USA ham rules
Thanks. To repeat my first question, What's the bandwidth of an FSK signal whose shift is 1 kHz and whose symbol rate is limited to a maximum of 300 baud? Feel free to parametize as necessary. 73, Dave, AA6YQ -Original Message- From: digitalradio@yahoogroups.com [mailto:digitalra...@yahoogroups.com]on Behalf Of expeditionradio Sent: Thursday, March 26, 2009 12:31 AM To: digitalradio@yahoogroups.com Subject: [digitalradio] No FCC data bandwidth limit on HF Re: USA ham rules Dave, AA6YQ wrote: Do you think its a good idea for amateurs to transmit 150 Khz-wide signals on HF bands like 20m that are 350 Khz wide? Hi Dave, Yes. There are certainly conditions now that would be perfectly fine for 150kHz bandwidth signals to be used at power levels that would not cause harmful interference. There is currently RF digital technology available that can enable 100kHz bandwidth signals on HF to provide many more simultaneous QSOs than our traditional mid-20th century methods are capable of. I predict that in the near future, there will be such advanced radio technologies being used more and more on the ham bands. Through cooperation, goodwill, and planning, new methods can co-exist with legacy modes. Certainly, we can take a lesson from mobile phone technology. As a cellphone RF design engineer, I witnessed significant advancements in spectrum efficiency in that field. It made possible many more users on the same frequency band or channel at the same time, than was ever thought viable when my first cellphone design went to production in 1986. Similar advancement could be forged in ham radio if we open our minds to it and encourage creative talent. 73 Bonnie KQ6XA
