Abstract:
A set top box arrangement includes transmitting circuitry for transmitting a message and an emulated reply to the message, and receiver circuitry for receiving the control message and comparing the control message to the emulated reply to the message. The transmitted message and emulated reply message are each a digital satellite equipment control message. The emulated reply message that was received is compared with the reply that was transmitted to verify 22kHz tone operation of a low noise block downconverter power supply.

Description:
FIELD OF THE INVENTION  
       [0001]     The present invention relates generally to satellite communications and, more particularly, to verifying 22 kHz tone operation of a satellite set-top box.  
       DESCRIPTION OF THE RELATED ART  
       [0002]     The open standard Digital Satellite Equipment Control (DiSEqC) relies on switching a 22 kHz tone rapidly on and off. In this way, a specially designed receiver can communicate to and control numerous devices that it may be connected to such as a low noise block downconverter (LNB). DiSEqC messages are sent as sequences of short bursts of 22 kHz tone modulated on the LNB power supply carried by the coax cable from the input on the receiver (the master) to the LNB and/or other devices. Messages comprise a number of digital bytes of nine bits each (8 bits of data+1 odd parity bit). Each bit occupies a specific time and the proportion of that time filled with the 22 kHz burst determines whether that bit is a 1 or a 0. It is a simple pulse-width modulation scheme.  
         [0003]     The DiSEqC system has been designed primarily to meet the problem of multi-satellite and/or multi-band systems with ease. It has commands for switching between inputs, changing frequencies within devices, and many others as well as allowing for custom commands to be used in systems.  
         [0004]     The first byte of the DiSEqC protocol is the Framing byte. The first five bits of this byte follow the pattern, ‘11100’ to allow listening devices (slaves) to synchronize to the signal. Some of the bit definitions may change with later versions of DiSEqC and also allow for custom data definitions to be used. The sixth bit is set to ‘0’ if the message is a command from the master or ‘1’ if it&#39;s a reply from a slave. Bit seven is set to ‘1’ if a response is required or ‘0’ if not. The last framing bit signals whether this message is a re-transmission of a message for which a reply has not been received. The second byte indicates which family of devices the message is for. The first half (four bits) indicates the type of device (LNB, switch, positioner, etc) and the second half the particular type. In each half of this Address byte a value of ‘0’ means the message is open to all. Next comes the Command byte. This actually tells the listening devices what to do. This is followed by a number of Data bytes to pass on numbers relevant to the command (such as the angle required from a separate polarizer).  
         [0005]     For control of simple switches which do not necessarily need to support the full DiSEqC protocol extension to the protocol known as tone burst is used. A 12.5 ms burst of continuous 22 kHz tone is used to select position ‘A’ on the switch and a sequence of nine DiSEqC ‘1’ bits is used to select position ‘B’.  
         [0006]     While trying to trouble shoot an installation of a user&#39;s set-top box, it would be helpful in narrowing some problems down if some of the set-top box hardware could perform a self-test procedure. Simple detection circuits consisting of only one or two transistors and a few discrete components can be implemented to perform this test. This additional circuitry adds cost and could fail itself and falsely indicate a problem with the set-top while the set-top&#39;s LNB supply is actually operating correctly.  
         [0007]     Accordingly, there is a need for determining whether or not the 22 kHz portion of a set-top box&#39;s LNB power supply is functioning properly and within specifications without needing any additional hardware to do so.  
       SUMMARY OF THE INVENTION  
       [0008]     A set top box arrangement includes transmitting circuitry for transmitting a message, and receiver circuitry for receiving the control message and comparing the control message to the transmitted message. The transmitted message is a digital satellite equipment control message.  
         [0009]     In an alternative embodiment, a set top box arrangement includes transmitting circuitry for transmitting a message; an input terminal controlled for emulating a reply to the message transmitted, and circuitry for comparing the reply emulated with the message received.  
         [0010]     A method for verifying 22 kHz tone operation in a satellite set top box includes the steps of sending a digital satellite equipment control message with a transmitter; changing control of the transmitter over to a controlled input pin, pulsing the input pin to send an emulated reply to the control message, and comparing the emulated reply to the received reply to verify operation. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0011]     A more complete understanding of the present invention may be obtained from consideration of the following description in conjunction with the drawings, in which:  
         [0012]      FIG. 1  is a block diagram of an exemplary satellite set-top box front end arrangement for carrying out the invention; and  
         [0013]      FIG. 2  is a block diagram of an exemplary method for verifying 22 kHz tone operation in accordance with the invention. 
     
    
     DETAILED DESCRIPTION  
       [0014]     As part of a satellite set-top box, the LNB power supply may include the generation of a 22 kHz tone or a pulse-width modulated 22 kHz tone for communication to the LNB or other peripherals, such as a multi-switch, that may be connected to the set-top box. This invention allows the set-top box to determine if this 22 kHz portion of the set-top&#39;s LNB power supply is functioning properly using hardware already in the set-top that is being used for the communication to and from the LNB and/or peripherals  
         [0015]     The invention is a methodology for determining whether or not the 22 kHz portion of a set-top&#39;s LNB power supply is functioning properly and within specifications without needing any additional hardware to do so.  
         [0016]      FIG. 1  shows a block diagram  100  for a typical front-end configuration of a satellite set-top box (STB). The Satellite signal is brought from the outdoor unit (ODU) (not shown) consisting of the LNB and/or multi-switches and/or other accessories to the satellite input  101  of the STB via coaxial cable. The radio frequency (RF) signal is passed to the satellite tuner  102 . The 22 kHz tone and/or DiSEqC messages are passed to the DiSEqC receiver  105 . The tone shows up at the DiSEqC receiver  105  regardless of whether it originates in the LNB power supply or in the ODU. The LNB power supply  103  is responsible for passing DC and control signals to the ODU via the same coaxial cable that is bringing the radio frequency RF signal to the STB. The control signal could consist of DiSEqC messages or some similar pulse-width modulated messaging scheme or continuous tone.  
         [0017]     When it becomes necessary to diagnose a problem as to why satellite signals are not getting to the STB, many things could be wrong. It could be anything from a loose connection or broken cable to a problem with the circuitry in the STB. Testing the 22 kHz to verify that this portion of the LNB power supply is operating properly helps to narrow the problem down and possibly prevent “fixing” the wrong problem. This can be accomplished with a small circuit designed specifically for this purpose consisting of a few transistors and a few discrete parts. However, if the STB already has the circuitry to implement DiSEqC 2.x (bi-directional) for ODU control, this existing circuitry can be used to verify that the 22 kHz tone portion of the LNB power supply is operating properly. The 22 kHz can be verified by using the transmitting circuitry of the DiSEqC transmitter  104  to not only transmit an original DiSEqC message, but to emulate the reply that would happen from a device on the DiSEqC bus such as an LNB or multi-switch. Depending on the design of the LNB supply and DiSEqC circuitry, it may be possible for the receiving portion of the circuit to “receive” exactly what is being transmitted. The received data can then be compared to the transmitted data and the 22 kHz operation verified. If the DiSEqC circuitry and the LNB supply are designed in such a way as to not allow the receiver portion to “receive” exactly what is being transmitted (i.e. ignore what&#39;s being sent), then the 22 kHz can be verified by emulating a reply on the bus. This can be done by “bit banging” the reply through the LNB power supply by using a general-purpose input/output (GPIO) pin under software control in the STB to create the DiSEqC message. The received data can then be compared to the expected emulated reply to verify the 22 kHz tone.  
         [0018]     Some other things can come into play. The 22 kHz tone from the STB must have sufficient amplitude to control the ODU properly. This may be different from what is normally expected on the DiSEqC bus. It may be possible to verify the amplitude also, given that the design of the DiSEqC receiver allows for adjustments to the amplitude threshold. There can be some problems that arise in testing the 22 kHz with the emulated reply. There may be devices on the DiSEqC bus that actually reply to the original transmitted signal. If the format and timing of the reply are proper and expected, this too will verify that the transmission of the 22 kHz is working properly. However, if the reply isn&#39;t exactly what is expected, then the emulated reply would be needed to truly verify that the 22 kHz tone is operating properly. The emulated reply, however, could “contend” with the reply from the ODU on the bus and both messages could be compromised. This contention can be eliminated with careful choice of the original transmitted DiSEqC message. For example, the original transmitted DiSEqC command can be the “sleep” command. This would then put all devices on the bus into sleep mode and they would not respond to further commands until they received the “awake” command. The “awake” command would have to be transmitted after the test was completed so that the devices on the DiSEqC bus would resume proper operation. Another example on how to avoid bus contention would be to send a DiSEqC command for which a reply is not expected. A “reset” command would be an example of such a command. One other example of trying to avoid bus contention would be to make the original transmitted command be an “unknown” command. For example, the first nibble of a proper DiSEqC message always consists of the binary bits ‘1’, ‘1’, ‘1’, ‘0’. Thus an unknown command would have the first nibble consist of a bit pattern, which does not match this pattern.  
         [0019]      FIG. 2  is a flow chart  200  example of how to verify the 22 kHz tone by receiving an emulated reply. The bold text in the chart gives the hexadecimal commands being sent on the DiSEqC bus. The original DiSEqC message is sent with the transmitter  201  followed by a sufficient waiting period for the bus to clear itself  202 . This first message is sent to really just clear the bus to a known state and is optional. At this point, the voltage thresholds of the DiSEqC receiver circuit can be adjusted  203  if such a control exists. This step is also optional. The DiSEqC message is then sent with the transmitter  204 . Control of the DiSEqC transmitter is changed over to the general-purpose input/output (GPIO) pin  205 . At least 15 milliseconds of silence on the bus is needed before sending the emulated reply  206 .  
         [0020]     The GPIO pin is pulsed high and low to create the 22 kHz tone or envelope of the 22 kHz tone depending on the LNB power supply design to send an emulated “reply”  207 . The byte being sent back is arbitrarily chosen to be a certain byte sequence plus the appropriate odd parity bit, i.e., 0xA5+‘1’. Sufficient time for the receiver to have received the entire message is allowed  208 . The received byte is compared with the expected byte sequence, 0xA5+‘1’,  209 . If the received message is identical to the expected byte sequence then the 22 kHz tone is operating properly  210 . If either the received message is not identical or if no message was received, and the comparison  209  was the first try, then another command is sent  213 . If the comparison test was not a first try then the 22 kHz tone is not operating properly  212 . The number of retries is arbitrary and is chosen based upon the probability of bus collision and/or user preference.  
         [0021]     Although various embodiments which incorporate the teachings of the present invention have been shown and described in detail herein, those skilled in the art can readily devise many other varied embodiments that will still incorporate these teachings.