Method and device for facilitating the transmission of ternary movable barrier drive information

Abstract

Ternary data corresponding to a movable barrier drive is provided (21) and converted (22) into corresponding binary information. In a preferred approach, this comprises converting each ternary bit into a corresponding binary pair. According to a preferred approach, binary bits corresponding to, for example, fixed and / or non-fixed information (32 and 33) are provided (31) and then converted (34) into the aforementioned ternary data.

Description

Technical area

[0001] The invention relates generally to movable barrier drives and more particularly to the transmission of movable barrier drive information. background

[0002] Movable barrier operators of various types are known in the art. These include operators that provide selective control and movement of single-panel and sectional garage doors, swing, rolling, and overhead doors, guard gates, roller shutters, and various other types of movable barriers. In general, such movable barrier operators typically operate (at least in part) in response to a remote control signal. For example, an individual in a vehicle may operate a corresponding wireless remote control device to send an open command to a given movable barrier operator, thereby causing the latter to move a corresponding movable barrier toward an open position.It is also known to effect communications between a movable barrier operator and various other elements, such as, but not limited to, connected or disconnected control interfaces, displays, lighting modules, alarm systems, obstacle detectors, and so on. One known approach to supporting such communications uses ternary data. While many data communications rely on binary data, ternary data has been used for at least some movable barrier operator communications. However, it is not always directly convenient to support the sending and receiving of true ternary data (i.e., data that can assume any of three distinct states). For example, corresponding problems can arise when the movable barrier operator is faced with a peripheral element that can only communicate using standardized serial hardware based on binary signals.

[0003] A ternary-to-binary converter is known from US 4 243 976 A. A system for the secure opening of garage doors, for example, is known from US 6 690 796 B1.

[0004] It is also known that encryption can be used to secure a given data transmission. Unfortunately, many encryption techniques are relatively expensive to implement. This can be prohibitive when considering the use of encryption in a highly price-sensitive context such as movable barrier operators and their peripherals. Brief description of the drawings

[0005] The above needs are at least partially met by providing the method and apparatus for facilitating the transmission of ternary movable barrier drive information, which is partially described in the following detailed description when considered in conjunction with the drawings in which: Fig. 1 a representation of state-of-the-art ternary coding; Fig. 2 is a flowchart as configured in accordance with various embodiments of the invention; Fig. 3 is a flowchart as configured in accordance with various embodiments of the invention; Fig. 4 illustrates a mapping table as configured in accordance with various embodiments of the invention; Fig. 5 is a schematic view of a data frame as configured in accordance with various embodiments of the invention; Fig. 6 is a data frame flow diagram as configured in accordance with various embodiments of the invention; Fig. 7 is a data frame flow diagram as configured in accordance with various embodiments of the invention; Fig. 8 is a data frame flow diagram as configured in accordance with various embodiments of the invention; Fig. 9 is a block diagram as configured in accordance with various embodiments of the invention;

[0006] Those skilled in the art will appreciate that elements in the figures are not necessarily drawn to scale for simplicity and clarity. For example, the dimensions and / or relative arrangement of some of the elements in the figures may be exaggerated with respect to other elements to assist in enhancing the understanding of various embodiments of the present invention. Also, commonly used but well-known elements that are useful or necessary in a commercially viable embodiment are often not shown to facilitate a less cluttered illustration of those various embodiments of the present invention.It will also be understood that the terms and expressions used herein have the commonly used meanings assigned to such terms and expressions with respect to their respective fields of application and investigation, unless where specific meanings have otherwise been set forth herein. Detailed description

[0007] Generally speaking, according to these various embodiments, ternary data such as that corresponding to a movable barrier drive is provided and converted into a binary format. The binary information is then sent to or from a movable barrier drive. As will be shown in more detail below, this process can provide an encryption effect while also serving to ensure compatible use of binary peripheral platforms.

[0008] In a preferred approach, converting the ternary data to binary format comprises mapping each trit (a base-3 digit, or the information obtained by selecting from three equally likely outcomes) of the ternary data into a corresponding pair of binary bits (a base-2 digit, or the information obtained by selecting from two equally likely outcomes). A pair of binary bits can represent four discrete information elements, and in a preferred approach, these discrete information elements are each mapped to one of the three trit states or levels, and the fourth discrete information element (which would otherwise comprise an invalid value) serves a synchronization function.

