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: is an integer telling the number of bytes in 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 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 /* 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.