EP3127259A1

EP3127259A1 - System and method for controlling outdoor unit connected with an integrated receiver decoder using a single cable

Info

Publication number: EP3127259A1
Application number: EP15716460.9A
Authority: EP
Inventors: Asher Gil MEDIOUNI
Original assignee: Gt-Sat Int Sarl; Gt-Sat International SA RL
Current assignee: Gt-Sat Int Sarl; Gt-Sat International SA RL
Priority date: 2014-04-01
Filing date: 2015-03-31
Publication date: 2017-02-08
Anticipated expiration: 2035-03-31
Also published as: LU92417B1; WO2015150422A1; EP3127259B1; ZA201608426B

Abstract

The invention describes a method, system, and computer program for controlling a single-cable Outdoor Unit (ODU) by one or more Integrated Receiver Decoders (IRDs) connected to this ODU via single cable. The control method comprises assigning a User Band (UB) to a particular IRD.

Description

SYSTEM AND METHOD FOR CONTROLLING OUTDOOR UNIT CONNECTED WITH AN INTEGRATED RECEIVER DECODER USING A SINGLE CABLE

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. [001 1 ] 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 1 10 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 (1 10 - 2147 vs. 300 - 2350MHz). The ULEM algorithm defines a different calculation of the incorporated "tuning word" in order to ensure fitting the range of 1 10 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 is 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 nonvolatile 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 the steps of: a) issuing digitally coded command ODU_Translnit 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 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 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 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 for reiterating step a) a predefined number of times if no reply received by means b), e) means for sending request command ODU_Translnit from IRD to ODU for file sending, f) means for receiving reply from ODU in response to the ODU_Translnit command. For the receivers with DiSEqC 1 .0 communication (no reply capability) this part is excluded. g) means for sending the command ODU_File from IRD to ODU with file payload which is the consequence of the positive reply on ODU_Translnit command h) means 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 to repeat step g) and h) until entire file is transmitted, j) means for sending the command ODU_EOT from IRD to ODU after entire file transmission, k) means 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 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 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 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 for sending reply to the IRD in response to command ODU_Translnit, (if reply is requested) when ready for file or data reception, e) means for sending reply to the IRD in response to command ODU_File (if reply is requested) and storing the payload of data, f) means 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 deallocation 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_Translnit 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 connnnand. Byte3 of the connnnand 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.1 1 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_Translnit" 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) 3. 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.1 1 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, Datal byte and optional Data2 byte. Datal 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 Datal 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. Datal is 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 Datal 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 1 1 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 Datal (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, Datal byte and optional Data2 byte. Datal 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 Datal byte. Datal 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, Datal byte, Data2 byte, Data3 byte and optional Data4 byte. Datal 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 1 1 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, Datal byte and optional Data2 byte. Datal 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.1 1 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_AI locate" 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_AI locate" 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 deallocates 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 deallocates 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 deallocates 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_Translnit" command. Command consists of a header byte, address byte and 0x4E. Header byte is an 8-bit word which can take value OxEO or 0xE2. Value OxEO indicates DiSEqC 1 .x transmission (unidirectional) and value 0xE2 DiSEqC 2.x (bidirectional). Address byte can take values: 0x00, 0x10 or 0x1 1 . Third byte 0x4E is ODU_Translnit 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 OxEO or 0xE2. Value OxEO indicates DiSEqC 1 .x transmission (unidirectional) and value 0xE2 DiSEqC 2.x (bidirectional). Address byte can take values: 0x00, 0x10 or 0x1 1 . 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 OxEO or 0xE2. Value OxEO indicates DiSEqC 1 .x transmission (unidirectional) and value 0xE2 DiSEqC 2.x (bidirectional). Address byte can take values: 0x00, 0x10 or 0x1 1 . 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 ByteO in every command - 0xE2 indicating request for reply. If IRD wants to send the file to ODU, it sends the ODU_Translnit 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.

Claims

1 . 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 or static user band (UB) allocation; wherein in dynamic user band allocation the ODU assigns the UB number to the IRD and wherein in static user band allocation the IRD asks ODU for assigning to particular UB number,

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 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) 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).

2. The method according to claim 1 , wherein the first digitally coded command ODU_Allocate contains the UB number if the IRD 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 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 is cannot be deallocated or a success message ODU_OK if UB 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 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.

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 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.

6. The method according to claim 5, wherein 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.

7. A method of file transmission form an integrated receiver/decoder (IRD) to ODU comprising the steps of:

a. issuing digitally coded command ODU_Translnit 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, whereas if ODU is not ready for the file reception, it sends ODU_Fail,

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, whereas 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,

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, whereas if there have been errors and entire file image is corrupted, ODU 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), 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) comprising:

a) means 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 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 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 for reiterating step a) a predefined number of times if no reply received by means b).

e) means for sending request command ODU_Translnit from IRD to ODU for file sending,

f) means for receiving reply from ODU in response to the ODU_Translnit command,

g) means for sending the command ODU_File from IRD to ODU with file payload which is the consequence of the positive reply on ODU_Translnit command,

h) means for receiving reply from ODU in response to the ODU_File command,

i) means to repeat step g) and h) until entire file is transmitted,

j) means for sending the command ODU_EOT from IRD to ODU after entire file transmission,

k) means for receiving reply from ODU in response to the ODU_EOT command.

1 1 . The integrated receiver/decoder (IRD) according to claim 10 comprising means for implementing the method according to any of claims 1 to 7.

12. The integrated receiver/decoder (IRD) according to claim 10 or 1 1 comprising a computer program product according to any of claims 8 or 9.

13. An outdoor unit (ODU), comprising:

a) means 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 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 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 for sending reply to the IRD in response to command ODU_Translnit, (if reply is requested) when ready for file or data reception. e) means for sending reply to the IRD in response to command ODU_File (if reply is requested) and storing the payload of data f) means for sending reply to the IRD in response to command ODU_EOT (if reply is requested) after the file has been received uncorrupted.

14. The outdoor unit (ODU) according to claim 13 comprising means for implementing the method according to any of claims 1 to 7.

15. The outdoor unit (ODU) according to claim 13 or 14 comprising a computer program product according to any of claims 8 or 9.