[0009] Configured in this way, different encoded ternary values ​​in a given field can represent a specific corresponding amount of payload as exchanged between a movable barrier drive and a given peripheral unit, and / or the updating of rolling code information. The payload can, for example, include non-fixed information that somehow corresponds to the movable barrier drive. It is also possible, and indeed preferable, to combine such non-fixed information with fixed information (such as, but not limited to, fixed information as identification information for the movable barrier drive and / or the peripheral platform).

[0010] It is also possible to combine one or more of the above data elements with rolling code bits (where the rolling code itself comprises the same rolling code otherwise used by the movable barrier operator to authenticate incoming communications and / or communication sources). Indeed, and as disclosed in more detail below, the inclusion of rolling code information may also serve an encryption function.

[0011] These and other advantages will become clearer upon careful consideration and study of the following detailed description. Reference is now made to the drawings and in particular to Fig. 1, it may be helpful to first describe a typical ternary data protocol commonly found in connection with many movable barrier actuators. According to the outlined approach, pulses of similar amplitude have one of three different durations. For example, a first pulse 10 with a short duration may represent the data element "0." A second pulse 11 with a medium duration may represent the data element or state "1," and a third pulse 12 with a long duration may represent the data element or state "2." Such a data mapping protocol is very useful for effecting base-3 data exchange. As will be disclosed in more detail below, these teachings utilize and incorporate a ternary approach for effecting relatively secure and compatible communications between a movable barrier actuator and corresponding optional peripheral components.In general, however, these teachings avoid the specific ternary approach just described.

[0012] Reference is now made to Fig. 2. In general, these teachings provide a process 20 that itself provides ternary data 21, such as would correspond to a movable barrier drive, and then converts this ternary data into binary format 22 to provide resulting binary information. This binary information is then transmitted from one platform to another 23. As will be shown below, this ternary-to-binary conversion process serves, at least in part, as a type of encryption process, which in turn helps ensure the authentication and accuracy of the transmitted information.

[0013] The ternary data itself may at least partially comprise user data. In particular, and now with reference to Fig. 3, according to a preferred (although optional) approach, providing ternary data may comprise the prior provision of binary bits 31 comprising information corresponding to the movable barrier drive (e.g., information originating from or intended for a movable barrier drive). Such information may optionally comprise, for example, movable barrier drive fixed information 32, such as identification information for a specific movable barrier drive, a specific peripheral component, or the like. Such information may also optionally comprise (in addition to or instead of the fixed information 32) non-fixed information 33, again corresponding to the movable barrier drive. This non-fixed information 33 may comprise payload data / useful information (such as, but not limited to, platform status information, commands, acknowledgments, and so on).As will be shown below, this non-fixed information 33 may also include varying amounts of data if necessary.

[0014] These binary bits are then preferably converted into the above-mentioned ternary data (34). This could, in a suitable platform, comprise a conversion from binary data to ternary data in the manner described above with respect to Fig. 1. However, such a method generally does not need to be used. Instead, the binary data can be converted into a binary-bit-based ternary format (an illustrative example of which is provided below).

[0015] As mentioned above, these teachings contemplate converting such ternary data into binary information. However, in a preferred approach, this does not involve simply reversing the binary-to-ternary process just described. Instead, in a preferred approach, the ternary-to-binary conversion involves mapping each trit of the binary data to a corresponding pair of binary bits. Referring now to Fig. 4, the ternary data element "0" (which corresponds to the ordinary binary data element "0") maps to the binary pair "01". Similarly, the ternary "1" (which corresponds to the ordinary binary "1") maps to the binary pair "10", and the ternary "2" (which corresponds to the ordinary binary "11") maps to the binary pair "11".

