[go: up one dir, main page]

EP3127259B1 - Système et procédé pour controller une unité extérieure qui est reliée à un decodeur récepteur intégré à travers un câble unique - Google Patents

Système et procédé pour controller une unité extérieure qui est reliée à un decodeur récepteur intégré à travers un câble unique Download PDF

Info

Publication number
EP3127259B1
EP3127259B1 EP15716460.9A EP15716460A EP3127259B1 EP 3127259 B1 EP3127259 B1 EP 3127259B1 EP 15716460 A EP15716460 A EP 15716460A EP 3127259 B1 EP3127259 B1 EP 3127259B1
Authority
EP
European Patent Office
Prior art keywords
odu
command
ird
reply
file
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP15716460.9A
Other languages
German (de)
English (en)
Other versions
EP3127259A1 (fr
Inventor
Asher Gil MEDIOUNI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Gt-Sat International SA RL
Original Assignee
Gt-Sat International SA RL
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gt-Sat International SA RL filed Critical Gt-Sat International SA RL
Publication of EP3127259A1 publication Critical patent/EP3127259A1/fr
Application granted granted Critical
Publication of EP3127259B1 publication Critical patent/EP3127259B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H40/00—Arrangements specially adapted for receiving broadcast information
    • H04H40/18—Arrangements characterised by circuits or components specially adapted for receiving
    • H04H40/27—Arrangements characterised by circuits or components specially adapted for receiving specially adapted for broadcast systems covered by groups H04H20/53 - H04H20/95
    • H04H40/90—Arrangements characterised by circuits or components specially adapted for receiving specially adapted for broadcast systems covered by groups H04H20/53 - H04H20/95 specially adapted for satellite broadcast receiving

Definitions

  • 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.
  • 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.
  • PVRs personal video recorder
  • STBs single or multiple tuner set-top-boxes
  • 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).
  • Single-cable distribution allows connection of many receivers or a receiver with many tuners by means of a single cable to external satellite equipment.
  • satellite equipment is commonly referred to as an outdoor unit (ODU).
  • 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.
  • 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.
  • 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.
  • 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).
  • L-band intermediate frequency band
  • the converted RF signal carried in L-Band is connected by means of fiber optic or coax cable to the receiver for demodulation.
  • Each of RF signal 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.
  • EPG Electronic Program Guide
  • a channel is a radio frequency transponder signal.
  • 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.
  • 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.
  • EN 50494 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.
  • CENELEC European Committee for Electrotechnical Standardization
  • 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.
  • the communication between ODU and IRD is one-way.
  • the EN 50494 prescribes a Digital Satellite Equipment Communication (DiSEqCTM 1.x). This protocol allows unidirectional communication between ODU and IRD (DiSEqCTM 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.
  • 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.
  • EN 50607 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.
  • CENELEC European Committee for Electrotechnical Standardization
  • 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.
  • the installation process is defined with two-way communication based on DiSEqC 2.x protocol.
  • IRD 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).
  • ULEM Universal LNB Emulation Mode
  • the ULEM algorithm defines a different calculation of the incorporated "tuning word" in order to ensure fitting the range of 110 to 2147MHz.
  • 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.
  • 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.
  • the present invention proposes a method of auto-installing an integrated receiver/decoder (IRD) comprising the steps of:
  • 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.
  • the method may comprise the steps of:
  • the method further may comprise the steps of:
  • the method further may comprise the steps of:
  • 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.
  • 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.
  • 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:
  • the invention relates to an integrated receiver/decoder (IRD) comprising:
  • the invention concerns an outdoor unit (ODU), comprising:
  • 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.
  • the program instructions are contained in at least one semiconductor chip.
  • 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.
  • Command "ODU_Allocate” has a parameter indicating type of allocation: dynamic or static and UB number in case of static allocation request.
  • ODU decides which UB number and frequency is assigned to IRD sending ODU_Allocate command.
  • 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.
  • 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.
  • ODU_Error a failure message
  • 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.
  • 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.
  • 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).
  • band indication (low or high) is encoded in "tuning word”.
  • band indication low or high
  • 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.
  • IRD 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.
  • 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.
  • IRD 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.
  • 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.
  • 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.
  • 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.
  • 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.).
  • IRD 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.
  • 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.
  • ODU_EOT End of Transmission
  • FIG.1 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.
  • 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.
  • 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.
  • 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.
  • the divider 7 allows command signals (for example DiSEqCTM signals of the type described by CENELEC EN 50494 or EN 50607 standards) to be communicated to the ODU 2 from IRDs 10, 12.
  • 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.
  • 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).
  • FIG.2 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.
  • LNA low noise amplifiers
  • LNA low noise amplifiers
  • LNA low noise amplifiers
  • LNA low noise amplifiers
  • LO Local oscillator 15 generates a tone signal which is mixed along with the radio signal in mixers 14 separately for each polarization.
  • SCIF Single Cable Interface
  • 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.
  • the microcontroller and associated memory can reside elsewhere in LNB or in another part of ODU.
  • 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.
  • SCIF module 24 may be located inside the house building 13 (e.g. multiswitch).
  • 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.
  • UB center frequencies 27 may be dynamically changed and re-programmed at any time by internal microcontroller 19.
  • 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.
  • IRD no.1 10 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).
  • digital modulation techniques e.g. QPSK or 8PSK.
  • 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.
  • 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).
  • QPSK digital modulation technique
  • 8PSK 8PSK
  • 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.
  • 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.
  • the IRDs 10, 12 or ODU 2 include microprocessors and microcontrollers that function as Central Processing Units (CPUs) to control operation of the system.
  • CPUs Central Processing Units
  • 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.
  • 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.
  • the processing and controlling devices need not be physically collocated with the part of the system it serves.
  • 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.
  • 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.
  • 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.
  • Data1 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).
  • 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).
  • LO Local Oscillator
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • the first bit of the encoded value (i.e. bit 14) is always 0.
  • 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.
  • 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.
  • 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.
  • FIG.11 is a flow diagram of a dynamic UB allocation.
  • IRD 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.
  • 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.
  • 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.
  • FIG.12 is a flow diagram of a static UB allocation.
  • IRD 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.
  • 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.
  • 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.
  • 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).
  • IRD leaves the procedure with failure message 60. If UB center frequency is beyond of the 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.
  • 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.
  • 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.
  • 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.
  • IRD 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.
  • 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.
  • IRD 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.
  • 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.
  • 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.
  • ODU_Error 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.
  • FIG.14 shows the flowchart of the static allocation for IRDs that support only unidirectional communication according to DiSEqC 1.x protocol.
  • installer 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.
  • LOs Local Oscillators
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • ODU_File command 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.
  • 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.

