433 mhz - decoding receieved signal

[CAPTB]

Hi there,

I am in the process of decoding signals from a 433mhz remote to control some rf-sockets from my Arduino MEGA. I am using the rc-switch library. My remote is able to control 5 channals (A-E). Each channal has a button to turn ON and a button to turn OFF. The rf sockets have 'auto-learning' feature, so no dip-switches.

I have succeeded connecting the 433 mhz receiver to my Arduino and have decoded the signal for channal A when the ON button is pressed. This is where I have some questions.

• My signal is 32 bits long. How do I know which bits are address bits and which are data bits? Are there any thumb rules to determine how the signal is constructed?

• When pressing the ON button for channal A I get different variations of the signal. Why is this happening? I thought that the signal for button A ON would always be the same. When the signal differs, how do I know which one to pick for transmitting from my Arduino?

The signal variations when pressing the ON button for channal A is seen below.

I hope somebody would be willing to help a newbie

Best wishes,

Decimal: 3158573056 (32Bit) Binary: 10111100010001000000000000000000 Tri-State: not applicable PulseLength: 710 microseconds Protocol: 2
Raw data: 7136,1368,600,380,1588,1368,616,1352,616,1356,608,1360,620,368,1596,372,1604,364,1604,1352,612,372,1588,384,1592,380,1588,1368,596,388,1584,388,1580,388,1580,1380,592,1376,600,380,1588,1372,596,1376,596,392,1572,1380,612,1352,608,388,1572,396,1572,1380,592,392,1576,392,1576,1384,240,28,280,

Decimal: 2567699155 (32Bit) Binary: 10011001000010111111101011010011 Tri-State: not applicable PulseLength: 711 microseconds Protocol: 2
Raw data: 7148,1356,624,360,1600,368,1616,1336,608,1372,596,388,1580,392,1580,1372,612,372,1584,388,1580,388,1584,388,1576,1384,592,388,1580,1376,600,1372,592,1372,596,1376,600,1364,612,1360,612,1356,612,376,1588,1368,608,380,1592,1360,600,1372,600,384,1588,1368,612,368,1592,380,1592,1360,608,36,224,

Decimal: 3158601107 (32Bit) Binary: 10111100010001000110110110010011 Tri-State: not applicable PulseLength: 708 microseconds Protocol: 2
Raw data: 7136,1380,588,396,1584,1368,596,1380,588,1376,600,1364,616,372,1596,376,1588,384,1584,1368,612,376,1584,388,1584,384,1580,1376,600,388,1580,384,1580,392,1588,1368,596,1376,604,380,1588,1372,600,1364,596,392,1572,1380,604,1372,588,400,1576,384,1584,1376,68,40,228,112,44,44,96,184,236,

Decimal: 2567699155 (32Bit) Binary: 10011001000010111111101011010011 Tri-State: not applicable PulseLength: 714 microseconds Protocol: 2
Raw data: 7196,1320,640,340,1636,336,1632,1320,652,1324,640,340,1628,344,1636,1316,644,340,1620,356,1620,344,1616,360,1620,1332,648,332,1628,1332,632,1340,640,1316,652,1320,648,1324,656,1316,644,1320,660,328,1640,1316,660,324,1628,1324,656,1312,660,328,276,56,340,432,52,348,76,92,60,264,16,

Decimal: 3158601107 (32Bit) Binary: 10111100010001000110110110010011 Tri-State: not applicable PulseLength: 712 microseconds Protocol: 2
Raw data: 7204,1304,656,328,1648,1304,668,1304,672,1296,668,1304,660,480,1020,488,260,1236,1024,480,1032,464,264,1244,256,1244,1236,264,1236,272,1228,280,2336,1032,484,256,1248,260,1236,1016,256,1236,1028,476,268,1232,1024,480,264,1236,264,1224,1032,276,1232,1032,476,1016,488,252,1256,1004,488,1020,476,

Decimal: 2567698944 (32Bit) Binary: 10011001000010111111101000000000 Tri-State: not applicable PulseLength: 712 microseconds Protocol: 2
Raw data: 7184,1328,636,348,1620,348,1616,1348,620,1344,636,348,1620,352,1632,1320,636,348,1620,352,1600,376,1604,368,1600,1356,616,372,1588,1360,640,1332,620,1344,636,1332,632,1336,628,1344,644,1328,628,360,1608,1344,628,360,1604,1344,1412,48,436,16,660,112,1112,48,96,196,196,44,204,136,124,