[0016] This leaves an otherwise unused binary pair of "00." According to a preferred approach, this otherwise invalid value can serve a synchronization function when supporting communications between a movable barrier drive and one or more peripheral components using a binary format that does not otherwise have a synchronization mechanism built into its format (for example, a stream of binary bits such as: 0110111111110100111011101101111111101001110111011111101001110111 which format has no frame mark or any other synchronization point). To illustrate, a synchronization signal comprising this "00" binary pair, or a corresponding synchronization mark, can be used to indicate, for example, the regular end and / or beginning of a frame or message, as in the following example: 0001101111111010010111011000110111111110100111011100110110111111010011 where the bold "00" regularly spaced binary pairs serve as frame markers and, due to their synchronized regular spacing, are easily distinguishable from other "00" pairs (shown in italics in the example above for explanatory purposes) which may arise for whatever reason.

[0017] Those skilled in the art will recognize that this process of converting binary information to ternary information, followed by converting this ternary information into corresponding binary pairs, will in most cases result in a different bit sequence (and even a different number of bits) when compared to the initial binary information. This difference serves, at least in part, a non-key-based encryption technique, thereby providing an additional element of security with respect to the transmitted data.

[0018] As mentioned above and as will be described in more detail below, message payloads of different sizes can be accommodated by these teachings. According to a preferred approach, for example, at least two different sized payloads can be accommodated. However, it is helpful to provide a specific indication in a transmitted message regarding which payload size has been transmitted. By a preferred approach, and reference is now made to Fig. 5, a frame 50 of otherwise fixed data in this illustrative example comprises a first field 51 of fixed bits and a second field 52 of fixed bits (wherein these fixed bits correspond, for example, to non-changing information such as source and / or destination identification information) and also comprises a ternary value "X" 53 (preferably comprising a corresponding binary pair according to the mapping convention described above).

[0019] A first special ternary value 53 may correspond to the provision of payload having a first size and otherwise indicate it, while a second special ternary value 53 may correspond to the provision of payload having a second, different size and otherwise indicate it. For example, the second value may indicate a payload of a smaller size than the first value. The third possible ternary state / value may correspond to a third size of payload, if desired. However, in a preferred approach, and as will be described in more detail below, the third available ternary level may be used to identify a rolling code update (for the rolling code otherwise used by the movable barrier operator during normal operation).

[0020] Constructed in this way, ternary data, as commonly used by and with a movable barrier drive, can be supported in a binary environment, thereby enabling compatible operation with non-ternary signal links and / or peripheral platforms. The ternary nature of the source data can also be used to assist in characterizing a given communication with respect to the size and / or nature of its payload and / or to facilitate other system-related overhead such as synchronization. Furthermore, the processes outlined can, as a beneficial side effect, contribute to the security of the resulting transmissions. This security can be enhanced through appropriate data manipulation and also through the inclusion of the rolling code mechanism commonly used by movable barrier drives to authenticate the sources of incoming signals.

[0021] Reference is now made to Fig. 6, some specific illustrative examples are now provided.

[0022] In this first illustrative example, a peripheral component (such as, but not limited to, an intrusion detection alarm system) has a 15-binary-bit payload 60 for communicating with a movable barrier operator. This payload, in this example, includes non-fixed data, the content of which can and will vary depending on the need and circumstances.

[0023] A framing / source / direction header 61 comprises 4 trits of data (since the platform involved is likely by definition a non-ternary-based platform, these trits each preferably comprise a binary pair counterpart, as by the mapping convention disclosed above).

[0024] A fixed code frame 50 as disclosed above (in this example comprising a 15-bit fixed code field, a 14-bit fixed code field, and a 1-bit identifying field 53) is used in this example to contain a fixed identifier for the peripheral component itself (such as an identification code assigned to a manufacturer or installer) that assists the movable barrier operator in identifying the peripheral component and in distinguishing its communications from those with other devices and sources.

[0025] In this example, the identifying 1-bit field 53 has a bit value of "0," which in this example indicates the above-described 15-bit size of the data payload 60. This field, upon receipt, can assist the movable barrier operator in retrieving this payload 60.

[0026] The contents of the header 61 and the fixed-code frame 50 are manipulated and processed according to a back-end process 62 described below. However, it may be beneficial to first describe a front-end data manipulation process corresponding to the data payload 60 itself.

