Technical field
[0001] The present invention generally relates to methods, devices, systems and software
routines relating to satellite television signal reception technology and in particular
to controlling methods of ODUs in single-cable satellite television distribution scheme.
Background Art
[0002] The single-cable installation scheme refers to the satellite television techniques.
It enables the satellite reception by many receiving apparatus by means of single
plastic fiber optic, coaxial cable or the like. The single-cable installation excludes
connection many receivers or decoders (IRDs) by means of numerous cables that would
otherwise be used. IRDs convert electrical signals that can be used by any kind of
displays. IRDs include television tuner-receivers, single or twin tuner personal video
recorder (PVRs), single or multiple tuner set-top-boxes (STBs), servers that distribute
the signal to client apparatus, or the like. The term IRD refers to any such device
regardless of any additional capabilities (recording, transcoding, broadcasting over
Wi-Fi or the like) or the location of the device (beside, under or over the TV apparatus,
beside or stand alone or the like).
[0003] Single-cable distribution allows connection of many receivers or a receiver with
many tuners by means of a single cable to external satellite equipment. Such satellite
equipment is commonly referred to as an outdoor unit (ODU).
[0004] Typical ODUs include: a parabolic or elliptical satellite dish and a low-noise block
(LNB) attached to a dish. The LNBs may include RF front-end, switch or another signal
processing functional block. Parabolic dish redirects (reflects) RF microwave signal
to the input of LNB. This RF signal carries multiple encoded (modulated) television
signals over a wide bandwidth.
[0005] ODU doesn't necessarily have to refer to traditional satellite outdoor apparatus
and may include any other wide bandwidth RF receiving equipment, for instance, multiswitch
or head-end device also located indoor. ODU doesn't have to refer only to an apparatus
receiving signal from only one satellite.
[0006] The RF signals from one satellite can be received on one or more polarities. They
are usually identified as vertical and horizontal or right-hand and left-hand circular
polarization. Thus, an ODU is designed to receive two separate RF signals from one
satellite. The RF signal from each polarization may be in addition divided into two
sub-bands 1.2 GHz each. It refers then to universal architecture of ODU. If the RF
signal is not divided, but whole polarization is fed to input of the RF block, it
refers then to wide-band architecture of ODU. The ODU usually converts the RF signal
to lower frequencies, herein called intermediate frequency band (L-band). The converted
RF signal carried in L-Band is connected by means of fiber optic or coax cable to
the receiver for demodulation.
[0007] Each of RF signal (on each polarity) contains the transponders. A transponder is
a certain bandwidth of frequency containing modulated digital or analog television
signal. Each transponder may contain one or more TV, radio signals or EPG (Electronic
Program Guide), data, sound or any content. For the purposes of this discussion, a
channel is a radio frequency transponder signal. Before the advent of the single cable
technology, the entire frequency range of one polarity (with the channel, user wants
to watch) from one satellite was switched to the ODU output and conveyed through coax
cable to a particular receiver. However, another user may want to watch at the same
time a channel on another polarity. Since only one polarity can be carried by a cable
at the time, each receiver requires separate cable connection to ODU.
[0008] In a single-cable system, ODU converts down the channel (transponder) to a specific
frequency bandwidth (for instance, 60MHz) called user-band (UB). ODU may convert more
than one channel at the time, and each channel is converted to a different UB. Each
UB is centered on a fixed frequency, which a tuner in a receiver is assigned and always
tuned to. Unique number is assigned to each UB for identification. The IRD selects
a channel for viewing and informs the ODU about it. The ODU performs a converting
of the selected transponder from selected satellite (with channel for viewing on it)
to an assigned UB center frequency that is sent over a coax cable to a tuner in the
receiver. The receiver which is always tuned to the center frequency of its assigned
UB may decode the signal of its selected transponder. By stacking many UBs on the
same output frequency bandwidth, many receivers can be connected to ODU (by means
of single coax cable), each assigned with different UB and each tuned to a different
transponder independently on polarity and/or satellite.
[0009] A European industry standard for controlling the single-cable ODUs has been promulgated
in October 2007 by the European Committee for Electrotechnical Standardization (CENELEC),
herein referred to as EN 50494. The EN 50494 has been widely accepted by satellite
equipment industry. The physical controlling capabilities of the EN 50494 have been
limited to 8 UBs and 2 satellites.
[0010] In order to maintain a low cost and to maintain backward compatibility the communication
between ODU and IRD is one-way. To accommodate this, the EN 50494 prescribes a Digital
Satellite Equipment Communication (DiSEqC™ 1.x). This protocol allows unidirectional
communication between ODU and IRD (DiSEqC™ is a trademark of EUTELSAT). The EN 50494
supports also an auto-installation process, which helps in assignment of UB number
to the installed IRD. This demands a two-way communication, where the answer of ODU
to the IRD is executed by turning on a RF "tone" by the ODU. The ODU defines two types
of the answers to IRD: YES and NO. Answer YES is communicated to IRD by executing
RF "tone" at the center frequency of UB. Answer NO is communicated to IRD by executing
RF "tone" at 20MHz above center frequency of UB. The process of replying with RF "tones"
generates a lot of difficulties due to disturbance signals (for example, inter-modulation
signals appearance) or complexity of the "tone" recognition. Another problem is that
during "ODU_UBxSignal_ON" command a plurality of the "tones" is generated, which may
result with a video loss on the UBs that have already been assigned to its IRD. As
a consequence, installation protocol described in EN 50494 has generally not been
employed in majority of the IRDs. Rather, during first installation, an installer
is in charge of manual assignment a unique UB number to each receiver. This is time
consuming, demands certain degree of skill from the installer and may be impractical
in multi-dwelling installations.
[0011] Another European industry standard for controlling the single-cable ODUs has been
promulgated in September 2013 by the European Committee for Electrotechnical Standardization
(CENELEC), herein referred to as EN 50607. The physical controlling capabilities of
the EN 50607 have been limited to 32 UBs and 64 satellites. The EN 50607 keeps backward
compatibility to EN 50494 and is a natural successor of EN 50494. However, the installation
process is defined with two-way communication based on DiSEqC 2.x protocol.
[0012] In order to instruct the ODU to perform a conversion of certain transponder to its
UB, IRD sends "ODU_Channel_Change" command. To indicate the frequency of the selected
transponder, IRD must incorporate in the command a "tuning word" in the range of 110
to 2147MHz. "Tuning word" fits very well the frequency range for Ku-band devices (input
frequency: 10700 to 12750MHz) with universal architecture. However, for the devices
with wide-band architecture (for example: IF frequency: 300 to 2350 MHz) it is defined
to use so called ULEM (Universal LNB Emulation Mode) algorithm due to the limited
space for the transponder frequency (110 - 2147 vs. 300 - 2350MHz). The ULEM algorithm
defines a different calculation of the incorporated "tuning word" in order to ensure
fitting the range of 110 to 2147MHz. Thus, ULEM brings some inconsistency and confusion
to the IRD programmers. It is impossible to use "ODU_Channel_Change" command for other
than Ku-Band (C- or Ka-Band) device with wide-band architecture.
[0013] Both standards, EN 50494 and EN 50607, demands from the installer performing all
manual settings in IRD for proper installation. This means, that minimum LO (local
oscillator) frequency and manual assignment of unique UB number to IRD must be performed.
Technical problem
[0014] What is needed, therefore, is a method, system, and computer program for controlling
the single-cable ODU by one or more IRDs connected to this ODU via single coax cable.
The new controlling protocol should not be limited to less than 32 UBs and 8 satellites.
It should ensure automatic installation without any interaction from installer's side
(dynamic UB allocation and assignment), must be independent on the ODU architecture
(wide-band or universal) or band type (C-, Ka-, Ku-band). It should support all polarizations
as well as be suitable for any kind of ODU device (LNB, multiswitch, head-end, etc.).
It should also possibly eliminate usage of the RF "tones" as the possible cause of
the uncertainty during installation. It should be backward compatible to EN50494 and
EN50607 and provide mechanism for single and multi dwelling scenario. It should also
define the commands for sending data or file to ODU. This can be used for upgrading
with newer software which can contain improvements, necessary changes or bug fixing.
However, it must also be working with the IRDs supporting DiSEqC 1.x (unidirectional
communication) as well as DiSEqC 2.x protocol (bidirectional communication).
General Description of the Invention
[0015] In order to overcome the above-mentioned problem, the present invention proposes
a method of auto-installing an integrated receiver/decoder (IRD) comprising the steps
of:
- a) issuing first digitally coded command ODU_Allocate from the IRD to an outdoor unit
(ODU) requesting dynamic (ODU assigns UB number to IRD) or static (IRD asks ODU for
assigning to particular UB number) user band (UB) allocation;
- b) receiving reply from the ODU in response to the first command ODU_Allocate, if
UB is available; said reply comprising a UB number, a center frequency of said UB,
number of receivable satellite positions and information if ODU is aware of its local
oscillator (LO) frequency or not (i.e. if the ODU contains or possesses a local oscillator);
storing in the IRD the UB number, the center frequency of said UB, number of receivable
satellite positions and information if ODU is aware of its local oscillator (LO) frequency
or not (i.e. if the ODU contains or possesses a local oscillator);
- c) receiving reply from the ODU in response to the first command ODU_Allocate, if
UB is not available; said reply comprising a failure message ODU_Error;
- d) returning a predefined number of times to step a) if no reply received in step
b).
[0016] Preferably, the first digitally coded command ODU_Allocate contains the UB number
if the IRD is in static UB allocation mode, asking this way ODU for allocation to
certain UB frequency.
[0017] In a further embodiment, the method may comprise the steps of:
e) issuing second digitally coded command ODU_Release from the IRD to the ODU requesting
release of the previously allocated UB number;
f) receiving reply from the ODU in response to the second command ODU_Release, said
reply comprising a failure message ODU_Error if UB cannot be deallocated or a success
message ODU_OK if UB number has been deallocated.
[0018] In a still further embodiment, the method further may comprise the steps of:
g) issuing third digitally coded command ODU_Active from the IRD to the ODU indicating
that a UB number is occupied and active;
h) receiving reply from the ODU in response to the third command ODU_Active, said
reply comprising a failure message ODU_Error if UB number has already been deallocated
or UB number is invalid; or a success message ODU_OK if activeness of UB number is
confirmed.
[0019] In yet another embodiment, the method further may comprise the steps of:
i) issuing fourth digitally coded command ODU_Tune from the IRD to the ODU indicating
a feed the IRD wants to be connected to, comprising information on allocated UB number,
satellite, polarization and value for transponder frequency,
j) receiving reply from the ODU in response to the fourth command ODU_Tune, said reply
comprising a failure message ODU_Error if UB number has already been deallocated or
UB number, satellite, polarization and/or value for transponder frequency is invalid;
or a success message ODU_OK if command is confirmed and conversion has been performed
successfully.
[0020] Preferably, the value for transponder frequency is dedicated to (three) different
types of ODUs and wherein the value for transponder frequency is the actual transponder
frequency if the ODU is a Ku or Ka band ODU which is aware of its LO frequency; or
the value for transponder frequency is the actual transponder frequency increased
by a predetermined value, if the ODU is a C band ODU which is aware of its LO frequency.
[0021] Commands: ODU_Allocate, ODU_Tune, ODU_Release or ODU_Allocate_DiSEqC1 can be transferred
with additional, optional byte carrying PIN code matching the PIN code stored in ODU.
ODU should contain in non-volatile memory a table with PIN codes associated to the
user bands. PIN code feature is useful for multi dwelling installations where installers
making the installation on separate dwellings can't communicate between each other
on UB used for particular receivers.
[0022] In order to overcome the above-mentioned problem, the present invention also proposes
a method of sending files or data from integrated receiver/decoder (IRD) to ODU comprising,
further to at least the steps a) to d) described above, the steps of:
- a. issuing digitally coded command ODU_TransInit from IRD to ODU in order to initiate
the data or file upload,
- b. receiving positive reply ODU_Success if ODU is ready for data or file reception.
If ODU is not ready for the file reception, it sends ODU_Fail. For the receivers with
DiSEqC 1.0 communication (no reply capability) this part is excluded.
- c. issuing digitally coded command ODU_File from IRD to ODU with payload of the file,
- d. receiving positive reply ODU_Success after ODU has received the data correctly
without errors. If ODU hasn't received the command correctly or data have been corrupted,
it sends the command ODU_Parity in order to repeat the transmission of last command.
After second reception of corrupted command, ODU can decide to send the command ODU_Fail
for transmission interruption. For the receivers with DiSEqC 1.0 communication (no
reply capability) this part is excluded.
- e. issuing digitally coded command ODU_EOT from IRD to ODU signaling end of the file
or data,
- f. receiving positive reply ODU_Success from ODU, if entire file has been sent correctly.
If there have been errors and entire file image is corrupted, ODU sends ODU_Fail command.
For the receivers with DiSEqC 1.0 communication (no reply capability) this part is
excluded.
[0023] In a further aspect, the invention relates to an integrated receiver/decoder (IRD)
comprising:
- a) means arranged for issuing first digitally coded command ODU_Allocate from the
IRD to an outdoor unit (ODU) requesting dynamic or static user band (UB) allocation;
- b) means arranged for receiving reply from the ODU in response to the first command
ODU_Allocate, if UB is available; said reply comprising a UB number, a center frequency
of said UB, number of receivable satellite positions and information if ODU contains
local oscillator (LO) or not; storing in the IRD the UB number, the center frequency
of said UB, number of receivable satellite positions and information if ODU contains
local oscillator (LO) or not;
- c) means arranged for receiving reply from the ODU in response to the first command
ODU_Allocate, if UB is not available; said reply comprising a failure message ODU_Error;
- d) means arranged for reiterating the issuing of the first digitally coded command
ODU_Allocate of step a) a predefined number of times if no reply received by means
b),
- e) means arranged for sending request command ODU_TransInit from IRD to ODU for file
sending,
- f) means arranged for receiving reply from ODU in response to the ODU_TransInit command.
For the receivers with DiSEqC 1.0 communication (no reply capability) this part is
excluded.
- g) means arranged for sending the command ODU_File from IRD to ODU with file payload
which is the consequence of the positive reply on ODU_TransInit command
- h) means arranged for receiving reply from ODU in response to the ODU_File command.
For the receivers with DiSEqC 1.0 communication (no reply capability) this part is
excluded.
- i) means arranged to repeat step g) and h) until entire file is transmitted,
- j) means arranged for sending the command ODU_EOT from IRD to ODU after entire file
transmission,
- k) means arranged for receiving reply from ODU in response to the ODU_EOT command.
For the receivers with DiSEqC 1.0 communication (no reply capability) this part is
excluded.
[0024] In a still further aspect, the invention concerns an outdoor unit (ODU), comprising:
- a) means arranged for receiving a first digitally coded command ODU_Allocate from
an integrated receiver/decoder (IRD) requesting dynamic or static user band (UB) allocation;
- b) means arranged for sending reply to the IRD in response to the first command ODU_Allocate,
if UB is available; said reply comprising a UB number, a center frequency of said
UB, number of receivable satellite positions and information if ODU contains local
oscillator (LO) or not; storing in the IRD the UB number, the center frequency of
said UB, number of receivable satellite positions and information if ODU contains
local oscillator (LO) or not;
- c) means arranged for sending reply to the IRD in response to the first command ODU_Allocate,
if UB is not available; said reply comprising a failure message ODU_Error.
- d) means arranged for sending reply to the IRD in response to command ODU_TransInit,
(if reply is requested) when ready for file or data reception,
- e) means arranged for sending reply to the IRD in response to command ODU_File (if
reply is requested) and storing the payload of data,
- f) means arranged for sending reply to the IRD in response to command ODU_EOT (if
reply is requested) after the file has been received uncorrupted.
[0025] Finally, the invention also pertains to a computer program product comprising program
instructions which, when executed by a processor, cause the processor to auto-install
an integrated receiver/decoder (IRD), according to a method as described herein. Preferably,
the program instructions are contained in at least one semiconductor chip.
[0026] It is clear from the above that the invention also relates to a method of single-cable
automatic installation using one or more of the steps and/or one or more of the commands
as described herein.
[0027] The present invention thus presents many differences with and advantages over the
known solutions, such as in particular EN 50494 or the solution described in
WO 2010/086884 A1:
- the ODU must know its LO frequency in order to perform the frequency conversion properly.
This is in contrast to WO 2010/086884 A1 and EN 50494 which require the IRD to know the LO frequency (in fact, it has to be
set by the installer/end user)
- WO 2010/086884 A1 describes a protocol for only dynamic UB slot allocation and EN 50494 describes a
protocol for only static UB slot allocation, while the present invention includes
both methods within one protocol (it can be used interchangeably),
- although WO 2010/086884 A1 and EN 50494 basically result in the same final effect of the protocol as the present
invention, the final effect is however reached with totally different methods,
- the present invention's static mode does not use typical DiSEqC syntax (described
in DiSEqC standard) as in EN 50494 and is therefore faster and more efficient, and
- the present invention differs from WO 2010/086884 A1 and EN 50494 with no need for the installer's interaction. WO 2010/086884 A1 and EN 50494 require minimum settings being performed by the installer.
[0028] The following presents a simplified summary of embodiment in order to provide basic
understanding of some aspects of such embodiment. This summary is not extensive overview
of embodiment and its sole purpose is to present some concepts of the described embodiment
in a simplified form as a prelude to the more detailed description that is presented
later.
[0029] To address problems described above, a number of controlling commands are described.
It is assumed that IRD is DiSEqC 2.X compatible and all replies of ODU to IRD are
also sent in DiSEqC command format.
[0030] Before the IRD tunes to the first transponder after turning-on or any other deactivation
period, it must get the unique UB number assigned. Therefore, the IRD sends a command
"ODU_Allocate". Command "ODU_Allocate" has a parameter indicating type of allocation:
dynamic or static and UB number in case of static allocation request. By dynamic slot
allocation ODU decides which UB number and frequency is assigned to IRD sending ODU_Allocate
command. In case of static mode of UB allocation, IRD asks ODU for assigning to the
specific UB number given in ODU_Allocate command. Command "ODU_Allocate" can also
contain additional byte, a PIN code which should match the PIN code stored in internal
non-volatile memory of ODU. If the IRD requests dynamic UB allocation, ODU in return
sends response (by means of DiSEqC commands) to IRD with UB number, UB center frequency
(with accuracy to 0.125MHz), number of receivable satellites and information whether
ODU "knows" its LO frequency or not. If the IRD requests static UB allocation indicating
in the parameter UB number it requires to be assigned to, ODU in return sends in confirmation
desired UB number, UB center frequency (with accuracy to 0.125MHz), number of receivable
satellites and information whether ODU "knows" its LO frequency or not. If, in both
cases allocation is impossible due to lack of free UBs in dynamic allocation mode
or due to already assigned or non-existing UB in static allocation mode, the ODU sends
in return a failure message ("ODU_Error"). A failure message ("ODU_Error") can also
be sent if command ODU_Allocate contains an optional PIN code which doesn't match
the PIN code stored in ODU. If the IRD doesn't receive any return message from ODU
it must repeat the command five times.
[0031] Within the entire period of IRD's activity and tuning to the UB, IRD sends the command
"ODU_Active" with UB number as parameter indicating its presence on the coax cable
and tuning to the assigned UB. The ODU returns acceptance command ("ODU_OK") while
command received properly and failure command while the UB parameter is incorrect
(for example, UB number given in command is not assigned to any IRD or simply doesn't
exist at all). The command "ODU_Active" must be sent at least once per five minutes.
If ODU doesn't receive any command within a time frame of 5 minutes, it de-allocates
occupied UB and frees it for another allocation. If the IRD doesn't receive any return
message from ODU it must repeat the command five times.
[0032] If IRD requires to tune to a transponder with desired channel for viewing, it sends
"ODU_Tune" command. "ODU_Tune" command contains in parameter number of satellite (valid
for multi-satellite ODU), number of assigned UB, polarization and "tuning-word" for
desired frequency of the transponder. "Tuning word" is interpreted differently by
ODU depending on the value range. In general, "tuning word" distinguishes three types
of ODU: Ka/Ku band ODU, C-band ODU and ODU which doesn't know its LO frequency (for
example, multiswitch). If the "tuning word" range (0 - 4095) indicates ODU which doesn't
know its LO frequency, in addition band indication (low or high) is encoded in "tuning
word". For Ka-, Ku- and C-band ODU the direct transponder frequency is encoded in
"tuning word" and is independent on ODU architecture. The ODU returns acceptance command
while command received properly and conversion performed correctly and failure command
while the UB parameter is incorrect (for example, UB number given in command is not
assigned to any IRD or simply doesn't exist at all). A failure message ("ODU_Error")
can also be sent if command "ODU_Tune" contains invalid PIN code or doesn't contain
PIN code at all while previously sent command "ODU_Allocate" did. If the IRD doesn't
receive any return message from ODU it must repeat the command five times.
[0033] Before IRD decides to enter inactivity period (switch-off or connecting to another
alternative medium like Ethernet or cable modem), it must send "ODU_Release" command
with UB number as parameter. It results with de-allocation and freeing occupied UB.
The ODU should switch off the de-allocated UB in order to decrease power consumption.
The ODU returns acceptance command while command received properly and de-allocation
performed correctly and failure command while the UB parameter is incorrect (for example,
UB number given in command is not assigned to any IRD or simply doesn't exist at all).
A failure message ("ODU_Error") can also be sent if command "ODU_Release" contains
invalid PIN code or doesn't contain PIN code at all while previously sent command
"ODU_Allocate" did.
[0034] The command "ODU_Allocate" is designed for the IRDs supporting DiSEqC 2.x, bidirectional
communication. Those IRDs are capable to receive the reply command from ODU. The IRD
that supports only DiSEqC 1.x unidirectional communication must send "ODU_Allocate_DiSEqC1"
command which is especially designed for those IRDs. IRD sends "ODU_Allocate_DiSEqC1"
command with UB number as parameter in order to get assigned to this specific UB.
If the assignment is successful, ODU activates a "tone" in the center frequency of
desired UB. It keeps a "tone" for 30 seconds waiting until IRD detects it. After the
successful detection, IRD must send still within the time frame of 30 seconds a command
"ODU_Tune" which becomes a certain confirmation of the proper assignment. However,
this method demands from the installer a manual setting of LO frequency and UB number
with its corresponding center frequencies. All remaining commands ("ODU_Tune", "ODU_Active"
and "ODU_Release") are sent without any changes. If command "ODU_Allocate_DiSEqC1"
has been sent with optional PIN code, subsequent commands ("ODU_Tune", "ODU_Release")
must also contain properly matching PIN code in order to be processed. However, IRDs
(supporting only DiSEqC 1.x) have no possibility to verify the proper reception of
the commands by ODU due to only unidirectional compatibility.
[0035] If command "ODU_Allocate" or "ODU_Allocate_DiSEqC1" has been sent with optional PIN
code, command "ODU_Release" must also contain properly matching PIN code in order
to be processed and de-allocate the previously allocated user band slot. However,
lack of command "ODU_Active" e.g. for 5 minutes will also deallocate the user band,
although it has been allocated with "ODU_Allocate" or "ODU_Allocate_DiSEqC1" with
valid PIN code.
[0036] IRD can decide to send any data or file to ODU in order to update its software or
change configuration parameters (UB frequency, UB number, UB bandwidth, etc.). In
order to initiate the file transmission, IRD has to send ODU_TransInit command. ODU
replies with ODU_Success if it is ready and capable to receive a file. If it doesn't
have the capability to receive the file it replies with ODU_Fail. Once the ODU replies
with ODU_Success, the IRD can start sending the file or data using ODU_File command.
Byte3 of the command ODU_File syntax is a packet number and indicates running number
of ODU_File commands which file comprises of. It starts from 1 and after reaching
255 it rolls over again to 1. The last 2 bytes are CRC16 representation of 64-bytes
payload. The command ODU_File has to be send by IRD so many times until entire file
or all data are sent out. ODU replies to every ODU_File command, either with ODU_Success
if received command is error free or ODU_Parity if command has been received corrupted
and ODU wants IRD to send the command with the same payload again (IRD doesn't increment
Byte3 then) or ODU_Fail if command is received corrupted two times or more and ODU
wants to interrupt transmission. After last ODU_File command, IRD sends ODU_EOT (End
of Transmission) command in order to indicate the end of transmission. ODU replies
with ODU_Success if entire file has been received without errors or with ODU_Fail
if the transmission failed and entire file is corrupted. If IRD doesn't get the reply
from any of the above sent commands it should leave the procedure with error value.
Brief Description of the Drawings
[0037] Preferred embodiments of the invention will now be described, by way of example,
with reference to the accompanying drawings in which:
Fig. 1 is an example of typical home installation of a single-cable system;
Fig. 2 is an example of a block diagram of LNB circuitry, which generally is a part
of a ODU;
Fig. 3 schematically represents composite UB signals;
Fig. 4 is an example of a typical block diagram of an IRD;
Fig. 5 is an example of a typical block diagram of another IRD;
FIG.6 shows the syntax of a preferred format of the first "ODU_Allocate" command.
FIG.7 shows the syntax of a preferred format of the second "ODU_Release" command.
FIG.8 shows the syntax of a preferred format of the third "ODU_Active" command.
FIG.9 shows the syntax of a preferred format of the fourth "ODU_Tune" command.
FIG.10 shows the syntax of a preferred format of a fifth "ODU_Allocate_DiSEqC1" command.
FIG.11 is a flow diagram of an example of a preferred dynamic UB allocation.
FIG.12 is a flow diagram of an example of a preferred static UB allocation.
FIG.13 is a flow diagram illustrative of a normal operation after successful UB allocation.
FIG.14 shows a flowchart of an example of static allocation for IRDs that only support
unidirectional communication according to DiSEqC 1.x protocol.
FIG.15 shows a flowchart of an example of PIN commands handling by ODU.
FIG.16 shows the syntax of a preferred format of the "ODU_TransInit" command.
FIG.17 shows the syntax of a preferred format of the "ODU_File" command.
FIG.18 shows the syntax of a preferred format of the "ODU_EOT" command.
FIG.19 shows a flowchart of an example of file transmission for receivers with DiSEqC
2.x capability.
[0038] Further details and advantages of the present invention will be apparent from the
following detailed description of several not limiting embodiments with reference
to the attached drawings.
Description of Preferred Embodiments
[0039] A typical home installation of a single-cable system is shown on FIG.1 as an illustrative
example of an environment
4 in which the methods described herein for controlling ODU may be employed. The environment
4 illustrates a home installation having two IRDs, IRD no.1
10 and IRD no.2
12. IRD no.1 is associated with, for example, personal video recorder (PVR). IRD no.2
is associated with, for example, set-top-box (STB) integrated in TV-set. IRD no.1
and no.2 are located in separate locations of a dwelling or house
13. Alternatively, the IRDs
10, 12 may be associated with plenty of other functional apparatus or systems. The IRDs
may be part of PVR system having multiple inputs, a satellite radio system, a network
hub to wireless network or other system or device that converts radio-frequency signals
to a useful user form. In the particular example illustrated, the IRD no.1
10 provides television signal to a display
11 and IRD no.2
12 displays the television signal directly on the screen via integrated receiver.
[0040] It should also be noted that although a single dwelling or house
13 is shown for illustration, the methods and systems may be employed in plenty of other
installation locations. Examples may include apartment complex, business building
or hospital.
[0041] As shown in FIG.1 satellite signals
5 are received by an outdoor unit (ODU)
2. The ODU
2 comprises of satellite dish
14 and low-noise-block (LNB)
3 and is mounted on the roof or another appropriate location on the house
13. The LNB
2 down-converts the radio signal to appropriate user bands (UB). A radio signal divider
7 receives an input signal from the ODU
2 on a single-cable
6. The IRDs
10, 12 receive intermediate frequency (IF) signals from the radio signal divider
7. The radio signal divider
7 is a two-way splitter that receives IF signal with incorporated UBs combined with
DC signal. These received signals are communicated from the ODU
2 through the radio signal divider to the IRDs
10, 12 on coax cables
8 and
9. In the other direction, the divider
7 allows command signals (for example DiSEqC™ signals of the type described by CENELEC
EN 50494 or EN 50607 standards) to be communicated to the ODU
2 from IRDs
10, 12.
[0042] The cables
6, 8, 9 may be of any suitable type: coaxial, fiber optic or the like. It should be noted
that multiple cable satellite installation carries different information on each cable.
However, in single-cable network, even though every cable is physically different,
they are coupled to each other and carry always the same information.
[0043] The IRDs
12, 14 are of conventional construction. However, software modification is needed in order
to operate in single-cable distribution installation. Furthermore, hardware of IRDs
should be able to tune to the assigned UB within a standard IF tuning range and modulate
LNB power voltage with a 22 kHz signal issuing DiSEqC commands (according to DiSEqC
Bus Functional Specification v. 4.2).
[0044] A block diagram of LNB circuitry, which is a part of ODU, is shown on FIG.2. The
reflected radio signal (C-, Ka-, Ku-band) from satellite dish reflector is focused
in feed
21. The signal is induced on probes
22, 23 of, for example, two polarities (vertical/horizontal or RHCP/LHCP) and then amplified
by low noise amplifiers (LNA)
16. Local oscillator (LO)
15 generates a tone signal which is mixed along with the radio signal in mixers
14 separately for each polarization. Thus, the radio signal is converted to intermediate
frequency bandwidth and applied to Single Cable Interface (SCIF) block
24. SCIF block
24 performs another conversion of the selected transponder to a desired UB center frequency
by means of CSS modules
25 in CSS block
17. CSS block
17 contains also a combiner
26 which combines or assembles all UBs onto a single-cable
6. The output of combiner
26 contains a number of composite UB signals which are filtered out together by IF filter
18 before being outputted. Every CSS circuitry is controlled by microcontroller
19 and associated to it memory
20. The microcontroller is also responsible for reading incoming DiSEqC commands and
proper interpretation of them. Alternatively, the microcontroller and associated memory
can reside elsewhere in LNB or in another part of ODU. Furthermore, the components
and functions that are shown as being included within the LNB may be housed in several
modules, where each module is a separate device. For example, SCIF module
24 may be located inside the house building
13 (e.g. multiswitch).
[0045] Composite UB signals are shown on FIG.3. Each UB bandwidth
28 contains center frequency
27 and is generated by CSS circuitry. The UBs are numbered UB_1 UB_2 until UB_N. Transponder
belonging to any polarization is converted by CSS circuitry
25 to selected UB center frequency
27. The same transponder may be converted to more than one UB
28. Currently, UB center frequencies
27 may be dynamically changed and re-programmed at any time by internal microcontroller
19. However, there are still CSS devices on the market which don't allow dynamically
changing the UB center frequencies
27. Those devices have the UB center frequencies predetermined during manufacturing.
Analog surface acoustic wave (SAW) filters are used to separate each UB.
[0046] Typical block diagram of IRD no.1
10 is shown on FIG.4, to which reference is additionally made. IRD no.1
10 is shown for illustration as being associated with a Personal Video Recorder (PVR).
IRD no.1 has the following elements: satellite tuner
30, processor
31, memory
32 and PVR circuitry
33. Memory
32 is associated with processor
31 and contains machine code (software) which is executed by processor
31. Memory may be distributed among one or many semiconductor chipsets that provide also
other PVR functionality (e.g. channel recording). A coax cable
9 is connected directly to satellite tuner
30. A coax cable
9 carries composite UB signals from LNB 3 via radio signal divider
7. Processor
31 programs satellite tuner
30 in order to tune to assigned UB
28 and demodulate encoded digital data. Digital data are modulated by means of very
efficient digital modulation techniques (e.g. QPSK or 8PSK). Thus, on the output of
satellite tuner
30 digital data of the transponder appear which are applied to processor for further
processing. Video, audio, EPG, system data are decoded and sent to TV via cable
29 for viewing.
[0047] Similarly, typical block diagram of IRD no.2
12 is shown on FIG.5, to which reference is additionally made. IRD no.2
12 is shown for illustration as being associated with a set-top-box (STB). IRD no.2
has the following elements: satellite tuner
34, processor
35, memory
36 and STB circuitry
37. Memory
36 is associated with processor
35 and contains machine code (software) which is executed by processor
35. Memory may be distributed among one or many semiconductor chipsets that provide also
other STB functionality (e.g. EPG processing). A coax cable
8 is connected directly to satellite tuner
34. A coax cable
8 carries composite UB signals from LNB
3 via radio signal divider
7. Processor
35 programs satellite tuner
34 in order to tune to assigned UB
28 and demodulate encoded digital data. Digital data are modulated by means of very
efficient digital modulation techniques (e.g. QPSK or 8PSK). Thus, on the output of
satellite tuner
34 digital data of the transponder appear which are applied to processor for further
processing. Video, audio, EPG, system data are decoded and sent to internal display
for viewing.
[0048] FIG.11 and FIG.12 are flow diagrams showing a series of steps for performing allocation
and assignment to IRD of UB (for details see below). The procedure allows a UB to
be auto-assigned to without disturbance or interference to active UBs. In the following
description it should be understood that the various commands, replies, determinations,
and any other actions may be performed by the respective microprocessor and memory
of the respective IRD
10, 12. These can be done with conjunction with the microcontroller
19 and memory
20 of the LNB
3. Program instructions in the memories are executed by their respective microprocessor
or microcontroller to perform the stated actions. Nevertheless, it should be also
understood that other methods may be employed to implement the actions described.
[0049] The IRDs
10, 12 or ODU
2 include microprocessors and microcontrollers that function as Central Processing
Units (CPUs) to control operation of the system. The terms microprocessor or microcontroller
are intended to encompass any processing device capable of operating the system or
parts thereof. This includes microprocessors, microcontrollers embedded controllers,
application-specific integrated circuits (ASICs), digital signal processors (DSPs),
state machines, dedicated discrete hardware, or the like. In one embodiment, the central
processing functions are performed by devices that are not programmed, such as discrete
components or one or more state machines. Accordingly, it is not intended that the
microprocessors or microcontrollers be limited to any particular type of hardware
component implementation. These devices may also be implemented as combinations of
computing devices, for example, a combination of a DSP and a microprocessor, a plurality
of microprocessors, one or more microprocessors in conjunction with a DSP core, or
any other such configuration. Moreover, the processing and controlling devices need
not be physically collocated with the part of the system it serves. For example, a
central processing unit or programmed computer may be associated with and appropriately
connected to each of the various components of the system to perform the various actions
described herein.
[0050] FIG.6 shows the syntax of the "ODU_Allocate" command. Command consists of a command
byte - 0x9A, Data1 byte and optional Data2 byte. Data1 is an 8-bit word, the first
three bits (i.e. bits 7 through 5) indicate allocation mode and the next five bits
(i.e. bits 4 through 0) indicate UB number (from 0 to 31). If the first three bits
take the value 0, it means, IRD wants to perform the static UB allocation. Another
5 bits in Data1 indicates the UB number, which IRD wants to get allocated to. If the
first three bits take the value larger than 0, it means, IRD wants to perform dynamic
allocation. For this mode, the value of remaining 5 bits is meaningless. Data2 is
an 8-bit word, where all bits comprise the PIN code value. In reply ODU can send either
one or four bytes. One byte "ODU_Error" - 0x97 is sent if the allocation hasn't been
performed successfully or PIN code is incorrect. If the allocation (regardless of
allocation type: static or dynamic) has been performed successfully, ODU sends four
bytes starting from byte "ODU_OK" - 0x94. Data1is an 8-bit word, the first three bits
(i.e. bits 7 through 5) indicate number of satellites, ODU is capable to receive.
Value comprised of those three bits indicates the number of supported satellites minus
one (i.e. value 0 means support for only one satellite). Another 5 bits in Data1 indicates
the UB number, the IRD has been assigned to. Data2 is an 8-bit word, the all bits
comprise the first 8-bits (i.e. bits 11 through 4) of the UB center frequency. Data2
is an 8-bit word, the four five bits (i.e. bits 7 through 4) indicate the last four
bits (i.e. bits 3 through 0) of UB center frequency. Another 3 bits of Data1 (i.e.
bits 3 through 1) comprise the decimal part of the UB center frequency counted in
0.125MHz. Last bit (i.e. bit 0) indicates the status of the ODU device. Value 0 indicates
the device that contains Local Oscillator (LO) frequency and this means that it also
"knows" its frequency (i.e. LNB) and value 1 indicates the ODU device that doesn't
contain Local Oscillator (LO) frequency and this way it doesn't "know" what is its
frequency used for frequency conversion (i.e. multiswitch to which LNB with internal
Local Oscillator is connected).
[0051] FIG.7 shows the syntax of the "ODU_Release" command. Command consists of a command
byte - 0x9B, Data1 byte and optional Data2 byte. Data1 is an 8-bit word, the first
three bits (i.e. bits 7 through 5) are reserved and meaningless for this method and
the next five bits (i.e. bits 4 through 0) indicate UB number (from 0 to 31), which
IRD wants to get de-allocated from. Data2 is an 8-bit word, the all bits comprise
the PIN code value. In reply ODU can send either "ODU_Error" - 0x97 if the de-allocation
hasn't been performed successfully, UB number is invalid or PIN code is incorrect
or "ODU_OK" - 0x94 if the de-allocation (regardless of allocation type: static or
dynamic) has been performed successfully.
[0052] FIG.8 shows the syntax of the "ODU_Active" command. Command consists of a command
byte - 0x9C and Data1 byte. Data1 is an 8-bit word, the first three bits (i.e. bits
7 through 5) are reserved and meaningless for this method and the next five bits (i.e.
bits 4 through 0) indicate UB number (from 0 to 31), which IRD indicates as active
and occupied. In reply ODU can send either "ODU_Error" - 0x97 if the UB has already
been released or UB number is invalid "ODU_OK" - 0x94 if the activeness has been confirmed.
[0053] FIG.9 shows the syntax of the "ODU_Tune" command. Command consists of a command byte
- 0x9D, Data1 byte, Data2 byte, Data3 byte and optional Data4 byte. Data1 is an 8-bit
word, the first three bits (i.e. bits 7 through 5) indicates the feed, IRD wants to
be connected to. Feed corresponds to the received satellite as single feed can receive
only one satellite. The next five bits (i.e. bits 4 through 0) indicate the UB number,
IRD has been assigned to. Data2 is an 8-bit word, the first bit (i.e. bit 7) indicates
the polarization the IRD wants to tune to (0 - vertical/RHCP, 1 - horizontal/LHCP).
The next seven bits (i.e. bits 6 through 0) comprise the first 7-bits (i.e. bits 14
through 8) of the encoded value for transponder frequency, IRD wants to tune to. Data3
is an 8-bit word, the all bits comprise the last 8-bits (i.e. bits 7 through 0) of
the encoded value for transponder frequency. The encoded value is dedicated to three
different types of devices. If encoded value takes the number from 10001 to 32767,
then it is dedicated to Ku- or Ka-band devices, which "know" their LO frequency. The
value is a direct transponder frequency that IRD wants to tune to. If encoded value
takes the number from 8192 to 10000, then it is dedicated to C-band devices, which
"know" their LO frequency. In this case the first bit of the encoded value (i.e. bit
14) is always 0. In order to get direct transponder frequency, the encoded value has
to be decreased by number 5000 (frequency range: 3192 to 5000MHz). If encoded value
takes the number from 0 to 8191, then it is dedicated to any device that doesn't "know"
its LO frequency. In this case the first two bits of the encoded value (i.e. bit 14
through 13) are always 0. The bits 11 through 0 comprise the transponder frequency
after the down-conversion. Bit 12 indicates the band (0 - low, 1 - high) for the devices
with universal architecture. Data4 is an 8-bit word, the all bits comprise the PIN
code value. In reply ODU can send either "ODU_Error" - 0x97 if the UB has already
been released or UB, feed number, frequency is invalid or PIN code is incorrect or
"ODU_OK" - 0x94 if the command reception has been confirmed and conversion has been
performed successfully.
[0054] FIG.10 shows the syntax of the "ODU_Allocate_DiSEqC1" command. Command consists of
a command byte - 0x9E, Data1 byte and optional Data2 byte. Data1 is an 8-bit word,
the first three bits (i.e. bits 7 through 5) are reserved and meaningless for this
method and the next five bits (i.e. bits 4 through 0) indicate UB number (from 0 to
31), which IRD indicates as UB number it wants to allocate to. Data2 is an 8-bit word,
the all bits comprise the PIN code value. No reply is expected after issuing the "ODU_Allocate_DiSEqC1"
command.
[0055] FIG.11 is a flow diagram of a dynamic UB allocation. In order to assign certain UB
bandwidth to the IRD, IRD must send "ODU_Allocate" command
40 to ODU. IRD waits for the reply from ODU
41. If reply doesn't appear within certain time frame (time frame for the reply from
ODU is defined in DiSEqC Bus Functional Specification v. 4.2), IRD repeats sending
the command "ODU_Allocate"
40 to ODU after randomly generated pause
49. The repeating can reach maximal five times. If the reply is not received after 5
th repeat, IRD can assume that ODU is not connected to IRD or doesn't support the described
protocol and leaves the procedure with failure message
48. If the ODU replies for 1
st command or any of the repeated commands, IRD decodes the reply checking if message
contains "ODU_OK" byte
43. If reply from ODU contains "ODU_Error" byte
43, the IRD must check whether all parameters of "ODU_Allocate" command are within a
specified range and whether PIN code is correct
64 (if given in command syntax). If PIN is incorrect (if given) or any of parameters
is out of the range, IRD exits with failure. If all parameters of "ODU_Allocate" command
are correct, that means that ODU has all UBs allocated and IRD must wait five minutes
44 in order to repeat sending "ODU_Allocate" message
40. Time period of five minutes is needed to wait for automatic de-allocation of any
UB on the line. If the IRD receives from ODU reply message with "ODU_OK" byte, it
means that allocation is successful and ODU has assigned UB to the IRD. IRD can now
decode the center frequency of the UB, (which is encoded in the rest of the reply
message) in order to check whether the UB center frequency fits the range of the output
bandwidth
45 (normally, it should be 950 - 2150 MHz). If UB center frequency is beyond of the
output bandwidth, IRD leaves the procedure with failure message
48. If UB center frequency is within output bandwidth, IRD can decode now the rest of
the reply message (UB number, number of supported satellites and status of ODU) and
along with UB center frequency store it in memory
46. IRD leaves the procedure of dynamic allocation with success message
47.
[0056] FIG.12 is a flow diagram of a static UB allocation. In order to assign desired UB
bandwidth to the IRD, IRD must send "ODU_Allocate" command
50 to ODU. As a parameter, IRD passes also number of the UB that it wants to get assigned
to. IRD waits for the reply from ODU
52. If reply doesn't appear within certain time frame (time frame for the reply from
ODU is defined in DiSEqC Bus Functional Specification v. 4.2), IRD repeats sending
the command "ODU_Allocate"
50 to ODU after randomly generated pause
61. The repeating can reach maximal five times. If the reply is not received after 5
th repeat, IRD can assume that ODU is not connected to IRD or doesn't support the described
protocol and leaves the procedure with failure message
60. If the ODU replies for 1
st command or any of the repeated commands, IRD decodes the reply checking if message
contains "ODU_OK" byte
55. If reply from ODU contains "ODU_Error" byte
55, the IRD must check whether all parameters of "ODU_Allocate" command are within a
specified range and whether PIN code is correct
63 (if given in command syntax). If PIN is incorrect (if given) or any of parameters
is out of the range IRD exits with failure. If all parameters of "ODU_Allocate" command
are correct, that means that desired UB number has already been allocated, IRD increments
the UB number
53 and check whether UB number exceeded overall number of UBs available in the system
51. Then IRD sends again "ODU_Allocate" command
50 with incremented UB number as a parameter. If number of incremented UB number reached
maximum of available UB numbers, IRD waits five minutes, resets the UB number counter
62 and starts the entire process from the beginning by sending again "ODU_Allocate"
command. If the IRD receives from ODU reply message with "ODU_OK" byte
55 after any of sent "ODU_Allocate" commands, it means that allocation is successful
and ODU has assigned desired UB to the IRD. IRD compares the returned UB number (which
is encoded in the rest of the reply message) with the desired one
56. If UB number is different, IRD must increment the UB number
53 and send "ODU_Allocate" command again
50. If UB number is the same as the desired one
56, IRD decodes the center frequency of the UB, (which is encoded in the rest of the
reply message) in order to check whether the UB center frequency fits the range of
the output bandwidth
57 (normally, it should be 950 - 2150 MHz). If UB center frequency is beyond of the
output bandwidth, IRD leaves the procedure with failure message
60. If UB center frequency is within output bandwidth, IRD can decode now the rest of
the reply message (UB number, number of supported satellites and status of ODU) and
along with UB center frequency store it in memory
58. IRD leaves the procedure of dynamic allocation with success message
59.
[0057] After the successful UB allocation, IRD can control the ODU for channel viewing.
It makes no difference which type of UB allocation has been performed: static or dynamic.
The normal operation after successful UB allocation is shown on FIG.13 in a form of
a flowchart. After successful UB allocation, IRD must run the timer, which is reset
every time, the new command: ODU_Allocate, ODU_Tune, ODU_Active arrives. If timer
is not reset and rich out five minutes it automatically de-allocates the slot and
frees memory. This is the situation when ODU assumes that IRD has hung up or has been
switched off without proper de-allocation procedure. This way, the allocated UB may
be within five minutes released and be available for another IRD for allocation. First
thing after allocation is checking the time whether five minutes has already elapsed
77. If time hasn't elapsed yet, the IRD checks whether IRD hasn't got the command to
change the transponder
80. If so, it sends command "ODU_Tune"
72 with appropriate parameters for conversion. IRD waits for the reply from ODU. If
the reply doesn't come
75 within time frame described in DiSEqC Bus Functional Specification v. 4.2 (possible
command conflict on the single-cable line), the IRD sends the command "ODU_Tune" command
once more
72 after a randomly generated pause (from 0 to 1000ms)
71. This random value is going to avoid a command conflict when two or more IRD are sending
the command at the same time. If IRD doesn't receive the reply after five repeats
of command sending
73, it assumes that ODU has been disconnected or mistakenly UB has been de-allocated.
Then IRD de-allocates the UB number, frees memory
74 and try repeating the allocation procedure once again
70. If IRD receives the reply after any of "ODU_Tune" command sending
75, it checks whether the reply is "ODU_OK"
76. If the reply from ODU is negative ("ODU_Error"), the IRD assumes that the UB has
already been mistakenly released, it de-allocates UB number, frees memory
74 and tries allocating the UB again
70. If the reply from IRD is "ODU_OK", IRD checks again whether the five minutes have
elapsed
77 from last command sending. If timer indicates that five minutes are going to elapse,
IRD must send the command "ODU_Active"
79 in order to mark its presence on single-cable line. IRD checks if the reply has been
received
81. If reply hasn't come, the IRD sends the command "ODU_Active" command once more
79 after a randomly generated pause (from 0 to 1000ms)
78. This random value is going to avoid a command conflict when two or more IRD are sending
the command at the same time. If IRD doesn't receive the reply after five repeats
of command sending
82, it assumes that ODU has been disconnected or mistakenly UB has been de-allocated.
Then IRD de-allocates the UB number, frees memory
74 and try repeating the allocation procedure once again
70. If IRD receives the reply after any of "ODU_Active" command sending
79, it checks whether the reply is "ODU_OK"
83. If the reply from ODU is negative ("ODU_Error"), the IRD assumes that the UB has
already been mistakenly released, it de-allocates UB number, frees memory
74 and tries allocating the UB again
70. If the reply from any command "ODU_Active" sent from ODU is positive, the IRD checks
again whether the time of five minutes has elapsed. Monitoring of the timer is performed
in a continuous loop. If the timer still indicates that five minutes haven't elapsed
and there is no request to change the transponder, IRD checks whether the IRD is not
going to be switched off or somehow the satellite tuners are not going to be inactivated.
If not, IRD checks the timer again. If the request for inactivation appears, IRD sends
the command "ODU_Release"
86 in order to de-allocate UB and free memory. IRD checks if the reply has been received
88. If reply hasn't come, the IRD sends the command "ODU_Release" command once more
86 after a randomly generated pause (from 0 to 1000ms)
85. This random value is going to avoid a command conflict when two or more IRD are sending
the command at the same time. If IRD doesn't receive the reply after five repeats
of command sending
87, it assumes that ODU has been disconnected or mistakenly UB has been de-allocated.
Then IRD de-allocates the UB number, frees memory
91 and exit procedure with failure message
92. If IRD receives the reply after any of "ODU_Active" command sending
79, it checks whether the reply is "ODU_OK"
89. If the reply from ODU is negative ("ODU_Error"), the IRD assumes that the UB has
already been mistakenly released, it de-allocates UB number, frees memory
74 and exit procedure with failure message
92. If the reply from any command "ODU_Active" sent from ODU
89 is positive ("ODU_OK"), IRD exits procedure with success message
90.
[0058] FIG.14 shows the flowchart of the static allocation for IRDs that support only unidirectional
communication according to DiSEqC 1.x protocol. Before starting the procedure, installer
must type into receiver the center frequencies of all UBs and frequencies of Local
Oscillators (LOs)
95. Then IRD sends "ODU_Allocate_DiSEqC1" command with requested UB number as parameter
96. Upon received command, ODU activate RF tone at the center frequency of the requested
UB number
97 only for 30 seconds. During this period of time, IRD has to detect the RF tone at
expected frequency
100. If the RF tone doesn't appear
101, IRD should repeat sending "ODU_Allocate_DiSEqC1" command
96. If RF tone still doesn't appear after repeated command sending
101, IRD increments the UB number
99 and checks out if the UB number is not last one available
98. If so, it waits five minutes, resets the UB number
105 and sends again the command "ODU_Allocate_DiSEqC1"
96 starting the entire procedure from the beginning. If incremented UB number is not
the last one, IRD sends again the command "ODU_Allocate_DiSEqC1"
96 with new UB number. If IRD finally detects the RF tone
100, after any of "ODU_Allocate_DiSEqC1" command sending
96, IRD sends immediately the command "ODU_Tune" for first transponder conversion
102. Then, IRD tries to tune to desired transponder
103. If tuning fails, IRD repeats command sending
102 after randomly generated pause (0 to 1000ms)
109. Before subsequent command "ODU_Tune" repetition, IRD checks the number of repeated
commands
107. If number of repeated command reaches more than five, IRD exits with failure message
108. This is information for IRD that the tuning parameters are wrong (satellite, transponder
frequency, polarization, etc.). If IRD finally tunes to the desired transponder
103, it stores assigned UB number in memory
106 and exits procedure with success message
104.
[0059] FIG. 15 shows the flowchart of the PIN commands handling by ODU. ODU decodes the
incoming command. If the command is "ODU_Allocate", "ODU_Tune", "ODU_Release" or "ODU_Allocate_DiSEqC1",
ODU may expect additional byte which indicates PIN code. If decode command is "ODU_Tune"
or "ODU_Release"
120, ODU checks out whether command syntax contains PIN code
123. If command is without the PIN code, ODU has to determine if the "ODU_Allocate" command
sent for slot allocation has also been sent with PIN code
121. If not, ODU checks the correctness of parameters inside the command
127. If parameters are correct, ODU sends "ODU_OK" command
129. If the received command is with PIN code
123, ODU has to determine whether command "ODU_Allocate" for slot allocation has been
sent with PIN code
124, as well. If not, ODU sends "ODU_Error" command as reply
128. If command "ODU_Allocate" has been received with PIN code, ODU compares received
PIN code with the PIN code stored in non-volatile memory and assigned to the same
UB slot
126. If PIN code matches with the PIN code in non-volatile memory, ODU checks all parameters
of the command, whether they are within a range
127. If the parameters are correct, ODU sends command "ODU_OK"
129. If parameters are beyond the range, ODU sends "ODU_Error" command as reply
128.
[0060] FIG.16 shows the syntax of the "ODU_TransInit" command. Command consists of a header
byte, address byte and 0x4E. Header byte is an 8-bit word which can take value 0xE0
or 0xE2. Value 0xE0 indicates DiSEqC 1.x transmission (unidirectional) and value 0xE2
DiSEqC 2.x (bidirectional). Address byte can take values: 0x00, 0x10 or 0x11. Third
byte 0x4E is ODU_TransInit command identifier. If header byte is 0xE2, in reply ODU
can send either "ODU_Success" - 0xE4 if the ODU is ready to receive the file or "ODU_Fail"
- 0xE5 if the ODU is not ready for file reception.
[0061] FIG.17 shows the syntax of the "ODU_File" command. Command consists of a header byte,
address byte, byte 0x4F, packet number byte, 64-bytes payload data and 2-byte CRC16.
Header byte is an 8-bit word which can take value 0xE0 or 0xE2. Value 0xE0 indicates
DiSEqC 1.x transmission (unidirectional) and value 0xE2 DiSEqC 2.x (bidirectional).
Address byte can take values: 0x00, 0x10 or 0x11. Third byte 0x4F and non-zero fourth
byte (packet number) is ODU_File command identifier. Packet number byte is 8-bit word
indicating running number of command. This byte can take value from 1 to 255 only.
Value 0 of packet number byte is invalid. If the file is big the packet number byte
is rolling over to 1 after reaching value of 255. The 64-bytes payload data can be
any data, mostly part of the bigger file. The last 2 bytes are CRC16 checksum value
calculated for 64-bytes payload. If header byte is 0xE2, in reply ODU can send either
"ODU_Success" - 0xE4 if the ODU has received the command successfully and CRC16 checksum
has been correctly verified. ODU replies with ODU_Parity - 0xE6 if received file is
corrupted and CRC16 checksum hasn't been verified successfully. ODU replies with "ODU_Fail"
- 0xE5 if the ODU has received the corrupted data n-th time in a row and/or wants
to interrupt the transmission.
[0062] FIG.18 shows the syntax of the "ODU_EOT" command. Command consists of a header byte,
address byte, 0x4F and 0x00. Header byte is an 8-bit word which can take value 0xE0
or 0xE2. Value 0xE0 indicates DiSEqC 1.x transmission (unidirectional) and value 0xE2
DiSEqC 2.x (bidirectional). Address byte can take values: 0x00, 0x10 or 0x11. Third
byte 0x4F and fifth 0x00 is ODU_File command identifier. If header byte is 0xE2, in
reply ODU can send either "ODU_Success" - 0xE4 if the ODU has received entire file
successfully or "ODU_Fail" - 0xE5 if the ODU received the entire file corrupted.
[0063] FIG.19 shows the flowchart of the file transmission for receivers with DiSEqC 2.x
capability. All commands must have Byte0 in every command - 0xE2 indicating request
for reply. If IRD wants to send the file to ODU, it sends the ODU_TransInit command
140. If reply doesn't come
141 or it is different than ODU_Success
142, IRD leaves the procedure with failure value
154. If the received reply is ODU_Success
142, IRD gets the indication that ODU is ready for file reception. IRD prepares the file
and divides it in 64-bytes blocks. Each block is encapsulated in ODU_File command
and sent to ODU
143. Every ODU_File command contains a packet counter which is incremented for each ODU_File
command. After sending ODU_File command
143, IRD waits for response. If reply doesn't come
144, IRD leaves the procedure with failure value
154. If reply is ODU_Parity
147 the IRD must repeat last ODU_File command without incrementing the packet counter
(with the same packet number)
143, If reply is ODU_Success
148 IRD sends another command ODU_File
143 with another portion of 64-bytes payload and with incremented packet number
145. The procedure repeats until entire file is sent out
149. If reply to any of ODU_File command is ODU_Fail
147, IRD leaves the procedure with failure value
154. After entire file is sent out, IRD sends ODU_EOT command
150, indicating end of transmission. If reply to ODU_EOT command, doesn't come
151 or it is different than ODU_Success
152, IRD leaves the procedure with failure value
154. If reply to ODU_EOT command is ODU_Success
152, IRD can assume that file has been received successfully and can leave the procedure
with success value
153.
[0064] The file transmission for receivers with DiSEqC 1.x capability is similar like in
the FIG.19 with the assumption that for every command IRD receives in reply command
ODU_Success.
1. A method of auto-installing an integrated receiver/decoder (IRD, 10, 12) comprising
the steps of:
a) issuing first digitally coded command ODU_Allocate from the IRD (10, 12) to an
outdoor unit (ODU, 2) requesting dynamic or static user band (UB) allocation; wherein
in dynamic user band allocation the ODU (2) assigns the UB (28) number to the IRD
and wherein in static user band allocation the IRD asks ODU (2) for assigning to particular
UB (28) number,
b) receiving reply from the ODU (2) in response to the first command ODU_Allocate,
if UB (28) is available; said reply comprising a UB number, a center frequency of
said UB (28), number of receivable satellite positions and information if ODU (2)
contains local oscillator (LO) or not; storing in the IRD (10, 12) the UB (28) number,
the center frequency (27) of said UB (28), number of receivable satellite positions
and information if ODU (2) contains local oscillator (LO) or not;
c) receiving reply from the ODU (2) in response to the first command ODU_Allocate,
if UB (28) is not available; said reply comprising a failure message ODU_Error;
d) returning a predefined number of times to step a) if no reply received in step
b).
2. The method according to claim 1, wherein the first digitally coded command ODU_Allocate
contains the UB (28) number if the IRD (10, 12) is in static UB allocation mode.
3. The method according to claim 1 or 2, further comprising the step of:
e) issuing second digitally coded command ODU_Release from the IRD (10, 12) to the
ODU (2) requesting release of the previously allocated UB (28) number;
f) receiving reply from the ODU (2) in response to the second command ODU_Release,
said reply comprising a failure message ODU_Error if UB (28) cannot be deallocated
or a success message ODU_OK if UB (28) number has been deallocated.
4. The method according to any of the previous claims, further comprising the step of:
g) issuing third digitally coded command ODU_Active from the IRD (10, 12) to the ODU
(2) indicating that a UB (28) number is occupied and active;
h) receiving reply from the ODU (2) in response to the third command ODU_Active, said
reply comprising a failure message ODU_Error if UB (28) number has already been deallocated
or UB number is invalid; or a success message ODU_OK if activeness of UB number is
confirmed.
5. The method according to any of the previous claims, further comprising the step of:
i) issuing fourth digitally coded command ODU_Tune from the IRD (10, 12) to the ODU
(2) indicating a feed the IRD (10, 12) wants to be connected to, comprising information
on allocated UB (28) number, satellite, polarization and value for transponder frequency,
j) receiving reply from the ODU (2) in response to the fourth command ODU_Tune, said
reply comprising a failure message ODU_Error if UB (28) number has already been deallocated
or UB (28) number, satellite, polarization and/or value for transponder frequency
is invalid; or a success message ODU_OK if command is confirmed and conversion has
been performed successfully.
6. The method according to claim 5, wherein the value for transponder frequency is dedicated
to three different types of ODUs (2) and wherein the value for transponder frequency
is the actual transponder frequency if the ODU (2) is a Ku or Ka band ODU which is
aware of its LO frequency; or the value for transponder frequency is the actual transponder
frequency increased by a predetermined value, if the ODU (2) is a C band ODU which
is aware of its LO frequency.
7. A method according to any of claims 1 to 6, for file transmission from the integrated
receiver/decoder (IRD, 10, 12) to the ODU (2), comprising the further steps of:
a. issuing digitally coded command ODU_TransInit from IRD (10, 12) to ODU (2) in order
to initiate the data or file upload,
b. receiving positive reply ODU_Success if ODU (2) is ready for data or file reception,
whereas if ODU (2) is not ready for the file reception, it sends ODU_Fail,
c. issuing digitally coded command ODU_File from IRD (10, 12) to ODU (2) with payload
of the file,
d. receiving positive reply ODU_Success after ODU (2) has received the data correctly
without errors, whereas if ODU (2) hasn't received the command correctly or data have
been corrupted, it sends the command ODU_Parity in order to repeat the transmission
of last command,
e. issuing digitally coded command ODU_EOT from IRD (10, 12) to ODU (2) signaling
end of the file or data,
f. receiving positive reply ODU_Success from ODU (2), if entire file has been sent
correctly, whereas if there have been errors and entire file image is corrupted, ODU
(2) sends ODU_Fail command.
8. A computer program product comprising program instructions which, when executed by
a processor, cause the processor to auto-install an integrated receiver/decoder (IRD,
10, 12), according to a method as claimed in any of claims 1 to 7.
9. The computer program product of claim 8 wherein the program instructions are contained
in at least one semiconductor chip.
10. An integrated receiver/decoder (IRD, 10, 12) comprising:
a) means arranged for issuing first digitally coded command ODU_Allocate from the
IRD (10, 12) to an outdoor unit (ODU, 2) requesting dynamic or static user band (UB,
28) allocation;
b) means arranged for receiving reply from the ODU (2) in response to the first command
ODU_Allocate, if UB (28) is available; said reply comprising a UB number, a center
frequency of said UB (28), number of receivable satellite positions and information
if ODU contains local oscillator (LO) or not; storing in the IRD (10, 12) the UB number,
the center frequency (27) of said UB (28), number of receivable satellite positions
and information if ODU (2) contains local oscillator (LO) or not;
c) means arranged for receiving reply from the ODU (2) in response to the first command
ODU_Allocate, if UB (28) is not available; said reply comprising a failure message
ODU_Error;
d) means arranged for reiterating the issuing of the first digitally coded command
ODU_Allocate of step a) a predefined number of times if no reply received by means
b).
e) means arranged for sending request command ODU_TransInit from IRD (10, 12) to ODU
(2) for file sending,
f) means arranged for receiving reply from ODU (2) in response to the ODU_TransInit
command,
g) means arranged for sending the command ODU_File from IRD (10, 12) to ODU (2) with
file payload which is the consequence of the positive reply on ODU_TransInit command,
h) means arranged for receiving reply from ODU in response to the ODU_File command,
i) means arranged to repeat step g) and h) until entire file is transmitted,
j) means arranged for sending the command ODU_EOT from IRD (10, 12) to ODU (2) after
entire file transmission,
k) means arranged for receiving reply from ODU (2) in response to the ODU_EOT command.
11. The integrated receiver/decoder (IRD, 10, 12) according to claim 10 comprising means
arranged for implementing the method according to any of claims 1 to 7.
12. The integrated receiver/decoder (IRD, 10, 12) according to claim 10 or 11 comprising
a computer program product according to any of claims 8 or 9.
13. An outdoor unit (ODU, 2), comprising:
a) means arranged for receiving a first digitally coded command ODU_Allocate from
an integrated receiver/decoder (IRD, 10, 12) requesting dynamic or static user band
(UB, 28) allocation;
b) means arranged for sending reply to the IRD (10, 12) in response to the first command
ODU_Allocate, if UB is available; said reply comprising a UB (28) number, a center
frequency of said UB (28), number of receivable satellite positions and information
if ODU contains local oscillator (LO) or not; storing in the IRD (10, 12) the UB (28)
number, the center frequency of said UB (28), number of receivable satellite positions
and information if ODU (2) contains local oscillator (LO) or not;
c) means arranged for sending reply to the IRD (10, 12) in response to the first command
ODU_Allocate, if UB (28) is not available; said reply comprising a failure message
ODU_Error.
d) means arranged for sending reply to the IRD (10, 12) in response to command ODU_TransInit,
(if reply is requested) when ready for file or data reception.
e) means arranged for sending reply to the IRD (10, 12) in response to command ODU_File
(if reply is requested) and storing the payload of data
f) means arranged for sending reply to the IRD (10, 12) in response to command ODU_EOT
(if reply is requested) after the file has been received uncorrupted.
14. The outdoor unit (ODU, 2) according to claim 13 comprising means arranged for implementing
the method according to any of claims 1 to 7.
15. The outdoor unit (ODU, 2) according to claim 13 or 14 comprising a computer program
product according to any of claims 8 or 9.
1. Verfahren zur automatischen Installation eines integrierten Empfängers/Decoders (IRD,
10, 12), umfassend die folgenden Schritte:
a) Ausgeben eines ersten digital codierten Befehls ODU_Allocate aus dem IRD (10, 12)
an eine Außeneinheit (ODU, 2), die eine dynamische oder statische Zuordnung eines
Benutzerbands (UB) anfragt; wobei die ODU (2) bei der dynamischen Benutzerbandzuordnung
dem IRD die UB-(28)-Zahl zuweist und wobei der IRD bei der statischen Benutzerbandzuordnung
die ODU (2) anfragt, einer besonderen UB-(28)-Zahl zuzuordnen,
b) Empfangen einer Antwort von der ODU (2) in Reaktion auf den ersten Befehl ODU_Allocate,
falls das UB (28) verfügbar ist; wobei die Antwort eine UB-Zahl, eine Mittenfrequenz
des UB (28), eine Zahl von empfangbaren Satellitenpositionen sowie Informationen,
ob die ODU (2) einen lokalen Oszillator (LO) enthält oder nicht, umfasst; Speichern,
in dem IRD (10, 12), der UB-(28)-Zahl, der Mittenfrequenz (27) des UB (28), der Zahl
von empfangbaren Satellitenpositionen und von Informationen, ob die ODU (2) einen
lokalen Oszillator (LO) enthält oder nicht;
c) Empfangen einer Antwort von der ODU (2) in Reaktion auf den ersten Befehl ODU_Allocate,
falls das UB (28) nicht verfügbar ist; wobei die Antwort eine Ausfallmeldung ODU_Error
umfasst;
d) Zurückkehren zu Schritt a) für eine vorbestimmte Anzahl von Malen, falls in Schritt
b) keine Antwort empfangen wurde.
2. Verfahren gemäß Anspruch 1, wobei der erste digital codierte Befehl ODU_Allocate die
UB-(28)-Zahl enthält, falls sich der IRD (10, 12) im statischen UB_Zuordnungsmodus
befindet.
3. Verfahren gemäß Anspruch 1 oder 2, ferner umfassend den folgenden Schritt:
e) Ausgeben eines zweiten digital codierten Befehls ODU_Release aus dem IRD (10, 12)
an die ODU (2), in dem die Freigabe der zuvor zugeordneten UB-(28)-Zahl angefragt
wird;
f) Empfangen einer Antwort von der ODU (2) in Reaktion auf den zweiten Befehl ODU_Release,
wobei die Antwort eine Ausfallmeldung ODU_Error umfasst, falls die Zuordnung des UB
(28) nicht aufgehoben werden kann, oder eine Erfolgsmeldung ODU_OK umfasst, falls
die Zuordnung der UB-(28)-Zahl aufgehoben wurde.
4. Verfahren nach einem der vorhergehenden Ansprüche, ferner umfassend die folgenden
Schritte:
g) Ausgeben eines dritten digital codierten Befehls ODU_Active aus dem IRD (10, 12)
an die ODU (2), der anzeigt, dass eine UB-(28)-Zahl belegt und aktiv ist;
h) Empfangen einer Antwort von der ODU (2) in Reaktion auf den dritten Befehl ODU_Active,
wobei die Antwort eine Ausfallmeldung ODU_Error umfasst, falls die Zuordnung der UB-(28)-Zahl
bereits aufgehoben wurde oder die UB-Zahl ungültig ist; oder eine Erfolgsmeldung ODU_OK
umfasst, falls bestätigt wird, dass die UB-Zahl aktiv ist.
5. Verfahren nach einem der vorhergehenden Ansprüche, ferner umfassend die folgenden
Schritte:
i) Ausgeben eines vierten digital codierten Befehls ODU_Tune aus dem IRD (10, 12)
an die ODU (2), der eine Versorgung anzeigt, mit der der IRD (10, 12) verbunden werden
möchte, umfassend Informationen über die zugeordnete UB-(28)-Zahl, den Satelliten,
die Polarisation und den Wert für die Transponderfrequenz,
j) Empfangen einer Antwort von der ODU (2) in Reaktion auf den vierten Befehl ODU_Tune,
wobei die Antwort eine Ausfallmeldung ODU_Error umfasst, falls die Zuordnung der UB-(28)-Zahl
bereits aufgehoben wurde oder die UB-(28)-Zahl, der Satellit, die Polarisation und/oder
der Wert für die Transponderfrequenz ungültig ist; oder eine Erfolgsnachricht ODU_OK
umfasst, falls der Befehl bestätigt wird und die Umwandlung erfolgreich ausgeführt
wurde.
6. Verfahren gemäß Anspruch 5, wobei der Wert für die Transponderfrequenz für drei verschiedene
Typen von ODUs (2) reserviert ist und wobei der Wert für die Transponderfrequenz die
tatsächliche Transponderfrequenz ist, falls die ODU (2) eine Ku- oder Ka-Band-ODU
ist, die ihre LO-Frequenz kennt; oder der Wert für die Transponderfrequenz die tatsächliche
Transponderfrequenz erhöht um einen vorbestimmten Wert ist, falls die ODU (2) eine
C-Band-ODU ist, die ihre LO-Frequenz kennt.
7. Verfahren gemäß einem der Ansprüche 1 bis 6 zur Dateiübertragung von dem integrierten
Empfänger/Decoder (IRD, 10, 12) an die ODU (2), umfassend die folgenden weiteren Schritte:
a. Ausgeben eines digital codierten Befehls ODU_TransInit aus dem IRD (10, 12) an
die ODU (2), um das Hochladen der Daten oder Datei zu initiieren,
b. Empfangen einer positiven Antwort ODU_Success, falls die ODU (2) für den Daten-
oder Dateiempfang bereit ist, während, falls die ODU (2) nicht für den Dateiempfang
bereit ist, diese ein ODU_Fail sendet,
c. Ausgeben eines digital codierten Befehls ODU_File aus dem IRD (10, 12) an die ODU
(2) mit einer Nutzinformation der Datei,
d. Empfangen einer positiven Antwort ODU_Success, nachdem die ODU (2) die Daten korrekt
ohne Fehler empfangen hat, während, falls die ODU (2) den Befehl nicht korrekt empfangen
hat oder die Daten beschädigt worden sind, sie den Befehl ODU_Parity sendet, um die
Übertragung des letzten Befehls zu wiederholen,
e. Ausgeben eines digital codierten Befehls ODU_EOT aus dem IRD (10, 12) an die ODU
(2), der das Ende der Datei oder Daten signalisiert,
f. Empfangen einer positiven Antwort ODU_Success von der ODU (2), falls die gesamte
Datei korrekt gesendet worden ist, während, falls Fehler aufgetreten sind und das
gesamte Dateibild beschädigt ist, die ODU (2) einen Befehl ODU_Fail sendet.
8. Computerprogrammprodukt, umfassend Programmbefehle, welche, wenn sie von einem Prozessor
ausgeführt werden, den Prozessor veranlassen, einen integrierten Empfänger/Decoder
(IRD, 10, 12) nach einem Verfahren gemäß einem der Ansprüche 1 bis 7 automatisch zu
installieren.
9. Computerprogrammprodukt nach Anspruch 8, wobei die Programmbefehle in mindestens einem
Halbleiterchip enthalten sind.
10. Integrierter Empfänger/Decoder (IRD, 10, 12), umfassend:
a) Mittel, die angeordnet sind zum Ausgeben eines ersten digital codierten Befehls
ODU_Allocate aus dem IRD (10, 12) an eine Außeneinheit (ODU, 2), die eine dynamische
oder statische Zuordnung eines Benutzerbands (UB) anfragt;
b) Mittel, die angeordnet sind zum Empfangen einer Antwort von der ODU (2) in Reaktion
auf den ersten Befehl ODU_Allocate, falls das UB (28) verfügbar ist; wobei die Antwort
eine UB-Zahl, eine Mittenfrequenz des UB (28), eine Zahl von empfangbaren Satellitenpositionen
und Informationen, ob die ODU einen lokalen Oszillator (LO) enthält oder nicht, umfasst;
Speichern, in dem IRD (10, 12), der UB-Zahl, der Mittenfrequenz (27) des UB (28),
der Zahl von empfangbaren Satellitenpositionen und von Informationen, ob die ODU (2)
einen lokalen Oszillator (LO) enthält oder nicht;
c) Mittel, die angeordnet sind zum Empfangen einer Antwort von der ODU (2) in Reaktion
auf den ersten Befehl ODU_Allocate, falls das UB (28) nicht verfügbar ist; wobei die
Antwort eine Ausfallmeldung ODU_Error umfasst;
d) Mittel, die angeordnet sind zum Wiederholen der Ausgabe des ersten digital codierten
Befehls ODU_Allocate aus Schritt a) für eine vorbestimmte Anzahl von Malen, falls
von den Mitteln b) keine Antwort empfangen wird,
e) Mittel, die angeordnet sind zum Senden eines Anfragebefehls ODU_TransInit aus dem
IRD (10, 12) an die ODU (2) zum Senden einer Datei,
f) Mittel, die angeordnet sind zum Empfangen einer Antwort von der ODU (2) in Reaktion
auf den Befehl ODU_TransInit,
g) Mittel, die angeordnet sind zum Senden des Befehls ODU_File aus dem IRD (10, 12)
an die ODU (2) mit der Datei-Nutzinformation, was die Folge der positiven Antwort
auf den Befehl ODU_TransInit ist,
h) Mittel, die angeordnet sind zum Empfangen einer Antwort von der ODU in Reaktion
auf den Befehl ODU_File,
i) Mittel, die angeordnet sind zum Wiederholen der Schritte g) und h), bis die gesamte
Datei übertragen wurde,
j) Mittel, die angeordnet sind zum Senden des Befehls ODU_EOT von dem IRD (10, 12)
an die ODU (2) nach der Übertragung der gesamten Datei,
k) Mittel, die angeordnet sind zum Empfangen einer Antwort von der ODU (2) in Reaktion
auf den Befehl ODU_EOT.
11. Integrierter Empfänger/Decoder (IRD, 10, 12) gemäß Anspruch 10, umfassend Mittel,
die angeordnet sind zum Implementieren des Verfahrens gemäß einem der Ansprüche 1
bis 7.
12. Integrierter Empfänger/Decoder (IRD, 10, 12) gemäß Anspruch 10 oder 11, umfassend
ein Computerprogrammprodukt gemäß einem der Ansprüche 8 oder 9.
13. Außeneinheit (ODU, 2), umfassend:
a) Mittel, die angeordnet sind zum Empfangen eines ersten digital codierten Befehls
ODU_Allocate von einem integrierten Empfänger/Decoder (IRD, 10, 12), der eine dynamische
oder statische Benutzerband-(UB, 28)-Zuordnung anfragt;
b) Mittel, die angeordnet sind zum Senden einer Antwort an den IRD (10, 12) in Reaktion
auf den ersten Befehl ODU_Allocate, falls das UB verfügbar ist; wobei die Antwort
eine UB-(28)-Zahl, eine Mittenfrequenz des UB (28), eine Zahl von empfangbaren Satellitenpositionen
und Informationen, ob die ODU einen lokalen Oszillator (LO) enthält oder nicht, umfasst;
Speichern, in dem IRD (10, 12), der UB-(28)-Zahl, der Mittenfrequenz des UB (28),
der Zahl von empfangbaren Satellitenpositionen und von Informationen, ob die ODU (2)
einen lokalen Oszillator (LO) enthält oder nicht;
c) Mittel, die angeordnet sind zum Senden einer Antwort an den IRD (10, 12) in Reaktion
auf den ersten Befehl ODU_Allocate, falls das UB (28) nicht verfügbar ist; wobei die
Antwort eine Ausfallmeldung ODU_Error umfasst,
d) Mittel, die angeordnet sind zum Senden einer Antwort an den IRD (10, 12) in Reaktion
auf den Befehl ODU_TransInit (falls eine Antwort angefragt wird), wenn er zum Datei-
oder Datenempfang bereit ist;
e) Mittel, die angeordnet sind zum Senden einer Antwort an den IRD (10, 12) in Reaktion
auf den Befehl ODU_File (falls eine Antwort angefragt ist) und Speichern der Nutzinformation
der Daten;
f) Mittel, die angeordnet sind zum Senden einer Antwort an den IRD (10, 12) in Reaktion
auf den Befehl ODU_EOT (falls eine Antwort angefragt ist), nachdem die Datei unbeschädigt
empfangen worden ist.
14. Außeneinheit (ODU, 2) gemäß Anspruch 13, umfassend Mittel, die angeordnet sind zum
Implementieren des Verfahrens gemäß einem der Ansprüche 1 bis 7.
15. Außeneinheit (ODU, 2) gemäß Anspruch 13 oder 14, umfassend ein Computerprogrammprodukt
gemäß einem der Ansprüche 8 oder 9.
1. Procédé d'auto-installation d'un récepteur/décodeur intégré (IRD, 10, 12) comprenant
les étapes de :
a) émission d'une première commande codée numériquement ODU_Allocate depuis l'IRD
(10, 12) vers une unité extérieure (ODU, 2) requérant une affectation de bande utilisateur
(UB) dynamique ou statique ; dans lequel, dans l'affectation de bande utilisateur
dynamique, l'ODU (2) attribue le numéro d'UB (28) à l'IRD et dans lequel, dans l'affectation
de bande utilisateur statique, l'IRD demande à l'ODU (2) d'attribuer à un numéro d'UB
(28) particulier,
b) réception d'une réponse de l'ODU (2) en réponse à la première commande ODU_Allocate,
si l'UB (28) est disponible ; ladite réponse comprenant un numéro d'UB, une fréquence
centrale de ladite UB (28), un nombre de positions satellitaires recevables et une
information si l'ODU (2) contient un oscillateur local (LO) ou non ; stockage dans
l'IRD (10, 12) du numéro d'UB (28), de la fréquence centrale (27) de ladite UB (28),
du nombre de positions satellitaires recevables et de l'information si l'ODU (2) contient
un oscillateur local (LO) ou non ;
c) réception d'une réponse de l'ODU (2) en réponse à la première commande ODU_Allocate,
si l'UB (28) n'est pas disponible ; ladite réponse comprenant un message d'erreur
ODU_Error ;
d) retour un nombre prédéterminé de fois à l'étape a) si aucune réponse n'est reçue
à l'étape b).
2. Procédé selon la revendication 1, dans lequel la première commande codée numériquement
ODU_Allocate contient le numéro d'UB (28) si l'IRD (10, 12) est en mode d'affectation
d'UB statique.
3. Procédé selon la revendication 1 ou 2, comprenant en outre l'étape de :
e) émission d'une deuxième commande codée numériquement ODU_Release depuis l'IRD (10,
12) vers l'ODU (2) demandant la libération du numéro d'UB (28) précédemment affecté
;
f) réception d'une réponse de l'ODU (2) en réponse à la deuxième commande ODU_Release,
ladite réponse comprenant un message d'erreur ODU_Error si l'UB (28) ne peut être
désattribuée ou un message de succès ODU_OK si le numéro d'UB (28) a été désattribué.
4. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre
l'étape de :
g) émission d'une troisième commande codée numériquement ODU_Active depuis l'IRD (10,
12) vers l'ODU (2) indiquant qu'un numéro d'UB (28) est occupé et actif ;
h) réception d'une réponse de l'ODU (2) en réponse à la troisième commande ODU_Active,
ladite réponse comprenant un message d'erreur ODU_Error si le numéro d'UB (28) a déjà
été désattribué ou si le numéro d'UB est invalide ; ou un message de succès ODU_OK
si le caractère actif du numéro d'UB est confirmé.
5. Procédé selon l'une quelconque des revendications précédentes, comprenant en outre
l'étape de :
i) émission d'une quatrième commande codée numériquement ODU_Tune depuis l'IRD (10,
12) vers l'ODU (2) indiquant un flux auquel l'IRD (10, 12) veut être connecté, comprenant
une information sur le numéro d'UB (28) affecté, le satellite, la polarisation et
la valeur pour la fréquence de transpondeur,
j) réception d'une réponse de l'ODU (2) en réponse à la quatrième commande ODU_Tune,
ladite réponse comprenant un message d'erreur ODU_Error si le numéro d'UB (28) a déjà
été désattribué ou si le numéro d'UB (28), le satellite, la polarisation et/ou la
valeur pour la fréquence de transpondeur est invalide ; ou un message de succès ODU_OK
si la commande est confirmée et si la conversion a été exécutée avec succès.
6. Procédé selon la revendication 5, dans lequel la valeur pour la fréquence de transpondeur
est dédiée à trois types différents d'ODU (2) et dans lequel la valeur pour la fréquence
de transpondeur est la fréquence de transpondeur réelle si l'ODU (2) est une ODU en
bande Ku ou Ka qui a connaissance de sa fréquence de LO ; ou la valeur pour la fréquence
de transpondeur est la fréquence de transpondeur réelle augmentée d'une valeur prédéterminée,
si l'ODU (2) est une ODU en bande C qui a connaissance de sa fréquence de LO.
7. Procédé selon l'une quelconque des revendications 1 à 6, pour une transmission de
fichier du récepteur/décodeur intégré (IRD, 10, 12) à l'ODU (2), comprenant les étapes
supplémentaires de :
a. émission d'une commande codée numériquement ODU_TransInit de l'IRD (10, 12) à l'ODU
(2) afin d'initier le chargement de données ou de fichier,
b. réception d'une réponse positive ODU_Success si l'ODU (2) est prête pour une réception
de données ou de fichier, tandis que si l'ODU (2) n'est pas prête pour la réception
de fichier, elle envoie ODU_Fail,
c. émission d'une commande codée numériquement ODU_File de l'IRD (10, 12) à l'ODU
(2) avec la charge utile du fichier,
d. réception d'une réponse positive ODU_Success après que l'ODU (2) a reçu les données
correctement sans erreurs, tandis que si l'ODU (2) n'a pas reçu la commande correctement
ou si des données ont été corrompues, elle envoie la commande ODU-Parity afin de répéter
la transmission de la dernière commande,
e. émission d'une commande codée numériquement ODU_EOT de l'IRD (10, 12) à l'ODU (2)
signalant une fin du fichier ou des données,
f. réception d'une réponse positive ODU_Success de l'ODU (2), si la totalité du fichier
a été envoyée correctement, tandis que s'il y a eu des erreurs et si la totalité du
fichier image est corrompue, l'ODU (2) envoie une commande ODU_Fail.
8. Produit de programme informatique comprenant des instructions de programme qui, lorsqu'elles
sont exécutées par un processeur, font que le processeur auto-installe un récepteur/décodeur
intégré (IRD, 10, 12), conformément à un procédé selon l'une quelconque des revendications
1 à 7.
9. Produit de programme informatique selon la revendication 8 dans lequel les instructions
de programme sont contenues dans au moins une puce à semi-conducteur.
10. Récepteur/décodeur intégré (IRD, 10, 12) comprenant :
a) un moyen agencé pour émettre une première commande codée numériquement ODU_Allocate
depuis l'IRD (10, 12) vers une unité extérieure (ODU, 2) requérant une affectation
de bande utilisateur (UB) dynamique ou statique ;
b) un moyen agencé pour recevoir une réponse de l'ODU (2) en réponse à la première
commande ODU_Allocate, si l'UB (28) est disponible ; ladite réponse comprenant un
numéro d'UB, une fréquence centrale de ladite UB (28), un nombre de positions satellitaires
recevables et une information si l'ODU (2) contient un oscillateur local (LO) ou non
; stocker dans l'IRD (10, 12) le numéro d'UB, la fréquence centrale (27) de ladite
UB (28), le nombre de positions satellitaires recevables et l'information si l'ODU
(2) contient un oscillateur local (LO) ou non ;
c) un moyen agencé pour recevoir une réponse de l'ODU (2) en réponse à la première
commande ODU_Allocate, si l'UB (28) n'est pas disponible ; ladite réponse comprenant
un message d'erreur ODU_Error ;
d) un moyen agencé pour réitérer l'émission de la première commande codée numériquement
ODU_Allocate de l'étape a) un nombre prédéterminé de fois si aucune réponse n'est
reçue par le moyen b).
e) un moyen agencé pour envoyer une commande de requête ODU_TransInit de l'IRD (10,
12) à l'ODU (2) pour un envoi de fichier,
f) un moyen agencé pour recevoir une réponse de l'ODU (2) en réponse à la commande
ODU_TransInit,
g) un moyen agencé pour envoyer la commande ODU_File de l'IRD (10, 12) à l'ODU (2)
avec une charge utile de fichier qui est la conséquence de la réponse positive à la
commande ODU_TransInit,
h) un moyen agencé pour recevoir une réponse de l'ODU en réponse à la commande ODU_File,
i) un moyen agencé pour répéter l'étape g) et h) jusqu'à ce que la totalité du fichier
soit transmise,
j) un moyen agencé pour envoyer la commande ODU_EOT de l'IRD (10, 12) à l'ODU (2)
après la transmission de la totalité du fichier,
k) un moyen agencé pour recevoir une réponse de l'ODU (2) en réponse à la commande
ODU_EOT.
11. Récepteur/décodeur intégré (IRD, 10, 12) selon la revendication 10 comprenant un moyen
agencé pour mettre en œuvre le procédé selon l'une quelconque des revendications 1
à 7.
12. Récepteur/décodeur intégré (IRD, 10, 12) selon la revendication 10 ou 11 comprenant
un produit de programme informatique selon l'une quelconque des revendications 8 ou
9.
13. Unité extérieure (ODU, 2), comprenant :
a) un moyen agencé pour recevoir une première commande codée numériquement ODU_Allocate
depuis un récepteur/décodeur intégré (IRD, 10, 12) requérant une affectation de bande
utilisateur (UB, 28) dynamique ou statique ;
b) un moyen agencé pour envoyer une réponse à l'IRD (10, 12) en réponse à la première
commande ODU_Allocate, si l'UB (28) est disponible ; ladite réponse comprenant un
numéro d'UB (28), une fréquence centrale de ladite UB (28), un nombre de positions
satellitaires recevables et une information si l'ODU contient un oscillateur local
(LO) ou non ; stocker dans l'IRD (10, 12) le numéro d'UB (28), la fréquence centrale
(27) de ladite UB (28), le nombre de positions satellitaires recevables et l'information
si l'ODU (2) contient un oscillateur local (LO) ou non ;
c) un moyen agencé pour envoyer une réponse à l'IRD (10, 12) en réponse à la première
commande ODU_Allocate, si l'UB (28) n'est pas disponible ; ladite réponse comprenant
un message d'erreur ODU_Error.
d) un moyen agencé pour envoyer une réponse à l'IRD (10, 12) en réponse à une commande
ODU_TransInit (si une réponse est requise) lorsqu'elle est prête pour une réception
de fichier ou de données.
e) un moyen agencé pour envoyer une réponse à l'IRD (10, 12) en réponse à une commande
ODU_File (si une réponse est requise) et stocker la charge utile de données
f) un moyen agencé pour envoyer une réponse à l'IRD (10, 12) en réponse à une commande
ODU_EOT (si une réponse est requise) après que le fichier a été reçu non corrompu.
14. Unité extérieure (ODU, 2) selon la revendication 13 comprenant un moyen agencé pour
mettre en œuvre le procédé selon l'une quelconque des revendications 1 à 7.
15. Unité extérieure (ODU, 2) selon la revendication 13 ou 14 comprenant un produit de
programme informatique selon l'une quelconque des revendications 8 ou 9.