Method and apparatus to facilitate transmission of ternary movable barrier operator information

[0001] This invention relates generally to movable barrier operators and more particularly to the transmission of movable barrier operator information.

[0002] Movable barrier operators of various kinds are known in the art. These include operators that effect the selective control and movement of single panel and segmented garage doors, pivoting, rolling, and swinging gates, guard arms, rolling shutters, and various other movable barriers. In general, such movable barrier operators typically operate (at least in part) by responding to a remotely sourced control signal. For example, an individual in a vehicle can manipulate a corresponding wireless remote control device to transmit an OPEN command to a given movable barrier operator to thereby cause the latter to move a corresponding movable barrier towards an opened position. It is also known to effect communications between a movable barrier operator and various other elements such as, but not limited to, tethered and un-tethered control interfaces, displays, lighting modules, alarm systems, obstacle detectors, and so forth.

[0003] One known approach to supporting such communications makes use of ternary data. Whereas many data communications rely upon binary data, ternary data has been used for at least some movable barrier operator communications. It is not always readily convenient, however, to facilitate the transmission and reception of true ternary data (i.e., data that can have any of three different states). Such problems can arise, for example, when interfacing a movable barrier operator with a peripheral element that only communicates using standard serial hardware that relies upon binary signaling.

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

[0015] Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will also be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.

[0016] Generally speaking, pursuant to these various embodiments, ternary data as corresponds to a movable barrier operator is provided and converted into a binary format. The binary information is then transmitted to or from a movable barrier operator. As will be shown below in more detail, this process can achieve an encryption effect while also serving to ensure compatible use of binary peripheral platforms.

[0017] In a preferred approach, converting the ternary data to a binary format comprises mapping each trit of the ternary data to a corresponding pair of binary bits. A pair of binary bits can represent 4 discrete information elements and in a preferred approach, three of these discrete information elements each correspond to one of the three trit states/levels and the fourth discrete information element (which otherwise comprises an illegal value) serves a synchronization function.

[0018] So configured, different encoded ternary values in a given field can represent a particular corresponding size of bearer content as is being exchanged between a movable barrier operator and a given peripheral and/or the updating of rolling code information. The bearer content can comprise, for example, non-fixed information that corresponds in some way to the movable barrier operator. It is also possible, and actually preferred, to combine such non-fixed information with fixed information (such as, but not limited to, fixed information such as identifying information for the movable barrier operator and/or the peripheral platform).

[0019] It is also possible to combine one or more of the above data elements with rolling code bits (wherein the rolling code itself comprises the same rolling code as is otherwise used by the movable barrier operator to authenticate incoming communications and/or communication sources). In fact, and as will be disclosed below in more detail, the incorporation of rolling code information can serve an encryption function as well.

[0020] These and other benefits may become clearer upon making a thorough review and study of the following detailed description. Referring now to the drawings, and in particular to FIG. 1, it may be helpful to first describe in more detail a typical ternary data protocol as one finds often deployed in conjunction with many movable barrier operators. Pursuant to the illustrated approach, pulses of similar amplitude have one of three different durations. For example, a first pulse 10, having a shortest duration, can represent the data element “0.” A second pulse 11, having a medium length duration, can represent the data element or state “1.” And a third pulse 12, having a longest duration, can represent the data element or state “2.” Such a data mapping protocol serves well to effect a base three-based data exchange. As will be disclosed below in more detail, these teachings utilize and leverage a ternary approach to effect relatively secure and compatible communications between a movable barrier operators and corresponding peripheral components of choice. In general, however, these teachings eschew the specific ternary approach just described.

[0021] Referring now to FIG. 2, in general, these teachings provide a process 20 that itself provides 21 ternary data as corresponds to a movable barrier operator and then converts 22 that ternary data to a binary format to provide resultant binary information. This binary information is then transmitted 23 from one platform to another. As will be shown below, this ternary-to-binary conversion process serves, at least in part, as a kind of encryption process which in turn aids in ensuring the authenticity and accuracy of the information being transmitted.

