[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: Brief msgs via 9600 Pacsats?

At 02:04 PM 10/21/98 -0400, you wrote:
>   1) It appears that a message may be uplinked as a "file transfer"
>      which is done via a "connection" to the PACSAT or it may be
>      sent in a few UI frames with handshaking.

No, uploading messages must be done in connected mode.

>   2) If I have to take a second or more to turn the Kenwood transceiver
>      TNC from the UHF band for receive to the VHF band for transmit
>      and then back, it would appear that it would miss ANY pacsat
>      handshaking packet unless there were a known and long delay
>      between the uplinked request and the downlinked response.
>Is this handshaking delay a documented quantity?

No, it depends on what other traffic is on the downlink.  The satellite
will wait until the current frame is completed (and possibly a few
more, depending on internal algorithms that are not published)
and then send your ack.  If the downlink is idle, the ack is sent
with no delay, not even the standard TXDelay used on terrestrial
half-duplex packet.  The designers assumed you'd be running
full duplex.

>If the return handshake
>is missed, I assume it is not repeated.  Thus there is no chance that this
>would ever work.  It all boils down to the limits on the T/R turn around
>expectations of the PACSAT protocol as implemented.

It might work a tiny percentage of the time, and only when the downlink
is congested.  Not good.

>3)  This being the case, does anyone see a way to overcome this
>limitation and still be able to uplink your short (typically one
>line) message from the wilderness with such a long delay between transmit
>and receive?

No, I don't see any way around it.

With highly customized TNC software you might be able to make some
improvements by trying to transmit at times when you know the link will
be busy for a while.  I won't go any further down that road, since I know
you don't have the freedom to customize the TNC firmware in the HT.

>In any case, I can see that I can RECEIVE a brief message in Receive
>only mode if the essence of the message is included in the Directory
>broadcast and limited to about 30 characters in the Subject line and a few
>other words in the Key Word display..

You should be able to receive arbitrary messages with little problem.
The transmission you make to request transmission of a file is a UI
frame.  The file you request generally won't be transmitted immediately,
so your receiver will have plenty of time to change bands while your
request is in the queue.  An exception is made for extremely short
requests -- they're jumped to the front of the queue.  So, you might
have to rely on downlink congestion for delay when you're asking for
an extremely short file or for a small "hole" to be filled.

>Actually, from what I read, these fields can be larger, but the limits
>above are what I observe on my WISP (receive only) Directory display.

The full field info is available in the directory file, I believe, if you
want to write a program to extract it.  The directory file is in the
documented Pacsat File Header format, as broadcast by the satellite
in the documented directory broadcast.

73  -Paul

Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org