Decimal: 3158601107 (32Bit) Binary: 10111100010001000110110110010011 Tri-State: not applicable PulseLength: 710 microseconds Protocol: 2
Raw data: 7160,1344,644,336,1616,1344,632,1340,616,1352,624,1344,624,360,1612,356,1608,364,1608,1344,628,360,1596,376,1604,364,1600,1356,616,372,1592,376,1592,376,1612,1344,608,1356,632,356,1588,1368,608,1364,604,380,1596,1360,616,140,140,56,240,32,40,380,152,40,320,256,80,20,92,20,144,

Decimal: 2567699155 (32Bit) Binary: 10011001000010111111101011010011 Tri-State: not applicable PulseLength: 712 microseconds Protocol: 2
Raw data: 7164,1344,624,360,1604,368,1616,1340,616,1348,624,364,1616,352,1616,1340,624,360,1600,372,1600,368,1596,376,1600,1348,628,364,1596,1356,620,1352,612,1352,632,1336,632,1340,632,1340,628,1340,628,356,1612,1348,624,360,1612,1344,620,1344,636,352,536,16,444,56,40,504,100,296,28,56,324,

Decimal: 3158601107 (32Bit) Binary: 10111100010001000110110110010011 Tri-State: not applicable PulseLength: 712 microseconds Protocol: 2
Raw data: 7156,1356,616,368,1592,1364,616,1348,628,1340,628,1344,620,360,1616,356,1616,356,1600,1356,604,376,1600,372,1592,384,1604,1348,616,364,1592,376,1596,380,1588,1364,604,1364,608,376,1592,1360,612,1356,624,368,1592,1356,620,1348,624,368,1604,360,1604,1348,620,368,1600,84,116,24,108,52,20,

Decimal: 2567699155 (32Bit) Binary: 10011001000010111111101011010011 Tri-State: not applicable PulseLength: 711 microseconds Protocol: 2
Raw data: 7168,1340,632,352,1624,344,1624,1332,640,1328,656,332,1620,356,1608,1340,636,348,1612,364,1600,376,1596,364,1604,1352,624,364,1600,1356,612,1360,612,1352,632,1340,620,1352,620,1348,628,1340,636,352,1608,1344,632,352,1616,1336,632,1340,628,356,1620,1336,636,348,1608,364,72,52,296,596,16,

Decimal: 3158601107 (32Bit) Binary: 10111100010001000110110110010011 Tri-State: not applicable PulseLength: 710 microseconds Protocol: 2
Raw data: 7168,1336,612,376,1600,1352,620,1348,632,1336,640,1332,628,356,1608,364,1608,356,1616,1344,616,364,1604,372,1608,360,1596,1364,616,364,1600,372,1592,380,1584,1372,596,1372,604,380,1588,1360,632,1344,608,376,1592,1352,652,1308,1192,44,516,20,1144,392,24,552,24,356,16,16,244,56,24,

Decimal: 2567634944 (32Bit) Binary: 10011001000010110000000000000000 Tri-State: not applicable PulseLength: 712 microseconds Protocol: 2
Raw data: 7164,1348,628,356,1604,364,1604,1348,632,1336,632,356,1616,356,1604,1348,624,364,1616,352,1600,372,1596,376,1600,1352,620,360,1624,1332,620,1356,620,1344,632,1340,628,1340,628,1340,628,1344,620,368,1620,1332,636,344,1620,1336,632,1340,632,352,1612,1348,624,40,208,236,160,40,128,28,64,

Decimal: 3158600960 (32Bit) Binary: 10111100010001000110110100000000 Tri-State: not applicable PulseLength: 711 microseconds Protocol: 2
Raw data: 7156,1352,612,372,1592,1360,632,1336,616,1356,616,1352,624,360,1608,360,1608,368,1588,1364,628,356,1592,384,1588,380,1592,1356,628,356,1596,376,1592,376,1592,1360,620,1352,612,372,1608,1344,616,1356,624,364,1592,1360,632,1336,624,368,1596,368,1596,1360,220,24,520,396,32,476,32,20,180,

Decimal: 2567699155 (32Bit) Binary: 10011001000010111111101011010011 Tri-State: not applicable PulseLength: 711 microseconds Protocol: 2
Raw data: 7112,1388,584,404,1564,404,1572,1380,592,1380,588,400,1568,400,1572,1380,584,404,1576,392,1568,404,1560,408,1568,1384,588,400,1568,1384,584,1384,584,1388,588,1380,580,1392,584,1384,584,1384,592,396,1572,1380,592,396,1564,1388,592,1380,584,400,1572,1384,596,392,1568,400,1572,1380,592,1376,600,

