• 10 dec 2017: forum version update. In case of issues use this topic.
  • 30 nov 2017: pilight moved servers. In case of issues use this topic.
Hello There, Guest! Login Register

[Solved] Came door opener automatic gates
I am using a Came automatic gate opener (see, for example, their UK website). I would like to analyze the code Came is sending. For that purpose I used a superheterodyn 433MHz-receiver (RXB 12) who is supposed to be better than the cheaper XY-MV-5 version.

[EDIT] I worked at least a week on this thread and learned a lot. I decided to edit this text heavily from the beginning (including deleting posts with wrong "Heureka"-moments) because I went on several wrong tracks during that time that will distract the reader who starts from here.[/EDIT]

I believe that it must be possible to re-engineer the signal: The Came-senders can be "duplicated" using cheap Chinese sender-receivers so I do not suspect any rolling code here.
I had difficulties using pilight-debug, RFSniffer, RCSwitch and similar tools. Later on it turned out why: These kind of programs do not only receive the signal, they already try to analyze it. What they do is the following.

Internally they have stored several codes (called "protocol"). The raw code that is sent from the receiver is now compared to those stored codes. If they find a match they pick the protocol that fits best and adapt the received signal to that protocol.

If this is a known protocol this is a good approach. Came's protocol is not known until I wrote this thread and hence I got several wrong catches that lead me to believe that the software cracked the signal. Unfortunately, I hold too long onto this illusion and was always wondering why I was not able to open the garage door by sending these (wrong) protocols back.

First lesson learned: If it is an unknown protocol always use
pilight-raw -L
or, if you happen to have an arduino, the code from SimpleRCScanner.
You have to analyze the raw code, not an interpreted version.
I was playing for several weeks now with arduino, lpf, ATTtiny etc to no avail. First, I will summarize what I have learned, which is a (longer) comment. In particular I believe that the word "low pass filter" (lpf) is misleading as several authors here and there pointed out. Why? It does not filter lower wavelengths as it is supposed to do. To understand that we have to start from the beginning.

There is a signal with 433Mhz. This signal is the carrier. On top of that signal another information is transmitted. There are two ways to do that: AM or FM (see this nice picture from the wiki). In almost all cases AM is used. A lpf would be necessary to distinguish the 433MHz signal from any signal that has a higher frequency (=lower wavelength). But the filters that are mentioned in this forum do not do that! They record more or less accurately 433MHz. But why do we need filters then?

First, the signal is not only AM. With AM there could be several "signal-strength" as shown in the nice wiki picture above. Here, we have a special case called OnOffKey (or OOK). That means: We have only two possible signals, either nothing or full. With "classical" AM there would be plenty of signal levels, now there are only two.

Now, the second point: Those cheap receivers are built for OOK. But then, there is a technological problem. Assume for a moment that a receiver is getting signals from two and not from one transmitter. How can this OOK-receiver distinguish both signals? It cannot use the level (1st: string signal, 2nd: weak signal) because there are no different levels. Hence, the receiver will always search for a 433MHz signal. Even if there are no signals around. Hence, those cheap Rx will always, even in the absence of any "real" signal, measure something.

How is that "noisy signal" reported? There are many software products that give us numbers, like
220 23530 180 25 55 650 175 20 50 715 210
meaning that (assuming we startet with "signal") for 220us (mikro seconds) "no signal" was received, the next 23530us we got "strong signal", then for 180us there was "no signal", again for 25us "strong signal" and so forth. These numbers are pulse lengths and, if I understand it correctly, several pulse lengths together contain a pulse train. In particular, a pulse train is typically terminated by a very long pulse called footer. The above numbers seem like a perfect 433MHz-OOK-signal that could in principle open or close my Came garage opener.

But this signal will contain not only the message from Came but also "noise" when Came finished its sending job but my receiver was still looking for any signal - but it is not noise in the 433MHz-frequency but "wrong", "misleading" or "not button-pressed" signals (the error is in the modulation, not in the frequency). Our job is now to filter those noise signals and we have some information in order to do that:

  1. Usually, a signal is not sent once, but several times to a receiver (because errors can occur). So, if we are going through "noisy numbers" we should look for repetitions.
  2. The time between no-signal and full-signal is seldom below 100us.
  3. Sometimes, the signal has a special pattern (Manchester encoding, see below). In this case, the pattern can be identified with simple eyesight.
  4. Typically, there is a long footer signal (HIGH) at the end.