Landscapes

  • Physics & Mathematics (AREA)
  • Astronomy & Astrophysics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Circuits Of Receivers In General (AREA)
  • Radio Relay Systems (AREA)

Claims (15)

  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.
EP15716460.9A 2014-04-01 2015-03-31 Système et procédé pour controller une unité extérieure qui est reliée à un decodeur récepteur intégré à travers un câble unique Active EP3127259B1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
LU92417A LU92417B1 (en) 2014-04-01 2014-04-01 ODU Controlling system in single-cable installation environment
PCT/EP2015/057107 WO2015150422A1 (fr) 2014-04-01 2015-03-31 Système et procédé de commande d'une unité extérieure connectée à un récepteur-décodeur intégré à l'aide d'un seul câble

Publications (2)

Publication Number Publication Date
EP3127259A1 EP3127259A1 (fr) 2017-02-08
EP3127259B1 true EP3127259B1 (fr) 2019-12-25

Family

ID=50841928

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15716460.9A Active EP3127259B1 (fr) 2014-04-01 2015-03-31 Système et procédé pour controller une unité extérieure qui est reliée à un decodeur récepteur intégré à travers un câble unique

Country Status (4)

Country Link
EP (1) EP3127259B1 (fr)
LU (1) LU92417B1 (fr)
WO (1) WO2015150422A1 (fr)
ZA (1) ZA201608426B (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3157263B1 (fr) * 2015-10-13 2018-04-18 Unitron NV Système d'empilement de canaux d'habitations multiples
BR112019012030A2 (pt) * 2016-12-13 2019-11-12 Telefonica Sa método para configurar um bloco de baixo ruído, sistema para configurar um bloco de baixo ruído, e bloco de baixo ruído configurável
DE202017003510U1 (de) 2017-06-21 2017-09-11 ROTEK microelectronic GmbH Steuervorrichtung für dCSS Signalquellen nach EN50607
KR102530606B1 (ko) 2018-07-11 2023-05-09 베스텔 일렉트로닉 사나이 베 티카레트 에이에스 위성 접시 lnb, 위성 방송 신호 수신기 및 동작 방법들
US12177035B2 (en) 2021-01-22 2024-12-24 Arris Enterprises Llc System and method for the improved provision of user bands via one or more single-cable interfaces

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6049892C1 (en) * 1997-02-24 2002-06-04 Ethos Software Corp Process and apparatus for downloading data from a server computer to a client computer
CA2525821A1 (fr) * 2003-05-16 2004-12-02 Viasat, Inc. Procede et appareil pour interface de telemesure d'unite exterieure vers l'unite interieure dans des systemes vsat
WO2010086884A1 (fr) * 2009-01-28 2010-08-05 Sky Italia S.R.L. Procédé d'attribution d'un canal de communication entre un bloc à bas bruit et un boîtier décodeur dans un système de télévision domestique
US9319644B2 (en) * 2009-07-20 2016-04-19 Bce Inc. Automatic user band assignment in a satellite signal distribution environment
US8639179B2 (en) * 2011-04-16 2014-01-28 Entropic Communications, Inc. Single-cable automatic IRD installation procedure
US10034030B2 (en) * 2013-09-24 2018-07-24 DISH Technologies L.L.C. Field-programmable low-noise block downconverter

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
None *

Also Published As

Publication number Publication date
LU92417B1 (en) 2015-10-02
WO2015150422A1 (fr) 2015-10-08
EP3127259A1 (fr) 2017-02-08
ZA201608426B (en) 2019-10-30

Similar Documents

Publication Publication Date Title
US9042810B2 (en) Single-cable automatic IRD installation procedure
EP3127259B1 (fr) Système et procédé pour controller une unité extérieure qui est reliée à un decodeur récepteur intégré à travers un câble unique
US5373288A (en) Initializing terminals in a signal distribution system
US6944878B1 (en) Method and apparatus for selecting a satellite signal
KR101526967B1 (ko) 방송 송신기, 방송 수신기 및 케이블 방송의 소프트웨어수신 방법
US9319644B2 (en) Automatic user band assignment in a satellite signal distribution environment
CN101779456A (zh) 用于监视节目可用性的方法和装置
EP1798955A2 (fr) Appareil de réception de données de diffusion par câble et procédé de transmission/réception de logiciel de diffusion par câble
EP2392134B1 (fr) Procédé d'attribution d'un canal de communication entre un bloc à bas bruit et un boîtier décodeur dans un système de télévision domestique
KR102530606B1 (ko) 위성 접시 lnb, 위성 방송 신호 수신기 및 동작 방법들
KR102770057B1 (ko) 방송수신장치 및 그 제어방법
US11582529B2 (en) Satellite integrated receiver decoder and conflict detecting method
US9924233B2 (en) Systems and methods for controlling a single-wire multiswitch device
CN111314753B (zh) 信号处理方法、数字视频变换设备和低噪声下变频器
WO2003084217A1 (fr) Convertisseur de diffusion de television numerique terrestre/ diffusion de television numerique par satellite
US20070288968A1 (en) Video and data home networking architectures
KR20080006864A (ko) 데이터 방송 어플리케이션을 제어하는 방법 및 이를수신하는 방송 수신기
WO2017211397A1 (fr) Système ayant un signal de communication à durée de temps dynamique entre un récepteur satellite et un commutateur multicoupelle
WO2007143219A9 (fr) Architectures de mise en réseau domestique combinée de vidéo et de données
JP2009239875A (ja) ミリ波送受信システム、ミリ波送信装置及びミリ波受信装置

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20161028

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20181023

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20190723

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: AT

Ref legal event code: REF

Ref document number: 1218296

Country of ref document: AT

Kind code of ref document: T

Effective date: 20200115

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602015044228

Country of ref document: DE

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: SE

Ref legal event code: TRGR

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20191225

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200325

Ref country code: BG

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200325

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200326

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG4D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200520

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20200425

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

REG Reference to a national code

Ref country code: DE

Ref legal event code: R097

Ref document number: 602015044228

Country of ref document: DE

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: MC

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1218296

Country of ref document: AT

Kind code of ref document: T

Effective date: 20191225

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

26N No opposition filed

Effective date: 20200928

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: TR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: MT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

Ref country code: CY

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: MK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20191225

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IE

Payment date: 20240325

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: SE

Payment date: 20240327

Year of fee payment: 10

Ref country code: FR

Payment date: 20240325

Year of fee payment: 10

Ref country code: BE

Payment date: 20240325

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: CH

Payment date: 20240401

Year of fee payment: 10

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: DE

Payment date: 20250328

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: LU

Payment date: 20250328

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20250328

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: IT

Payment date: 20250328

Year of fee payment: 11

REG Reference to a national code

Ref country code: CH

Ref legal event code: H13

Free format text: ST27 STATUS EVENT CODE: U-0-0-H10-H13 (AS PROVIDED BY THE NATIONAL OFFICE)

Effective date: 20251023

REG Reference to a national code

Ref country code: SE

Ref legal event code: EUG