Hello everyone, I'm trying to decode the Ir signal from my air conditioning control with the IRremoteESP8266.h library and so far I've been able to send the raw signals successfully. The problem or inconvenience is that the raw data is very long (I have a data length of 244 and 122 bits for each button of the control) so I would like to know if I can pass this data to hexadecimal and send it as such.
I clarify that the library does not know the protocol of my control, but it throws me a hexadecimal that I do not know how to send it (with the library) or that it is. Also I clarify that the hexadecimal that me throws the library doesn't coincide with the that shows me IrScrutinizer
I am using the example IRrecvDumpV2 that comes in the library and I have not modified anything.
Thanks in advance.
There are several FAQ & Wiki pages that cover this topic already:
but they can implement a function where I only encode the bits to hex and I pass the values of the start carrier or where I tell you what percentage of the duty cycle is a 1 and what is a 0.
Thanks in advance
Again this is covered in the FAQ, have you read the suggested pages properly, or is it anything that is preventing you from doing so?
Another question out of curiosity, what made you remove the contents from the issue template instead of filling it in?
Hello again, I have read the pages you recommended and I see that apparently the hexadecimal is random if it does not have a protocol, which means that it is not possible and I have to send it by force as a raw.
Am I right?
You can NOT use the simple short hex value associated with an UNKNOWN message for sending.
If you want to reproduce that message, you need to use the raw values.
If you follow the wiki pages I linked, it will show you how to decode your message into an appropriate "hex code" and produce the code needed to be able to send that "hex code" for your particular remote/protocol.
If you've read the documentation that was in the initial issue template, and in the wiki pages, and in the troubleshooting guide you will have seen we can't really help you without you providing the raw data. We are not magicians or mind-readers. :-)
this is all the info he throws at me in the serial:
Protocol : UNKNOWN
Code : 0x28DACDC4 (122 Bits)
uint16_t rawData[243] = {8360, 4248, 582, 518, 556, 1582, 586, 1572, 528, 572, 556, 1590, 526, 572, 554, 1586, 528, 578, 558, 1582, 556, 542, 558, 1598, 528, 572, 556, 1590, 528, 1610, 556, 1600, 554, 546, 556, 544, 558, 542, 558, 542, 676, 400, 606, 492, 582, 542, 556, 544, 556, 542, 558, 544, 556, 542, 556, 544, 558, 542, 556, 544, 530, 570, 586, 516, 584, 514, 558, 542, 558, 542, 558, 542, 554, 546, 558, 542, 558, 1582, 734, 342, 580, 552, 528, 1610, 556, 544, 554, 546, 554, 544, 556, 544, 556, 544, 558, 542, 558, 552, 558, 542, 558, 542, 558, 542, 556, 544, 558, 542, 558, 542, 554, 544, 584, 516, 558, 542,
528, 572, 588, 512, 556, 544, 532, 568, 560, 542, 558, 542, 560, 540, 560, 538, 530, 570, 558, 542, 558, 542, 560, 540, 558, 542, 558, 542, 530, 568, 558, 542, 558, 542, 532, 570, 530, 570, 558, 542, 558, 542, 558, 542, 530, 570, 530, 568, 560, 540, 560, 540, 532, 568, 558, 542, 558, 542, 532, 568, 560, 542, 532, 568, 532, 568, 530, 570, 532, 570, 530, 570, 558, 540, 560, 540, 558, 534, 558, 542, 556, 1600, 558, 1592, 558, 542, 560, 1590, 530, 570, 530, 570, 556, 544, 560, 540, 556, 544, 558, 1582, 556, 544, 558, 1600, 556, 542, 560, 542, 532, 568, 558, 542, 610, 1538, 504, 1646, 582, 518, 528, 572, 528, 1612, 556, 544, 528, 580, 554}; // UNKNOWN 28DACDC4
I'll take a look at it shortly. In the meantime, can you tell us the brand & model numbers of both the a/c unit and the remote please?
Well, the brand of the air conditioning is mirage model vlu series and the remote control is a universal control. The model of the control is va-cr1000u from AVALY brand.
If there is another data you need I will be aware
uint16_t rawData[243] = {8360, 4248, 582, 518, 556, 1582, 586, 1572, 528, 572, 556, 1590, 526, 572, 554, 1586, 528, 578, 558, 1582, 556, 542, 558, 1598, 528, 572, 556, 1590, 528, 1610, 556, 1600, 554, 546, 556, 544, 558, 542, 558, 542, 676, 400, 606, 492, 582, 542, 556, 544, 556, 542, 558, 544, 556, 542, 556, 544, 558, 542, 556, 544, 530, 570, 586, 516, 584, 514, 558, 542, 558, 542, 558, 542, 554, 546, 558, 542, 558, 1582, 734, 342, 580, 552, 528, 1610, 556, 544, 554, 546, 554, 544, 556, 544, 556, 544, 558, 542, 558, 552, 558, 542, 558, 542, 558, 542, 556, 544, 558, 542, 558, 542, 554, 544, 584, 516, 558, 542,
528, 572, 588, 512, 556, 544, 532, 568, 560, 542, 558, 542, 560, 540, 560, 538, 530, 570, 558, 542, 558, 542, 560, 540, 558, 542, 558, 542, 530, 568, 558, 542, 558, 542, 532, 570, 530, 570, 558, 542, 558, 542, 558, 542, 530, 570, 530, 568, 560, 540, 560, 540, 532, 568, 558, 542, 558, 542, 532, 568, 560, 542, 532, 568, 532, 568, 530, 570, 532, 570, 530, 570, 558, 540, 560, 540, 558, 534, 558, 542, 556, 1600, 558, 1592, 558, 542, 560, 1590, 530, 570, 530, 570, 556, 544, 560, 540, 556, 544, 558, 1582, 556, 544, 558, 1600, 556, 542, 560, 542, 532, 568, 558, 542, 610, 1538, 504, 1646, 582, 518, 528, 572, 528, 1612, 556, 544, 528, 580, 554}; // UNKNOWN 28DACDC4
Looking at your supplied data, there is a very odd/unexpected values (see above in bold), this indicates a poor collection/reception issue.
What is the part number for the hardware IR demodulator you are using? e.g. Is it a VS1838b per chance?
Can you please download and try PR #1291 / https://github.com/crankyoldgit/IRremoteESP8266/tree/mirage_basic and let me know how you go?
If it works, can you please capture an a sequence of messages starting from the lowest temp to the highest temp. This is needed to determine if we have the protocol's bit ordering correct or not. All we will need is the Temp value & the state[] code for each message, not the rawData, assuming it is recognised correctly as MIRAGE.
Please note, I suspect your hardware IR receiver has some issues. You may need to the following line:
irrecv.setTolerance(kTolerance + 10); // Increase the Tolerance by an extra 10% to handle possible poor hardware.
irrecv.setTolerance(kTolerance + 10); // Increase the Tolerance by an extra 10% to handle possible poor hardware.
irrecv.enableIRIn(); // Start the receiver
}
You may need to tweak that value higher, but 10% extra worked for the data you supplied.
I don't really know what type it is, I just know that it came with a sensor kit that I bought and it's a KY-022 module but it supports 38 khz https://cdmxelectronica.com/producto/modulo-ky-022-sensor-receptor-infrarrojo-ir/
I tried the library you told me about and it sent some temperature codes fine, only I realized that the hex changes and it is not always the same, but it performs the indicated action. The only thing that happened is that some commands were sent, but my weather did not recognize them and others were recognized.
Maybe this is due to the fact that I did it a bit hastily, but tomorrow I will be trying it out more calmly but so far I am super impressed that it already throws the hex at me and it works.
By the way, I am using the IrReciverDumpV3 and I added this line of code that you told me:
irrecv.setTolerance(kTolerance + 10); // Increase the Tolerance by an extra 10% to handle possible poor hardware.
I tried the library you told me about and it sent some temperature codes fine, only I realized that the hex changes and it is not always the same, but it performs the indicated action. The only thing that happened is that some commands were sent, but my weather did not recognize them and others were recognized.
Yes, The value should change. But again, without the data, I can't help you.
I don't really know what type it is, I just know that it came with a sensor kit that I bought and it's a KY-022 module but it supports 38 khz https://cdmxelectronica.com/producto/modulo-ky-022-sensor-receptor-infrarrojo-ir/
From the images in that link, it looks like it might be one of the poorly performing/cheap IR demodulators.
The on and off commands are the same, e.g.
Timestamp : 000005.003
Protocol : MIRAGE
Code : 0x6A4E0000840000000000ECE894 (120 Bits)
uint16_t rawData[243] = {8382, 4290, 530, 548, 526, 1644, 502, 1660, 502, 602, 530, 1602, 526, 602, 500, 1646, 554, 558, 500, 604, 500, 1646, 502, 600, 502, 578, 552, 1634, 502, 1628, 556, 1614, 528, 584, 502, 602, 528, 574, 504, 576, 526, 602, 528, 576, 528, 552, 554, 574, 502, 592, 528, 576, 502, 600, 502, 602, 528, 576, 528, 576, 502, 602, 556, 548, 500, 610, 504, 1652, 502, 600, 502, 602, 530, 574, 528, 576, 528, 1618, 556, 548, 612, 500, 500, 604, 500, 604, 526, 576, 500, 604, 528, 576, 528, 576, 500, 604, 500, 570, 526, 602, 500, 604, 500, 602, 528, 574, 530, 574, 556, 548, 526, 576, 528, 610, 502, 574,
502, 602, 556, 548, 528, 574, 530, 548, 554, 574, 530, 574, 502, 594, 526, 576, 528, 578, 500, 602, 502, 602, 502, 602, 528, 574, 528, 576, 504, 610, 502, 602, 502, 600, 528, 576, 530, 574, 500, 604, 526,
580, 500, 602, 528, 576, 526, 576, 528, 552, 552, 578, 524, 552, 554, 576, 502, 602, 500, 604, 528, 574, 502, 600, 500, 604, 498, 604, 528, 602, 476, 604, 526, 574, 502, 604, 498, 604, 528, 1620, 500, 1666, 524, 1630, 526, 578, 500, 1658, 498, 1658, 524, 578, 526, 570, 500, 1664, 528, 1628, 526, 1620, 502, 604, 500, 1664, 526, 578, 526, 578, 500, 596, 500, 1664, 526, 578, 526, 576, 500, 1682, 502, 576, 684, 1464, 526, 578, 500, 614, 522}; // MIRAGE
uint8_t state[15] = {0x6A, 0x4E, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xEC, 0xE8, 0x94};
but the temperature commands, for example 16 differs a little:
Timestamp : 000279.293
Protocol : MIRAGE
Code : 0x6A360000840000000000600064 (120 Bits)
uint16_t rawData[243] = {8388, 4262, 558, 546, 584, 1562, 530, 1632, 558, 546, 558, 1598, 556, 546, 584, 1564, 556, 554, 558, 546, 558, 556, 1590, 558, 1606, 556, 548, 556, 1600, 584, 1562, 558, 554, 584, 518, 560, 544, 558, 546, 558, 546, 558, 544, 588, 516, 556, 548, 584, 510, 556, 546, 558, 546, 558, 546, 556, 548, 530, 574, 558, 546, 556, 548, 530, 582, 530, 1624, 558, 546, 584, 520, 586, 518, 584, 518, 586, 1562, 558, 544, 558, 556, 556, 546, 558, 546, 556, 548, 530, 572, 556, 548, 558, 546, 558, 544, 558, 538, 558, 546, 584, 520, 558, 544, 584, 520, 558, 546, 556, 548, 556, 548, 558, 554, 586, 516,
584, 520, 560, 544, 558, 546, 558, 546, 558, 544, 558, 546, 586, 508, 560, 546, 562, 540, 558, 546, 558, 546, 560, 544, 586, 516, 532, 574, 558, 554, 558, 546, 558, 546, 556, 546, 558, 546, 532, 574, 556,
548, 584, 520, 558, 548, 558, 546, 558, 546, 586, 520, 558, 546, 558, 546, 532, 572, 560, 544, 558, 546, 558, 546, 584, 520, 584, 520, 560, 544, 558, 546, 558, 546, 560, 546, 556, 546, 558, 548, 558, 1588, 584, 1580, 558, 546, 556, 548, 558, 546, 558, 546, 584, 512, 558, 546, 560, 544, 556, 548, 558, 546, 558, 546, 558, 546, 558, 546, 558, 554, 558, 546, 560, 1596, 560, 1588, 586, 518, 558, 546, 558, 1606,
584, 520, 560, 534, 530}; // MIRAGE
uint8_t state[15] = {0x6A, 0x36, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x60, 0x00, 0x64};
Timestamp : 000330.389
Protocol : MIRAGE
Code : 0x6A36000084000000E000E4 (120 Bits)
uint16_t rawData[243] = {8388, 4262, 556, 550, 558, 1586, 558, 1608, 556, 548, 530, 1624, 556, 546, 584, 1564, 556, 554, 558, 546, 556, 548, 556, 1590, 556, 1608, 556, 548, 556, 1600, 558, 1590, 584, 530, 556, 546, 584, 520, 584, 520, 556, 546, 584, 520, 558, 544, 582, 522, 556, 536, 558, 546, 586, 520, 554, 548, 558, 546, 586, 518, 530, 574, 558, 546, 558, 554, 558, 1598, 554, 548, 556, 548, 530, 574, 558, 544, 558, 1590, 558, 546, 556, 554, 558, 546, 556, 546, 610, 494, 556, 548, 556, 548, 558, 546, 556, 548, 556, 540, 556, 548, 558, 548, 554, 548, 554, 548, 558, 548, 530, 574, 556, 548, 554, 558, 558, 546,
558, 546, 560, 546, 582, 520, 556, 548, 584, 520, 554, 548, 556, 540, 554, 548, 558, 548, 556, 546, 556, 550, 556, 548, 558, 546, 558, 548, 554, 556, 556, 546, 556, 548, 558, 546, 558, 544, 556, 548, 556,
548, 556, 546, 556, 548, 558, 546, 558, 548, 586, 518, 558, 546, 558, 546, 558, 546, 558, 548, 556, 548, 556, 548, 556, 546, 558, 546, 558, 546, 556, 548, 558, 546, 554, 550, 556, 548, 530, 1616, 554, 1610, 560, 1598, 556, 548, 558, 548, 556, 546, 556, 550, 554, 550, 556, 548, 584, 520, 562, 542, 554, 548, 556, 548, 558, 548, 528, 574, 558, 546, 556, 1592, 556, 1610, 554, 1602, 554, 550, 556, 548, 584, 1572, 558, 546, 556, 550, 582}; // MIRAGE
uint8_t state[15] = {0x6A, 0x36, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xE0, 0x00, 0xE4};
Both are for temperature 16
We still want you to give us the code (the hex part) for all temperatures, from the lowest, to the highest temp, for every code include which temp it was.
Will I get anything for sharing my codes?
16
uint8_t state[15] = {0x6A, 0x36, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x60, 0x00, 0x64};
17
uint8_t state[15] = {0x6A, 0xB6, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x60, 0x00, 0xE4};
18
uint8_t state[15] = {0x6A, 0x76, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xA0, 0x00, 0xE4};
19
uint8_t state[15] = {0x6A, 0xF6, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xA0, 0x00, 0x14};
20
uint8_t state[15] = {0x6A, 0x0E, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xA0, 0x00, 0x58};
21
uint8_t state[15] = {0x6A, 0x8E, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xA0, 0x00, 0xD8};
22
uint8_t state[15] = {0x6A, 0x4E, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xA0, 0x00, 0x38};
23
uint8_t state[15] = {0x6A, 0xCE, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xA0, 0x00, 0xB8};
24
uint8_t state[15] = {0x6A, 0x2E, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0xB8};
25
uint8_t state[15] = {0x6A, 0xAE, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x78};
26
uint8_t state[15] = {0x6A, 0x6E, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0xF8};
27
uint8_t state[15] = {0x6A, 0xEE, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x20, 0x00, 0x04};
28
uint8_t state[15] = {0x6A, 0x1E, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0, 0x00, 0x04};
29
uint8_t state[15] = {0x6A, 0x9E, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0, 0x00, 0x84};
30
uint8_t state[15] = {0x6A, 0x5E, 0x00, 0x00, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 0x00, 0x04};
Will I get anything for sharing my codes?
Not sure I understand the question.
Thank you!, With that information, we can, as @crankyoldgit wrote, make sure that the decode is correct.
Are you willing to help us, help you? (If you read the FAQ that was linked previously you should know what it takes to get this done, without your help we will not be able to get this right, and thus not help you,)
@joelzavala Thanks for the data. It confirms we've got the bit order wrong. It was a 50:50 guess.
I'll update the branch & PR momentarily.
What I don't understand is why some of your state[15] codes for some of the temps are actually 16 bytes long instead of 15. I'm really hoping it's a cut-n-paste problem.
e.g. 23C, 28C, & 29C
Regarding the Power on and off being the same, that is fairly common when an A/C protocol uses a "power toggle" command instead of discrete commands/settings for if the power is on or off.
@joelzavala If you re-download it via PR #1291 / https://github.com/crankyoldgit/IRremoteESP8266/tree/mirage_basic
the state[] format should now be finalised.
i.e. Any previous state[] lines are now invalid as we had to reverse all the bits in each byte to correctly align with the protocol.
New data collected via that branch etc should now work just fine with the updated code.
FYI, we have now just complete this step in adding support for your remote & A/C. This is why we asked for that data. It was in one of the pages we recommended you look at originally.
From here on in, it's up to you to do further analysis if you want better/detailed support for your A/C's protocol.
i.e. To be able to construct arbitrary messages based on your desired settings, rather than just replaying previously captured codes.
When you've done that analysis, please create a new issue with all the data and we'll try to help you by converting it to code.
Tips for your analysis:
state[1].state[14], &state[12] _might_ be an indication of what button was pressed. [Not sure]Great, just one more thing, can I send the hexadecimal together (without having to put it in an array) and pass it directly into the function?
Great, just one more thing, can I send the hexadecimal together (without having to put it in an array) and pass it directly into the function?
If you are using the library in your own code, No. The size of the code (15 bytes) is larger than any native integer size the processor has. i.e. 64 bits is the largest (64 / 8 == 8 bytes long) You will have to do some processing of a string to convert it into any array if you want to do that yourself.
However, IRMQTTServer (in the examples folder), Tasmota, & ESPeasy (I think) will let use a string of hexidecimal to send instead of an array.
e.g.
https://github.com/crankyoldgit/IRremoteESP8266/blob/56992713c1eebb6259e1f700791c3067a6dfc024/examples/IRMQTTServer/IRMQTTServer.ino#L70
&
https://github.com/crankyoldgit/IRremoteESP8266/blob/56992713c1eebb6259e1f700791c3067a6dfc024/examples/IRMQTTServer/IRMQTTServer.ino#L108-L113
Hello again.
I would like to know if passing the decimal values in the array works the sendMirage method
Thanks in advance
If you mean:
uint8_t hex_state[] = {0x00, 0x02, 0x10, 0xFF}; // Is the same as the next line
uint8_t dec_state[] = {0, 2, 16, 255}; // Is the same as the previous line.
Then, Yes, as it is the same.
If you mean:
\\ 0x000210FF (hex) == 135423 (dec)
uint8_t hex_state[] = {0x00, 0x02, 0x10, 0xFF}; // Is NOT the same as the next line
uint8_t dec_state[] = {0, 13, 54, 23}; // Is NOT the same as the previous line.
Then, No, as the values are different.
https://lmgtfy.app/?q=how+to+convert+decimal+to+hexadecimal+in+arduino
Hi, I have an AC prime but when I decode the signal it tells me it's coolix.
I am analyzing the returned hexadecimal and I see that it has problems to recognize the data with some modes and temperatures.
For example, if I set it to fan mode and turn it up, I set certain temperatures, it changes to dry and doesn't show the temperature and gives me a fan speed that it doesn't have in dry mode;
Temperature 21, fan mode
Protocol: COOLIX
Code: 0xB29FE4 (24 Bits)
Decoded: Power: On, Mode: 4 (Fan), Fan: 4 (Min), Follow Zone: Off, Sensor Temperature: Off
uint16_t rawData[199] = {4446, 4520, 530, 1636, 504, 590, 530, 1636, 532, 1624, 504, 602, 504, 592, 504, 1660, 504, 600, 532, 572, 504, 1652, 506, 600, 502, 602, 504, 1652, 504, 1652, 530, 572, 532, 1616, 532, 1634, 504, 592, 530, 582, 532, 1618, 502, 1662, 504, 1652, 530, 1626, 506, 1650, 502, 594, 502, 1662, 478, 1680, 532, 572, 504, 590, 506, 610, 502, 600, 504, 592, 506, 1650, 506, 1660, 530, 1624, 530, 574, 502, 594, 502, 1662, 506, 592, 504, 610, 504, 600, 502, 594, 530, 584, 504, 1644, 528, 1636, 532, 564, 504, 1660, 530, 1626, 528, 5750, 4400, 4522, 504, 1654, 504, 600, 504, 1654, 504, 1662, 504, 592, 504, 600, 504, 1652, 504, 610, 504, 600, 504, 1654, 530, 572, 530, 568, 504, 1660, 530, 1628, 504, 600, 504, 1652, 506, 1644, 560, 552, 504, 600, 532, 1624, 504, 1646, 532, 1634, 504, 1652, 508, 1642, 506, 608, 532, 1616, 532, 1634, 530, 566, 504, 608, 504, 600, 532, 572, 504, 600, 532, 1616, 506, 1652, 532, 1634, 504, 592, 504, 600, 504, 1654, 504, 600, 504, 608, 506, 592, 502, 612, 530, 574, 504, 1652, 532, 1616, 530, 582, 502, 1646, 506, 1658, 532}; // COOLIX B29FE4
uint64_t data = 0xB29FE4;
Temperature 22, fan mode (dry mode with fan speed 4 does not exist)
Protocol: COOLIX
Code: 0xB29FF4 (24 Bits)
Decryption: Power: On, Mode: 1 (Dry), Fan: 4 (Min), Temperature: 30C, Follow Zone Off, Sensor Temperature: Off
uint16_t rawData[199] = {4446, 4520, 506, 1660, 502, 594, 504, 1658, 530, 1626, 500, 604, 532, 564, 530, 1634, 476, 628, 504, 600, 504, 1652, 504, 600, 504, 600, 506, 1650, 530, 1626, 530, 574, 528, 1620, 504, 1662, 506, 590, 504, 608, 504, 1644, 502, 1662, 502, 1654, 532, 1626, 528, 1626, 504, 594, 500, 1664, 504, 1654, 502, 602, 528, 568, 502, 612, 502, 602, 502, 594, 502, 1654, 530, 1634, 560, 1598, 532, 1624, 530, 574, 506, 1652, 504, 600, 502, 602, 502, 602, 478, 626, 504, 602, 504, 592, 528, 1636, 506, 590, 504, 1662, 502, 1654, 504, 5774, 4400, 4522, 502, 1656, 504, 600, 478, 1680, 506, 1658, 506, 592, 502, 602, 502, 1654, 502, 612, 476, 626, 504, 1654, 506, 600, 504, 592, 500, 1664, 530, 1628, 504, 602, 502, 1654, 504, 1644, 502, 612, 528, 576, 530, 1626, 506, 1644, 504, 1662, 504, 1654, 504, 1646, 504, 610, 530, 1618, 502, 1662, 504, 592, 504, 608, 504, 602, 504, 600, 532, 574, 504, 1644, 532, 1626, 504, 1660, 506, 1652, 530, 576, 502, 1656, 504, 600, 504, 600, 506, 602, 504, 600, 504, 592, 530, 582, 504, 1646, 502, 610, 502, 1644, 504, 1662, 506}; // COOLIX B29FF4
uint64_t data = 0xB29FF4;
I would like to know if I can decode it as prime
Thank you in advance
Please create a new issue for this. This has nothing to do with the now closed issue.
FYI, the changes mentioned above have now been included in the new v2.7.12 release of the library.
Most helpful comment
Not sure I understand the question.
Thank you!, With that information, we can, as @crankyoldgit wrote, make sure that the decode is correct.
Are you willing to help us, help you? (If you read the FAQ that was linked previously you should know what it takes to get this done, without your help we will not be able to get this right, and thus not help you,)