So what we have to do is to look for patterns in those numbers. This is a software issue (and applied by pilight-debug and the like!). Although ATTtiny, arduino and the like seem like hardware, in fact what we are doing is: Looking for patterns in a list of numbers. This is not a low-pass filter, but an "identifying pattern software piece". (In order to use the lpf-abbreviation we might call it "look-for pattern filter".)

Of course, such a piece of software might be so possessive that the raspberry cannot handle the amount of data. Therefore it might be useful to use ATTtiny, arduino etc pp. But one could also record those numbers and then go through them by hand. This is what I have done with my Came door opener because all other attempts failed completely. I had numbers in a row and was looking for repetitions or any other pattern. (Will be continued)
I known you haven't finished you posts, but already, thanks for writing this up and taking time in investigating this!
Now, again some "theory". Assume, we have those bunch of numbers as in the previous post. What I learned from other threads is the following pattern.
  1. Any remote will send the same signal at least twice, sometimes even to five times. This can be helpful because we must have (at least) twice the same pattern.
  2. There will be only a few numbers that form or establish one signal (the "pulse train"). In particular, numbers below 100 (sometimes below 200) can be considered as "noise", so have no information value. Also, there will not be, say, fifteen or twenty numbers used to decode one signal. Usually, two to five numbers will be sufficient.

    So if you found until now, say, ten numbers allegedly building your signal you should continue looking at the data.
  3. The signal always ends with a long "footer", meaning a "high" for a very long time compared to the previous much shorter HIGH-LOWs.
There are two cases of No.2.
  1. Manchester code: happens if there are exactly two numbers. Often, those numbers have a particular relation, say 2:1.

    Unfortunately, I was looking for Manchester with my Came remote and did not find anything (I am now certain that it is not Manchester). Manchester is (relatively) easy to spot: You have only two numbers to look for! If there are more than two then it is not Manchester.

  2. PWM: If there are more then two numbers (EDIT: I think that four are involved with Came) we speak of pulse width modulation (PWM) since the width of the pulse modulates during the pulse train. Here you will have to deal not only with two but with three to five numbers.

Now "practice" with Came. First I had a technical problem. I wanted to press the button (=left hand is occupied) and to record the signal (=right hand is occupied). But in order to stop the recording you need to interrupt the program with <CTRL>-C which does not work if you have only two hands. So I wrote a dirty programmed bash-script that started pilight-raw and interrupted after 0.4 seconds, here it is:
# Launch script in background
sudo pilight-raw -L >> daten.txt &
# Wait for 0.4 seconds
sleep 0.4
# Kill it
PID=$(ps ax | grep pilight-raw | awk '{print $1}')
sudo kill -9 $PID
Later I learned that there are some software products that exactly address this problem (see, for example, this code for the arduino) and that pressing the button very long will result in continuously sending the same signal over and over again - so avoiding any "silence" and hence noise in the 433MHz signal.

That way I ended up with a 20k file that contained (hopefully) several signals for my Came remote. I visualized the data using this weboszi and indeed could see "something", like this:

.png   multiple shots.png (Size: 63.07 KB / Downloads: 13)
You can spot three long signals (in fact, there were five long signals contained!) so I was lucky that I recorded something. (I followed this procedure five times until I got this nice result.)

Next, I went to look at the numbers. The long footer was easy to find, these were numbers like
...23245 ...23544 ...23424...23540...23395
so all the numbers in front of those big 23xxx must be the signal. Using Excel I wrote them down in five rows, one row for each signal. I wanted to compare the first pulse train to the second to the third and so forth hoping that I got similar numbers in each column. That was not the case. The numbers were very different, for example like
first:   180  25  55 650 175  20 ...
second: 255 656 194   35 56  674...
third:  215  10  35 655 200  20 ...

Then I remembered that numbers below 100 must be noise. This applies to the 25, 55, 20, 35, 56, 10 etc above. I added them up. The reason is the following. Normally, you seem to have a signal like
...HIGH (200us) - LOW (10us) - HIGH (160us)-...
resulting in
200 10 160
If the 10 contains no information (it is "noise") then you had in fact 200+10+160=370us a HIGH and no LOW in between. I went through all five pulse trains by hand and remove everything below 100. All of a sudden a pattern appeared: The beginning was similar, also the end. But in the middle things were sometimes different. I then tried and used "common sense" and lots of trial-and-error and finally arrived at a pulse train that contained only numbers in the 100-range, 200-range, 400-range, 700-range, 800-range and 1000-range. I then realized that the 100- as well as the 800-range appeared only in one of the five pulse trains, so I removed them too (as above: added them up). This gave me then four ranges for the signal numbers:
I averaged the numbers of every of the four ranges and got the following averages:
216,28    444,83    739,1    1031,6
and I believe that the Came code is written using four numbers close to these averages.