[0027] The (in this example) existing 32-bit rolling code value used by the movable barrier drive is incremented by a value of "3" to provide an incremented rolling code value of 63. In many cases, the peripheral component will already have a correct (or otherwise usable) rolling code value by means well known in the art and requiring no further explanation here. In other cases, where substantial rolling code synchronization has been lost for some reason, the peripheral device may receive an update regarding the rolling code, for example, from the movable barrier itself (one technique for effecting such an update, as by these teachings, is set forth later in this specification).

[0028] The 15 bits of the data payload 60 are then combined by concatenation with the lower 16 bits 64 (i.e., the least significant bits) of the incremented rolling code value 63. The 15 bits of the data payload 60 are then XORed with 15 bits of the lower 16 bits 64, and the resulting value is then incremented by "1" to obtain a 15-bit XORed result 65. In this exemplary procedure, this completes the front-end data manipulation process, which prepares the payload data 60 for manipulation by the back-end process 62.

[0029] Turning now to the back-end process 62, the XOR result 65 is inverted or mirrored with respect to the lower 16 bits of the incremented rolling code 64 to provide a series of bits 62C in reverse order. These binary bits are then converted to a ternary form 62D (i.e., from a base 2 to a base 3 representation). For example, for illustrative purposes, the value "9" (in base 10 representation) would appear in binary format as "1001." This binary number, once converted to ternary form, would appear as "100." In general, however, the peripheral components will not be able to perform literal arithmetic or processing using a ternary data system. Therefore, in a preferred approach, these ternary trits are each mapped to a corresponding binary pair, as described above, to provide binary pair-encoded trits 62E.To complete this example, the original ternary value "100" would then be expressed as three binary pairs "10 01 01." It can thus be seen that the original binary value "1001" is converted into the binary expression "100101."

[0030] Those skilled in the art will understand and appreciate that this conversion process thus provides the additional benefit of effectively encrypting the original binary expression as an encoded expression. It will also be appreciated that the inclusion of the rolling code value as described above adds another element of variability and thus also serves a form of encryption purpose (with the XOR operation, concatenation, and reverse bit ordering also contributing, at least in part, to the encoded-encrypted result).

[0031] Referring again to the fixed code frame 50 described above, the binary data comprising the fixed code frame 50 is similarly converted into a ternary system, and more specifically, converted into corresponding binary pair-encoded trits 62A. These binary pair-encoded trits 62A, comprising the aforementioned fixed code information, are then modified in conjunction with the binary pair-encoded trits 62E, representing the rolling code-modified, non-fixed code information.

[0032] The precise nature of this modification may vary with the needs of a given setting and / or the preferences of the designer. According to one approach, this modification involves combining, on a single-trit basis, the binary-pair-encoded trits 55A representing the non-fixed code information with the binary-pair-encoded trits 62E representing the fixed code information, and then retaining the least significant bit of the resulting combination. For example, the 20th bit of the fixed code information is added to the 20th bit of the non-fixed code information, and the least significant bit of the resulting sum is then retained as the modified result 62B. Preferably, this modification occurs with respect to both the 15-bit fixed code field information 51 and the 14-bit code field information 52 (in combination with the identifying field 53).

[0033] The resulting fixed-code information-modified binary pair-encoded trits 62B are then interleaved with the non-fixed-code information-modified binary pair-encoded trits 62E to provide a set of 40 binary pair-encoded interleaved trits 62G. These are then preferably combined with the source header 61 to provide a resulting message 62A, which in this example comprises 44 trits encoded as 44 binary pairs (i.e., 88 binary bits).

[0034] The above process allows the encoding of up to 15 bits of non-fixed data and communication to or from a movable barrier drive using common concepts, strengths, and resources (such as maintaining and using ternary data and rolling code) of the movable barrier drive. Reference is now made to Fig. 7, if desired, a reduced data capacity can also be accommodated. In the example shown, the non-fixed code field 70 will accommodate 7 bits of data. Here, during front-end processing of the non-fixed information, these 7 bits of non-fixed code 70 are padded with the next 8 bits of rolling code value 63 incremented by 3 (that is, the next 8 bits following the first 16 bits 64, as already applied for concatenation to the non-fixed code information 70). The resulting 15 bits are then XORed again with the lower 16 bits of the incremented rolling code value and concatenated with "1", as described above. The back-end process 62 then executes as described above.