Decimal: 3158601107 (32Bit) Binary: 10111100010001000110110110010011 Tri-State: not applicable PulseLength: 710 microseconds Protocol: 2
Raw data: 7116,1388,576,412,1560,1392,584,1384,588,1384,588,1384,580,404,1600,372,1560,408,1564,1392,580,408,1560,408,1568,404,1564,1388,576,408,1568,404,1556,412,1568,1388,576,1392,580,408,1568,1384,576,1396,580,404,1580,1376,584,1384,588,400,1568,400,1564,1388,584,404,1564,408,1572,1380,584,1388,596,

Decimal: 2567699155 (32Bit) Binary: 10011001000010111111101011010011 Tri-State: not applicable PulseLength: 710 microseconds Protocol: 2
Raw data: 7124,1376,588,400,1568,400,1568,1388,584,1384,584,404,1572,396,1572,1380,592,396,1564,408,1560,408,1576,396,1560,1388,588,404,1564,1384,580,1392,580,1388,580,1392,584,1384,592,1376,584,1388,592,396,1576,1376,596,388,1568,1384,600,1372,584,404,1564,1388,588,396,1572,400,1568,1384,588,1380,592,

Decimal: 3158601107 (32Bit) Binary: 10111100010001000110110110010011 Tri-State: not applicable PulseLength: 711 microseconds Protocol: 2
Raw data: 7112,1392,580,408,1576,1376,584,1384,588,1380,588,1384,584,404,1568,400,1568,404,1564,1388,584,404,1564,404,1568,404,1572,1380,588,400,1584,384,1564,408,1568,1384,580,1388,580,412,1560,1392,584,1384,592,396,1568,1384,584,1388,580,408,1564,404,1572,1388,576,404,1568,404,1564,1388,592,1376,592,

Decimal: 2567699155 (32Bit) Binary: 10011001000010111111101011010011 Tri-State: not applicable PulseLength: 710 microseconds Protocol: 2
Raw data: 7116,1388,588,396,1572,400,1568,1384,588,1380,588,400,1584,388,1568,1384,588,400,1576,392,1568,400,1576,396,1568,1384,584,404,1564,1388,580,1388,588,1384,592,1376,588,1384,584,1384,584,1388,588,396,1580,1376,584,400,1568,1384,584,1388,584,404,1564,1388,588,400,1568,400,1568,1384,596,1376,596,

[CAPTB]

This is how the remote looks.

[CAPTB]

By examining the signals a little more it seems like when a button is pressed, the signal generally has two variations of the signal that it transmits. This is the case for every button. The reason I say generally is that sometimes a new variation will pop up, but you have to press the button multiple times for that to happen, and then the two general variations is back. I do not understand why the signal is not uniform.

When e.g. the ON button is pressed the RF socket turns ON. But it does not turn off again when the on button is pressed. For this the OFF-button would have to be activated. So this is not why the variation occurs:

Channal A
On: 
Decimal: 3158601107 (32Bit) Binary: 10111100010001000110110110010011 Tri-State: not applicable PulseLength: 709 microseconds Protocol: 2
Decimal: 2567699155 (32Bit) Binary: 10011001000010111111101011010011 Tri-State: not applicable PulseLength: 710 microseconds Protocol: 2

Off:
Decimal: 4094859411 (32Bit) Binary: 11110100000100101001100010010011 Tri-State: not applicable PulseLength: 709 microseconds Protocol: 2
Decimal: 3077728467 (32Bit) Binary: 10110111011100100110100011010011 Tri-State: not applicable PulseLength: 710 microseconds Protocol: 2


Channal B:
On:
Decimal: 1546779861 (32Bit) Binary: 01011100001100011111110011010101 Tri-State: FF10010F11101FFF PulseLength: 710 microseconds Protocol: 2
Decimal: 225478549 (32Bit) Binary: 00001101011100001000011110010101 Tri-State: not applicable PulseLength: 709 microseconds Protocol: 2

Off:
Decimal: 162068181 (32Bit) Binary: 00001001101010001111011011010101 Tri-State: not applicable PulseLength: 710 microseconds Protocol: 2
Decimal: 3698581 (32Bit) Binary: 00000000001110000110111110010101 Tri-State: not applicable PulseLength: 712 microseconds Protocol: 2

[CAPTB]

Anybody have any clue?

I tried to use the rc-switch library to send the two general code variations for button A ON, however without success.

