crankyoldgit
Protocol for STB ADB-1750CF(X)
I'm trying to decode the remote control for my STB but without success.
The brand is ADB and according to the information at irdb the protocol used is XMP-1. However, the library(IRrecvDumpV2.ino) always log "unknown".
I'm using the TSOP34338 which claims to be, within that type, the best choice for xmp.
Each key appears to have two codes that alternate with each press.(???) When a key is pressed continuously, the same code is generated as long as the key remains pressed.
Is there any chance we could get support for this protocol?
Below are the outputs for the UP and DOWN key.
UP - 1ª press:
Timestamp : 000185.285 Library : v2.8.6
Protocol : UNKNOWN Code : 0x4ACCCF10 (25 Bits) uint16_t rawData[49] = {336, 686, 284, 318, 250, 298, 280, 296, 284, 318, 250, 300, 280, 296, 284, 292, 286, 290, 542, 322, 256, 606, 280, 322, 258, 318, 512, 612, 282, 294, 286, 316, 252, 298, 280, 294, 284, 290, 542, 322, 256, 604, 542, 610, 276, 294, 286, 368, 336}; // UNKNOWN 4ACCCF10
UP - 2ª press:
Timestamp : 000816.242 Library : v2.8.6
Protocol : UNKNOWN Code : 0x77B67A08 (24 Bits) uint16_t rawData[47] = {332, 690, 278, 298, 282, 294, 284, 292, 276, 300, 280, 296, 282, 294, 274, 302, 276, 298, 544, 294, 276, 614, 280, 294, 286, 290, 540, 612, 284, 292, 276, 300, 278, 298, 280, 294, 284, 292, 540, 296, 284, 606, 542, 610, 538, 694, 328}; // UNKNOWN 77B67A08
UP - 3ª press:
Timestamp : 000906.086 Library : v2.8.6
Protocol : UNKNOWN Code : 0x4ACCCF10 (25 Bits) uint16_t rawData[49] = {334, 688, 280, 294, 274, 302, 278, 298, 280, 296, 284, 292, 276, 300, 278, 296, 282, 294, 538, 298, 280, 608, 276, 300, 278, 296, 546, 606, 278, 298, 282, 294, 274, 302, 278, 298, 280, 296, 536, 300, 278, 610, 538, 612, 334, 234, 282, 374, 332}; // UNKNOWN 4ACCCF10
DOWN - 1ª press:
Timestamp : 001045.971 Library : v2.8.6
Protocol : UNKNOWN Code : 0x81893889 (25 Bits) uint16_t rawData[49] = {334, 686, 282, 294, 276, 326, 252, 324, 254, 322, 258, 318, 250, 328, 252, 324, 256, 320, 512, 324, 254, 610, 276, 300, 278, 322, 520, 606, 278, 322, 256, 320, 248, 328, 252, 324, 254, 322, 520, 316, 252, 322, 256, 606, 542, 602, 282, 396, 310}; // UNKNOWN 81893889
DOWN - 2ª press:
Timestamp : 001087.309 Library : v2.8.6
Protocol : UNKNOWN
Code : 0xC26FEEFB (25 Bits)
uint16_t rawData[49] = {336, 686, 284, 318, 250, 326, 252, 324, 256, 320, 260, 318, 250, 324, 254, 322, 256, 318, 514, 324, 254, 608, 276, 298, 280, 322, 520, 604, 280, 322, 256, 320, 248, 328, 252, 324, 256, 320, 510, 326, 252, 322, 258, 604, 544, 318, 250, 694, 328};
// UNKNOWN C26FEEFB
DOWN - 3ª press:
Timestamp : 001094.983 Library : v2.8.6
Protocol : UNKNOWN Code : 0x81893889 (25 Bits) uint16_t rawData[49] = {338, 684, 284, 318, 250, 326, 254, 322, 256, 320, 248, 328, 250, 324, 254, 322, 258, 318, 514, 324, 254, 606, 278, 298, 280, 320, 522, 604, 280, 294, 284, 292, 276, 326, 252, 324, 256, 320, 512, 324, 254, 320, 248, 614, 544, 600, 274, 380, 336}; // UNKNOWN 81893889
Thank you for your time and for creating this library!
I don't know if it helps but I found this which, apparently, refers to an STB identical to mine.
Thanks.
As explained I. The FAQ, there really isn't codes for unknown protocols. The FAQ (and issue template) does cover a how-to on how to decide these if you want to try it yourself.
Thanks for the quick response. Yes, I will try it myself. I already read the faq and I don't know how. Can you give me just one tip on where to start?
Thanks.
I read the faq and the Troubleshooting Guide again. I played around with some kTimeout and kTolerancePercentage values.
I used the auto_analyse_raw_data.py program and this was the output:
PS C:\Disco D\Desenvolvimento\Py\IR> python auto_analyse_raw_data.py --stdin
338, 684, 284, 318, 250, 326, 254, 322, 256, 320, 248, 328, 250, 324, 254, 322, 258, 318, 514, 324, 254, 606, 278, 298, 280, 320, 522, 604, 280, 294, 284, 292, 276, 326, 252, 324, 256, 320, 512, 324, 254, 320, 248, 614, 544, 600, 274, 380, 336
^Z
Found 49 timing entries.
Potential Mark Candidates:
[544, 338]
Potential Space Candidates:
[684, 380]
Guessing encoding type:
Sorry, it looks like it is Mark encoded. I can't do that yet. Exiting.
I tried 4 other IRs and they were all recognized, even an AC. I have a Tuya IR device that recognized it without any problems, when I chose the STB ADB. I don't know what else to do.
I would appreciate your comment on this. Thanks.
Hi.
So I can move forward, can you please tell me if from the output of the auto_analyse_raw_data.py I can infer that the library is not capable of handling my remote?
But, if it does, what do I need to do?
Excuse my ignorance and thank you for your time.
Sorry, I looked at your data earlier. The protocol it is using is not a simple message protocol. It looks kind-of like RC family of protocols, but not. The automatic tools won't help you with this protocol, sorry. I hated coding the RC protocols with a passion. That's because the underlying way the library works makes decoding those quite convoluted and complex. I certainly lost many hours of my life to those types of protocols, so I won't code it for you. You'll have to do it yourself, or find some other kind-soul. Sorry.
Hi. Thanks.
I just need to know which key was pressed. I will try to use the DECODE_HASH code, but sometimes it fails (same key but different code than the two that normally return). Is there any way to make it "more consistent"?
Anyway, thank you very much.
I did some research, it seems to be a variant of XMP protocol, you might want to look at/tweak the ir_XMP.[cpp|h] files. You might be able to fiddle the values to make it detect/match your protocol. Or look up some other XMP protocol implementations to see if you can implement it.
Due to the way XMP works, DECODE_HASH (UNKNOWN) values will be especially likely to give poor results.
If you are using an ESP to be controlled by this specific remote, then I suggest using a different remote with a more common (e.g. NEC) protocol.
I control my TV and STB via a Node-Red flow.
Node-Red -> TUYA Cloud -> TUYA ir device -> TV & STB.
The problem is that I can't know what the status is, on or off, of the TV and STB, since both can also be controlled by their respective controls.
My idea is to have an Esp device that is aware of when the Power key is pressed and thus saves and manages the on/off state and informs Node-Red. Later, the purpose is to get rid of the TUYA device and the need for TUYA cloud.
I don't know if it helps but I found this which, apparently, refers to an STB identical to mine.
I'll look at the code and see if I can understand how things work.
What do the numbers in rawData represent?
Thank you for not letting this matter die just yet.
I certainly haven't decoded the protocol but I found a way to identify each key.
For my purpose, each element of rawData smaller than 400 µs represents one bit, if larger two bits. For the first element the bit(s) will have the value 1, the next 0, the third 1, alternating so on.
Applying the algorithm:
UP key:
1001010101010101010110100101011001010101010110100110010101
DOWN key:
1001010101010101010110100101011001010101010110101001100101
It can be seen that, for the same key pressed successively (press, release, press, release, etc.) the generated code alternates between two values.
UP key:
1st - 100101010101010101011010010101100101010101011010011001 0101
2nd - 100101010101010101011010010101100101010101011010011001 1001
3rd - 100101010101010101011010010101100101010101011010011001 0101
The only part that changes are the last 4 bits.
These 4 bits alternate between 0101 and 1001 whenever a key is pressed, even if it is another key.
The sequence UP, DOWN, DOWN, UP will generate the following codes:
100101010101010101011010010101100101010101011010011001 0101
100101010101010101011010010101100101010101011010100110 1001
100101010101010101011010010101100101010101011010100110 0101
100101010101010101011010010101100101010101011010011001 1001
If the key is held down for some time, the generated code does not change, i.e. the last 4 bits remain the same.
As I looked at the codes for various keys for patterns, it seemed to me that I could break down the code as follows:
100101 01010101 01010110 10010101 10010101 01010110 10011001 0101
Starting from the right side:
- 4 bits - toggles between two values whenever a key is pressed.
- 6 Groups of 8 bits:
- 2 Bytes - are different for each key, I will call it "key code"
- 4 Bytes - they are always the same
- 6 bits - always the same
The sequence UP, KEY_1, KEY_2, V-:
100101 01010101 01010110 10010101 10010101 01010110 10011001 0101
100101 01010101 01010110 10010101 10010101 01010101 01010110 1001
100101 01010101 01010110 10010101 10010101 01010101 01011001 0101
100101 01010101 01010110 10010101 10010101 01010110 01010101 1001
"Key codes":
UP = 0x5699 KEY_1 = 0x5556 KEY_2 = 0x5559 V- = 0x5655