--- In [email protected], "Jose A. Amador" <[EMAIL PROTECTED]> wrote:
>
> Not a big problem if the activity detector senses the maximum
> possible bandwidth to be possibly used. P3 exchanges are full
> bandwidth for the server (some 2.4 kHz) and P2 bandwidth (500 Hz)
> for the ARQ responses.
>
> Making the activity detector to hold it only to P2 level would raise
> the level of complexity and would quite likely deemed not acceptable
> on channels designated as #P3 by the Winlink network.
>
>
I suspect an activity detector IS going to have a problem knowing if
there is another close by signal while the auto station is
tranmsitting. In fact, so will a client, while it is transmitting.
If, while transmitting, the busy detector would prevent expanding the
bandwidth if there is a close by signal, then I see no reason this why
this wouldn't prevent qrm'ing of other nearby qso's.
>
>
> It did not work well on packet. The choice of 300 baud and shared
> frequencies (which is not provided on Pactor, that works as a peer
> to peer link) were the causes I see as main technically
> based reasons for the HF packet demise. I kept my BBS fwd link on
> pactor for at least 6 years with far better results and thruput than
> I had in AX.25 packet.
>
> Unless a new protocol is devised (seemingly what the ARRL is
> seeking) that addresses the shared frequency limitations that packet
> had. Sharing is not a bad idea, but may be abused with long flags,
> agressive p-persist and slottime parameters, as happened on HF
> packet.
>
> I saw systems using BPQ set so aggresively that did not allow time
> for the ARQ reply to arrive and resent the same again before
> allowing the confirmation to arrive. A few more milliseconds
> (500 to 1000 milliseconds perhaps) would have avoided massive
> repeats and used the channel more efficiently.
>
>
I wasn't really really talking about interleaving sessions. I was
talking about using an interval of say 3 minutes where the server
tells the current client, hold on, we're going to accept new requests
that will be put into queue. At this point, a broadcast would be
made, a CQ if you will, and clients would use a random timing like
ethernet to determines who goes first. That next client would place a
call to whatever server it wants that is on the freq. and the request
would be put into queue. Since, in winlinks case, the pmbo's are
connected to the internet, they could interactively build a queue list
to determine what server/client goes next after the current session.
>
>
> Something that was discussed before is using the maximum bandwidth
> allowable the least time as possible.
>
> It helps to squeeze the juice out of small propagation windows.
>
> It is what P3 allows, and seemingly was one of the goals of SCAMP.
> I understand that all channels may not be wide channels, but at
> least one or two per band (like 7103.5 on 40 m ) seem desirable.
>
>
I have heard the winlink folks spout this and it may be the case, but
winlink at least, doesn't practice what they preach. If this was
really true, they wouldn't need to have so many different pmbo's on
different frequencies. They would have a lot of them on just one
frequency. Instead, they have set their system up so that there is
immediate access by clients by using horizontal frequency spreading
rather than asking them to monitor a frequency until it clears. With
this type of operation, the speed makes no difference.
> 73,
>
> Jose, CO2JA
>
>
>
>
> __________________________________________
>
> V Conferencia Internacional de Energía Renovable, Ahorro de Energía
y Educación Energética.
> 22 al 25 de mayo de 2007
> Palacio de las Convenciones, Ciudad de la Habana, Cuba
> http://www.cujae.edu.cu/eventos/cier
>