[Power_Broker]

Post your code in tags, please.

[CAPTB]

Hi Power_Broker,

Thank you for your answer.
This is what I tried to transmit:

#include <RCSwitch.h>

RCSwitch mySwitch = RCSwitch();

void setup() {

  Serial.begin(9600);
  
  // Transmitter is connected to Arduino Pin #10  
  mySwitch.enableTransmit(10);

  // Optional set pulse length.
   mySwitch.setPulseLength(710);
  
  // Optional set protocol (default is 1, will work for most outlets)
   mySwitch.setProtocol(2);
  
  // Optional set number of transmission repetitions.
  // mySwitch.setRepeatTransmit(5);
  
}

void loop() {
  /* Same switch as above, but using decimal code */
  mySwitch.send(3158601107, 32);
  delay(5000);  
  mySwitch.send(2567699155, 32);
  delay(5000);
}

The two codes are the two variations of the ON signal for channal A that I captured from the remote.
I first tried with just one, no luck. Then I added the other one, still no luck.
The protocol and pulse length is from the signals I captured.

My setup is like attached picture.

[jremington]

RF data transmission is not reliable, so you should never believe that every message you receive is "correct".

The RC-Switch protocols are for the most part described. Here is a list of known devices that are compatible with one library.

For decoding remote RF sensors in general, I use Audacity and a laptop, as described in this blog article.

[CAPTB]

Hi jremington,
Thank you for your reply.

I do not know what device is inside the remote, so I've worked from the thesis that since rcswitch is able to receive and show the signal from the remove in the serial monitor it is supported. Is that incorrect?

I have read through the article, however, what I am wondering is: you say that you use audacity to decode signals. What would the difference be using audacity or rcswitch to decode the signal? In both methods the same receiver is acting as the receiving device. Would it not be the same result? If not, why?

[jremington]

You need to read the article more carefully.

Audacity shows you what the signal looks like, and you have to decide on that basis which of the many possible signal types it is.

[CAPTB]

Yes, that I understand.

But what you are saying is that the signals decoded by rcswitch library are not correct - is that what I am hearing?

If that is the case I would like to know why that can be. By reading other articles I see that people are succesfully using rcswitch library to decode their remotes, and it is the same procedure I am using here.

[jremington]

Audacity shows you what the signal looks like, and you have to decide on that basis which of the many possible signal types it is.

[CAPTB]

Can you elaborate on the term 'signal types'? Are you refering to the fact that I generally get two different signals when one of the buttons is pressed?

I have tried to send both of the two general signal variations, however, without luck.

Are you suggesting that none of the two signals are correct? If so, my question is still: is the rcswitch not able to do the decoding correct since it seems like none of the two variations will trigger the rf socket? I am just wondering why since it seems like other users of the library have had succes just listening to the remote, have rcswitch receive the signal and then retransmit the exact same signal to the rf socket. It just does not work in this case.

[Joseph_hewitt]

CAPTB:
I have tried to send both of the two general signal variations, however, without luck.

Are you suggesting that none of the two signals are correct?

Sorry if this sounds patronising, that's not my intention:

Are you sure your RF transmitter is working and on the correct frequency? Also, is your transmitter corrected to the same pin as defined in your code? It sounds like the receiver could be working fine and the problem is with the transmitter instead.

Also, how close is your transmitter to the socket? Some of those transmitters have very short range, especially if you don't have an antenna on it.

[CAPTB]

Hi Joseph,

Thank you for your reply.

No need to pardon - I'm very new to Arduino, so all inputs are very welcome as I am very eager to solve this issue - and especially to learn what is going wrong so that I can draw on that knowledge for future projects

I have also thought of the transmitter as a possible place of error.
I searched google for a way to test it, however, it seems like you need two Arduinos to do that and I do only own one. I did try to put a digital multimeter (set to 200mv) to ground and on the data pin of the transmitter while a transmission was going on/off, and there seemed to be change in the readings, so I thought that it was an indication that the transmitter was working and transmitting. However, now I am not sure if it is even possible to do the test as described above?

