Sorry for the short-notice reload of UO-22. Full operation was restored
after only one interrupted orbit.
The 20 April reload of UO-22 brings in some minor new features.
1) "Sked", which produces a periodic status message, is a facility
which allows the command station to schedule command operations at
any time in the future. It creates log files which will be type 216,
and are of no interest to users.
2) PBP, the broadcast server has had some new features added.
2.1) CL files
The server can now keep track of all the stations who have issued
broadcast requests each day. This information is kept in RAM and
written to a file once per day. The file will be named CLyymmdd and
will have file type 217. The format of the file is an array of 6-byte
strings. There will be a maximum of 400 callsigns in this array (at
the moment.)
2.2) BL files
The BL file data structure has been extended and the BL file format
has been changed slightly. As previously, everything is stored in
log records:
<length> <data>
<length> is an integer telling the number of bytes in <data>
From now on, there will be a record at the beginning of the
file giving the file format version. This record will have
length two and the <data> field will be an integer telling
the version of the log file. The present version is number 2.
The remaining records in the file have BL structures as <data>
/* BL structure for keeping statistics. Cleared hourly. */
struct STAT_STRUCT {
/* Time at which log entry was written. */
time_t log_time;
/* command counters */
long nHolefills;
long nStartFile;
long nEndFile;
long nNoFile; /* No -2 */
long nNoRoom; /* No -1 */
long nNotOK; /* No -3 */
/* nb are byte counters */
long nbRequested; /* bytes in all requests added to queue */
long nbOverwrite; /* removed by another request from same stn */
long nbUnfresh; /* removed from queue after 10 minutes */
long nbPfhErr; /* removed because PFH couldn't be read. */
long nbFopenErr; /* removed because file couldn't be opened. */
long nbEnd; /* removed from queue by file end commands */
long nbTransmitted; /* actually transmitted */
long nhRequested; /* holes in hole fill requests */
/* (not directory fills) */
long nDirReqs; /* dir fill requests */
long nbDirTxd; /* bytes of dirs transmitted */
/* ticks Count time devoted to various actions */
/* a tick is 10 msec */
long ticksDir; /* spent sending directories */
long ticksData; /* spent sending data */
/* Count calls heard this hour. */
int CallsHeard;
};
The BL logs are written roughly every hour, though this can be changed
by ground command. A log will always be written so that the
ticksData, TicksDir, nbDirTxd and nbTransmitted are consistant with
one another. I.E. you can calculate dir and data throughput using the
ticks numbers.
2.3) The PBLIST Transmission
The PBLIST message has been slightly modified. The list
message has two functions; it is an invitation to transmit, and it is
an indication of who is on the list. In the past, all list messages
were transmitted to "PBLIST." From now on, there will be three
possible callsigns:
CALL MEANING
------ -------
PBLIST Invites all groundstations not listed to send their
pending requests.
PBFULL Shows the list, but is not an invitation to send new requests.
PBCTRL Indicates that PBP is in control mode. Only the control
station can send requests.
All versions of PB will respond correctly to these messages, simply
because PB checks for the destination call "PBLIST" before processing
the list packet. All other groundstation software should conform to this
standard (I think that NET already does).
The "PBFULL" packet will be transmitted whenever there are more than X
stations in the list. X can be varied from the ground, and will be used
for some experiments.
Jeff Ward, G0SUL
P.S. There have already been some preliminary results from the new
logging features. On 20 April, 150 stations used UO-22's Broadcast
services. This is about 3 times the number of stations who use the
FTL0 upload service on an average day. The program CLOGDISP is
included here for you to display the CL files.