Finally, I was able at least to see something (I am not finished, I will go through the file again in the next days). Every single pulse regardless whether 200, 400, 700 or 1000 was preceded by exactly one 200-pulse. So if I substitute
"200 200" = A
"200 400" = B
"200 700" = C
"200 1000" = D

[EDIT]Later on it turned out that "200 200" does not seem to appear.[/EDIT]

I could write the code I found in the following way:
CCBACBCCD etc. pp.
Maybe this can help us to reengineer the Came protocol.
I am still struggling what the correct signal numbers are; until now I only know its ranges. It could be that averages are a bad choice (one very wrong value can distort too heavily). Therefore, I plotted a histogram of the numbers that appeared in the pulse trains (after removing noisy signal numbers below 100). Here it is:

.png   histogram.png (Size: 46.99 KB / Downloads: 11)
One can clearly see the smallest pulse signal number hovering around 220, the next around 450 and then the highest pulse numbers at 750 and 1025.

220 and 450 fit together if we take, for example 225*2=450. The next number 750 is more "difficult" because it is not a multiple of 220 or 225. The same with 1050. So if I am sending signals (transmitter not arrived yet) I will start with 220 and 440 and then I need to guess about ~ 750 and ~1050.

Another info: The transmitter from Came (model TOP-432EV) contains "4096 combinations". Since
4096 = 2^12
there must be a simpler solution. With my knowledge up to now I have far too much combinations.
It gets more complicated. As a Christmas present I got a new sender ;-) and I realized that although both open the garage in the same manner they are internally different. There are two versions of senders: TOP432EE (gray, old version; difficult to buy and often price-reduced) and TOP432EV (black, new version; sold everywhere now). Both have different footers:
  • gray uses the above ~23.200
  • black uses ~15.300
There is no >16.000 in a two second recording from the black sender!

From what I have seen until now the newer sender seem to produce less "noise" in the sense that the raw recordings are (much) shorter. I do not need to understand every sender so from now on I will concentrate on the black sender only. I hope that they use both the same encoding but this will be analyzed next.

PS Notice that there is also a Came sender that has a rolling code, for business use. I knew that my sender was not using a rolling code because I could clone it easily with a cheap $1-sender.
I think I now have the solution. Before I can present the details here are the next processing steps I did. I recorded 42 pulse trains from the black Came. I went through the numbers and "reduced" or eliminated every entry below 100 as described above ("noise elimination" or "finding pattern"). So I came up with 42 pulse trains (none of them checked under real conditions, so I might be on a complete wrong track...) with a length of 25 numbers plus the footer.

I realized that all of these numbers (except the footer) are from three ranges, as already mentioned:
  • between ~180 and ~240
  • between ~410 and ~490
  • between ~750 and ~850
  • between ~1070 and ~1150
Also, every number from the second, third or forth entry (i.e. 410 and above) and the footer is always preceded by a number from the first entry (say between 180 and 240).

In order to determine the precise value of the signal length I wanted to understand the shape or distribution of the error. I concentrated on the first entry (the numbers between 180 and 240), because there I have the highest amount of data: I have 546 of those numbers (42 pulse trains times 13 pulses in each train are preceded by a number between 180 and 240, makes 546). In my opinion the error arises from errors of the sender as well as the receiver and both should be independent. Also, the error should be symmetric: Meaning disturbances that increase the correct number should show up as often as disturbances that decrease the correct number.

So I plotted again a histogram of those 546 values. So many values should result in a stable distribution and this, more or less, turned out to be the case:

.png   histogramm of 200microsec.png (Size: 23.94 KB / Downloads: 9)
One can see two things. First, the distribution is symmetric. So taking the simple average should be fine in order to get the correct value (assuming all errors cancel in the end). Second, not all numbers show up, there are gaps in the distribution. I believe this has to do with the way my receiver works. I hope that this does not distort my average.