The transmitter and reciever was bought together and both on the 433 mhz. It is similar to the set of the attached picture (don't mind the 315 mhz text on the picture - mine is 433). The transmitter is connected to my Arduino on digital pin 10 which is also declared in the code.

I tried to solder an antenna on the transmitter, however, without any difference. I also tried holding the transmitter so close to the rf socket that they touch, and that did not do any difference.

If that can be of any clue, I have now managed to take the remote apart. There is an IC, but without any numbers. There is also a little silver-colored box that might be the remote transmitter - not sure though. It reads 'NDR4208' and then with small font 'j4'. Please see attached pictures. I do not seem to be able to find any datasheet by googling it.

[jremington]

The point I was trying to make is that your remote may not send any of the recognized RCSwitch signal types. It may be a proprietary signal.

You have to carefully analyze the timing of the pulses and compare that to the timing for known signals to know if that is the case.

If you have a link to a website that claims to successfully imitate or receive signals from that exact same remote with the RCSwitch library, please post it.

[mauried]

The RCswitch protocol is very simple having only 3 states 1,0 and floating.
Its has no error checking of any kind as its main usage is for simple tasks like RC power points.
The protocol relies on multiple transmissions of the same data for the receiver decoder to
syncronise itself with the sync pulses at the end of each data field.
It wouldnt be hard at all to create a protocol that looks like Rcswitch but in fact isnt, which would give a decoded output that was nonsense.
You really need to pull apart either the transmitter or the receiver and try to identify the chips inside.
If you cant read any writing on the chips then count the pins and then look on the pin thats should be the data out if the chips a PT2262 or SC2262 as these are the most common
RCswitch compatible encoders.

[CAPTB]

Jremington,
Thank you for your reply. It was this kind of explanation which along with the post from mauried I was looking for in order to understand why using rcswitch to decode is not necessarily giving me the correct signal. I will look into trying to decode with audacity and get back.

I do not have any link from anybody claiming to be able to decode this exact remove as I have not been able to detect the chips (see post #13). I was just saying that I have read of other people succesfully using rcswitch to decode their remove signals and was confusing why it was not working in my case.

Mauried,
Thank you very much for your explanation. Very good background info!
Regarding the chip I tried pulling the remote apart, however, I have difficulties telling what it is. There is a black Ic with no text on it as well as a silver-colored box of a kind. Please see post #13 for pictures and a description. It could be that it is the silver colored box that is the transmitter, but I am not sure. Do you have a clue?

[mauried]

OK, the chip in the picture has only 14 pins so its not a SC2262 / PT2262.
One of the pins will be the data out, so try and find it and feed the output into Audacity or whatever you are using to display the code.
Its much better to get the code directly from the transmitter as theres no noise present in the data, so you get more consistant results.
The rectangular device could be a saw resonater to set the transmitters frequency.
They are usually round though and have 3 pins .

Its possible you have one of these types of encoders.
https://forum.arduino.cc/index.php?topic=178765.0

[CAPTB]

I managed to construct a reciever curciut to feed into the line-in jack port.
Using Audacity I tried to decode the signal for channal A when pressing the ON button. This is what I got:

001011100101100110100000100100010

That is 33 bits. Can that be correct?

When not pressing any button there is a lot of somewhat uniform noise.
Then, when pressing the button: the first part of the signal looks rather long and confusing. After that I see 4 signals divided by a long pause. Those four signals look rather similar. I decoded two of them and got the same code above.

I tried to measure the timing of those signals:

Short: 130 samples
Long: 482 samples
Long pause between the signals: 2712 samples

Audacity Hz: 384000

I do not, however, know how to use this timing information.

I tried to feed the signal into the RCSWITCH send-sketch, but without luck:

/*
  Example for different sending methods
  
  https://github.com/sui77/rc-switch/
  
*/

#include <RCSwitch.h>

RCSwitch mySwitch = RCSwitch();

void setup() {

  Serial.begin(9600);
  
  // Transmitter is connected to Arduino Pin #10  
  mySwitch.enableTransmit(10);

  // Optional set pulse length.
   //mySwitch.setPulseLength(710);
  
  // Optional set protocol (default is 1, will work for most outlets)
  //mySwitch.setProtocol(2);
  
  // Optional set number of transmission repetitions.
   mySwitch.setRepeatTransmit(5);
  
}

void loop() {
  /* Same switch as above, but using decimal code */
  mySwitch.send("001011100101100110100000100100010");
  delay(5000);  
}

I feel that I am getting closer - however, it still does not work.
Any inputs are greatly appreciated!

I have attached two screenshots from audacity. One shows the overall signal when the button is pressed along with the initial noise that is always there when the button is not pressed. The other one is more zoomed in and shows the initial confusing part of the signal along with 3 of the uniform signals following.

Red: noise that is always there when no button is pressed.
Blue: signal that appears when button is pressed.

[jremington]

That does not look at all like the PT2262 protocol to me. You have something different.

See this page for some different examples of protocols.