stargate@stargate.COM (02/22/88)
A query in this newsgroup recently asked about the stargate transmission protocols. At the lowest level, the system used by stargate is sufficiently different from what was being envisioned by the Kentucky educational project as to not show too many parallels. The Kentucky system plans to use a one-of-a-kind 2 byte per frame system. This is sufficient for a service that is operating in an environment where bandwidth isn't at a premium (such as the Kentucky eductional TV network). However, most broadcasters require that much higher bandwidth data systems be used, since vertical interval space is at a premium for most commercial and non-commercial metropolitan broadcasters and satellite services. The systems used in such situations are very high bandwidth. For example, the Stargate service currently operates at a constant 2400 bps and takes up but a portion of the data bandwidth on one TV line of Superstation TBS. Other data operations both share the same line and exist on other lines of TBS simultaneously with Stargate. Only through the use of higher bandwidth systems, which can yield maximal revenue for the broadcaster who is selling that space to data services, are broadcasters usually willing to make their vertical intervals available at less than unbelievably high prices for a given service. The complexity of these high bandwidth systems, along with the required multiplexing, segmentation, and error correction systems that are inherent in such systems, is what causes decoders for such systems to be highly integrated. The manufacturers of such systems also tend to consider the exact details of the transmission systems to be proprietary. But unless such systems are used, most broadcasters won't let you touch their vertical interval. At a higher level, the issues of upper level error correction and message retransmission need to be customized for any given application. Stargate is a national service, and we have to be able to deal with a wide variety of different quality cable systems, different sorts of satellite receiving equipment, etc. With the current hardware, we include our own checksum information and repeat blocks on a staggered basis to avoid the "burst" errors that are most common in a cable TV environment. Articles are "aged" so that as an article becomes older it is repeated less and less frequently until after a number of days it no longer is transmitted at all. While we've had no need to do so up to now, it would also be possible to allow sites that wanted to request a particular article that was no longer in the data stream (but that might still be on disk) to be retransmitted via a message request.