Maker Pro
Maker Pro

How can i decode the IR protocol from these details?

wouder1

Jan 16, 2020
2
Joined
Jan 16, 2020
Messages
2
From below, response get from IR receiver (using Arduino library )

could you please help me decode the protocol formate?

thanks.

Timestamp : 000657.493 Library : v2.7.2

Protocol : UNKNOWN

Code : 0xB4C0FCA9 (129 Bits)

uint16_t rawData[257] =

{
462, 1044, 474, 532, 472, 1016, 492, 532, 472, 532, 448, 1038,
492, 514, 490, 1010, 462, 544, 490, 1014, 450, 558, 416, 1090, 474, 1012, 490, 516, 492, 1008, 418, 590, 462, 544, 492, 514, 584, 440, 472, 532, 536, 474, 462, 538, 446, 560,
416, 590, 462, 548, 492, 516, 464, 560, 434, 570, 444, 556, 466, 538, 416, 588, 462, 544, 490, 1014, 472, 534, 462, 548, 486, 518, 492, 514, 492, 536, 560, 440, 468, 534,
472, 532, 416, 590, 462, 544, 492, 514, 492, 532, 472, 532, 472, 532, 472, 532, 444, 560, 416, 590, 486, 520, 490, 516, 490, 534, 470, 538, 446, 554, 470, 534, 416, 590,
462, 544, 490, 516, 492, 534, 470, 534, 470, 534, 470, 534, 470, 536, 416, 590, 462, 544, 490, 516, 490, 534, 470, 534, 470, 534, 470, 534, 418, 588, 460, 546, 488, 518,
490, 536, 470, 532, 472, 534, 470, 534, 468, 536, 416, 590, 462, 548, 486, 520, 492, 478, 518, 536, 470, 534, 470, 534, 416, 588, 460, 546, 490, 518, 490, 534, 470, 534,
470, 534, 470, 534, 444, 560, 416, 600, 454, 544, 490, 518, 488, 538, 470, 530, 468, 536, 470, 536, 416, 590, 434, 578, 482, 520, 490, 534, 470, 536, 474, 528, 470, 538,
458, 542, 416, 592, 460, 546, 490, 518, 488, 538, 470, 536, 444, 556, 446, 560, 442, 562, 482, 530, 476, 530, 478, 544, 462, 540, 468, 536, 468, 536, 466, 538, 416, 590,
436, 570, 488, 518, 488, 536, 468
};
 

Harald Kapp

Moderator
Moderator
Nov 17, 2011
13,700
Joined
Nov 17, 2011
Messages
13,700
What are these? Analog values? I think they are. Usually one would expect digital values for a protocol. Can hese values be digitized in a simple way (e.g. < 500 = low, >= 500 = high)?
What is the time scale?
Which Library v2.7.2 do you use?
What type is the IR sender (make, model)? This information wil greatly help to reduce the number of possibilities.
 

wouder1

Jan 16, 2020
2
Joined
Jan 16, 2020
Messages
2
What are these? Analog values? I think they are. Usually one would expect digital values for a protocol. Can hese values be digitized in a simple way (e.g. < 500 = low, >= 500 = high)?
What is the time scale?
Which Library v2.7.2 do you use?
What type is the IR sender (make, model)? This information wil greatly help to reduce the number of possibilities.


The raw data is the duration of successive marks and spaces in microseconds.
I am using the library IResp8266-master from GitHub. https://github.com/crankyoldgit/IRremoteESP8266
IR transmitter is mounded in an unknown modem.
 
Last edited:

Fish4Fun

So long, and Thanks for all the Fish!
Aug 27, 2013
481
Joined
Aug 27, 2013
Messages
481
@wouder1

There are several basic IR protocols and each of these basic protocols can have a myriad of variations ... Most major Electronics companies (ie Sony, RCA, Phillips etc) tend to use a base protocol across a wide range of devices, some include device specific headers, redundancy checks, and other information. More generic devices tend to go with a "bare bones" approach using a simple Start Bit xx data bits + 1 Stop Bit packet with no regard to interference with other devices or remotes.

Before you start down the rabbit hole, you need to make 100% certain you really need to "decode the format" .... AND .... Should you answer "yes", you need to accept **before you start** that it will be virtually impossible to fully decode all of the protocol from a limited number of samples. For example: If your device only uses 64 codes in a 10-bit data packet then all you can know for 100% certain is what 64 of the possible 1024 codes mean ... that is the best possible outcome would be "decoding" 6.25% of the protocol.

