CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-1-
TITLE OF THE INVENTION
Ethernet Digital Storage (EDS) Card and Satellite Transmission System
Including
Faxing Capability
CROSS-REFERENCE TO RELATED APPLICATIONS
The present application is a continuation in part of U.S Patent Application
Serial No.
09/425,118, filed October 22, 1999, entitled "Ethernet Digital Storage (EDS)
Card
and Satellite Transmission System." The present application is also a
continuation in
part of U.S Patent Application Serial No. 09/287,200, filed April 3, 1999,
entitled
"Satellite Receiver/Router System and Method of Use." The present application
also
claims priority to U.S. Provisional Patent Application Serial No. 60/248,072,
filed
November 13, 2000, entitles EDAS Enhancements Requirements Specification. The
disclosures of all the aforementioned applications are incorporated herein by
reference.
BACKGROUND OF THE INVENTION
The present invention generally relates to an Ethernet Digital Storage (EDS)
Card, satellite transmission system, and method for data delivery or
advertising.
More particularly, the present invention relates to an EDS Card for receiving,
storing,
and transmitting files including video, audio, text, fax, and multimedia
files,
especially files received via satellite transmission.
The effort to develop a system for error-free, time-crucial distribution of
bandwidth consumptive files has driven the data delivery industry for some
time.
Within the broadcasting industry, especially radio broadcasting, private
network
systems have been developed to facilitate the distribution of audio files for
subsequent
radio broadcasting. These private network systems often use satellites as
"bent-pipes"
to deliver their content reliably and quickly. These private network systems
have
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-2-
evolved from primitive repeaters to systems allowing the receiving station
greater
degrees of interaction and reliability.
The Internet is an enormous network of computers through which digital
information can be sent from one computer to another. The Internet's strength -
its
high level of interconnectivity -also poses severe problems for the prompt and
efficient distribution of voluminous digital information, particularly
digitized
imaging, audio, or video information, such as an audio broadcast transmission.
Internet service providers (ISP's) have attempted to accelerate the speed of
delivery of
content to Internet users by delivering Internet content (e.g., TCP/IP
packets) to the
user through a satellite broadcast system. One such system is the direct-to-
home
("DTH") satellite delivery system such as that offered in connection with the
trademark, "DirecPC." In these DTH types of systems, each subscriber or user
of the
system must have: (i) access to a satellite dish; (ii) a satellite receiver
connected to the
satellite dish and mounted in the user's PC; and (iii) an Internet back
channel in order
to request information from Internet Web sites. The DTH system is thus quite
costly,
since each user must have its own receiver and connection to a satellite dish.
The
DTH system is also somewhat difficult to deploy since the satellite antenna
and
receiver is mounted in each DTH user's PC.
The DTH system also does not take advantage of pre-existing satellite
systems, and it often is a single Garner system, dedicated to the delivery of
Internet
content to the user. It does not allow the user flexibility to receive, much
less
distribute to others, other types of services, such as non-Internet radio
broadcast or
faxing services for example. The DTH systems also typically modify the IP
packets at
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-3-
the head end, thus introducing significant processing delay through the need
to
reconstruct packets on the receiving end.
DTH systems typically utilize the DVB standard, in which event the system
might broadcast other services. DVB systems, however, utilize a statistical
data
Garner. For this and other reasons, the DVB systems often cause significant
additional
delay due to the need to reconstruct packets from the statistically
multiplexed Garner
sent through DVB system. DTH systems also add significant overhead to the data
stream they provide, thus requiring additional bandwidth and associated costs
in order
to processes and deliver DVB data streams.
The DTH system is also typically quite limited in its bandwidth capabilities.
The consumer DirecPC system, for example, is limited to 440 kbps, thus
limiting its
effectiveness as a reliable, flexible, and quick distribution vehicle for
Internet content,
particularly voluminous content, to all users of the system through the one
Garner.
Another system used by ISP's and others to deliver Internet content through
satellites is the use of commercial or professional quality satellite
receivers in
conjunction with traditional Internet routers connected into an ISP LAN or
similar
LAN for delivery of the received content through its LAN to its subscribers
either on
the LAN or through modems and telecommunications lines interconnecting the
modems. (See Prior Art Figure 3.) These types of separate receiver-and-muter
satellite systems have typically required use of traditional satellite data
receivers with
integrated serial (often RS-422) interfaces or data outputs. The data output
is
connected into the router, which then converts the data into Ethernet
compatible
output and routes and outputs the Ethernet onto the LAN.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-4-
The applicant has discovered that these prior art data receiver and separate
muter systems present many problems. For example, the traditional data
receivers are
relatively inflexible and support only one or two services; and the use of a
separate
router is expensive. In addition, these types of systems usually employ a DVB
transport mechanism, which not well suited to transmitting Internet and
similar types
of content for a number of reasons. One reason is that, as noted above, the
DVB
transport protocol and mechanism add substantial delays into the system.
Another is
that, as the applicant has discovered, the DVB transport mechanism utilizes
excessive
amounts of bandwidth.
In addition, prior art data receiver and separate muter systems often employ a
separate storage memory, often linked to the router via a Local Area Network
(LAN)
which adds further expense, complication, and bandwidth consumption.
Additionally,
prior art receivers typically are unable to provide multicasting and expensive
multicasting routers must be added to the system to support multicasting.
The applicants have attempted to solve many problems through the
development of several prior art satellite data transmission systems and
modules,
available from StarGuide Digital Networks, Inc. of Reno, Nevada, that may be
added
to a receiver including an Asynchronous Services Statistical Demux Interface
Module, a Digital Video Decoder Module, an MX3 Digital Multimedia Mulitplexer,
a
Digital Audio Storage Module, and a Digital Multimedia Satellite Receiver.
With regard to the field of broadcasting, specifically the distribution of
advertising materials and time-critical materials, several improvements have
long
been desired.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-5-
Typically, many corporations may desire to have an ad campaign "localized" or
"regionalized," for example by including the voice of a locally known
celebrity. The
corporation desiring to localize the ad campaign in the various localities
would
contract with local networks, such as radio networks in the localities to
construct
advertisements that were specific to an individual locale yet abided by
general
corporate guidelines. The local buys of advertising from the local advertising
providers are then presented locally, for example, the advertising content may
be
distributed through the local radio stations.
Starguide recognized that the localization of advertisements or "spots"
required a great deal of duplication of effort and expense. Additionally,
Starguide
recognized that performing the ad buys locally deprives the nationwide radio
networks of advertising revenues which the nationwide networks could achieve
more
efficiency and in a broader scale. That is, the nationwide network may develop
a
single advertisement and provide a regionalized advertisement to the local
networks.
Starguide recognized that the development of a cost effective system for
providing regionalized advertisements would be very commercially valuable to
nationwide advertisers in order to reduce their total advertising expenses and
to
nationwide networks to provide access to business opportunities typically
reserved for
regional agencies.
For example, spot localization and distribution is extremely cumbersome in
prior art systems. Often prior art systems require audio tapes to be generated
at a
centralized location and then physically mailed to a local broadcaster, which
is costly,
labor intensive and not time effective. Starguide recognized that the
development of a
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-6-
distribution system providing reliable, fast and efficient delivery of content
as well as
increased automation capability throughout the system may be of great use in
data
delivery enterprises such as nation ad campaign distribution and may lead to
industry
growth and increased profitability. For example, increased automation, ease of
use
and speed of distribution of a national ad campaign to a number of local
broadcasters
may allow increased broadcast advertising and may draw major advertising
expenditures into national broadcasting advertising campaigns.
Additionally, Starguide also recognized that an advertisement distribution
system providing additional functionality would also be highly desirable,
particularly
in the radio, TV and Internet distribution industries. For example, the
distribution
system may be used to distribute data other than advertising data, such as fax
data.
By distributing data via a dedicated, internally controlled network, a user
may achieve
several benefits such as reduced communication fees and better control and
tracking
of data passing over the network. Furthermore, such an advertisement
distribution
system may be expandable to form a "mini-telco" or mini-telecommunications
company providing many services to the users.
Additionally, Starguide further recognized that such an advertising
distribution
system which is more. easily accessible by a user and may be interacted-with
to a great
degree would also be highly desirable. For example, the ability of the system
to
provide access via a web browser to advertising content and configuration
parameters
of the system may also be highly desirable.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
BRIEF SUMMARY OF THE INVENTION
A preferred embodiment of the present invention provides an Ethernet Digital
Storage (EDS) Card operable in a satellite data transmission system for
storing and
routing any kind of data including audio, video, text, fax, image or
multimedia files.
Use of the preferred embodiment provides a satellite data transmission system
with
the ability to receive a multiplexed data stream of a variety of files, such
as audio,
video, data, fax, images, and other multimedia files. Received files may be
demultiplexed and stored automatically on the EDS Card locally in a flash
memory
storage. Files stored in the flash memory storage may be retrieved later.
Alternatively, received files may be routed by the EDS Card over a network
such as a
Local Area Network (LAN). In a preferred embodiment, audio files may be
retrieved,
mixed with external audio, further manipulated and output as audio output. All
files
stored in the flash memory storage may be transmitted externally via an
Ethernet Port,
an M&C Port or a modem-enabled Auxiliary RS-232 Port. In addition to a data
stream received from a satellite, files may be uploaded to the flash memory
storage
via an Ethernet Port, an M&C Port or a modem-enabled Auxiliary RS-232 Port.
The
EDS Card provides efficient multicasting via an IGMP multicasting processor.
The
EDS Card includes an HTTP server and a DNS resolver allowing the operation of
the
EDS Card and the contents of the flash memory storage to be accessible
remotely via
a web browser. The EDS Card provides a satellite receiver with a digital data,
video,
or audio storage and local insertion device, web site, Ethernet output device
and
muter.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
_g_
Additionally, a preferred embodiment of the present invention provides a fax
distribution system that provides a virtual private network for faxes to
increase
security and on-time deliverability of faxes, to replace transmission over
standard
telephony resources when the standard resources are faulty or intermittent, to
minimize costs associated with faxing by directly transmitting faxes over the
satellite
network to a local fax machine for transmission to a local user, and to
provide easy
record keeping or backup of faxes.
Additionally, in a preferred embodiment, the faxing ability may be combined
with the Ethernet routing and data storage capabilities of the EDS card, which
is most
preferably removable and field-insertable and upgradable.
These and many other aspects of a preferred embodiment of the present
invention are discussed or apparent in the following detailed description of
the
preferred embodiments of the invention. It is to be understood, however, that
the
scope of the invention is to be determined according to the accompanying
claims.
ADVANTAGES OF A PREFERRED EMBODIMENT OF THE INVENTION
The various preferred embodiments of the present invention provide at least
one, but not necessarily more than one of the following advantages:
To provide an EDS card capable of storing any kind of data, not just audio
data. For example, the EDS card may be used to store text, numbers,
instructions,
images or video data.
To distribute TCP/IP compatible content by satellite.
To provides an Ethernet/Router card that may be mounted in a satellite
receiver quickly, easily, and economically.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-9-
To provide a satellite receiver with the capability of receiving TCP/IP
compatible content and routing and distributing it onto a LAN or other
computer
network without need for a router to route the content onto the LAN or
network.
To provide a preferred card that may be hot swappable and may be removed
from the receiver without interfering with any other services provided by the
receiver.
To provide a preferred card that may be used in a receiver that may deliver
other services, through other cards, in addition to those provided by the
present
invention itself. For example, other services, available from StarGuide
Digital
Networks, Inc. of Reno, Nevada that may be added to a receiver include an
Asynchronous Services Statistical Demux Interface Module, a Digital Video
Decoder
Module, an MX3 Digital Multimedia Mulitplexer, a Digital Audio Storage Module,
a
Digital Audio Decoder, and a Digital Multimedia Satellite Receiver.
To provide satellite distribution of TCPlIP compatible content, eliminating
the
need for each PC receiving the content through the receiver to have its own
dish or its
own satellite receiver.
To provide satellite TCP/>I' distribution to PC's without having a satellite
receiver being mounted in a PC and subject to the instability of the PC
environment.
To provide data services in addition to delivery of Internet content. Another
advantage is that the satellite receiver in which the card is inserted
preferably can
provide yet additional services through other cards inserted in slots in the
receiver.
To allow existing networks of satellite receivers to be adapted to deliver
Internet services by mere insertion of the present cards in the receivers
without having
to replace the existing networks.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
- 10-
To provides the ability to deliver TCP/IP content to Ethernet LAN's without
need for custom software.
To provide a system in which, both the overall system and the Ethernet/Router
card in particular, process IP packets without modification or separation of
the
contents of the packets. The applicants' satellite transmission system and the
present
Ethernet/Router card are thus easier to implement; and since they process each
IP
packet as an entire block with no need to reconstruct packets on the receiving
end, the
system and the Ethemet/Router card more quickly process and route the IP
packets
from the head end to an associated LAN on the receiving end.
To provide an Ethernet portion of the card useing an auto-negotiating 10/100
BT interface so that the card can integrate into any existing 10 BT or 100BT
LAN.
To provide a PPP connection to tie into an external modem so that the card
can be tied to a distribution network via telco lines. This connection can be
used for
distribution as well as automatic affidavit and confirmation.
To provide a DHCP (Dynamic Host Configuration Protocol), which allows the
card's IP address to be automatically configured on an existing LAN supporting
DHCP. This eliminates the need too manually configure the card's IP address.
To provide a DNS (Domain Name Service) protocol to allow the card to
dynamically communicate with host web servers no matter what their IP address
is.
To provide an HTTP server (web server) so that the card may be configured or
monitored via a standard Web Browser. Additionally, the files stored on the
EDS
CARD may be downloaded or upload via a standard web browser.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-11-
To provide an EDS card including an analog audio input port to allow a "live"
feed to be mixed/faded with the locally stored audio. Additionally, an analog
output
is provided to allow auditioning of the local feed.
To provide an EDS Card having a relay input port that allows external
command of the card's behavior. Additionally, the card may be commanded via an
Ethernet link, an Auxiliary RS-232 Port, a Host Interface Processor, or a
received data
stream.
To provide an EDS Card including a scheduler which allows the card to act at
predetermined times to, for example, play an audio file and, if desired, to
automatically insert such content into another content stream being received
and
output by the receiver and card.
To provide an IGMP multicasting processor to provide efficient multicasting
to an attached LAN. Alternatively, the IGMP multicasting processor may be
configured to allow a local muter to determine the multicast traffic.
To provide an EDS Card including a local MPEG Layer II decoder to allow
stored audio files to be converter to analog audio in real time.
To provide an EDS Card that may be configured as a satellite WAN with
minimal effort and external equipment.
To allow a network to deploy a receiver system with, for example, an audio
broadcasting capability, and later add additional capability such as Ethernet
output,
etc., by adding the EDS card of the present invention. This prevents the user
from
having to replace the receiver, remove the audio card or utilize a separate
satellite
carrier for the transmission of differing content types.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
- 12-
To provide the ability to distribute faxes between a producer and a number of
recipients and preferably to do so without incurnng typical telecommunication
fax
charges.
To allow the faxing capabilities of the receiver system to be coupled to the
Ethernet connectivity, storage, and web access of content and configuration
information for ease of use.
There are many other objects and advantages of the present invention, and in
particular, the preferred embodiments and various alternatives set forth
herein. They
will become apparent as the specification proceeds. It is to be understood,
however,
that the scope of the present invention is to be determined by the
accompanying
claims and not by whether any given embodiment achieves all objects or
advantages
set forth herein.
BRIEF DESCRIPTION OF THE DRAWINGS
The applicants' preferred embodiments of the present invention are shown in
the accompanying drawings wherein:
Figure 1 illustrates a block diagram of the EDS card of the present invention;
Figure 2 illustrates a hardware block diagram of the EDS Card of the present
invention;
Figure 3 further illustrates some of the functionality of the EDS Card of the
present invention;
Figure 4 is a block diagram showing the applicant's preferred uplink
configuration utilizing a multiplexer to multiplex the satellite transmission;
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-13-
Figure 5 is a block diagram of the applicants' preferred downlink
configuration
for reception of a multiplexed satellite transmission for distribution onto an
associated
LAN;
Figure 6 is a block diagram of the applicants' preferred redundant uplink
configuration for clear channel transmission of up to 10 mbps;
Figure 7 is a block diagram of the applicants' preferred redundant uplink
configuration for clear channel transmission of up to 50 mbps;
Figure 8 is a block diagram of one embodiment of the applicants' preferred
satellite transmission system, with an Internet backchannel, in which the
applicants'
preferred EDS card has been inserted into a slot in a satellite receiver in
order to
distribute Internet content through the card onto an Ethernet LAN to which the
card is
connected;
Figure 9 is a block diagram of an alternative embodiment of the applicants'
preferred satellite transmission system for distribution of TCP/IP content
onto an
intranet with a telecommunications-modem-provided backchannel from the
receiver
to the headend of the intranet;
Figure 10 is a block diagram of a prior art satellite data receiver, separate
Internet muter, and LAN, as described in the BACKGROUND section above.
Figure 11 illustrates a flowchart of the present invention employed to
distribute data or content, for example, audio advertising, from a centralized
origination location to a number of geographically diverse receivers.
Figure 12 illustrates a system 1200 for providing fax service over a satellite
network using the EDS card 100 according to an embodiment of present
invention.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
- 14-
Figure 13 illustrates a wiring diagram 1300 for an affiliate system according
to
a preferred embodiment of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
Figure 1 illustrates a block diagram of the EDS card 100. The EDS card 100
includes a StarGuide backplane 102, an HDLC Processor 104, a host interface
processor 106, a Network Protocol Filtering (Stack) processor 108, a local
message
filtering processor 110, a Store and forward address/file filtering processor
112, a
flash memory storage 114, an audio decoder 116, a decoder monitor and control
processor 118, an audio filter 120, an audio mixer/fader 122, an audio driver
124, an
audio output port 126, an audio input port 128, an audio receiver 130, an
audio
audition port 132, an event scheduler 134, a relay input processor 138, a
relay input
port 140, a RS-232 Transceiver 142, and M&C Port 144, a 10/100BT Ethernet
Transceiver 146, an Ethernet Port 148, a confirmation web client 150, a PPP
and
modem processor 152, an RS-232 Transceiver 154, an Auxiliary RS-232 Port 156,
an
IGMP multicasting processor 158, an HTTP Server 160, a DHCP Processor 162, and
a DNS Resolver 164.
In operation, the StarGuide backplane 102 interfaces with a receiver,
preferably the prior art StarGuide~ II Receiver (not shown), available from
StarGuide
Digital Networks, Inc., Reno, Nevada. The Backplane 102 provides the EDS card
100 with a clock 101 and an HDLC packetized TCP/IP data stream 103. As
mentioned above, the TCP/IP data stream may represent, audio, video, text,
image or
other multimedia information, for example. The clock 101 and the data stream
103
are provided to the HDLC processor 104 which depacketizes the data stream 103
and
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
- 15-
outputs TCP/IP packets to the network protocol filtering (stack) processor
108. The
stack processor 108 may be configured to control the overall function and data
allocation of the EDS card 100. The stack processor 108 may send the received
data
stream to any one of the IGMP multicasting processor 158, the HTTP Server 160,
the
DHCP Processor 162, the DNS resolver 164, the confirmation web client 150, the
10/100BT Ethernet Transceiver 146, the PPP and modem processor 152 or the
local
message filtering processor 110 as further described below. The stack
processor 108
may be controlled by commands embedded in the data stream, commands sent
through the M&C Port 144, commands sent through the Ethernet Port 148,
commands
through the Host interface processor 106, or commands received through the
Auxiliary RS-232 port 156. These commands may be expressed in ASCII format or
in the StarGuide Packet Protocol. The commands received by the stack processor
108
via the Ethernet Port 148 may use various interfaces including Simple Network
Management Protocol (SNMP), Telnet, Hyper Text Transfer Protocol (HTTP) or
other interfaces. The externally receivable operation commands for the stack
processor 108 are set forth in APPENDIX A.
The stack processor 108 may further decode a received data stream to send a
raw message 109 to the local message filtering processor 110. The local
message
filtering processor 110 determines if the raw message 109 is a content message
such
as audio, video, or text, for example, or a command message. The local message
filtering processor 110 passes content messages 111 to the Store and forward
address/file filtering processor 112 and passes command messages 135 to the
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
- 16-
command processor 136. The Store and forward address/file filtering processor
112
generates encoded files 113 which are passed to the flash memory storage 114.
The flash memory storage 114 stores the encoded files 113. Encoded files
stored in the flash memory storage 114 may be passed to the audio decoder 116
if the
encoded files are audio files. Encoded files 172 other than audio files may be
passed
from the flash memory storage 114 to the stack processor 108 for further
transmission. The flash memory storage 114 preferably stores at least up to
256 audio
files or "spots". The flash memory storage 114 preferably uses MUSICAM MPEG
Layer II compression with a maximum spot size up to the storage capacity if
the file
stored is a compressed audio file. Other files, such as compressed video
files, may be
stored using MPEG2 compression or an alternative compression protocol. The
storage capacity of the flash memory storage 114 is preferably at least 8 MB
to 144
MB, which is roughly equivalent to 8 to 144 minutes of digital audio storage
at 128
kbps MPEG audio encoding. The flash memory storage 114 preferably supports
insertion activation with the relay contract closure in absolute time and
supports an
insertion mode with or without cross-fading.
The audio decoder 116 decodes the encoded files 115 and generates an analog
audio signal 117. The audio decoder 116 is monitored by the decoder monitor
and
control processor 118 while the audio decoder 116 decodes the encoded files
115.
The analog audio signal 117 is passed to the audio filter 120 where the analog
audio
signal 117 is further filtered to increase its audio output quality. The audio
decoder
116 includes an MPEG Layer II decoder allowing the pre-encoded stored files
from
the flash memory storage 114 to be converted to analog audio signals 117 in
real time.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
- 17-
The analog audio signal is then passed from the audio filter 120 to the audio
mixer/fader 122 and the audio audition port 132. The analog audio signal 119
received by the audio audition port 132 may be passed to an external listening
device
such as audio headphones to monitor the audio signal. The audio audition port
132 of
the EDS card allows the locally stored audio to be perceived without altering
the
output audio feed through the audio output port 126. The audio audition port
132 may
be of great use when the audio output port 126 output is forming a live
broadcast feed.
An external audio signal may be received by the audio input port 128. The
external audio signal is then passed to the audio receiver 130 and the
resultant analog
audio signal 131 is passed to the audio mixer/fader 122. The audio mixer/fader
may
mix or fade an external analog audio signal 131 (if any) with the audio signal
received
from the audio filter 120. The output of the audio mixer/fader is then passed
to the
audio driver 124 and then to the audio output port 126. Also, the audio input
port 128
allows a "live" audio feed to be mixed or faded at the audio mixer/fader 122
with a
locally stored audio spot from the flash memory storage 114. The audio
mixer/fader
allows the live feed and the local (stored) feed to be mixed, cross faded or
even
amplified. Mixing entails the multiplication of two signals. Cross fading
occurs
when two signals are present over a single feeds and the amplitude of a first
signal is
gradually diminished while the amplitude of a second signal is gradually
increased.
Mixing, amplification, and cross fading are well known to those skilled in the
art.
As mentioned above, the flash memory storage 114 may store a large number
of audio spot files in addition to files such as video, text or other
multimedia, for
example. Files stored in the flash memory storage 114 are controlled by the
event
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-18-
scheduler 134. The event scheduler 134 may be controlled through the relay
input
processor 138 of the relay input port 140 or through the command processor
136. The
command processor 136 may receive programming including event triggers or
command messages through the local message filtering processor 110 and the
stack
processor 108 from the M&C Port 144, the Auxiliary RS-232 Port 156, the
Ethernet
Port 148, the received data stream 103, or the Host interface processor 106.
For example, with respect to audio spots stored in the flash memory storage
114, the audio spots may be triggered at a pre-selected or programmed time by
the
event scheduler 134. The event scheduler 134 may receive audio spot triggers
from
either the command processor 136 or the relay input processor 138. The command
processor 136 may receive programming including event triggers from the M&C
Port
144, the Auxiliary RS-232 Port 156, the Ethernet Port 148, the received data
stream
103, or the Host interface processor 106. External audio spot triggers may be
received directly by the relay input port 140, which passes digital relay info
141 of the
audio spot trigger to the relay input processor 138. Additionally, the local
message
filtering processor 110 may detect a command message in the raw message 109 it
receives from the stack processor 108. The command message detected by the
local
message filtering processor 110 is then passed to the command processor 136.
Also,
the command processor 136 may be programmed to trigger an event at a certain
absolute time. The command processor 136 receives absolute time information
from
the StarGuide backplane 102.
Additionally, once the command processor 136 receives a command message,
the command processor 136 sends a response message to the command originator.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
- 19-
For example, when the command processor 136 receives a command message from
the M&C Port 144, the command processor 136 sends a response message 145 to
the
M&C Port 144 via the RS-232 Transceiver 142. Similarly, when a command
message is received from the Ethernet Port 148, Auxiliary RS-232 Port 156, or
Host
interface processor 106, the command processor 136 sends a response message
through the stack processor 108 to the command originating port to the command
originating device. When a command message is received from the received data
stream 103, a response may be sent via one of the other communication ports
148,
156, 106 or no response sent.
In addition to activating audio spots, the event scheduler 134 may trigger the
flash memory storage 114 to pass a stored encoded file 172 to the stack
processor 108.
The encoded file 172 may be audio, video, data, multimedia or virtually any
type of
file. The stack processor 108 may further route the received encoded file 172
via the
Ethernet Port, 148, the Auxiliary RS-232 Port 156, or the M&C Port 144 to an
external receiver. Additionally, the stack processor 108 may repackage the
received
encoded data file 172 into several different formats such as multicast via the
IGMP
Multicasting Processor 158, or HTTP via the HTTP server 160, telnet, or SNMP
for
external transmission.
The 10/100BT Ethernet Transceiver 146 receives data from the stack
processor 108 and passes the data to the Ethernet Port 148. The 10/100BT
Ethernet
Transceiver 146 and Ethernet Port 148 may support either lOBT or 100BT
Ethernet
traffic. The 10/100BT Ethernet Transceiver 146 uses an auto-negotiating
10/100BT
interface so that the EDS card 100 may easily integrate into an existing lOBT
or
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-20-
100BT LAN. In addition to supplying data to an existing lOBT or 100BT LAN via
the
Ethernet Port 148, the stack processor 108 may receive data from an external
network
via the Ethernet Port 148. External data passes from the Ethernet Port 148
through
the 10/100BT Ethernet Transceiver 146 to the stack processor 108. The external
data
may constitute command messages or audio or video data for example.
The EDS card 100 also includes a PPP and modem processor 152. The PPP
and modem processor may be used for bi-directional communication between the
stack processor 108 and the Auxiliary RS-232 Port 156. The PPP and modem
processor 152 reformats the data for modem communication and then passes the
data
to the RS-232 Transceiver 154 of the Auxiliary RS-232 Port 156 for
communication
to an external receiving modem (not shown). Data may also be passed from an
external modem to the stack processor 108. The PPP and modem processor 152
allows the EDS card 100 to communicate with an external modem so that the EDS
card may participate in a distribution network via standard telecommunications
lines,
for example. The PPP and modem processor 152 may be used for distribution as
well
as automatic affidavit and confirmation tasks.
The EDS card 100 also includes an Internet Group Multicasting Protocol
(IGMP) Multicasting Processor 158 receiving data from and passing data to the
stack
processor 108. The IGMP multicasting processor 158 may communicate through the
stack processor 108 and the Ethernet Port 148 or the Auxiliary RS-232 Port 156
with
an external network such as a LAN. The IGMP multicasting processor 158 may be
programmed to operate for multicasting using IGMP pruning, a protocol known in
the
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-21-
art, for multicasting without using IGMP Pruning (static routes) and for
Unicast
routing.
When the 1GMP multicasting processor 1S8 is operated using the IGMP
pruning, the IGMP multicasting processor 1S8 may be either an IGMP queries or
a
S non-queries. When the IGMP multicasting processor 1S8 is operated as a
qu~rier, the
IGMIP multicasting processor ! S8 periodically emits IGMP queries to
deterrr:ine if a
user desires multicasting traffic that the EDS Card 100 is curren!ly
receiving. If a
user desired multicasting traffic, the user responds to the IGMP multicasting
processor 1S8 and the IGIvIP multicasting processor 1S8 transmits the
rruiticast
transmission through the stack processor 108 to an external LAIC. 'The ICrMP
rnuliicasting peocessar 1 ~8 continues emitting IG1~IP queries wl,i ~;~
~ransrs~.ittinb th
multicast transmission to the external user and the external uses ~;c~:-
:.:.inueresponding
while. to;, external us:r desires the r:-~vlt:;,a~t irsnsmission. When tn::
v~sz~ n;; 'onger
desires th;; .nulticast transmission. ate user ceases !o respond to t?':e TGMP
queries or
the user issues an IGMIP "leave:" message. 'T.he I(iMP multicasting
pro;:e:;sor d-~te;as
:he :ailurn of the user to respond an;? ceases transmitting tl-ce :rul~ticust
!rarsrnissia~~..
Under the IGA~IP Protoco~, ,,ni;' one IGMP queries may ~x~sv en a ;mt~~orl: at
a
given time. l~hus, if, for example, the n~tv~oik connected to the Et.hernea
Port 148
already has an IGMP enabled :outer or switch, the IGMP maltic:~s;_nprocessor
iS8
mash ne progru:~nued to ac;t as a na~c-queries. When the IGMP n~ultii:a~~~inp
processor
153 acts a;. a ;nor.-qu~i-ier, tt:° IG~1P n~Giiicasiin~; processoo ma
af,;.;- a:nd rauaes tEie
ttmlricasting traffic, bnt is not the qu:.rier and thus does not emit queries.
'the IG>~~TP
~nulticasting processor 138 instead :esponds to commands from ao ~.ot:ernal
rout,°.r.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
- 22 -
When the IGMP multicasting processor 158 performs multicasting without
using IGMP pruning, the IGMP mult'icasting processor 158 acts as a static
muter.
The IGMP multicasting processor 158 does not use IGMP and instead uses a
static
route table that may be programmed in one of three ways. First, the IGMP
multicasting processor 158 may be programmed to merely pass though all
multicast
traffic through the stack processor 108 to an external LAN. Second, the IGMP
multicasting processor 158 may be programmed to pass no multicast traffic.
Third,
the IGMP multicasting processor 158 may be programmed with a static route
table
having individual destination 1P address or ranges of destination IP
addresses. Only
when the IGMP multicasting processor 158 receives multicast traffic destined
for an
IP address in the static route table, the multicast traffic is passed to the
external LAN.
When the IGMP multicasting processor 158 performs Unicast routing, the
IGMP multicasting processor 158 acts as a static muter wherein received
traffic in not
multicast and is instead delivered only to a single destination address. As
when
performing multicast routing without IGMP pruning, the IGMP Multicast
Processor
158 uses a static route table and may be programmed in one of three ways.
First, to
merely pass through received traffic to its individual destination address.
Second, to
pass no Unicast traffic. Third, the IGMP multicasting processor 158 may be
programmed with a static route table having individual destination IP
addresses and
the IGMP multicasting processor 158 may pass traffic only to one of the
individual
destination TP addresses.
The IGMP multicasting processor 158 may be programmed via the M&C Port
144, the Ethernet Port 148, the Auxiliary RS-232 Port 156, the Host interface
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-23-
processor 106 or the received data stream 103. Additionally, the IGMP
multicasting
processor 158 may multicast via the Auxiliary RS-232 Port 156 in addition to
the
Ethernet Port 148.
The EDS card 100 also includes an HTTP Server 160 (also referred to as a
Web Server). The HTTP Server 160 receives data from and passes data to the
stack
processor 108. Data may be retrieved from the HTTP Server 160 by an external
device through either a LAN communicating with the Ethernet Port 148 or a
modem
communicating with the Auxiliary RS-232 Port 156. Either the modem or the LAN
may transmit an HTTP data request command to the stack processor 108 via their
respective communication channels, (i.e., the PPP and modem processor 152 and
the
10/100BT Ethernet Transceiver respectively). The stack processor 108 transmits
the
received data request command to the HTTP Server 160 which formats and
transmits
a response to the stack processor 108 which transmits the response back along
the
appropriate channel to the requestor.
Preferably, the HTTP Server 160 may be used to allow the EDS Card 100 to
be configured and monitored via a standard Web Browser accessible through both
the
Ethernet Port 148 or the Auxiliary RS-232 port. Additionally, the HTTP Server
160
allows a web browser access to the files stored in the flash memory storage
114. Files
may be downloaded for remote play, may be modified and up loaded, or may be
played through the web browser. Additionally, the event scheduler 134 may be
controlled with a web browser via the HTTP Server 160. The HTTP Server 160
allows complete remote access to the functionality of the EDS Card 114 and the
contents of the flash memory storage 114 through a convenient web browser.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
- 24 -
Additionally, the HTTP Server 160 allows new files to be uploaded to the flash
memory storage 114 via a convenient web browser. Use of the HTTP Server 160 in
conjunction with a web browser may be the preferred way of monitoring the
function
and content of the EDS Card 100 remotely.
The EDS card 100 also includes a DHCP Processor 162 receiving data from
and passing data to the stack processor 108. The DHCP Processor 162 provides
Dynamic Host Configuration Protocol services for the EDS card 100. That is,
the
DHCP Processor allows the EDS card's 100 IP address to be automatically
configured
on an existing LAN supporting DHCP. The DHCP Processor thus eliminates the
need
to manually configure the EDS card's 100 IP address when the EDS card 100 is
operated as part of a LAN supporting DHCP. In operation, the DHCP Processor
162
communicates with an external LAN via the Ethernet Port 148. IP data is passed
from
the external LAN through the Ethernet Port 148 and 10/100BT Ethernet
Transceiver
146 and the stack processor 108 to the DHCP Processor 162 where the IP data is
resolved and the dynamic IP address for the EDS card 100 is determined. The
EDS
card's 100 IP address is then transmitted to the external LAN via the stack
processor
108, 10/100BT Ethernet Transceiver 146 and Ethernet Port 148. Additionally,
the
DHCP Processor 163 determines if the external LAN has a local DNS server. When
the external LAN has a local DNS server the DHCP Processor 163 queries the
local
DNS server for DNS addressing instead of directly quering an Internet DNS
server.
Also, the DHCP Processor 162 allows the IP address for the EDS Card 100 to be
dynamically reconfigured on an existing LAN supporting DHCP.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-25-
The EDS card 100 also includes a DNS Resolver 164 receiving data from and
passing data to the stack processor 108. The DNS Resolver 164 provides Domain
Name Service to the EDS card 100 to allow the EDS card to dynamically
communicate with external host web servers regardless of the web server IP
address.
In operation, the DNS Resolver 164 communicates with an external host web
server
via the stack processor 108 and either the Ethernet Port 148 or the Auxiliary
RS-232
Port 156. The DNS Resolver 164 receives IP address information from the
external
host web server and resolves mnemonic computer addresses into numeric IP
addresses and vice versa. The resolved IP address information is then
communicated
to the stack processor 108 and may be used as destination addressing for the
external
host web server.
The EDS Card 100 also includes a confirmation web client 150 receiving data
from and passing data to the stack processor 108. When a data file, such as an
audio
file, is received by the EDS Card 100, the confirmation web client 150
confirms that
the EDS Card 100 received the data by communicating with an external server
preferably an HTTP enabled server such as the StarGuide~ server. The
confirmation
web client's 150 confirmation data may be transmitted via either the Ethernet
Port
148, the Auxiliary Port 156 or both. Additionally, once a file, such as an
audio spot is
played or otherwise resolved, the confirmation web client 150 may also send a
confirmation to an external server preferably an HTTP enabled server such as
the
StarGuide~ server. The confirmation web client's 150 confirmation may be then
be
easily accessed via web browser from the HTTP enabled server.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-26-
The flash memory storage 114 operates in conjunction with the event
scheduler 134 and the command processor 136 to provide audio insertion
capability
and support for manual and automatic sport insertion, external playback
control via
the relay input port 140, Cross-Fade via the audio mixer/fader 122 and spot
localization. The command processor 136 also maintains a built-in log of audio
spots
played. The built-in log may be retrieved through the M&C Port 144, the
Ethernet
Port 148, or the Auxiliary RS-232 Port 156. The built-in log may assist
affidavit
collection for royalty or advertising revenue determination, for example.
The Host interface processor 106 receives data from and transmits data to the
StarGuide backplane 102. The Host interface processor 106 allows the EDS Card
100
to be controlled via the front panel (not shown) of the receiver in which the
EDS Card
100 is mounted. The Host interface processor 106 retrieves from the command
processor 136 the current operating parameters of the EDS Card 100 for display
on
the front panel of the receiver. Various controls on the front panel of the
receiver
allow users to access locally stored menus of operating parameters for the EDS
Card
100 and to modify the parameters. The parameter modifications are received by
the
Host Processor 106 and then transmitted to the command processor 136. The Host
interface processor 106 also contains a set of initial operating parameters
and
interfaces for the EDS Card 100 to support plug-and-play setup of the EDS Card
100
within the receiver.
As described above, the EDS card 100 includes many useful features such as
the following. The EDS card 100 includes the audio input port 128 to allow a
"live"
audio feed to be mixed or faded at the audio mixer/fader 122 with a locally
stored
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-27-
audio spot from the flash memory storage 114. Also, the audio mixer/fader
allows the
live feed and the local (stored) feed to be mixed, cross faded or even
amplified.
Additionally, the EDS card's 100 relay input port 140 allows external
triggering of the
EDS card including audio event scheduling. Also, the event scheduler 134
allows the
EDS card to play audio files at a predetermined time or when an external
triggering
event occurs. Additionally, the audio decoder 116 includes an MPEG Layer II
decoder allowing the pre-encoded stored files from the flash memory storage
114 to
be converted to analog audio signals 117 in real time. Also, the audio
audition port
132 of the EDS card allows the locally stored audio to be perceived without
altering
the output audios feed through the audio output port 126. The audio audition
port 132
may be of great use when the audio output port 126 output is forming a live
broadcast
feed.
The features of the EDS card 100 also include the ability to receive files
from
a head end distribution system (such as ExpressNet) based on the EDS card's
unique
stored internal address. Once the EDS Card 100 receives an ExpressNet digital
package, the EDS Card 100 may send a confirmation via the Ethernet Port 148 or
the
Auxiliary RS-232 port 156 to the package originator. Also, the IGMP
multicasting
processor 158 of the EDS card 100 provides locally configured static routing
which
allows certain IP addresses to be routed from a satellite interface through
the EDS
card 100 directly to the Ethernet Port 148. Also, the EDS Card 100 supports a
variety of communication interfaces including HTTP, telnet, and SNMP to allow
configuration and control of the EDS Card 100 as well as downloading,
uploading,
and manipulation of files stored on the flash memory storage 114.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-28-
Additionally, because the traffic received by the EDS Card 100 is HDLC
encapsulated, the traffic received by the EDS Card 100 appears as if it is
merely
arnving from a transmitting router and the intervening satellite
uplink/downlink is
transparent. Because of the transparency, the EDS Card 100 may be configured
as a
satellite Wide Area Network WAN with minimal effort and additional equipment.
In general, the EDS Card 100 is an extremely flexible file storage and
transmission tool. The EDS Card 100 may be programmed through the Host
interface
processor 106, the M&C Port 144, the Auxiliary RS-232 Port 156, the received
data
stream 103, and the Ethernet Port 148. It may be preferable to program the EDS
Card
100 through the Host interface processor 106 when programming from the
physical
location of the EDS card 100. Alternatively, when programming the EDS Card 100
remotely, it may be preferable to program the EDS Card 100 via the Ethernet
Port 148
because the Ethernet Port 148 supports a much higher speed connection.
In addition, files such as audio, video, text, and other multimedia
information
may be received by the EDS card 100 through the received data stream 103, the
M&C
Port 144, the Auxiliary RS-232 Port 156, and the Ethernet Port 148.
Preferably, files
are transmitted via the received data stream 103 or the Ethernet Port 148
because the
received data stream 103 and the Ethernet Port 148 support a much higher speed
connection. Also, files such as audio, video, text and other multimedia
information
may be transmitted by the EDS card 100 through the M&C Port 144, the Auxiliary
RS-232 Port 156, and the Ethernet Port 148. Preferably, files are transmitted
via the
Ethernet Port 148 because the Ethernet Port 148 supports a much higher speed
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-29-
connection. Audio files may also be transmitted via the audio output port 126
in
analog form.
Additionally, the EDS Card 100 may perform time-shifting of a received data
stream 103. The received data stream 103 may be stored in the flash memory
storage
114 for later playback. For example, an audio broadcast lasting three hours
may be
scheduled to begin at gam, New York time in New York and then be scheduled to
begin an hour later at lam. Los Angeles time in Los Angeles. The received data
stream 103 constituting the audio broadcast may be received by an EDS Card in
California and stored. After the first hour is stored on the California EDS
Card,
playback begins in California. The EDS card continues to queue the received
audio
broadcast by storing the audio broadcast in the flash memory storage while
simultaneously triggering, via the event scheduler 134, the broadcast received
an hour
ago to be passed to the audio decoder and played.
Figure 2 illustrates a hardware block diagram of the EDS Card 200. The EDS
Card 200 includes a Backplane Interface 210, a Microprocessor 210, a Serial NV
Memory 215, a Reset Circuit 220, a 10/100BT Transceiver 225, a 10/100BT
Ethernet
Port 230, a RS-232 4 Channel Transceiver 235, a M&C Port 240, an Opto-Isolated
Relay Input 245, a Digital Port 250, an audio decoder 255, and audio filter
260, a
Mixer/Amplifier 265, a Balanced Audio Receier 270, a Balanced audio driver
275, an
Audio Port 280, a Boot Flash, 285, an Application Flash 287, an SDRAM 90, and
a
Flash Disk 295.
In operation, the Backplane Interface 205 performs as the StarGuide
backplane 102 of Figure 1. The Microprocessor 210 includes the HDLC Processor
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
- 30 -
104, the Host interface processor 106, the stack processor 108, the local
message
filtering processor 110, the Store and forward address/file filtering
processor 112, the
event scheduler 134, the command processor 136, the decoder monitor and
control
processor 118, the relay input processor 138, the confirmation web client 150,
the PPP
and modem processor 152, the IGMP multicasting processor 158, the HTTP Server
160, the DHCP Processor 162, and the DNS Resolver 164, as indicated by the
shaded
elements of Figure 1. The Serial NV Memory 215 stores the initial command
configuration used at power-up by the command processor 136. The Reset Circuit
220 ensures a controlled power-up. The 10/100BT Transceiver performs as the
10/100BT Ethernet transceiver 146 of Figure 1 and the 10/100BT Ethernet Port
230
performs as the Ethernet Port 148 of Figure 1. The RS-232 4 Channel
Transceiver
235 performs as both the RS-232 Transceiver 142 and the RS-232 Transceiver 154
of
Figure 1. The Digital Port 250 in conjunction with the RS-232 Channel
Transceiver
235 performs as the Auxiliary RS-232 Port 156 of Figure 1. The M&C Port 240
performs as the M&C Port 144 of Figure 1. The Opto-Isolated Relay Input 245
and
the Digital Port 250 perform as the relay input port 140. The audio decoder
255,
audio filters 260, Mixer/Amplifiers 265, Balanced audio receiver 270, Balanced
audio
drivers 275 and Audio Port 280 perform as the audio decoder 116, audio filter
120,
audio mixer/fader 122, audio receiver 130, audio driver 124, and audio output
port
126 respectively of Figure 1. The Flash Disk 295 performs as the flash memory
storage 114 of Figure 1.
The Boot Flash 285, Application Flash 287, and SDRAM 290 are used in the
start-up and operation of the EDS Card 100. The Boot Flash 285 holds the
initial
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-31-
boot-up code for the microprocessor operation. When the Reset Circuit 220 is
activated, the Microprocessor 210 reads the code from the Boot Flash 285 and
then
performs a verification of the Application Flash 287. The Application Flash
287
holds the application code to run the microprocessor. Once the Microprocessor
210
has verified the Application Flash 287, the application code is loaded into
the
SDRAM 290 for use by the microprocessor 210. The SDRAM 290 holds the
application code during operation of the EDS Card 100 as well as various other
parameters such as the static routing table for use with the IGMP Multicasting
Microprocessor 158 of Figure 1.
The microprocessor 210 is preferably the MPC860T microprocessor available
from Motorola, Inc. The Reset Circuit 220 is preferably the DS1233 available
from
Dallas Semiconductor, Inc. The 10/100BT Ethernet Transceiver 225 is preferably
the
LXT970 available from Level One, Inc. The audio decoder 255 and the Mixer
Amplifier 265 are preferably the CS4922 and CS3310 respectively, available
from
Crystal Semiconductor, Inc. The Flash Disk 295 is preferably a 144Mbx8
available
from M-Systems, Inc. The remaining components may be commercially obtained
from a variety of vendors.
Figure 3 further illustrates some of the functionality of the EDS Card 300 of
a
preferred embodiment of the present invention. Functionally, the EDS card 300
includes an IP Multicast Router 310, a Broadband Internet Switch 320, a High
Reliability Solid State File Server 330, and a High Reliability Solid State
Web Site
340. The EDS card 300 may receive data from any of a number of Internet or
Virtual
Private Network (VPN) sources including DSL 350, Frame Relay 360, Satellite
370,
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
- 32 -
or Cable Modem 380. The EDS card 300 may provide data locally, such as audio
data, or may transmit received data to a remote location via an Ethernet link
such as a
100 Base T LAN link 390 or via DSL 350, Frame Relay 360, Satellite 370, or
Cable
Modem 380. Data received by the EDS Card 300 may be routed by the IP Multicast
Router 310, may be switched through the Broadband Internet Switch 320, or may
be
stored on the High Reliability Solid State File Server 330. The EDS card may
be
monitored and controlled via the High Reliability Solid State Website 340,
which may
be accessed via the100 Base T LAN link 390, DSL 350, Frame Relay 360,
Satellite
370, or Cable Modem 380.
Referring now to Figure 8, the applicants' preferred Internet backchannel
system 10 is preferably utilized to distribute Internet content (according to
the TCP/IP
protocol, which may include UDP packets) onto a remote LAN 12 interconnecting
PC's, e.g., 14, 16, on the remote LAN 12. Through the applicants' preferred
Internet
satellite transmission system 10, content residing on a content server PC 18
is
distributed according to the TCP/IP protocol through a third-party satellite
20 to the
client PC's 14, 16 on the remote Ethernet LAN 12.
In the applicants' preferred system 10, the TCP/IP content flow is as follows:
1. A PC, e.g., 14, on the remote Ethernet LAN 12 is connected to the Internet
through a conventional, and typically pre-existing, TCP/IP router 36 in a
fashion well known to those skilled in the art. The router 36 can thus send
requests for information or Internet content through the Internet 38 to a
local
muter 40 to which a content server 18 (perhaps an Internet web server) is
connected in a fashion well known to those skilled in the art.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-33-
2. The content server 18 outputs the Internet content in TCP/IP Ethernet
packets
for reception at the serial port (not shown) on a conventional Internet router
22;
3. The router 22 outputs HDLC encapsulated TCP/1P packets transmitted via RS-
422 signals at an RS-422 output port (not shown) into an RS-422 service input
into a StarGuide(R) MX3 Multiplexer 24, available from StarGuide Digital
Networks, Inc., Reno, Nevada. (All further references to StarGuide~
equipment refer to the same company as the manufacturer and source of the
equipment.) The method of multiplexing utilized by the MX3 Multiplexer is
disclosed in Australia Patent No. 697851, issued on January 28, 1999, to
StarGuide Digital Networks, Inc, and entitled -Dynamic Allocation of
Bandwidth for Transmission of an Audio Signal with a Video Signal."
4. The StarGuide~ MX3 Multiplexer 24 aggregates all service inputs into the
Multiplexer 24 and outputs a multiplexed TDM (time division multiplexed)
data stream through an RS-422 port (not shown) for delivery of the data
stream to a modulator 26, such as a Comstream CM701 or Radyne DVB3030,
in a manner well known to those skilled in the art. The modulator 26 supports
DVB coding (concatenated Viterbi rate N/(N+I) and Reed-Solomon 187/204,
QPSK modulation, and RS-422 data output). Multiple LANs (not shown) may
also be input to the StarGuideg Multiplexer 24 as different services, each
connected to a different service input port on the StarGuideg Multiplexer 24,
5. The modulator 26 outputs a 70 MHz RF QPSK or BPSK modulated signal to a
satellite uplink and dish antenna 28, which transmits the modulated signal 30
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-34-
through the satellite 20 to a satellite downlink and dish antenna 31 remote
from the uplink 28.
6. The satellite downlink 31 delivers an L-Band (920-2050MHz) radio
frequency (RF) signal through a conventional satellite downlink
downconverter to a StarGuide~ II Satellite Receiver 32 with the applicants'
preferred EthemetlRouter card 34 removably inserted into one of possibly five
available insertion card slots (not shown) in the back side of the StarGuide~
II
Receiver 32. The StarGuide~ II Receiver 32 demodulates and demultiplexes
the received transmission, and thus recovers individual service data streams
for use by the cards, e.g., EDS Card 34, mounted in the StarGuide~ II
Receiver 32. The Receiver 32 may also have one or more StarGuide~ cards
including audio card(s), video card(s), relay card(s), or async cards)
inserted
in the other four available slots of the Receiver 32 in order to provide
services
such as audio, video, relay closure data, or asynchronous data streams for
other uses or applications of the single receiver 32 while still functioning
as a
satellite receiver/router as set forth in this specification. For example,
other
services, available from StarGuide Digital Networks, Inc. of Reno, Nevada
that may be added to a receiver include an Asynchronous Services Statistical
Demux Interface Module, a Digital Video Decoder Module, an MX3 Digital
Multimedia Mulitplexer, a Digital Audio Storage Module, and a Digital
Multimedia Satellite Receiver.
7. The EDS Card 34 receives its data and clock from the StarGuide~ II Receiver
34, then removes the HDLC encapsulation in the service stream provided to
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-35-
the EDS Card 34 by the StarGuide~ II Receiver 32, and thus recovers the
original TCP/IP packets in the data stream received from the Receiver 32
(without having to reconstruct the packets). The EDS Card 34 may then, for
example, perform address filtering and route the resulting TCP/IP packets out
the Ethernet port on the side of the card (facing outwardly from the back of
the
StarGuide~ II Receiver) for connection to an Ethernet LAN for delivery of the
TCP/IP packets to addressed PCs, e.g., 14, 16 if addressed, on the LAN in a
fashion well to those skilled in the art. Alternatively, as discussed above,
the
EDS Card 34 may store the received packets on the flash memory storage 114
of Figure 1 for example.
As a result, high bandwidth data can quickly move through the preferred
satellite system 10 from the content server 18 through the one-way satellite
connection 20 to the receiving PC, e.g., 14. Low bandwidth data, such as
Internet user
requests for web pages, audio, video, etc., may be sent from the remote
receiving PC,
e.g., 14, through the inherently problematic but established Internet
infrastructure 38,
to the content server 18. Thus, as client PC's, e.g., 14, 16, request data,
the preferred
system 10 automatically routes the requested data (provided by the content
server 12)
through the more reliable, higher bandwidth, and more secure (if desired)
satellite 20
transmission system to the StarGuide~ II Receiver and its associated EDS Card
34
for distribution to the PC's 14, 16 without going through the Internet 38
backbone or
other infrastructure.
Referring now to Figure 9, the applicants' preferred intranet system 42 is
preferably utilized to distribute TCP/IP formatted content onto a remote LAN
12
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-36-
interconnecting PC's, e.g., 14, 16, on the remote LAN 12. Through the intranet
system 42, content residing on a content server PC 18 is distributed through
the
intranet 42 to the client PC's 14, 16 through a private telecommunications
network 39.
The intranet system 42 of Figure 9 works similarly to the Internet system 10
of
Figure I except that the intranet system 42 does not provide a backchannel
through the
Internet 40 and instead relies on conventional telecommunications connections,
through conventional modems 44, 46, to provide the backchannel. In the
applicants'
preferred embodiment the remote LAN modem 44 connects directly to an RS-11
port
on the outwardly facing side of EDS Card 34 on the back side of the StarGuide~
II
Receiver 32 in which the EDS Card 34 is mounted. The Ethemet/Router card 34
routes TCP/IP packets addressed to the head end or content server 18 (or
perhaps
other machines on the local LAN 19) to an RS232 serial output (113 in Figure
8) to
the remote LAN modem 44 for delivery to the content servers or head end 18.
Alternatively, the remote modem 44 may be connected to accept and transmit the
TCP/IP data and requests from a client PC, e.g., 14, through a router (not
shown) on
the remote LAN 12, in a manner well known to those skilled in the art.
The local modem 46 is connected to the content server 18 or to a head-end
LAN on which the server 18 resides. The two modems 44. 46 thus provide a
TCP/1P
backchannel to transfer TCP/IP data and requests from PC's 14, 16 on the
remote
LAN (which could also be a WAN) 12 to the content server 18.
Referring now to Figure 4, the applicants' preferred "muxed" uplink system,
generally 48, is redundantly configured. The muxed system 48 is connected to a
local
or head-end Ethernet LAN 19, to which an Internet Web Server 50 and Internet
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-37-
Multicasting Server 52 are connected in a manner well known to those of skill
in the
art. Two lOBaseT Ethernet Bridges 53, 55 provide up to 8 mbps (megabits per
second) of Ethernet TCP/IP data into RS422 service ports (not shown) mounted
in
each of two StarGuideO II MX3 Multiplexers 24a, 24b, respectively. The main
StarGuide~ Multiplexer 24a is connected via its monitor and control (M&C)
ports
(not shown) through the spare Multiplexer 24b to a 9600 bps RS-232 link 56 to
a
network management PC 54 running the Starguide Virtual Bandwidth Network
Management System (VBNMS).
Each of the Multiplexers, e.g., 24a, output up to 8mbps through an RS422 port
and compatible connection to an MPEG-DVB modulator, e.g, 58. The modulators,
e.g., 58, in turn feed their modulated output to a l: 1 modulator redundancy
switch 60
and deliver a modulated RF signal at 70 to 140 MHz for transmission through
the
satellite (20 in Figure 8). In this regard, the VBNMS running on the network
management PC 54 is also connected to the redundancy switch 60 via an M&C
RS-232 port (not shown) on the redundancy switch 60.
With reference now to Figure 5, in the applicants' preferred muxed down-link
62, generally, there is no need for a muter between the StarGuide~ II
Satellite
Receiver 32 and the remote LAN 12. The Receiver 32 directly outputs the
Ethernet
encapsulated TCP/IP packets from the Ethernet output port (not shown) on the
Receiver 32 onto the LAN cabling 12 with no intermediary hardware at all other
than
standard in inexpensive cabling hardware.
The LAN 12 may also be connected to traditional LAN and WAN
components, such as local content servers 64, 66, router(s), e.g., 36, and
remote
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-38-
access server(s), e.g., 68, in addition to the LAN-based PC's, e.g., 14, 16.
In this
WAN configuration., yet additional remotely connected PC's 70, 72, may dial-in
or be
accessed on conventional telecommunications lines, such as POTS lines through
a
public switching teclo network (PTSN) 71 to procure TCP/IP or other content
acquired by the remote access server 68, including TCP/>P content delivered to
access
server 68 according to addressing to a remotely connected PC, e.g., 70, of
packets in
the Ethernet data stream output of the Ethemet/Router card (34 in Figure 8).
With reference now to Figure 6, the applicants' preferred clear channel
system.
Generally 74, eliminates the need for both costly multiplexers (e.g., 24 in
Figure 4)
and the VBNMS and associated PC (54 of Figure 4). The clear channel system 74
is
well suited to applications not requiring delivery of multiple services
through the
system 74. The clear channel system 74 of Figure 6 provides up to lOmbps of
Ethernet TCP/IP data directly into the input of an MPEG-DVB modulator, e.g.,
58,
for uplinking of the frequency modulated data for broadcast through the
satellite (20
in Figure 8). (Note that, although these systems employ MPEG-DVB modulators,
they do not utilize DVB multiplexers or DVB encrypting schemes.)
Alternatively and with reference now to Figure 7, the bridges 53, 55 may each
instead consist of a 100BaseT Ethernet router 53, 55. As a result, these
routers 53, 55
preferably may deliver up to 50 mbps HSSI output' directly into their
respective
modulators, e.g, 58. Applicants' preferred modulator for this application is a
Radyne
DM-45 available from Radyne Corporation.
The preferred receiver/router eliminates the need for any special or custom
software while providing a powerful, reliable, and flexible system for high
speed.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-39-
asymmetrical distribution of Internet or TCP/IP compatible content, including
bandwidth intensive audio, video, or multimedia content to an Ethernet
computer
network. This is particularly useful where a digital terrestrial
infrastructure is lacking,
overburdened, otherwise inadequate, or cost prohibitive.
Although in the above detailed description, the applicants preferred
embodiments include Internet or telecommunications backchannels, the above
system
may utilized to provide high speed audio or video multicasting (via UDP
packets and
deletion of the backchannel). In this utilization of the applicant's
receiver/router in a
one-way system from the uplink to the receiver/router, all remote LAN's or
other
connected computers receive the same data broadcast without any interference
to the
broadcast such as would be encountered if it were to be sent through the
Internet
backbone.
Additionally, the EDS Card may be preferably utilized in conjunction with a
Transportal 2000 Store-and-Forward System or the StarGuide III Receiver
available
from StarGuide Digital Networks, Inc., of Reno, Nevada.
Additionally, as illustrated in the flowchart 1100 Figure 11, the preferred
embodiment may be employed to distribute data or content, for example, audio
advertising, from a centralized origination location to a number of
geographically
diverse receivers. A particular example of such a data distribution system is
the
distribution of audio advertising, particularly localized audio spots
comprising a
national advertising campaign. First, at step 1110 content data is originated.
For the
audio spot example, the audio spots may be recorded at a centralized
origination
location such as a recording studio or an advertising agency. Next, at step
1120, the
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-40-
content data is localized. For the audio spot example, the audio spot is
localized by,
for example including the call letters of a local receiver or including a
reference to the
region. Next, at step 1130, the content data is transmitted to and received by
a remote
receiver. For the audio spot example, the audio spot may be transmitted for
geographically diverse broadcast receivers via a satellite data transmission
system.
Once the content data has been received by the remote receiver, the content
data may
be stored locally at the receiver step 1140, the content data may be modified
at the
receiver at step 1150, the content data may be immediately broadcast at step
1160, or
the content data may be further transmitted at step 1170, via a LAN for
example. For
the audio spot example, the audio spot may be stored at the receiver, the
audio spot
may be modified, for example by mixing or cross fading the audio spot with a
local
audio signal, the audio spot may be immediately broadcast, or the audio spot
may be
further transmitted via a network such as a LAN or downloaded from the
receiver.
Finally, at step 1180, a confirmation may optionally be sent to the data
origination
location. The confirmation may indicate that the content data has been
received by
the receiver. Additional confirmations may be sent to the data origination
location
when the content data is broadcast as in step 1160, or further transmitted as
in step
1170, for example. For the audio spot example, a confirmation may be sent when
the
spot is received and additionally when the spot is broadcast or further
transmitted, for
example. A preferred embodiment of the present invention thus provides a
distribution system providing reliable, fast and efficient delivery of content
as well as
increased automation capability throughout the system. For the audio spot
example,
increased automation, ease of use and speed of distribution of a national ad
campaign
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-41-
to a number of local broadcasters may allow increased broadcast advertising
and may
draw major advertising expenditures into national broadcasting advertising
campaigns.
Figure 12 illustrates a system 1200 for providing fax services over a
satellite
network using the EDS card 100 according to an embodiment of present
invention. In
the system 1200 of Figure 12, a document 1201 is transmitted over a satellite
transmission system 1208 to a recipient 1211. The system 1200 may be used, for
example, 1) to provide a virtual private network for faxes to increase
security and on-
time deliverability of faxes, 2) to replace transmission over standard
telephony
resources when the standard resources are faulty or intermittent, 3) to
minimize costs
associated with faxing by directly transmitting faxes over the satellite
network to a
local fax machine for transmission to a local user, and 4) to provide easy
record
keeping or backup of faxes.
Turning to Figure 12, first, a document 1201 to be faxed is prepared by a user
at a terminal. For example, the user may prepare the document 1201 using a
word
processor such as Microsoft Word. The user also enters traffic instructions
for the
document 1201 at the terminal. The traffic instructions may include the
destination
fax number for the recipient 1211, the time at which the fax is to be
transmitted, client
information for billing purposes, or destination information such as
individual or
company information. Figure 12 illustrates a single user generating a single
document 1201, however, the system 1200 may service a number of users
simultaneously, as further described below.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-42-
Next, the user sends the document 1201 to be faxed and the traffic
instructions
to a virtual fax print driver 1202. The virtual fax print driver 1202 is
preferably a
software driver that is preferably installed on the user's terminal or is
available to the
user via a network connection. The virtual fax print driver 1202 converts the
document 1201 received from the user into a format, such as the Tagged Image
File
Format (TIFF) .tif format, that is suitable for transmission over a fax
network. The
conversion of the document to .tif format may occur on a page-by-page basis
into a
sequence of individual .tif files 1203 and the individual .tif files 1203 may
then be
combined to form a single large .tif file, as further described below. For
example,
when the document is converted into a sequence of .tif files, each of the .tif
files in the
sequence preferably has a name including a prefix and a number. The prefix is
the
same for each file in the sequence while the number identifies the page number
of the
of document in the original file. Alternatively, the entire document may be
converted
into a single .tif file automatically by the virtual fax print driver 1202.
As mentioned above, the system 1200 may service a number of users
simultaneously. For example, a number of networked users may send documents to
be faxed and traffic instructions to a single virtual fax print driver.
Additionally, the
virtual print driver may be based on currently available fax print drivers
such as the
Ibex fax print driver.
Next, the single .tif file or sequence of .tif files and the traffic
instructions are
sent to the ExpressNet producer 1204. If the document is received by the
ExpressNet
producer 1204 as a sequence of .tif files, the ExpressNet producer 1204 then
converts
the sequence of .tif files into a single .tif file. Alternatively, the
sequence of .tif files
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-43-
may be sent as multiple files to the affiliate. Preferably the affiliate
receives the
multiple .tif files, sorts the .tif files and then faxes the .tif files to the
recipient.
Once the document to be faxed is rendered as a single .tif file, the
ExpressNet
producer 1204 then compares the traffic information received from the user
with a
stored address list. The stored address list may include, for example, the
numbers and
locations of the fax machines or fax modems that are affiliates of the system
1200.
By comparing the traffic information to the stored address list, the
ExpressNet
producer 1204 determines the destination affiliate to direct the document for
faxing.
The ExpressNet producer 1204 then forms a package 1207 that includes the
document
and the destination information. The ExpressNet producer 1204 may be a
Transportal
2000 producer, for example, which is a high speed digital media delivery
system or a
"store and forward" system.
For example, the document generated by the user may be destined for a
recipient in the "312" area code. The user may enter the "312" area code as
traffic
instructions at the user's terminal. The area code is received by the
ExpressNet
producer 1204. The stored address list on the ExpressNet producer 1204 may
include
a list of affiliates for each area code. Each affiliate may be a fax machine
or fax
modem in the desired area code that may be used to transmit the document to be
faxed
from the affiliate in the areas code to the fax machine of the intended
recipient. The
ExpressNet producer 1204 may then determine the affiliate located in the "312"
area
code. Once the ExpressNet producer 1204 has located the affiliate, the
document to
be faxed is then routed to the affiliate for fax transmission to the
recipient. The
routing, to an identified affiliate, of the document to be faxed preferably
occurs
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-44-
transparently to the user. That is, the user need not be aware of the internal
workings
or the affiliate location or structure. The routing of the document to be
faxed
preferably occurs at the ExpressNet producer 1204 without intervention by the
user.
Alternately, the document to be faxed may be routed based on recipient
information other than the fax number. For example, the document may be routed
based on business name so that when an affiliate receives a document to be
faxed to
"XYZ Corp", for example, the affiliate faxes all documents addressed to XYZ
Corp.
to a single, predetermined fax number. In this way, the traffic instructions
need not
pass the recipient's fax number to the affiliate, only the business name is
used as the
destination.
The package 1207, including the document to be faxed, the destination
affiliate and the recipient information, is then transmitted to the head end
of a satellite
transmission system 1208. The operation of the satellite transmission system
is
described in detail Figures 8 and 9 and in U.S Patent Application Serial No.
09/287,200, filed April 3, 1999, entitled "Satellite Receiver/Router System
and
Method of Use", which is hereby incorporated by reference in its entirety. The
package 1207 passes through the satellite transmission system 1208 and is
uplinked to
a satellite and then downlinked to the destination affiliate that was selected
by the
ExpressNet producer 1204. At the destination affiliate, the package 1207 is
received
and passed to the EDS 1209. The EDS 1209 unpackages the package 1207 and
determines the recipient information, especially the recipient fax number to
which the
document is to be transmitted. Alternatively, as mentioned above, the package
1207
may be unpackaged and then faxed to a recipient based on the recipient's name
or
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-45-
business name contained in the document. That is, the recipient's name may be
compared to a cross reference listing of names and fax numbers and the
document
may be sent to the fax number corresponding to the recipient's name. The EDS
1209
then passes the document to a fax machine or fax modem 1210 for transmission
to the
recipient 1211. For example, the EDS 1209 may dial the recipient's fax number
using
the fax modem 1210 and then transmit the document to the recipient 1211.
With regard to the .tif file generated by the virtual fax print driver,
preferably,
the .tif file is compatible with the Consultive Committee on International
Telephone
and Telegraph (CCITT) Group 3 standard sometimes referred to as "TIFF-F". The
data in CCITT/3 fax files is compressed using one-dimensional Huffman encoding
scheme. Huffman encoding converts characters into variable length bit strings
and
because bits are encoded instead of bytes, an end-of-line (EOL) token may end
in the
middle of a byte. The process of byte alignment adds extra zero bits in order
for each
encoded scan line of the document 1601 to begin on a byte boundary. Each
encoded
scan line also contains EOL characters. Data may also be stored byte-packed.
The
.tif files are preferably formatted for a "standard" resolution of 98 dots-per
inch (dpi)
or 196 dpi, letter size pages (A4), and in black and white. Also, the .tif
files may
preferably be single page or multiple pages.
With regard to the stored address list at the ExpressNet producer 1204 the
address list is preferably defined at setup and may be edited at any time. For
example,
the address list may be edited to include new affiliates that become part of
the system
1200, or to include new EDS cards that may be added at an existing affiliate.
Additionally, a global address book may be shared by all producers and/or all
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-46-
affiliates. The global address book may be stored at each producer and/or
affiliate
and entries may be updated at a local producer and/or affiliate and then
posted to the
other producers and/or affiliates for storage. For example, when a new client
is added
to the system, the client's information may be added to the global address
book at a
producer situated at a control operations center. The new global address book
may
then be sent to each producer and affiliate for local storage and use.
The fax modem 1210 is preferably an analog fax modem with a rate of 28800
baud or higher and is CCITT Group 3/ Class 1 fax compatible. The fax machine
or
fax modem preferably supports the CCITT T.30 minimum capabilities for Group 3,
for example, a "standard" resolution of 98 dpi, A4 letter size pages, and
support
V.27ter at 4800 bps or higher. If the fax modem attempts to transmit to the
recipient's
fax machine but fails, the fax modem preferably automatically retries. The
number of
retried attempts and the time interval between these attempts may be
configured by a
user. For example, the system may be configured to retry 10 times with a time
interval of 1 minute between attempts.
Alternatively, the affiliate may communicate with a plurality of fax modems to
send faxes to multiple recipients simultaneously. For example, if an affiliate
includes
two fax modems, a received document to be faxed to a recipient may be directed
to
either fax modem or the fax modem that is not currently transmitting a fax.
Thus, at
an affiliate requested by the ExpressNet Producer, the affiliate may
preferably route a
received document to any available fax modem. Such routing may occur using
TCP/IP protocols over a LAN connection, for example..
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-47-
In another embodiment, the system 1200 may include two affiliates in a single
area code, for example, in order to support high usage rates within the area
code. In
this embodiment, the two affiliates may transmit information concerning their
level of
use back to the ExpressNet Producer so that the ExpressNet Producer may direct
faxes to the lesser used affiliate. Alternatively, a single affiliate may
include two EDS
cards that share a single fax modem.
Additionally, the EDS 1209 preferably records all fax attempts, successful or
not, in an activity log. The activity log may also be configured to record
destination
information and length of fax information. Additionally, the EDS 1209 may be
configured to transmit a re-send signal to the ExpressNet Producer if received
fax
includes an error. Additionally, the EDS may transmit an alert signal to the
ExpressNet Producer when a fax is unable to be transmitted, for example due to
received failure at a recipient's fax machine.
Additionally, the success or failure of a fax transmission is reported back to
the producer. The producer may then retry the fax, as discussed above, or may
sent a
confirmation to a user at the producer. Alternatively, tracking of faxes may
not be
automatic, but may occur upon request of the user at the producer.
Additionally, once the affiliate receives the fax from the producer, the
affiliate
may e-mail the fax to a recipient rather than fax the fax to the recipient. As
further
discussed below, the affiliate may be equipped with a connection to a Local
Area
Network (LAN) or other network and may forward to mail to a mail server or a
PC
connected to the network. Additionally, the affiliate may retain the fax in a
built-in
web server on the EDS card at the affiliate. The fax may then be retrieved
from the
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-48-
EDS card via a web browser, for example, for remote display at the recipient's
desktop. Additionally, faxed that are received by the affiliate may be printed
via a
printer attached to the LAN.
Additionally, the producer may be configured to associate fax documents with
a predetermined list of recipients rather than a single recipients. For
example, a user
may direct a fax to a destination group of recipients such as franchisees in
the New
England area, for example. The producer may receive the destination group
information and compare the destination group title to a listing of recipients
to
determine the actual individual recipients. Once the producer has determined
the
individual recipients, the producer may then copy and send the fax to each
individual
recipients. The recipients may be anywhere throughout the network and need not
be
situated at a single affiliate.
Prior art systems were either not able to provide faxing or could only fax
with
substantial additional modification and/or overhead. That is, prior system
were not
designed to support faxing and were able to do so, if at all, only after
significant
modification that often impaired the ability of the system to function. In
contrast, the
present application provides seamless faxing ability integrated with any other
types of
data transfer, storage, and re-transmission via LAN, local PC, or fax modem,
for
example. Preferably, these functions are all available through a single
removable (or
field insertable) card that may also provide local storage and Ethernet output
into a
pre-existing system so as to build off of presently installed systems, or to
allow the
integration of the card with the deployment of new systems. Thus, the present
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-49-
application may be scaled to match the user's demand and may be upgraded with
additional capacity as the user's demands increase.
Figure 13 illustrates a wiring diagram 1300 for an affiliate system according
to
a preferred embodiment of the present invention. The wiring diagram 1300
includes a
satellite receiver 1310, a fax modem 1320, a Local Area Network (LAN) 1330, a
PC
1340 preferably including a browser, a local printer 1350 at the PC 1340, and
a
network printer 1360. The satellite receiver 1310 includes six slots 1301-
1306, but is
not limited to having any number of slots. Each slot 1301-1306 may have an
installed
card such as an audio card or an EDS card, for example. In Figure 13, one of
the slots
1301-1306 includes an installed EDS card 1312. The EDS card 1312 includes an
Audio I/O port 1322, a communication port 1324, a M&C port 1326, and an
Ethernet
port 1328.
The fax modem 1320 communicates with the EDS card 1312 through the
communication port 1324. Additionally, the EDS card 1312 communicates with the
LAN 1330. The PC 1340 also communicates with the LAN 1330.
In operation, the package of documents to be faxed and destination
information are received by the receiver 1310 and sent to the EDS card 1312.
As
described above, the EDS card 1312 unpackages the package to access the
destination
information. The EDS card 1312 then sends control signals to the fax modem
1320 to
initiate a dialing sequence at the fax modem. Once the fax modem has initiated
a
connection with a recipient, the document is sent from the EDS card 1312 to
the fax
modem 1320 for transmission.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-50-
Alternatively, a received document may be routed to the LAN 1330 instead of
the fax modem 1320. For example, the EDS card 1312 may be directly connected
via
the LAN 1330 to a corporate network, for example. The documents to be faxed
are
received as .tif filed and may be unpacked and directed to the corporate
network or an
individual PC or e-mail address on the corporate network. The documents in
.tif
format may then be easily displayed through commercially available imaging
software.
Additionally, documents received by the EDS card 1312 may be stored at the
EDS card 1312 for later transmission or retrieval. For example, documents may
be
stored at the EDS card 1312 and then viewed from the LAN or sent to the
network
printer 1360.
Also, as mentioned above, the EDS card 1312 may be configured to respond
to a producer to indicate the status of a received document. Foe example, the
EDS
card 1312 may indicate to the producer whether the sent document was received
successfully or unsuccessfully and whether to retry sending the document.
Alternatively, the EDS card 1312 may simply store the status of the received
document, for example as successful or unsuccessful, and then await a status
request
from a producer. When a producer requests the status of a document, the EDS
card
1312 may respond whether the document was successfully received.
The PC 1340 may be used to interact with and configure the EDS card 1312
and fax modem 1320 via the LAN 1330. For example, the operation of the
receiver
1310 and the EDS card 1312 may be accessed and displayed via a web browser
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-51-
installed on the PC 1340. Through the web browser, a user may configure the
number
of retries for the fax modem, for example.
Additionally, as discussed above, the PC 1340 may be used to access faxed
documents that may be stored on the EDS card 1312. The documents may be
displayed at the PC via a browser installed on the PC. Additionally, the
documents
may be printed at the PC by the local printer 1350.
Also, documents that are sent to the EDS card 1312 may be sent via the LAN
1330 to the network printer 1360 for distribution. The network printer 1360
may be
near the EDS card 1312 or may be far away from the EDS card 1312 (for example,
in
another building) as long as the network printer 1360 is able to access the
EDS card
1312 via the LAN 1330.
In an alternative embodiment, multiple EDS cards may be installed in the
receiver 1310. Each EDS card may be equipped with its own fax modem.
Alternatively, a plurality of EDS cards may utilize a single fax modem.
Additionally,
the plurality of EDS cards may communicate with each other via the LAN 130.
In ari additional embodiment, the fax modem may be connected to the LAN
rather than directly to the EDS card. The EDS card may control the fax modem
through the LAN 1330.
Additionally, as described above, the EDS card 1312 is equipped with internal
storage. The internal storage allows received packages and documents to be
stored.
For example, a received document may be stored for fax transmission at a later
time.
While particular elements, embodiments and applications of the present
invention have been shown and described, it is understood that the invention
is not
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
-52-
limited thereto since modifications may be made by those skilled in the art,
particularly in light of the foregoing teaching. It is therefore contemplated
by the
appended claims to cover such modifications and incorporate those features,
which
come within the spirit and scope of the invention.
Image CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
54
EDS Commands
This document describes the Monitor and Control Interface commands for the
StarGuide Digital EDS plug-in module.
As the command list grows or changes this document will be updated. Several
commands are considered "debug"
commands and can not be accessed unless the debug command is issued with the
correct password.
The following list displays the current set of commands on the EDS Card board.
This also happens to be the output of
the HELP command.
ADDR - Addressing Settings
HELP - Usage Info
EO - EO Port Settings
NIC - M&C Conf ig
REBOOT - Software Reboot
STATS - Board Statistics
TIME (,value] - Calandar Time
TIN1E ZONE(, value, - Local,timezone
name]
DT_p. (oath] _ - Show directory
SCHED - Current schedule
VER - Software Version
If the unit has is in debug mode the following commands can also be accessed:
DEBUG COMMANDS:
COMMUVIITY - SNMP Community Settings
TP - Settings for FTP download
HDLC - HDLC Settings -
HOST - Communicate with Receiver Host
IGMP - IGMP Settings
NIR [address][,length] - Memory Read
P-l4d <address>, <value> (, value, . . . ] - Memory Write
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
NV - Non-volatile Memory Commands
RCV - Receiver Settings
S':S:'zM - SNM? System Variable Settings
ADDR
The ADDR command is used to set or query the addressing modes used in the In-
Band Control stream. The
types of addressing are the same used in the StarGuide Il receiver. Because
these commands are used
primarily for network control purposes, only a limited subset of commands is
shown to the user (using ADDR
SHOW). The list of options shown the user is as follows:
ADDR SER1AL NUMBER This form of the command queries the serial number
of the ethernet card.
ADDR SHOW This form of the command shows the current address
settings.
The ADDR command takes the following forms which can be used for network
control:
ADDR NID[,value] This form of the command queries or sets the
Network ID for the ethernet card.
ADDR LID,<index>[,value] (index range 0..1 ~) This form of the command sets or
queries the logical
ID settings for the ethernet card.
ADDR SID,<index>[,value] (index range 0..1 ~) This form of the command sets or
queries the slot 1D
settings for the ethemet card
COMh1UNITY
The community command is used to set or query the community strings used by
SNMP. This command is a debug
command and comes in the following forms:
COMMUNITY PUBLIC[,"string",index] To set the public strings used for SNMP GET
commands, the string must be less than 256 characters
and the index should be 0 for the strip' that has access
to the entire MIB 11 database and 1 for the string that
only has access to the ICMP portion of the database.
The string should be surrounded by double quotes as
shown.
COMMUNITY PRIVATE[,"string"] To set the private community string used for SNMP
SET
commands, the string must be less than 2~6 characters.
The string should be surrounded by double quotes as
shown.
COMMUNITY SHOW Shows the current community strings. For example, the
following display shows the default values when
queried.
>COMMUNITY SHOW
PUBLIC:
[0] public
( I ] icmp
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
56
PRIVATE:
private
DEBUC
The DEBUG command is used to enable various debug modes on the ethernet card.
If the debug mode has not
been turned on then all of the following commands will return an ERROR
response (except DEBUG SDN
which turns debug mode on). The following forms of the command are used:
DEBUG SDN Turns the debug mode on.
DEBUG OFF Turns all debug modes off.
DEBUG SHOW ' Show the current setting for the debug modes.
DIR
The DIR command is used to display the contents of the Flash Memory Storage of
the EDS Card card. This
command takes an optional parameter that is the pathname on the drive to list
the contents of. If no path is
given the root directory is assumed. The fornts of the DIR command are shown
below:
DIR Display the contents of the root directory
DIR path Display the contents of the directory specified by path
A sample display from a DI R. command is shown below:
>dir
MONDEC3117:00:00197998220 TEST.MP2 TestAudioSpot
MONDEC3117:00:001979486912 SPOT.MP2 . MyAudio
htONDEC3117:00:001979969 OEEAULT.HTM
t10t1DEC3117:00:001979135 TEST.HTM
h10t1DEC3117:00:001979112640 TEST.TXT
hIONDEC3117:00:001979<DIR> TEMP
TUEOCT1914:21:121999- 5120 NVAAM.BAK
TUESEP0709:27:501999997 TITLES. OLD
MONDEC3117:00:001979719 PACKAGE.HTM
WEOOCT2018:19:101999874 TITLES.BAK
THUAUG2619:22:321999599729 TEST.JPG
t40NDEC3117:00:00197932640 LOGO.GIF
MONDEC3117:00:001979349 AUDIO.GIF
hIONDEC3117:00:001979324 DATA.GIF
hlOPlDEC3117:00:001979417 IMAGE.GIF
MONDEC3117:00:001979398 PACKAGE.GIE
htONDEC3117:00:001979324 PEZOG.GIF
MONDEC3117:00:001979336 T:<T.GIF
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
57
MONDEC3117:00:001979 323 VIDEO.GIF
MONDEC3117:00:001979 1909 SEARCH.HTM
TUEOCT1914:21:141999 5120 NVRAM.CFG
WEDOCT2018:19:261999 874 TITLES.CFG
TUEOCT1914:37:521999 2748 003ED757. MXPRESS.COM Notes
1999/10/18
TUEOCT1914:37:561999 1673 003ED758. T2000 SILENCE IS GOLDEN
TUEOCT1914:38:021995 5955 003ED759. MXPRESS LOGO NAVYBLUE
TUEOCT1914:40:441999 717 003ED766. ABC predemo test
TUEOCT1919:41:121999 290592003ED767. ANTONIO BANDERAS
TUEOCT1914:41:441999 298881003E0768. MAGAZINES
TUEOCT1914:41:521999 189 003ED769. TEST
TUEOCT1914:41:581999 17726003ED76A. LOGO
WEOOCT2016:09:361999 2734 003ED760. 94470
WEDOCT2016:09:421999 691 003ED7fiE.MORE FP.OM THE FAQ
wE0OCT2016:10:361999 849 003ED76B. 8582
WEDOCT2016:10:541999 188352003ED76C. JEWEL ON WHY
MOtIDEC3117:00:001979 1430 SCHED.HTM
MOCIDEC3117:00:001979 919 CONFIG.HTM
MONDEC3117:00:001979 911 HELP.HTM
'
WEDOCT2018:19:081999 2799 003ED77D. 94471
WEDOCT2019:19:121999 1312 003ED77E. HOW DO I TRACK A PACKAGE
hIONDEC3117:00:001979 1263 NEW.GIF
39 bytes bytes free
files, used,
2169026 145313792
EO
The EO command (formerly the IP command) is used to configure or monitor the
ethernet port (E0) of the card. This
command has several sub-commands that can be used to configure the card's
behavior to packets being transferred
from the HDLC port to the ethernet port. The configuration of these parameters
can only be made if the unit is in
debug mode.
E0 IP ALLOW[,address,rnask] Queries or sets the addresses allowed to pass to
the ethernet port. Up to 8
address,mask pairs can be entered. If the unit is not in debug mode, this
sub command can only be queried.
E0 IP_ALLOW,<ANY,NONE> The ANY option allows all IP destination addresses to
be passed from the
HDLC port to the ethemet port.. The NONE option will prevent all IP
packets from being passed from the HDLG port to the ethernet port.
E0 I P-ADDR[,addr] This command sets or queries the lP address of the ethernet
interface.
After and changes have been made the REBOOT command must be
issued for the new changes to take affect.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
58
FT P
H OST
EO IP SUBNETMASK[,addr] This command sets or queries the IP address subnet
mask of the ethernet
interface. After and changes have been
made the REBOOT command
must be issued for the new changes to
take affect.
E0 IP_GATEWAY[,addr]This command sets or queries the IP address
of the ethernet interface's
default gateway. Any commands coming through
the HDLC port to
addresses that can not be resolved locally
are forwarded to the default
gateway. After and changes have been made
the REBOOT command
must be issued for the new changes to
take affect.
E0 IP_ALIAS ADDR[,addr]This command sets or queries the IP alias
address of the ethernet
interface.
E0 IP_ALIAS ADDR,DELETEThis command deletes the IP alias address
of the ethemet interface. The
I alias is a secondary
P address for the ethernet interface.
E0 IP_ALIAS NETMASK[,mask]This command sets or queries the IP alias
netmask of the ethernet
interface.
E0 SHOW Display the current settings for the ethernet
interface.
The FTP command is protected by the debug password. The FTP command is used to
setup and initiate an
FTP software download to flash memory. The items that need to be set prior to
initiating an FTP download
are the FTP server IP address, the username, and user password in order to
access the FTP server. These
settings are stored in non-volatile memory.
FTP IP ADDR[,address]Sets the IP address of the FTP server
FTP USER[,string] This is the user string used to log into
the FTP server.
FTP PASSWORD[,string]This is the password used to log onto the
FTP server.
FTP GET,filename This command initiates a download of the
file specified. Make sure that
the filename includes the entire path to
the file. For example
"/incoming/v0013.ftp". The FTP process
will report status indicators
indicating progress of the download. A
"." will be printed on every
download block to indicate that the download
is in process.
FTP GET-RCV,filenameThis command initiates a download of the
file specified for the StarGuide
Receiver. The downloaded file is sent through
the AUX ( port to the
receiver. Make sure that the filename includes
the eptire path to the file.
For example "/incoming/v0013.ftp". The
FTP process will report status
indicators indicating progress of the download.
A "." will be printed on
every download block to indicate that the
download is in process.
FTP GET_RCV,filename,HIFThis command initiates a download of the
file specified for the StarGuide
Receiver. The downloaded file is serif
through the host interface port to
the receiver rather than the AUX I port.
In order for this type of download
to work, the receiver must have the correct
host interface code (Clear
Channel Code V 1. l6 or later or CP Code
V3.72 or later). Make sure that
the filename includes the entire path to
the file. For example
.
"/incoming/v0013.ftp". The FTP process
will report status indicators
indicating progress of the download. A
"." will be printed on every
download block to indicate that the download
is in process.
FTP SHOW Display the FTP parameters. The output
is shown below.
lP_ADDR: 192.1683.168
USER: grasche
PASSWORD: newguy
The HOST command is protected by the debug password. The HOST command allows
the user to
communicate to the host receiver. There are nvo communication paths available
to communicate with the
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
59
HDLC
receiver: internally through the host interface or externally through a cable
from the AUX 1 port of the
ethernet card to the M&C port of the receiver. The first option, internal
communication, requires the clear
channel receiver code V 1.16 or higher. The second option works with any
version of receiver code but does
require an external cable. The two forms of the HOST command are shown below.
HOST string This command sends the string specified to the receiver through
the
internal host interface. Note that the string represents a command to
the receiver and as such MUST be in capital letters. if the string
contains a comma then it MUST be surrounded by double quote (")
characters.
HOST AUX l,string This command sends the string specified to the receiver
through the
external AUX I connector. Note that the string represents a command
to the receiver and as such MUST be in capital letters. if the string
contains a comma then it MUST be surrounded by double quote (")
characters.
The HDLC command is protected by the debug password. The HDLC command controls
the incoming.data
from the StarGuide II receiver. The data is received over the receiver
backplane. The data is ethernet data
packets encapsulated in an HDLC stream. One of the other parameters of the
HDLC command is the IBS
channel IP address and port number. This address (along with the associated
port) determines which packets
are designated as "in-band signalling".
HDLC DEBUG_LEVEL[,0(1(2] Sets the debug level for the HDLC
processing block.
HDLC DRV_DEBUG[,TRUE(FALSE] Sets the HDLC software driver debug level.
HDLC ENABLE[,TRUE(FA LSE] Enables the reception of data from the
- ~ receiver.
HDLC IBS_IP_ADDR[,value] - Set the In-Band Control Channel 1P address.
HDLC IBS_UDP_PORT[,value] - ( 1..8000) Sets the port used for the (BS stream.
HDLC STATISTICS_CLEAR Clears all HDLC statistics.
HDLC SHOW Display HDLC parameters and counters.
The output is shown below:
>HDLC SHOW
debugLevel 0
drv0ebug FALSE
enable TRUE
config.ibsIpAddr 239.255Ø1(OxEFFF0001)
config.ibsUdpPort 2002.
isrCount 0
Glitch on RX 0
Flag Status 0
Rx Frame 0
Busy Condition 0
Rx Buffer 0
Rx DPLL Error 0
R:< Length Error 0
Rx Nonalign FrameO
Rx Abort 0
Rx CRC Error 0
Rx Overrun 0.
discardframeCnt 0
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
IGMP
MC
PIIVC
crcErrorCnt
abortErrorCnt
ifaceErrorCnt
The values of the counters increase as IP traffic is received from the SGII
receiver
The IGMP command is also hidden behind the debug password. The IGMP command is
used to configure the
ethernet card's behavior in the presence of an IGMP network. This commands
options are shown below.
IGMP DEBUG[,TRUE~FALSE] Enables the debug
mode of the
IGMP process.
IGMP ENABLE[,TRUE~FALSE] Enables the card's
IGMP handling.
IGMP QUERIER_ENABLE[,TRUE~FALSE] In lGMP mode, this
command
enables the card's
query mode.
IGMP QUERY_INTERVAL[,value] - (!00..2500)Sets the query interval
in query
mode (in 1/10 of
second).
~
IGMP QUERY_RESPONSE_INTERVAL[,value] Sets
- (10..255) the response timeout
value (in
I/10 of a second).
IGMP IP ADDR_BASE[,value] -~(OxE0000000..OxEFFFFFFF)Base address of the
IGMP address
b lock.
IGMP (P ADDR_MASK[,value] - (OxFFFF0000..OxFFFFFFFF)Sets the mask for
the block which
d etermines the size
of the address
block.
IGMP GROUP_MEMBER,<ip addr>, Query if a particular
IP address is
joined or not.
IGMP SHOW Display the IGMP
settings. The
response is shown
below.
>IGMP SHOtJ
debug TRUE
vuerier TRUE
enable TRUE
querierEnable TRUE
queryInterval 600 (1/10 seconds)
queryResponseInterval 100. (1/10 seconds)
ipAddrBase ' w239.255Ø0 (OxEFFF0000)
ipAddrMask OxFFFF0000
The MC command is used to set the parameters of the monitor and control RS-232
interface. Currently only
the baud rate can be set although the parity, data bits, and stop bits will be
added to this command in the
future.
MC LOGMSG,<TRUE~FALSE>
MC TTY_BAUD_RATE,<value> (range 9600..38400) Sets the baud rate to the
specified setting.
MC SHOW Displays the current settings for the M&C port.
The PING command is used to check Ethernet connectivity from the EDS Card card
to another !P based
device. The PING command will send out an ICMP echo request message to the
specified IP address. The
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
61
command will display the results of the ping messages (either successor
failure). If the pings are successful.
time results will be displayed. The PING command comes in the following forms:
PING ipAddress<,numPin~s> Where the ipAddress can either be a dot
notation address or a hex number and the numPings represents the number
of pins .to send. The numPings must be greater than 0. The following
results show a successful ping followed by an unsuccessful ping.
NV
RCV
>ping 192.168.3.1
task-Spawn ok
>PING 192.168.3.1: 56 data bytes
64 bytes from sd-firewall.starguidedigital.com (192.168.3.1): icmp-seq=0.
time=4. ms
64 bytes from sd-firewall.starguidedigital.comr(192.168.3.1): icmp_seq=1.
time=2. ms
64 bytes from sd-firewall.starguidedigital.com,(192.168.3.1): icmp_seq=2.
time=2. ms
----192.168.3.1 PING Statistics----
3 packets transmitted, 3 packets received, 0~ packet loss
round-trip (ms) min/avg/max = 2/2/4
>ping 100.1.1.1
rdSkSpdwn Ok
>PING 100.1.1.1: 56. data bytes
no answer from 100.1.1.1
The NV command is a debug command. The NV command is used to access or display
various non-volatile
memory locations or structures. Currently it is used to store an event log so
all of the options of the command
revolve around the-log. In the future this command may be converted to a LOG
command with various
options.
NV DB_CLEAR Clears the entire non-volatile memory database.
NV LOG_CLEAR Clears the event log.
NV LOG_SHOW(,inder] Displays the contents of the event log.
The RCV command is used to configure or query critical parameters of the
receiver. This command
communicates with the receiver via the internal host interface. Thus, the
receiver must being running Clear
Channel Code Version. 1.16 code or newer. The following list shows the options
available with the RCV
command. Each command option indicates a command that is sent to the receiver.
For details on any of the
receiver commands, see the StarGuide !l User's Manual.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
62
RCV RF[,frequency] - (920000..200000) The RF queries or sets the receiver's L-
Band frequency in
kHz. Valid values are shown in parentheses.
RCV DR[,data_rate] - (512000..819?000)The DR queries or sets the receiver's
data rate in bits per
second. Valid values are shown in
parentheses.
RCV VR[,viterbi rate] The VR command sets or queries the
- (3..4) Viterbi decoder rate of
the receiver. Valid values are shown
in parentheses.
RCV CLR[,clr_mode] - (0..1)The CLR command sets or queries
the Clear Channel Mode
of the receiver. Valid values are
shown in parentheses.
RCV EB The EB command queries the current
Eb/No reading of the
receiver in l Oths of a dB. The
higher the number, the better
the signal strength.
RCV AG The AG command queries the current
AGC reading on the
receiver. The higher this value
is the less input signal level
there is at the input of the receiver.
This value ranges from
0 to 255 and should be kept as near
to.128 as possible when
configuring the receiver.
RCV SS The SS queries the current status
of the receiver. This value
represents a sum of the individual
status.bits currently
active. A value of 0 indicates no
errors are currently active.
See the StarGuide I l User's manual
for the bitmap values.
RCV SF The SF queries the fault history
of the receiver. This value
represents a sum of the individual
status bits that have been
activated since the last time they
were cleared (using the SF
0 command through either the HOST
or HOST AUX I
commands). A value of 0 indicates
no faults have occurred.
See the StarGuide II User's manual
for the bitmap values.
RCV REV The REV command queries the current
software version
running in the receiver. This command
shows the code
versions of the motherboard, the
demodulator, and the DSP
code.
RCV SHOW The RCV SHOW command displays the
current values of
the receiver parameters that are
queried. A parameter is
queried every 2 seconds and the
parameters are queried
sequentially. The output of this
command looks something
like the following.
>rcv shower
RF: 985000
DR: 6144000
VR: 3
CLR: 1
LB: 7.0
AG: 12'1
SS: 0x00000000
Sc: Ox00000C00
REV: 1.16,8,160
REBOOT
The REBOOT command is used to perform a soft boot. The command comes in one
form:
REBOOT <arg> Where arg can be either
0: This type of boot causes the system to go through the normal bootup
sequence but memory is not cleared.
l: This type of boot causes the reboot to pause at the boot prompt so the
user can change any boot parameters. Memory is not cleared in this type of
boot.
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
63
2: This performs a normal boot but memory is cleared. This is the default
if arg is not specified.
SCHED
The SCHED command is used to display the scheduler's current scheduled events.
The command comes in
the following forms:
SCHED SHOW Displays the currently active schedules, if any.
SCHED PURGE Delete any exisitin~ schedule.
SCHED ADD,dT,rly,fid0[,fidN] Add an event to the schedule.
The dT parameter indicates an event window time in which the
relay specified by rly must occur. If the relay is activated
during the active window then the file or files specified by the
fid0 through fidN parameters are played from the flash
memory disk. If multiple files are specified they are played
back to back starting from the first file through the last file.
STATS
The STATS command is used to display various bandwidth statistics kept on the
board. The statistics include
both the ethernet port and the hdlc port.
STATS_CLEAR Clears the statistics.
STATS SHOW Shows the current statistics. An example of the parameters
displayed are
shown below. The statistics are kept from the last time they were cleared. The
bandwidth statistics show the average bandwidth over the last 5 seconds.
>STATS SHOW
S=.TS:._=T.c IIVTEREACE (s0)
1G packets received; 0 packets sent
0 i:~put errors; 0 output errors
'_06~ bytes received
504 cps (average bandwidth) received
°' P.v..erage satellite packet size is 106
~TH~R~I~T INTERFACE ( e0 )
625 packets received; 439 packets sent
0 input errors; 0 output errors
600 collisions
3 packets routed from s0
849 bytes routed from s0
452 bps (average bandwidth) routed from s0
Average packet size routed from s0 is 283
.36 seconds since the statistics were cleared
SYSTEM
The system command is used to set or query the SNMP system table strings. This
command is a debug
command and comes in the following forms:
CA 02428586 2003-05-12
WO 02/069073 PCT/USO1/43986
64
SYSTEM CONTACT(,"string"] To set the contact string, the string must be less
than 2~6
characters. The string should be surrounded by double
quotes as shown.
SYSTEM LOCATION[,"string"J To set the location string, the string must be less
than
256 characters. The string should be surrounded by
double quotes as shown.
SYSTEM DESC[,INIT] This command can either query the current SNMP
description string or re-initialize it. The re-initialization
is only needed once after upgrading the code from
versions 5-7 to version 8 or newer because the format of
the string saved in flash memory was changed. If this is
not done the description in the SNMP will indicate both
the previous software version AND the new one.
SYSTEM SHOW Display the current settings for the SNMP System
tables. The output ofthis command is shown below
with the card's default strings.
>SYSTEM SHOW
LOCATION:
San Diego, CA 92121 (619)452-4920
CONTACT:
Starguide Digital Networks
TIME
VER
The time command is used to set or query the system time. The StarGuide
receiver will set the time based on
the network timestamp. An example of the query response is shown below.
9405a2936,THU OCT 2 I 14:5S:36 1999 PDT (GMT-7)
The time command can also be used to set the current time zone for the EDS
Card card since the time is sent
in GMT.
The VER command is used to query the current software version. The query
response includes the software
version, the date and the time the code was built. An example of a query is
shown below.
0Ø2,Jan 22 1997,16:35:50