In the end I got a value of 217 (ignoring all decimals) for the length of the shortest pulse. I repeated this calculation for the other pulse lengths and came up with the following values: 455, 782, 1123 and the footer 15.449.

Came's decoding is based on those five numbers.

Remark 1: The gray sender has a different footer.
Remark 2: I think these are strange numbers. Imagine an engineer designing a new software: Why would he choose those values? I played a little bit and maybe the correct values are 222, 444, 777, 1110 and 15540. These values are in absolute terms less then 2,5% from the values I determined and they have the nice feature that their ratio is
Quote:222 : 444 : 777 : 1110 : 15540 = 1 : 2 : 3,5 : 5 : 70
Now, the final description. I am at a point where I need help from the forum. First I describe the signal. I will delineate the signal as a series of numbers and from the last post it is clear that we have only four numbers (plus footer) that are possible. I will use the averages I calculated, not the artificial but "nicer" numbers. Then I have two questions.

I realized that there are only three combinations that emerged in all remotes at hand (I had two black ones with two buttons each and one gray one with two buttons, => 6 different codes). Every possible combination will be denoted by the following variables:
  • A equals a 217 455 pulse
  • B equals a 217 782 pulse
  • C equals a 217 1123 pulse
  • <footer> always equals a 217 15.449 pulse
I will call every of those three/four variables a "pulse combination" because it is more than one pulse but less than one pulse train.

Remark 1: Notice that the 217 217 pulse that I called "A" in a former post does not appear as far as I can see. This was a mistake.

Remark 2: I will concentrate only on the black remotes. The gray ones have a slightly different pulse train (it is longer), a different footer and produce a signal that is much worse, i.e. full of noise. If you happen to have a gray remote: get a black one.

Came sends 12 pulse combinations and then the footer pulse combination. So a complete pulse train could be, for example, written as
In all two black remotes (with both buttons) BBB were the first three pulse combinations. Is that a coincidence? In the gray remotes only BB were the first two pulse combinations, then an A appeared. The right button was in all three remotes decoded by an AC at the end (as in the example), the left button was decoded as BA at the end.

I was not able to see any repetitions or other duplicate entries here. So it seems that one pulse train of the Came signal is build using 12 variables out of three possibilities (A, B, C). What I do not understand is the following: Came says that they have "4096 possible combinations for their remotes" (exact citation!). With 12 positions this would be a perfect fit if not three, but two variables were possible: 2^12=4096. But with three choices there are much more combinations (namely 3^12=531441). Given that they were so proud to print the strange 4.096 number in their glossy brochure instead of saying "much more than 4.000 combinations are possible" (which would be perfectly fine for 99% of all customers) I am puzzled. Am I overlooking something? Or is anything hardwired here, for example that the second variable can only by B or A and not C (why?). This is my first question to you. Anyone with a Came who can test that?

My second question: How can we build a protocol based on that information? What can I do to help you?

Happy Christmas!
Have you been able to send the raw pulses back with pilight-send?

Possibly Related Threads...
Thread Author Replies Views Last Post
  Chamberlain Garage Door Opener Alex 13 6,494 01-01-2020, 01:57 AM
Last Post: clona
  [Solved] Quigg GT-1000 leaving transmitter ON VrahoK 11 1,444 12-22-2019, 12:17 AM
Last Post: VrahoK
Lightbulb [Fully Supported] Kaku Door sensor (AMST-606) geerttttt 53 29,419 10-19-2019, 06:26 PM
Last Post: curlymo
  KAKU Door contact (AMST-606) patrick van der tol 19 9,441 02-28-2017, 12:51 AM
Last Post: wo_rasp
  [SOLVED] Home Confort - Emulate TEL-010 or TEL-100 remote control xvolte 2 2,812 03-18-2016, 07:21 PM
Last Post: xvolte
  Rolling code garage door artas182x 4 2,867 08-16-2015, 01:02 PM
Last Post: artas182x
  Conrad/Skylink WD-101 door contact toomsec 0 1,953 02-14-2015, 02:53 PM
Last Post: toomsec
  ds10a door/window sensor kroonen 2 2,568 11-26-2014, 01:52 PM
Last Post: curlymo
  DI-O door switch yelti 12 6,757 01-29-2014, 09:22 PM
Last Post: yelti
  Ninja Blocks 433mhz Door Open Sensor scorpydude 4 4,240 12-09-2013, 10:23 AM
Last Post: scorpydude

Forum Jump:

Browsing: 1 Guest(s)