That being said, if you only "need" the 64 codes that your device actually uses then you really don't need to "decode" the protocol at all. All you need to do is "sample" each of the 64 codes and map them to the corresponding function. The numbers you posted are "Timer Values" that correspond to "On" & "Off" periods.

Most IR remotes operate with a carrier frequency between 20kHz and 40kHz. 33kHz implies a carrier signal of roughly 15uS "On" and 15uS "Off" ... Common IR Receiver modules use an analog filter tuned to the carrier frequency to create a constant "Low" output when the carrier is present, and a constant "High" output when the carrier is NOT present. To properly discriminate against ambient IR noise most IR signals select a minimum pulse width of > 10 carrier cycles .... in this case 33kHz >> 1 cycle = 30uS .... 30uS * 5 Cycles would imply a minimum pulse width of 150uS. (Your packet was 129 bits with a total packet time of 66.938mS making the average bit length 518.9uS).

462, 1044, 474, 532, 472, 1016, 492, 532, 472, 532, 448, 1038,

So, working from your data, the Arduino reported the minimum pulse period to be ~462 "clocks" ..... 150uS * 16Mhz = 2400 Arduino Clks. Since your data reports 462, we need to determine the most likely Clock Divider employed by the Arduino library .... 2400/462 = 5.19 .... So it would seem the most likely candidate is Clk/8 .... This would imply that the ACTUAL minimum pulse width is:

(8/16,000,000) * 462 = 231uS.

Next it is important to note that the longest pulse width in this packet is 1090 ....

(8/16,000,000) * 1090 = 545uS

Looking @ the packet it is reasonable to assume the various bits ("Start" | "1" | "0" | "Stop") repeat in some logical pattern and, likewise are "grouped" in some logical pattern containing some elements like : "Pre-Amble", "Device ID", "Instruction Id", "Data", "CRC", "END" etc, etc.

It is also important to remember that the 500nS resolution of the Arduino combined with the inherent imprecision of the analog filter in the IR Rx module being used may obfuscate details otherwise seemingly "obvious". By this I mean that if the IR module being used is designed for a 25kHz carrier frequency and the IR Remote uses a 40kHz carrier frequency the 500nS precision of the Arduino Timer will tend to High Light the marginal compatibility making it difficult to "see patterns" by just looking at numbers ...

To that end I "filtered" your data by dividing it by 30 and rounding to the nearest integer. Why 30? The results seemed "better" than 20, 25, 33, 36 or 50 ;-) Here are the results:

Code:
15    35    16    18    16    34    16    18    16    18
15    35    16    17    16    34    15    18    16    34
15    19    14    36    16    34    16    17    16    34
14    20    15    18    16    17    19    15    16    18
18    16    15    18    15    19    14    20    15    18
16    17    15    19    14    19    15    19    16    18
14    20    15    18    16    34    16    18    15    18
16    17    16    17    16    18    19    15    16    18
16    18    14    20    15    18    16    17    16    18
16    18    16    18    16    18    15    19    14    20
16    17    16    17    16    18    16    18    15    18
16    18    14    20    15    18    16    17    16    18
16    18    16    18    16    18    16    18    14    20
15    18    16    17    16    18    16    18    16    18
16    18    14    20    15    18    16    17    16    18
16    18    16    18    16    18    16    18    14    20
15    18    16    17    16    16    17    18    16    18
16    18    14    20    15    18    16    17    16    18
16    18    16    18    16    18    15    19    14    20
15    18    16    17    16    18    16    18    16    18
16    18    14    20    14    19    16    17    16    18
16    18    16    18    16    18    15    18    14    20
15    18    16    17    16    18    16    18    15    19
15    19    15    19    16    18    16    18    16    18
15    18    16    18    16    18    16    18    14    20
15    19    16    17    16    18    16

With only a single sample and NO information about the type of device the IR signal is designed to communicate with there is little more that can be done. With information about the remote's purpose AND a much larger group of samples it should certainly be possible to define the protocol within the constraints of the samples provided ... that is, as few as three or four samples should expose any preamble and/or header .... A half a dozen samples should expose the bit definitions and the packet length ... determine if the protocol sends compliment packets and/or Parity bits / CRC nibble/byte.

Sadly, the best that any of this can do is map a specific bit pattern to a specific key press .... You could just as easily achieve that goal by dividing your data samples by 8 and then simply using an Arduino based timer to enable/disable a 30kHz signal to an IR LED at the following Clk/64 intervals:

