On Fri, Sep 4, 2009 at 11:13 AM, Mike Haynes <n4znv1 at gmail.com> wrote: > Brian, > > Comment on the following? and I do see your point of view. > >> We actually have a pretty good >> example of something that works surprisingly well -- PACTOR. >> The one people use in the programs you mention below requires a proprietary >> piece of equipment. >> >> If you >> have used the WinLink or SailMail systems you know what I mean. > These are very nice programs and work well commercially and in the MARS > systems that have frequency allocations > for that purpose.? On the Amateur side I have been frustrated by > interference from these operations being automatic and even > beyond the bandwidth allowed by FCC Rules and Regs.
I have been frustrated by interference from automated PACTOR operations as well. They seem to want to light-up in the middle of my Olivia QSOs. :-) This just points out where there needs to be improvement. As for exceeding the alloted bandwidth, well, that is a legal/policy issue, not a technical one. Certainly PACTOR 1 and PACTOR 2 definitely fall within bandwidth limitations. For that matter it does a good job of showing up our antiquated system for determining acceptable bandwidth limits. PACTOR could actually be considered more efficient because it uses and relinquishes the bandwidth quickly, thus making that spectrum reusable. > So some operator interaction is required in Amateur Operations even in > EmComm and perhaps more so in EmComm > than on a day to day basis.? If one is properly using Winlink in the Amateur > bands it should be controlled by an operator and not > automated to reduce harmful interference. And therefore there is room for improvement. One part of improving the protocol is having it recognize intelligence already in the channel even if it is a different modulation/CODEC. > > ?But > there is a LOT of room for improvement in PACTOR and the layers above > it. > There is room for improvement in? a lot of areas for certain.? Developing > modes that do not involve and exclusive patented interface > allows for more experimentation and further development.? PACTOR? is seeing > this limitation presently I feel. I agree completely. The closed nature of PACTOR means it is a dead end. But we can still learn from it and use that knowledge as a springboard to something better. >> Fldigi represents a springboard for developing something newer, >> better, and more automatic. > > Embracing your points (and I do see some merits if one desires to operate as > you describe) any configuration set-up should have some manual override or > selectivity to add or subtract features.? If one chooses the automatic > configuration then that can function in and of itself.? Should one not want > that then we should be able to select a manual configuration and set things > according to our individual requirements and or style of operation. Agreed. In some cases the human may make a better decision than the automation. > As you are interested in EmComm Actually, I am not particularly interested in EmComm (although I can see where this would be useful to EmComm). My interest stems from a selfish desire to have reliable, low-bit-rate communications via HF from my boat at sea and from purely intellectual curiosity. Just having something that is automated and reliable is certainly interesting in and of itself. > you may want to be familiar or even qualify > as a certified COML (Communications Unit Leader) > which will give you a broader understanding of Agency needs and Comm. That presumes that the Agencies actually understand their own needs, something that I am not sure we can take for granted. > Requirements and Obligations in Disaster or All Hazards > events.? It may help you better define how Amateur Radio can augment > agencies in your community. That is certainly a possibility. > Here is a link that may be of interest to you. > http://www.safecomprogram.gov/SAFECOM/currentprojects/comltraining/ > > If we want to facilitate automatic operations to include how Winlink and > perhaps future programs may want to operate on the bands then we should work > with ARRL to develop Band Plans that facilitate these approaches and if > necessary Petition for rule changes to ensure legality which may further the > state of the art in the public interest and for the public good. You have jumped well ahead of the scope in which I am thinking. My thoughts are geared toward research and experimentation, not implementation. I am certainly not recommending the use of WinLink at this point, only in using it as an example of what has been tried and what we can learn from. > It is interesting to see the different viewpoints on these things.? It is > indeed a multi faceted Diamond we have. I certainly agree there. -- 73 de Brian, WB6RQN/J79BPL