[0022] The ternary data itself can comprise, at least in part, bearer data. More particularly, and referring momentarily to FIG. 3, pursuant to a preferred (though optional) approach, provision of ternary data can comprise prior provision 31 of binary bits comprising information that corresponds to the movable barrier operator (for example, information sourced by, or intended for, a movable barrier operator). Such information can optionally comprise, for example, movable barrier operator fixed information 32 such as identifying information for a particular movable barrier operator, a particular peripheral component, or the like. Such information can also optionally comprise (in addition to or in lieu of fixed information 32) non-fixed information 33 as again corresponds to the movable barrier operator. This non-fixed information 33 can comprise bearer data/information (such as, but not limited to, platform status information, commands, acknowledgments, and so forth). As will be shown below, this non-fixed information 33 can also comprise varying quantities of data if desired.

[0023] These binary bits are then preferably converted 34 into the aforementioned ternary data. This could comprise, in an appropriate platform, a conversion of the binary data into ternary data such as that described above with respect to FIG. 1. In general, such an approach need not be used. Instead, the binary data can be converted into a binary-bit-based ternary format (with an illustrative example being provided further below).

[0024] As mentioned above, these teachings contemplate converting such ternary data into binary information. In a preferred approach, however, this does not comprise a simple reversal of the binary-to-ternary process just described. Instead, the ternary-to-binary conversion step comprises, in a preferred approach, mapping each trit of the ternary data to a corresponding pair of binary bits. To illustrate, and referring momentarily to FIG. 4, the ternary data element “0” (which corresponds to the usual binary data element “0”) maps to the binary pair “01.” In similar fashion, ternary “1” (which corresponds to usual binary “1”) maps to the binary pair “10” and ternary “2” (which corresponds to usual binary “11”) maps to the binary pair “11.”

[0025] This leaves an otherwise unused binary pair “00.” Pursuant to a preferred approach, this otherwise illegal value can serve a synchronization function when facilitating communications as between a movable barrier operator and one or more peripheral components when using a binary format that otherwise has no synchronization mechanism built into its format (for example, a stream of binary bits such as:

[0026] 011011111110100111011101101111111010011101110110111111101001110111

[0027] which format lacks a frame marker or other point of synchronization). To illustrate, a synchronization signal/marker comprising this “00” binary pair can be used to indicate, for example, the regular end and/or start of a frame or message as in the following example:

[0028] 000110111111010010111011000110111111101001110111001101101111111010011