Code:
58    131    59    67    59    127    62    67    59    67
56    130    62    64    61    126    58    68    61    127
56    70    52    136    59    127    61    65    62    126
52    74    58    68    62    64    73    55    59    67
67    59    58    67    56    70    52    74    58    69
62    65    58    70    54    71    56    70    58    67
52    74    58    68    61    127    59    67    58    69
61    65    62    64    62    67    70    55    59    67
59    67    52    74    58    68    62    64    62    67
59    67    59    67    59    67    56    70    52    74
61    65    61    65    61    67    59    67    56    69
59    67    52    74    58    68    61    65    62    67
59    67    59    67    59    67    59    67    52    74
58    68    61    65    61    67    59    67    59    67
59    67    52    74    58    68    61    65    61    67
59    67    59    67    59    67    59    67    52    74
58    69    61    65    62    60    65    67    59    67
59    67    52    74    58    68    61    65    61    67
59    67    59    67    59    67    56    70    52    75
57    68    61    65    61    67    59    66    59    67
59    67    52    74    54    72    60    65    61    67
59    67    59    66    59    67    57    68    52    74
58    68    61    65    61    67    59    67    56    70
56    70    55    70    60    66    60    66    60    68
58    68    59    67    59    67    58    67    52    74
55    71    61    65    61    67    59

Why Clk/64 ??? It is "close enough" and allows all of your data to be 1 byte rather than 2 .... So, if you simply create a table with all of the salient keys "mapped" to tables like the above then you can Rx/Tx without any need to "decode" anything. If it turns out the first XX bits are common to all of the salient keys, you can reduce the "preamble" to a single table and then simply vector to the key-specific table values at the end of the preamble ....

Hope it helps!

Fish
 

Nanren888

Nov 8, 2015
622
Joined
Nov 8, 2015
Messages
622
So, to attempt to summarise:
Blind reverse-engineering of the timing will be difficult, but with soem context info it could be do-able.
What is the source? What type of thing is the source? Type of appliance? Modem, idea ot communication rate? Brand of product?
Any idea of the timing settings of your arduino listener?

.
 

Nanren888

Nov 8, 2015
622
Joined
Nov 8, 2015
Messages
622
irDecode001_raw.png
Having the timing settings makes it easier to guess how to round things. The actual protocol probably only has a few times, manual delays, frame, bit, maybe mark and space.
OK attempt top insert a .png failed.
 

Fish4Fun

So long, and Thanks for all the Fish!
Aug 27, 2013
481
Joined
Aug 27, 2013
Messages
481
The raw data is the duration of successive marks and spaces in microseconds.

I missed this second post .... If the timings are already in Micro Seconds then my numbers are off by 1/2, but the general advice and approaches remain sound.

As Nanren888 suggests, there is almost certainly a "single value" used to derive all of the various bit timings. For instance Base Time = 60uS:

BT = 60uS

Begin Transmission = BT x 8 = 480uS (Low)
Start Bit = BT x 3 (Low)
Timing Pulse = BT x 2 (High)
Data Pulse 0 = BT x 4 (Low)
Data Pulse 1 = BT x 5 (Low)
Stop Bit = BT x 6 (Low)
End Transmission = > 16 x BT (High)

Protocol Rules:
All Bits Except the "Start Bit" are Preceded by a "Timing Pulse" ....

Code:
Example $A55A :
480, 120, 180, 120, 300, 120, 240, 120, 300, 120, 240, 120, 240, 120, 300, 120, 240, 120, 300, 120, 360
120, 180, 120, 240, 120, 300, 120, 240, 120, 300, 120, 300, 120, 240, 120, 300, 120, 240, 120, 360
120, 960

***************************************************************************
Below is the numbers replaced with their definitions ...
***************************************************************************

BeginT, TP, Start, TP, 1, TP, 0, TP, 1, TP, 0, TP, 0, TP, 1, TP, 0, TP, 1, TP, Stop
TP, Start, TP, 0, TP, 1, TP, 0, TP, 1, TP, 1, TP, 0, TP, 1, TP, 0, TP, Stop
TP, EndT

***************************************************************************
Below is the numbers replaced in the same manner as the OP's Data was replaced in my previous post ... 
***************************************************************************
Packet Time: 0.00936 Seconds
16    4    6    4    10    4    8    4    10    4    8    4    8    4    10    4    8    4    10    4    12
4    6    4    8    4    10    4    8    4    10    4    10    4    8    4    10    4    8    4    12
4    32

My point here is that with a priori knowledge about the Protocol it is very easy to generate "clean data", but even with "clean data" it could prove more than a little difficult to extract the protocol.

Thankfully in most cases nothing about the protocol needs to be understood to reliably copy any given function ... All one needs is a table of "on" / "off" times for each function ... an error of up to +/- 20% will generally prove perfectly adequate.

Hope it Helps!

Fish
 
Top