rc-switch
rc-switch copied to clipboard
sui77
CAME protocol
How can I read and send data for the garage gate using this library?
In the screenshot the code is 3557
Check issue https://github.com/sui77/rc-switch/issues/103 That works with Raspberry pi and ESP8266 (it might fail with Arduino). Press your remote buttons long enough and very close to the receptor (3-5 seconds each). If you want to measure manually you need to measure in milliseconds in your plot: the width of the thin columns the width of the thick columns (apparently double than the thin) the width of the big silent gap.
then you write your protocol in the code: { thin width, { big gap/thin width, 1 }, { 1, 2 }, { 2, 1 }, true }
Your code is: 000110010010110111100101 or 111001101101001000011010 (I am not very familiar with inverted protocols)
If my universal receiver does not provide a suggestion, you already now how to view and measure the signal, so record and compare what you produce with what you want to get. Please report your advances, successes and failures. Best luck.
Your should allow the library to deal the timings for you instead of hard-coding them in your function. try sending codes: 1650149 or 15127066 (check if I converted the binary codes correctly) with the functions: setProtocol(7) and send(1650149, 24) or send(15127066, 24)
I suggest that your record the signals after these two commands, and compare those signals to your original one. That can lead to the correct path.
When you succeed, that you will, please describe in detail your brand and model. Maybe even with photographs or links to seller. It would be great if your could open your original remote and report which chipset it uses.
How can I read and send data for the garage gate using this library?
So. Did you successfully detect your signal? (using the examples) Did you generate and send data successfully? (with the send function - also in the examples) If not, what are you trying to achieve?
Please note that the right part of the code: 000110010010-110111100101 (1650149) is exactly 3557
try this protocol: { 299, { 74, 1 }, { 1, 2 }, { 2, 1 }, true } this should work with sui77's rc-switch in Arduino for both, sending and receiving codes.
I have found that my branch may not work in Arduino, although it does in RPi and ESP (thank you for testing and demonstrating that it works in RPi). I need to improve the output (it is in my roadmap). I suspect that the problem is with variable lengths. May I ask you to test this new code (for my branch) in Arduino (I do not have one and I cannot test). removed There, all ints were substituted for longs in the function: bool RECEIVE_ATTR RCSwitch::receiveProtocol(const int p, unsigned int changeCount) but I think not all ints need to be replaced. May be, if this code works for you you could try int by int to see which one was causing problems and thus helping me in debugging the code. Thanks in advance.
line 738 should read: const Protocol &pro = proto[i-1]; I just patched it a couple of days ago. but that line only applies to ESP8266. It should not even be read when compiling for Arduino.
Then my code, the one in the repository, not the one in the zip, definitely works. Anyway, try sui77's library with the protocol I wrote 3 comments ago.
Change this line: line 738 should read: const Protocol &pro = proto[i-1]; Just use the one in the repository, not the one in the zip. Note that the code downloaded in the RPi bundle may be linked to a previous commit, and not to the last one, the one I patched for ESP. Anyway, this change was the only one in that commit.
I assume that you are using my fork. The recognition loosely tries to match with a protocol. That algorithm is not exact. In fact the fork is about recognizing without protocol. In addition, I did not implement (yet) recognizing inverted protocols, and yours is. Also, your protocol is not the one you wrote. It is this one: { 299, { 74, 1 }, { 1, 2 }, { 2, 1 }, true } // protocol 7 CAME To send codes, you will need to use protocol 7. If you use sui77's branch... does it recognize your signals as protocol 7?
Does SENDING with that protocol 7 get recognized by your socket? (you can test with any branch, as the sending part of the library is identical for both) A) If so, then may be your remote emits with quite a lot of irregularity in the lengths (long ups 530-570, long downs 550-620, short ups 285-385, short downs 295-365) and sui77's library is quite stringent with respect to that. Just use my branch for receiving and check for your code. Ignore the protocol when receiving. B) If not recognized by your socket, please record the signal sent by rc-switch with that protocol 7, like in your initial post, to compare the original remote signal and this "synthetic" one, to search for differences.
I'm trying to set a new protocol into RCswitch.cpp in order to receive 13 bit code.
The type of code is 13 bit ( bit start = 0 , 10 bit of code , bit stop = 0 , bit stop =1). BIT 0 = 300µs , BIT 1 = 600µs. example : 0 1000010101 01
How should be the protocol? Is it possible to make one? Thank you
@giangel84 rc-switch does not look like the library you need (or you did not record/describe the signal adequately). This question does not belong here. It is a different issue. Show a recorded signal in a new issue. Have you tried the above links to automatically recognize the signal?
Yes I tried but I managed to receive only codes from other RC remote control, not mine that is a TOP434EV (CAME 4 channel remote). I will get an Logic signal analyzer to understand my signal's logic and will try again.
I have a CAME board with RF receiver and TAM432SA remotes. I'll try to use the information here to decode it. I have Arduino and ESP8266 (Node MCU) boards to try.
I've used Martin's library to receive and this is what I got. Proposed protocols only work in very short range (antenna included). Any idea?
Received 12490478 / 24bit Protocol: 0 data bits of pulse train duration: 22604 proposed protocol: { 314, { 73, 3 }, { 1, 2 }, { 2, 1 }, true }
first level down 22824 824 508 492 440 444 488 376 556 360 568 356 580 384 548 424 236 744 508 460 200 816 164 696 544 368 300 684 568 376 552 420 236 724 532 428 500 396 536 440 212 684 572 388 536 340 600 336 316 668
==== Received 16684782 / 24bit Protocol: 0 data bits of pulse train duration: 22836 proposed protocol: { 317, { 72, 3 }, { 1, 2 }, { 2, 1 }, true }
first level down 22820 824 560 404 552 408 544 396 560 368 588 380 576 392 548 432 244 700 532 476 192 768 192 716 516 408 256 672 564 400 556 412 248 684 568 380 556 392 564 372 308 676 560 364 588 376 564 384 296 644
==== Received 16684782 / 24bit Protocol: 0 data bits of pulse train duration: 22660 proposed protocol: { 315, { 73, 3 }, { 1, 2 }, { 2, 1 }, true }
first level down 22868 824 616 328 596 324 608 320 616 312 616 312 620 320 612 336 328 652 600 312 348 724 252 632 620 324 336 672 572 336 596 324 328 636 620 312 620 312 620 316 344 624 624 308 624 300 628 304 360 616
==== Received 16684782 / 24bit Protocol: 0 data bits of pulse train duration: 22648 proposed protocol: { 315, { 72, 3 }, { 1, 2 }, { 2, 1 }, true }
first level down 22836 828 564 400 528 416 520 344 580 352 580 364 572 348 584 376 284 728 520 372 288 700 280 656 588 404 260 728 520 420 512 368 288 724 528 364 568 352 576 380 284 696 548 368 568 344 584 332 332 656
==== Received 16684782 / 24bit Protocol: 0 data bits of pulse train duration: 22596 proposed protocol: { 314, { 73, 3 }, { 1, 2 }, { 2, 1 }, true }
first level down 22828 824 500 376 556 364 564 420 512 348 588 364 564 348 580 376 284 640 608 380 284 644 332 680 576 332 324 652 600 352 576 388 272 728 516 388 548 428 504 356 304 700 548 380 552 348 584 376 284 668
====
@CarlosLB use https://github.com/sui77/SimpleRcScanner record the signals that you generate and those from the original transmitter: compare those signals. You will see whether there are timing differences. If they aren't. You could try to send more repeats (default is 4). Check that your antenna is in the correct pin.
I have a 12-bit CAME TOP 432NA programmable transmitter and well working SENDING code:
#define txPin 3
#define Te 320
void setup(){
Serial.begin(9600);
Serial.println("Came send...");
pinMode(txPin, OUTPUT);
SendCame(3333); //for example code is 3333 (variants are from 0 to 4095)
Serial.println("success");
}
void loop(){
}
void SendCame(unsigned long code){
for (int j=0;j<10;j++) {
//Start impulse
digitalWrite(txPin,LOW);
delayMicroseconds(Te*36);
digitalWrite(txPin,HIGH);
delayMicroseconds(Te);
//Sending every bit
for (byte i=12;i>0;i--){
byte b = bitRead(code, i-1);
digitalWrite(txPin,LOW);
delayMicroseconds(Te);
if (!b) digitalWrite(txPin,HIGH);
delayMicroseconds(Te);
digitalWrite(txPin,HIGH);
delayMicroseconds(Te);
}
digitalWrite(txPin,LOW);
delay(16);
}
}
And I want to add support of CAME to RCSwitch library. I added to RCSwitch.cpp this code:
{ 320, { 36, 1 }, { 1, 2 }, { 2, 1 }, true }, // protocol 7 (Came) Holtek HT-12E
{ 700, { 36, 1 }, { 1, 2 }, { 2, 1 }, true } // protocol 8 (Nice) Holtek HT-12E
but CAME transmitter (and CAME receiver too) don't receive the code :(
mySwitch.setProtocol(7);
mySwitch.send(3333, 12);
Could you please explain me, why in "Send" procedure first is the sendind code, and the second is the sending Sync bit? I think this shoud be contrariwise. I found a solution:
void RCSwitch::send(unsigned long code, unsigned int length) {
if (this->nTransmitterPin == -1)
return;
#if not defined( RCSwitchDisableReceiving )
// make sure the receiver is disabled while we transmit
int nReceiverInterrupt_backup = nReceiverInterrupt;
if (nReceiverInterrupt_backup != -1) {
this->disableReceive();
}
#endif
for (int nRepeat = 0; nRepeat < nRepeatTransmit; nRepeat++) {
if (this->protocol.pulseLength == 320 || this->protocol.pulseLength == 700) this->transmit(protocol.syncFactor);
for (int i = length - 1; i >= 0; i--) {
if (code & (1L << i)) this->transmit(protocol.one); else this->transmit(protocol.zero);
}
if (this->protocol.pulseLength != 320 && this->protocol.pulseLength != 700) this->transmit(protocol.syncFactor);
}
#if not defined( RCSwitchDisableReceiving )
// enable receiver again if we just disabled it
if (nReceiverInterrupt_backup != -1) {
this->enableReceive(nReceiverInterrupt_backup);
}
#endif
}
Now RCSwitch sends CAME code. But I want to receive CAME code with RCSwitch. I've tried different "Sync bit length", "SeparationLimit" and "ReceiveTolerance", but there is no effect. Do you know how? Here is working receiveing code:
#define RX 2
#define CM_MAX_TE 500
#define CM_MIN_TE 200
#define CM_BITS12 12
#define CM_BITS24 24
volatile byte level = 255;
volatile unsigned long last, len;
byte p_level;
byte b;
unsigned long p_len, p_len_prev;
struct {
byte state;
byte dat_bit;
unsigned long data;
} came;
void process_came() {
unsigned char b;
switch(came.state) {
case 0:
if(p_level) break;
came.state = 1;
break;
case 1: //start
if(!p_level) break;
else if(p_len >= CM_MIN_TE && p_len <= CM_MAX_TE) {
came.state = 2;
came.dat_bit = 0;
came.data = 0;
}
else came.state = 0;
case 2: //dat
if(p_level) {
if(came.dat_bit == CM_BITS24) {
came.state = 0;
break;
}
if(p_len_prev <= CM_MAX_TE && p_len_prev >= CM_MIN_TE && p_len <= CM_MAX_TE*2 && p_len >= CM_MIN_TE*2) b = 0;
else if(p_len_prev <= CM_MAX_TE*2 && p_len_prev >= CM_MIN_TE*2 && p_len <= CM_MAX_TE && p_len >= CM_MIN_TE) b = 1;
else {
came.state = 0;
break;
}
came.data <<= 1;
bitWrite(came.data, 0, b);
came.dat_bit++;
break;
} else {
if((p_len > 5000) && (came.dat_bit == CM_BITS12 || came.dat_bit == CM_BITS24)) came.state = 3;
}
break;
}
}
void rx_int() {
if(level != 255) return;
len = micros() - last;
last = micros();
if(digitalRead(RX) == HIGH) level = 0; else level = 1;
}
void setup(){
attachInterrupt(0, rx_int, CHANGE);
Serial.begin(9600);
Serial.println("Came grabber");
interrupts();
}
void loop(){
if(level != 255){
noInterrupts();
p_level = level;
p_len = len;
len = 0;
level = 255;
interrupts();
process_came();
p_len_prev = p_len;
}
if(came.state == 3){
Serial.print(came.data);
Serial.print(" (");
Serial.print(came.dat_bit);
Serial.println(" bit)");
came.state = 0;
}
}
@Martin-Laclaustra hi, i've check working of your protocol on your branch, it still don't read CAME signal.
i have code for reading (and send) without libraries, could you pleace view and mayme be edit protocol 7 for CAME?
https://gist.github.com/superyarik/3eb4da9da728466c072e716532d732ef
any update please? I can not catch came remote with rc-switch simple/advanced receive
Hello @DarkDaemon1 the remote TOP432M is recognized... Received xxxx / 12bit Protocol: 6 data bits of pulse train duration: 12181 proposed protocol: { 339, { 34, 1 }, { 1, 2 }, { 2, 1 }, true }
Nothing for the remotes TOP432NA/TOP432EE and above.
Hi, I can confirm that the addition of { 320, { 36, 1 }, { 1, 2 }, { 2, 1 }, true } protocol allows me to control my CAME gate using TOP432M. Could this and the other protocols above be added to the library?
I attempted to perform this action on my CAME gate 5 years ago and didn't have the skills and/or commitment to decode the signal. Am so happy someone has figured this out. Fantastic work
Hi, yes you can submit a PR with them if you are at least 2 confirming they are working.
I have successfully cloned TOP432EV code using 433 receiver and sound card.
Here is the code https://github.com/Benas09/came/blob/master/remote.ino
As far I have only one distinct code, i can not make function universal.
I send code 1011101101011011010100011 Firmware from http://skproj.ru/otkryt-shlagbaum-came/ shows that my code is 1699 (011010100011 in binary). So I dont know if first part of code is unique or not.
EDIT: I have added functionality to read code. You can give it a try. It will print two possible codes (first digit can be 0 or 1, try to send both)
I have two TOP432NA remotes which are read with RX-470C-V01 (WL-101) receiver and the sketch/program/code from http://skproj.ru/otkryt-shlagbaum-came/ read left buttons as 1039 (yes, both) and right buttons as 1115 and 281, respectively. I've managed to emit successfully the same codes with my transmitter (WL-102) (with the sketch from the URL above) and a barrier has accepted them (hurah!). Then I've decided to use rc-switch library only (I want to send two different codes (for different gates) with the same single codebase) and I've tried to reproduce the same signals with it. I have got the success with the 'builtin' protocol 11 (as a my receiver sometimes decodes signal emitted with my transmitter (not a remote) with that protocol ID) - the barrier accepts signal sent but my receiver does not decode the original TOP432NA remote's signal with that protocol (nor any protocol).
So, I've tried @Martin-Laclaustra's (big thanks!) ProtocolAnalyzeDemo.ino, it has suggested
{ 323, { 45, 2 }, { 1, 2 }, { 2, 1 }, true } parameters, and voi-la! Now, my receiver decodes both the original's remote and my transmitter's signals!