[0029] where the bold font “00” regularly spaced binary pairs serve as frame markers (and which, due to their synchronized regular spacing, are readily distinguishable from other “00” pairs as may occur for whatever reason (illustratively depicted in the above example with italic font).

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

[0031] As mentioned above, and as will be described in more detail below, message payloads of differing sizes can be accommodated by these teachings. Pursuant to a preferred approach, for example, at least two differently sized payloads can be accommodated. It is helpful, however, to provide a specific indication in a conveyed message regarding which sized payload is being conveyed. By one preferred approach, and referring now to FIG. 5, a frame 50 of otherwise fixed data comprising, in this illustrative example, a first field 51 of fixed bits and a second field 52 of fixed bits (where these fixed bits correspond, for example, to non-changing information such as source and/or target identifying information) also comprises a ternary value “X” 53 (preferably comprising a corresponding binary pair as per the above-described mapping convention).

[0032] A first particular ternary value 53 can correspond to and otherwise indicate provision of bearer content having a first size while a second particular ternary value 53 can correspond to and otherwise indicate provision of bearer content having a second, different size. For example, the second value can indicate a smaller sized bearer content than does the first value. The third possible ternary state/value can correspond to a third size of bearer content if desired. In a preferred approach, however, and as will be described below in more detail, the third available ternary level can be used to identify a rolling code update (for the rolling code that is otherwise employed by the movable barrier operator in ordinary course of operation).

[0033] So configured, ternary data as ordinarily employed by and with a movable barrier operator can be supported in a binary context, thereby effecting compatible operation with non-ternary signal paths and/or peripheral platforms. The ternary nature of the source data can also be leveraged to aid in characterizing a given communication with respect to the size and/or nature of its payload and/or to facilitate other systems-related overhead such as synchronization. In addition, the processes set forth, as a beneficial side effect, can contribute to the security of the resultant transmissions. This security can be enhanced through appropriate data manipulation and also through incorporation of the rolling code mechanism as is typically employed by the movable barrier operator to authenticate incoming signal sources.

[0034] Referring now to FIG. 6, some specific exemplary illustrative examples will now be provided.

[0035] 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 to communicate to a movable barrier operator. This payload comprises, in this example, non-fixed data that can and will vary in content with need and circumstance.

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

[0037] A fixed code frame 50 as disclosed above (comprising, in this example, a 15 bit fixed code field, a 14 bit fixed code field, and a characterizing 1 trit field 53) serves to contain, in this example, a fixed identifier for the peripheral component itself (such as a manufacturer or installer assigned identifier code) that aids the movable barrier operator in identifying the peripheral component and distinguishing its communications from those of other devices and sources.

[0038] In this example, the characterizing 1 trit field 53 has a trit value of “0” which signifies, in this example, the 15 bit size of the data payload 60 described above. This field, upon receipt, can aid the movable barrier operator with respect to recovering that payload 60.

[0039] The contents of the header 61 and fixed code frame 50 are manipulated and processed pursuant to a back-end process 62 described below. First, however, it may be beneficial to first describe a front-end data manipulation process as corresponds to the data payload 60 itself.

[0040] The present 32 bit (in this example) rolling code value as used by the movable barrier operator in incremented by a value of “3” to provided an incremented rolling code value 63. In many instances the peripheral component will already have a correct (or otherwise usable) rolling code value by means well understood in the art and requiring no further elaboration here. In other cases, where substantial rolling code synchronization has been lost for whatever reason, the peripheral device can receive an update as pertains to the rolling code from, for example, the movable barrier itself (a technique for effecting such an update as per these teachings is set forth further below in this description).

[0041] The 15 bits of the data payload 60 are then combined through 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 exclusive ORed with 15 bits of the lower 16 bits 64 and the resultant value then incremented by “1” to yield a 15 bit exclusive ORed result 65. In this exemplary approach, this completes the front-end data manipulation process that prepares the payload data 60 for the manipulations of the back-end process 62.

[0042] Turning now to that back-end process 62, the exclusive ORed result 65 is inverted or mirrored with respect to the lower 16 bits of the incremented rolling code 64 to provide a reverse ordered series of bits 62C. These binary bits are then converted to a ternary form 62D (i.e., from a base two representation to a base three representation). For example, by way of illustration, the value “9” (in base ten) would appear in binary format as “1001.” This number in binary, once converted to ternary form, would appear as “100.” In general, however, the peripheral component will not be able to literally calculate or process 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, then, the original ternary value “100” would be expressed as the three binary pairs “10 01 01.” It may therefore be seen that the original binary value “1001” is converted into the binary expression “100101.”

[0043] Those skilled in the art will understand and appreciate that this conversion process therefore provides a supplemental benefit of effectively encrypting the original binary expression as a coded expression. It will further be appreciated that incorporation of the rolling code value as described above adds a further element of variability and hence further serves a kind of encryption purpose as well (with the exclusive ORing, concatenation, and reverse bit ordering also contributing at least in part to the encoded/encrypted result).

[0044] Referring again to the fixed code frame 50 described above, the binary data as comprise the fixed code frame 50 are similarly converted to a ternary system and in particular are converted to corresponding binary pair encoded trits 62A. These binary pair encoded trits 62A as comprise the aforementioned fixed code information are then modified in conjunction with the binary pair encoded trits 62E as represent the rolling code modified non-fixed code information.

[0045] The precise nature of this modification can vary with the needs of a given setting and/or the preferences of the designer. Pursuant to one approach, this modification comprises combining the trits, on a trit by trit basis, of the binary pair encoded trits 62A as represent the non-fixed code information with the binary pair encoded trits 62E as represent the fixed code information and then retaining the least significant bit of the resultant combination. For example, the 20^th bit of the fixed code information is added to the 20^th 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 fixed code field information 52 (in combination with the characterizing field 53).

[0046] The resultant 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 original header 61 to provide a resultant message 62H that comprises, in this example, 44 trits that are encoded as 44 binary pairs (i.e., 88 binary bits).

[0047] The above process permits up to 15 bits of non-fixed data to be encoded and communicated to or from a movable barrier operator using familiar concepts, strengths, and resources (such as ternary data and rolling code maintenance and usage) of the movable barrier operator. Referring now 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 the front-end processing of the non-fixed information, these 7 bits of non-fixed code 70 are effectively padded with a next 8 bits of the incremented-by-3 rolling code value 63 (that is, the next 8 bits as follow the first 16 bits 64 as were already applied for concatenation to the non-fixed code 70 information). The resultant 15 bits are then again exclusive ORed with the lower 16 bits of the incremented rolling code value 64 and concatenated with “1” as described above. The back-end process 62 than executes as described above.

[0048] If desired, the characterizing trit 53 in the fixed code information 50 can have a value or state that corresponds to and indicates that the non-fixed code size comprises the 7 bit quantity rather than the 15 bit quantity provided above with respect to FIG. 6. This in turn will permit a receiving platform to ascertain whether the resultant message contains 7 bits of non-fixed information or 15 bits of non-fixed information and hence whether to reverse the front-end process as corresponding to the one or the other.

[0049] These described processes presume that the encoding platform has an accurate value for the present rolling code. It is possible, for a variety of reasons, that this may not always be the case. In some cases the source platform may be able to independently ascertain that its present value for the rolling code is unsynchronized or otherwise inaccurate. In other cases, the source platform may be able to deduce this situation upon having its message rejected by the receiving platform. In such a case it may be helpful and/or desirable to provide a mechanism whereby a platform can be provided with an updated rolling code value to thereby re-establish its rolling code synchronicity.

[0050] Referring now to FIG. 8, the above described processes can be modified to accommodate a message that essentially serves to transmit a present rolling code value. Pursuant to this approach, a present rolling code value 63 (incremented again by the value “3” in this illustrative embodiment) is submitted to the above described back-end process without prior combination with any user data. The characterizing field 53 can again be set to a value, this time a value indicating that the resultant message comprises the rolling code value (incremented by “3”) and does not contain other non-fixed code information.

[0051] The above described processes are suitable for implementation via any number of presently known platforms and no doubt other platforms as will be developed hereafter. Generally speaking, and referring now to FIG. 9, a suitable enabling apparatus 90 (such as, but not limited to, a movable barrier operator or a device that communicates with a movable barrier operator) preferably has at least a first memory 91 containing the ternary data that is to be transmitted as between a movable barrier operator and a peripheral device. A ternary-to-binary converter 92 is operably coupled to this first memory 91 and serves to convert the ternary data into corresponding binary data.

[0052] More particularly, and pursuant to a preferred approach as set forth above, the ternary data comprises a binary expression of ternary data which the ternary-to-binary converter 92 then converts to corresponding binary pairs. A transmitter 93 receives this converted information and transmits the information to a given recipient (those skilled in the art will recognize that this transmitter 93 can use a wired/cabled pathway (such as an electrical conductor or an optical fiber) or a wireless pathway (such a radio frequency carrier, a freespace optical carrier, an ultrasonic carrier, and so forth).

[0053] The ternary data contained in the first memory 91 can be sourced in various ways. One optional but preferred approach begins, in part, with provision of a user data memory 94B that contain non-fixed binary user data and a rolling code memory 94C having rolling code data stored therein (such as a present rolling code value as incremented by “3”). Data from these two memories 94B and 94C are input to an exclusive OR 95 which provides its output to a concatenator 96. This concatenator 96 also operably couples 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 exclusive OR 95 with rolling code data.

[0054] A reverse bit orderer 97 operably couples to the concatenator 96 and serves to reverse order the concatenated output of the concatenator 96. The output of the reverse bit orderer 97 then operably couples to a binary-to-ternary converter 98 which serves to convert the binary data to binary-expressed ternary data as described above.

[0055] In this depicted embodiment an interleaver 99 couples to the binary-to-ternary converter 98 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 then couples to the first memory 91. So configured and arranged, the interleaved data from the interleaver 99 can comprise the ternary data that is then provided by the first memory 91 to the ternary-to-binary converter 92 described above.

[0056] So configured, the native capability of a movable barrier operator to process ternary data, along with the maintenance and use of a rolling code, is effectively leveraged and utilized to facilitate relatively secure communications as between such a movable barrier operator and one or more peripheral components/devices. Those skilled in the art will recognize that the blocks described above can be implemented using corresponding discrete physical elements and/or through us of a partially or wholly programmable platform. As many movable barrier operators comprise a programmable controller, in many instances it will likely be preferred to simply program the controller in accordance with the teachings.

[0057] Those skilled in the art will recognize that a wide variety of modifications, alterations, and combinations can be made with respect to the above described embodiments without departing from the spirit and scope of the invention, and that such modifications, alterations, and combinations are to be viewed as being within the ambit of the inventive concept.