[0035] If desired, the characterizing trit 53 in the fixed code information 50 may have a value or state corresponding to and indicating that non-fixed code size comprises the 7-bit data set rather than the 15-bit data set described above with respect to Fig. 6. This, in turn, will allow a receiving platform to determine whether the resulting message contains 7 bits of non-fixed information or 15 bits of non-fixed information and, accordingly, whether to reverse the front-end process to correspond to one or the other.

[0036] These described processes assume that the coding platform has an accurate value for the current rolling code. For a variety of reasons, this may not always be the case. In some cases, the source platform may be able to independently determine that its present rolling code value is out of sync or otherwise inaccurate. In other cases, the source platform may be able to infer this situation from the fact that its message has been rejected by the receiving platform. In such a case, it may be helpful and / or desirable to provide a mechanism whereby a platform is provided with an updated rolling code value, thereby re-establishing its rolling code synchronization.

[0037] Reference is now made to Fig. 8, the process described above can be modified to accommodate a message that essentially serves to transmit a current rolling code value. According to this procedure, a current rolling code value 63 (again incremented by the value "3" in this illustrated embodiment) is fed to the back-end process described above without prior combination with any user data. The identifying field 53 can again be set to a value, this time a value indicating that the resulting message includes the rolling code value (incremented by "3") and does not contain any other non-fixed code information.

[0038] The processes described above are suitable for implementation via any number of currently known platforms and undoubtedly other platforms as they may be developed later. Generally speaking, and now referring to Fig.9, an enabling device 90 (such as, but not limited to, a movable barrier drive or a device that communicates with a movable barrier drive) preferably has at least a first memory 91 containing the ternary data to be transferred between a movable barrier drive and a peripheral device. A ternary-to-binary converter 92 is operatively coupled to this first memory 91 and serves to convert the ternary data into corresponding binary data.

