jgorman01 wrote: > Just a few thoughts: > > * A busy detector is not a panacea for all qrm, especially as you > look at the lower bands. I can easily lay out a scenario for 80 > meters or daytime on 40m where the PMBO should transmit when the freq > is busy. This scenario happens less as you expand the skip zones on > the higher bands. But it needs to be included.
I would say that it happens on any band. On 20, I am in skip with southern W4 land, they become the hidden stations for me. > * The possibility of "killing" a system like winlink needs to be > assessed also. This could be done by folks qrming it with periodic > transmissions. Agreed. I foresaw the same possibilities when I wrote about "Obstination". > * One of the big problems with pactor is its proclivity to expand its > bandwidth regardless of who is operating close to the frequency. > You can hear a 5 minute session at 500 Hz in p2, figure you can start > up a psk31 qso as far away as 500 Hz, and ZAP, the pactor session > moves to p3 and wipes you out. To prevent this, any new protocol > needs to have a process built in that it will never expand once a > session is set up. Going more narrow is no problem, but once done, > you can't go back to a wider bandwidth. Pactor was designed to work > in a commercial channelized system not a shared frequency system. It > was set up so that once you claimed a channel, what you do with it is > up to you. This just doesn't work in a shared freq environment like > amateur radio. Not a big problem if the activity detector senses the maximum possible bandwidth to be possibly used. P3 exchanges are full bandwidth for the server (some 2.4 kHz) and P2 bandwidth (500 Hz) for the ARQ responses. Making the activity detector to hold it only to P2 level would raise the level of complexity and would quite likely deemed not acceptable on channels designated as #P3 by the Winlink network. > * While busy detection may help, it won't be a total solution. The > FCC had a big process a couple of years ago on Cognitive Radio > utilizing Software Defined Radios. The best minds in the business > couldn't come up with an adequate solution that could be applied in > just a transmitter that would prevent interference. The 'hidden' > transmitter problem would still occur. I am sure of that. Identifying arbitrary intelligent signals out of noise is not trivial. A sort of "software antivox" based on energy is far simpler and also, far less reliable. > * A new protocol really needs to utilize some kind of "control link" > and/or stacking of client requests so that a single frequency can > handle multiple requests on a queued basis. This will prevent the > need for horizontal frequency spreading of servers (PMBO's) and > achieve mazimum spectrum efficiency. It did not work well on packet. The choice of 300 baud and shared frequencies (which is not provided on Pactor, that works as a peer to peer link) were the causes I see as main technically based reasons for the HF packet demise. I kept my BBS fwd link on pactor for at least 6 years with far better results and thruput than I had in AX.25 packet. Unless a new protocol is devised (seemingly what the ARRL is seeking) that addresses the shared frequency limitations that packet had. Sharing is not a bad idea, but may be abused with long flags, agressive p-persist and slottime parameters, as happened on HF packet. I saw systems using BPQ set so aggresively that did not allow time for the ARQ reply to arrive and resent the same again before allowing the confirmation to arrive. A few more milliseconds (500 to 1000 milliseconds perhaps) would have avoided massive repeats and used the channel more efficiently. > * The protocol needs to be general in scope, like AX25, and not tied > to just one operating system. Someone mentioned in another message > here that it should work on Windows. The protocol should NOT be tied > to anything Windows specific. It should be implementable on > windows, linux. mac, etc. or even in a TNC like box. The software > that uses it can then be written on whatever system the programmer so > chooses. Seems reasonable...algorithms may be conditioned to, but do not need to be tied to development environments or operating systems. > Thanks for the bandwidth. I had some other thoughts too, but these > are the most important. > > Jim WA0LYK Something that was discussed before is using the maximum bandwidth allowable the least time as possible. It helps to squeeze the juice out of small propagation windows. It is what P3 allows, and seemingly was one of the goals of SCAMP. I understand that all channels may not be wide channels, but at least one or two per band (like 7103.5 on 40 m ) seem desirable. 73, Jose, CO2JA __________________________________________ V Conferencia Internacional de Energía Renovable, Ahorro de Energía y Educación Energética. 22 al 25 de mayo de 2007 Palacio de las Convenciones, Ciudad de la Habana, Cuba http://www.cujae.edu.cu/eventos/cier
