How to find native representation of BLUESTAR A/C message

[shubham-malasane]

hi,

I have Bluestar AC remote which is decoded as UNKNOWN protocol
for adding this protocol in library need information about native message representation of this protocol
how to get it

timing information share below

Timestamp : 018616.046
Library : v2.7.19

Tolerance : 27%
Protocol : UNKNOWN
Code : 0xAFFF4224 (106 Bits)
uint16_t rawData[211] = {5004, 4990, 534, 1488, 534, 1488, 534, 484, 534, 1488, 534, 484, 534, 1488, 534, 484, 534, 1496, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1496, 534, 1488, 534, 1488, 534, 482, 534, 1488, 534, 482, 534, 1488, 534, 1488, 534, 1496, 536, 482, 534, 484, 534, 1488, 534, 482, 534, 1488, 534, 1488, 534, 1488, 534, 1496, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 492, 534, 484, 534, 1488, 534, 1488, 534, 1488, 534, 482, 534, 1488, 534, 1488, 534, 1496, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 482, 534, 1496, 534, 484, 534, 484, 534, 484, 534, 484, 534, 1488, 534, 1488, 534, 1488, 534, 1496, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1496, 534, 484, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1496, 534, 484, 534, 484, 534, 484, 534, 484, 532, 1488, 534, 1488, 534, 484, 534, 492, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 1488, 534, 482, 534, 1496, 534, 1488, 534, 1488, 534, 484, 534, 1488, 534, 1488, 534, 1488, 532, 484, 534, 490, 5002}; // UNKNOWN AFFF4224

[crankyoldgit]

Answered in the wiki section on adding a new protocol.

https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-IR-protocol#use-the-auto_analyse_raw_datapy-program

eg. Using the data you've provided,

~/git/IRremoteESP8266/tools$ ./auto_analyse_raw_data.py -f /tmp/j
Found 211 timing entries.
Potential Mark Candidates:
[5004, 536]
Potential Space Candidates:
[4990, 1496, 492]

Guessing encoding type:
Looks like it uses space encoding. Yay!

Guessing key value:
kHdrMark   = 5003
kHdrSpace  = 4990
kBitMark   = 533
kOneSpace  = 1489
kZeroSpace = 484

Decoding protocol based on analysis so far:

kHdrMark+kHdrSpace+11010101111111111101011100101111111111100111011111111101000011111111111101111111000011001111110111011100
  Bits: 104
  Hex:  0xD5FFD72FFE77FD0FFF7F0CFDDC (MSB first)
        0x3BBF30FEFFF0BFEE7FF4EBFFAB (LSB first)
  Dec:  16954777438739307819267437428188 (MSB first)
        4733632457859168562554723893163 (LSB first)
  Bin:  0b11010101111111111101011100101111111111100111011111111101000011111111111101111111000011001111110111011100 (MSB first)
        0b00111011101111110011000011111110111111111111000010111111111011100111111111110100111010111111111110101011 (LSB first)
kHdrMark+
Total Nr. of suspected bits: 104

[crankyoldgit]

In short, the protocol is not yet supported (btw, try v2.7.20 just in case).
Read:
https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-IR-protocol
&
https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol

[shubham-malasane]

thank u for your kind help....
I have one more question...

when i decoded same IR signal using logic analyzer (Saleae) then it is shows only 65 bit signal
why it is like that? which we can consider a correct signal a raw data or IR signal on saleae

I think, logic analyzer shows always correct signal representation.

share signal decoded on logic analyzer (Saleae) below:

[NiKiZe]

It shows no time scale so hard to say, I would compare the captures in time and see if you can pinpoint the difference.

[shubham-malasane]

I have verified the timing it is same as
kHdrMark = 5003
kHdrSpace = 4990
kBitMark = 533
kOneSpace = 1489
kZeroSpace = 484

But, if u count the high pulses in the shared signal so it is only 65 not 106

[crankyoldgit]

It's 104 bits, or 15 bytes.
Feel free to not take my advice. Just know I've been doing this for over four years and have done over 50 different protocols. But what do I know. :-p

[shubham-malasane]

very sorry

but i am just asking u not saying u r wrong.
I just started working on ir library so i am using different tools for analysis the signal and what i observed that what i share with u.

yes u r having lot experience no doubt about it.

sorry once again if u hurt

[crankyoldgit]

Na. Not hurt at all. No need to worry. I understand. I'm just trying to say "trust me" in a stupid/odd way.

If you could please create an "issue" based on this, I'll start up the process of adding "basic" support for the protocol. i.e. capture and replay a state[] for the protocol. Then you/we can work on adding "detailed" support for it once we've done some analysis.