[0039] More specifically, and according to a preferred approach set forth above, the ternary data comprises a binary expression of ternary data, which the ternary-to-binary converter 92 then converts into corresponding binary pairs. A transmitter 93 receives this converted information and transmits the information to a given receiver (those skilled in the art will recognize that this transmitter 93 may be one using a wired / cabled routing path (such as an electrical conductor or an optical fiber) or one using a wireless routing path (such as a radio frequency carrier, a free-space optical carrier, an ultrasonic carrier, and so on).

[0040] The ternary data contained in first memory 91 can be used as a source in a variety of ways. An optional but preferred approach begins, in part, with the provision of a user data memory 94B containing non-fixed binary user data and a rolling code memory 94C with rolling code data stored therein (such as a current rolling code value when incremented by "3"). Data from these two memories 94B and 94C is input to an XOR 95, which provides its output to a concatenator 96. This concatenator 96 is also operatively coupled to receive, in this illustrative embodiment, rolling code data from the rolling code memory 94C. So configured, the concatenator 96 serves to concatenate the output of the XOR device 95 with rolling code data.A bit reorderer 97 is operatively coupled to the concatenator 96 and serves to reverse the order of the concatenated output of the concatenator 96. The output of the bit reorderer 97 is then operatively coupled to a binary-to-ternary converter 98 which serves to convert the binary data into binary-expressed ternary data, as described above.

[0041] In this illustrated embodiment, an interleaver 99 is coupled to a binary-to-ternary converter and a source of fixed-code information 94A, and interleaves the incoming data streams from these two sources (if desired, the fixed-code information can be developed as described above). The interleaved data output of the interleaver 99 is then coupled to the first memory 91. Thus constructed and arranged, the interleaved data from the interleaver 99 can include the ternary data, which is then provided by the first memory 91 to the ternary-to-binary converter 92 described above.

[0042] Constructed in this way, the inherent capability of a movable barrier drive to process ternary data, along with maintaining and utilizing a rolling code, is effectively implemented and used to facilitate relatively secure communications, such as between such a movable barrier drive and one or more peripheral components or devices. Those skilled in the art will recognize that the blocks described above may be implemented using appropriate discrete physical elements and / or through the use of a partially or fully programmable platform. Since many movable barrier drives include a programmable controller, in many cases it will likely be preferable to simply program the controller in accordance with the teachings.

[0043] Those skilled in the art will recognize that a wide variety of modifications, variations and combinations can be made to the embodiments described above without departing from the spirit of the invention and that such modifications, variations and combinations are to be considered within the scope of the inventive concept.

[0044] Further advantageous embodiments are described below as A1 to A26. A1. A method comprising: providing ternary data corresponding to a movable barrier drive; converting the ternary data into binary format to provide binary information; transmitting the binary information. A2. The method of A1, wherein converting the ternary data into binary format further comprises mapping each trit of the ternary data to a corresponding pair of binary bits. A3. The method of A2, wherein transmitting the binary information further comprises transmitting pairs of binary bits, each of the pairs of binary bits potentially representing one of the group consisting of: a specific ternary value; an invalid value. A4. Method according to A3, wherein the invalid value serves a synchronization function. A5. The method of A4, wherein: a first specific ternary value for the specific ternary value comprises usable capacity of a first size; a second specific ternary value for the specific ternary value comprises usable capacity having a second size, the second size being different from the first size; a third specific ternary value for the ternary value comprises updating a rolling code used by the movable barrier operator. A6. The method of A1, wherein providing ternary data further comprises: providing binary bits comprising information corresponding to the movable barrier drive; converting the binary bits into the ternary data. A7. The method of A6, wherein providing the binary bits comprising information corresponding to the movable barrier drive further comprises providing binary bits comprising fixed information corresponding at least in part to the movable barrier drive. A8. Method according to A7, wherein the fixed information comprises identification information. A9. The method of A8, wherein providing binary bits as information corresponding to the movable barrier drive further comprises providing binary bits as they at least partially correspond to non-fixed information corresponding to the movable barrier drive. A10. The method of A6, wherein providing ternary data further comprises: combining at least some of the binary bits with rolling code bits. A11. The method of A10, wherein combining at least some of the binary bits with rolling code bits further comprises: exclusive-oring the binary bits with the rolling code bits to provide encrypted bits; concatenating the encrypted bits with the rolling code bits to provide resulting bits; reversing the order of the resulting bits to provide reverse-ordered bits; and wherein converting the binary bits to ternary bits further comprises converting the reverse-ordered bits to ternary data. A12. The method of A11 and further comprising: interleaving the ternary data with other ternary data prior to providing interleaved ternary data; and wherein converting the ternary data into a binary format to provide binary information further comprises: converting the interleaved ternary data into the binary format to provide the binary information. A13. The method of A12, wherein interleaving the ternary data with other ternary data further comprises: providing additional binary bits comprising information corresponding to the movable barrier drive; converting the additional information corresponding to the binary bits comprising the movable barrier drive into intermediate ternary data; modifying the intermediate ternary data using rolling code information to provide the other ternary data; A14. The method of A13, wherein modifying the intermediate ternary data using rolling code information further comprises: modifying the intermediate ternary data using the ternary data. A15. The method of A14, wherein modifying the intermediate ternary data using the ternary data further comprises: combining each trit of the intermediate ternary data with a corresponding trit of the ternary data to provide a resulting multi-trit value; selecting a particular trit for each resulting multi-trit value to encompass the other ternary data. A16. The method of A15, wherein selecting a particular trit of each resulting multi-trit value further comprises selecting a least significant trit of each resulting multi-trit value. A17. The method of A1, wherein transmitting the binary information comprises transmitting the binary information to at least one of the group consisting of: a movable barrier operator; an alarm system; and a sensor. A18. A method of facilitating communication, such as between a movable barrier operator and a peripheral device, comprising: providing data to be transmitted, the data comprising at least in part ternary data; encrypting the data at least in part by converting at least some of the ternary data into corresponding binary data; transmitting the corresponding binary data. A19. The method of A18, wherein encrypting the data further comprises converting at least some trits comprising the ternary data into corresponding binary pairs such that each such converted trit is represented by a corresponding binary pair. A20. The method of A18, wherein providing data to be transmitted, the data at least partially comprising ternary data, further comprises: providing initial data to be transmitted, the initial data at least partially comprising initial binary data; providing rolling code bits; exclusive-oring at least some bits of the initial binary data with at least some of the rolling code bits to provide a resulting set of bits; reversing the resulting set of bits to provide reversed-order bits; converting the reversed-order bits to corresponding ternary data to provide the ternary data. A21. The method of A20, wherein providing initial data to be transmitted, the initial data at least partially comprising initial binary data, further comprises providing initial data selectively comprising any one of 15 binary bits and 7 binary bits. A22. A device comprising at least one of a movable barrier drive and a device communicating with a movable barrier drive, comprising: a first memory having ternary data to be transmitted between the movable barrier drive and the device communicating with a movable barrier drive; a ternary-to-binary converter operatively coupled to the first memory and having a binary data output; a transmitter operatively coupled to the binary data output. A23. The device of A22 and further comprising: a user data memory having binary user data stored therein; a rolling code memory having rolling code data stored therein; an exclusive-or gate having inputs operatively coupled to the user data memory and the rolling code memory; a concatenator operatively coupled to an output of the exclusive-or gate and the rolling code memory; a bit inverter operatively coupled to the output of the concatenator; a binary-to-ternary converter having an input operatively coupled to an output of the bit inverter and having an output operatively coupled to an input of the first memory. A24. Device according to A23, wherein the binary data output of the ternary-to-binary converter comprises a binary path data output. A25. Apparatus according to A24, wherein the ternary-to-binary converter comprises means for converting at least one trit of the ternary data into corresponding binary pairs such that each trit is represented by a corresponding binary pair. A26. Device according to A23 and further comprising an interleaver for interleaving trits output from the binary-to-ternary converter with fixed code information corresponding to the device for providing trits as input to the ternary-to-binary converter.

Claims

[1] A method of facilitating communication between a movable barrier operator and a peripheral device, comprising: - Providing data to be sent, the data comprising at least partly ternary data; - encrypting the data at least partially by converting at least some of the ternary data into corresponding binary data; - Wirelessly transmit the corresponding binary data. [2] The method of claim 1, wherein encrypting the data further comprises converting at least some trits comprising the ternary data into corresponding binary pairs such that each trit so converted is represented by a corresponding binary pair. [3] The method of claim 1, wherein providing data to be sent further comprises: - providing initial data to be transmitted, the initial data comprising at least partially initial binary data; - Providing rolling code bits; - EXCLUSIVE-ORing at least some bits of the initial binary data with at least some of the rolling code bits to provide a resulting set of bits; - reversing the order of the resulting set of bits to provide reversed-order bits; and - Converting the reversed bits into corresponding ternary data to provide the ternary data. [4] The method of claim 3, wherein providing initial data to be transmitted, the initial data at least partially comprising initial binary data, further comprises providing initial data selectively comprising any one of 15 binary bits and 7 binary bits. [5] A device comprising a movable barrier drive and / or a device communicating with a movable barrier drive, which is designed to carry out the method according to one of claims 1 to 4. [6] Device according to claim 5, further comprising: - a user data store with binary user data stored therein; - a rolling code memory with rolling code data stored therein; - an EXCLUSIVE-OR gate with inputs operatively coupled to the user data memory and the rolling code memory; - a concatenator operatively coupled to an output of the exclusive-or gate and the rolling code memory; - a bit inverter operatively coupled to an output of the concatenator; - a binary-to-ternary converter having an input operatively coupled to an output of the bit inverter and having an output operatively coupled to an input of a first memory. [7] The device of claim 6, wherein the binary data output of the ternary-to-binary converter comprises a binary pair data output. [8] The device of claim 7, wherein the ternary-to-binary converter comprises means for converting at least one trit of the ternary data into corresponding binary pairs such that each trit is represented by a corresponding binary pair. [9] The device of claim 8 and further comprising interleaving means for interleaving trits output from the binary-to-ternary converter with fixed code information corresponding to the means for providing trits input to the ternary-to-binary converter.

Images