-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement this but with rawdata #4
Comments
If I’m not wrong first value should be discarded (4438), signal is sent 2 times, separator would be -5296. Is that a correct way to start the analysis? |
Most IR protocols use encoding similar to NEC protocol: there is a preamble, there is a bit encoding with short mark and then either short or long silence, then there is a mark and long silence signaling end of packet. You just need to figure out all timings. From your example I would say that there is a 4400us carrier + 4400us silence, mark is ~565us mark followed by either 565us or 1625us silence; an finally - 5300us of silence at the end. Incorporate all those timings into a config, use code you mentioned above to encode AC state into sequence of bytes and then transmit them. |
As of raw data: it is fine for stateless devices like TV remotes (pressing same button generates same code), but for AC is kind of inconvenient as it has a lot of combinations of state and storing them all in raw is inconvenient and error prone. |
you mean already converted to ones and zeros? I have a 48 bits signal (it
is sent twice when you press the button) how would that line be?
…On Mon, Jun 24, 2019 at 2:28 PM Maxim Kulkin ***@***.***> wrote:
As of raw data: it is fine for stateless devices like TV remotes (pressing
same button generates same code), but for AC is kind of inconvenient as it
has a lot of combinations of state and storing them all in raw is
inconvenient and error prone.
But you can do that by replacing this line
<https://github.com/maximkulkin/esp-ir-thermostat/blob/master/main/fujitsu_ac_ir.c#L102>
with ir_raw_send(pulses, sizeof(pulses) / sizeof(*pulses)); (assuming
pulses is array of your raw pulse data)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#4?email_source=notifications&email_token=AJL4PCD5VUYV37LNJA2LBYLP4D74FA5CNFSM4H2XHTZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYNUSNA#issuecomment-505104692>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJL4PCC6UMDRJMJMBMDJZRDP4D74FANCNFSM4H2XHTZQ>
.
|
Just take that numbers, put them into signed int array (e.g. Well, 1) I haven't checked that it is the same bits, might be that this is part of a longer data packet; 2) if those two halves are the same, I think most likely you need only one half; 3) you might not need to worry about that if you plan to use raw signals: just hardcode whatever you read from remote and be done with it. |
My idea is to try to understand those 48 bits :) i think I'm close.
In the meantime. Could be possible to convert binary data instead of
storing those long codes?
…On Mon, Jun 24, 2019 at 5:55 PM Maxim Kulkin ***@***.***> wrote:
you mean already converted to ones and zeros?
Just take that numbers, put them into signed int array (e.g. pulses) and
use ir_raw_send() to send them.
Well, 1) I haven't checked that it is the same bits, might be that this is
part of a longer data packet; 2) if those two halves are the same, I think
most likely you need only one half; 3) you might not need to worry about
that if you plan to use raw signals: just hardcode whatever you read from
remote and be done with it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#4?email_source=notifications&email_token=AJL4PCCH5BVYF4VVGVELUWTP4EYDJA5CNFSM4H2XHTZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYOGLEA#issuecomment-505177488>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJL4PCGYK5FPAY2HQREFKJTP4EYDJANCNFSM4H2XHTZQ>
.
|
My usual workflow is:
ir_generic_config_t generic_config = {
.header_mark = 4400,
.header_space = -4400,
.bit1_mark = 565,
.bit1_space = -1625,
.bit0_mark = 565,
.bit0_space = -565,
.footer_mark = 565,
.footer_space = -5100,
.tolerance = 20,
};
ir_decoder_t *decoder = ir_generic_make_decoder(&generic_config); |
I make this, but can't get any code #include <ir/ir.h> #define IR_RX_GPIO 12 static ir_generic_config_t generic_config = {
};
} void user_init(void) {
} |
ok, make it read something with this code #include <stdio.h> #include <ir/ir.h> #define IR_RX_GPIO 12 static ir_generic_config_t generic_config = { .bit1_mark = 565, .bit0_mark = 565, .footer_mark = 565, .tolerance = 20, uint8_t buffer[48];
} void user_init(void) { xTaskCreate(ir_dump_task, "IR dump", 2048, NULL, tskIDLE_PRIORITY, NULL); I use a 48 buffer, I think I should read everything with that size, right? |
I was able to read this 18 19 20 21 22 23 24 25 26 27 28 29 30 mode mode mode mode mode fan speed fan speed fan speed fan speed swing swing swing swing turbo sleep sleep sleep off sleep on fresh self clean follow me follow me off led silence silence off I cannot understand how the temperature is being coded. Also, it seems what I get is inverted from the raw data. |
Ok, first of all: some data you've presented look as outliers, I think you had either error copy-pasting them or there were errors cap[turing those sequences. Then, the codes look like 6 byte sequence. I've decoded raw data manually and indeed it looks like they are repeated twice. Also, I've noticed that every odd byte is the inverse of corresponding even byte ( byte 1 is inverse of byte 0, byte 3 is inverse of byte 2, etc). Then, I've started decoding temperature codes (as they are the easiest). Looks like the temperature is encoded by lower 4 bits of 4'th byte (or 3rd if you do not count inverses) and counts from 17 (and corresponding code is 0). Also it seems that they are big endian (most significant bits come first, although it might be the consequences of IR library reversing them). But, numbers do not come in sequence. I've reversed the bits and got sequence (0, 1, 3, 2, 6, 7, 5, 4, ...). Then I just googled that sequence and found out that this is a Gray code, a way to represent data that is more error prone in some cases. Haven't looked into others as for decoding codes I need more data (repeated is even better) and don't want to spoil all the fun. Hope it will get you started. |
You were right about the temp. I found a library that works with my remote. |
Yes you can |
I'll work on it and let you know. Thanks for all your help. |
Hi Maxim, may I ask you for help on the decoder code? I don't understand how to include it on the dumper. It seems some part of the code is inverted. I read 0x4d 0xb2 for example and it should be b2 4d. |
What does it mean "it should be b2 4d" ? Who defines that? What's the problem of it being reverse as long as you can interpret and generate it properly? |
If I try to manually translate to binary the raw data I get that B2 4D on the prefix, for example. Thing is that I cannot get hex code that I can't tell has something to do with the original binary from the raw data. Maybe there is an error on the way I print the decoded signal. |
That does not make any sense. I would imagine bits in numbers being reversed, not like whole bit sequences swapped. Of course if you want to encode integers, you need to pay attention to endianness. This is all handwaving and to be more specific you have to provide real data (e.g. raw data) |
Hi Maxim, this is the raw data that I have for Power off for example:
from my understanding this would be the data in binary, just reading everything in sequence. And this would be the info in HEX, b24d7b84e01f, right? I don't know how to make the decoder to read b24d7b84e01f, for that same information I get Decoded packet (size = 96): static ir_generic_config_t generic_config = {
.header_mark = 4400,
.header_space = -4400,
.bit1_mark = 565,
.bit1_space = -1625,
.bit0_mark = 565,
.bit0_space = -565,
.footer_mark = 565,
.footer_space = -5250,
.tolerance = 45,
};
void ir_dump_task(void *arg) {
ir_rx_init(IR_RX_GPIO, 1024);
ir_decoder_t *generic_decoder = ir_generic_make_decoder(&generic_config);
uint16_t buffer[48];
while (1) {
uint8_t size = sizeof(buffer);
if (ir_recv(generic_decoder, 0, buffer, &size) <= 0)
continue;
printf("Decoded packet (size = %d):\n", size);
for (int i=0; i < 24; i++) {
printf("%lx", buffer[i]);
if (i % 12 == 11)
printf("\n");
}
if ((size + 7) % 128)
printf("\n");
}
}
void user_init(void) {
uart_set_baud(0, 115200);
xTaskCreate(ir_dump_task, "IR dump", 2048, NULL, tskIDLE_PRIORITY, NULL);
} So I'm sure I'm doing something wrong there. |
OMG, every time I get unformatted code, my eyes bleed. OK, regarding your code: uint16_t buffer[48];
while (1) {
uint8_t size = sizeof(buffer);
if (ir_recv(generic_decoder, 0, buffer, &size) <= 0)
continue;
// skip
}
Printing decoded data should take into account decoded size, not just do some fixed size packets: for (int i=0; i < 24; i++) {
printf("%lx", buffer[i]);
if (i % 12 == 11)
printf("\n");
} And also this code is strange and useless: it prints newline unless size is 121 if ((size + 7) % 128)
printf("\n"); Also, tolerance value of 45 (percent) is too high. static ir_generic_config_t generic_config = {
// skip
.tolerance = 45,
}; |
Ok, I tried, but with no luck, as I said, I don't understand how to modify the original code I'm using, the one one mention in the Readme.md @example receiving NEC-like command". |
Ok, that was my bad not updating all examples. Fixed. So, try to use the corrected example and see what happens. |
ok, so thesis what I get with the code example in the readme file. |
What code do you get on Arduino library? Have you tried sending this code (4d b2 de 21 07 f8) using this library? |
this is the info I get with IRremoteESP8266 library Timestamp : 000284.884 Encoding : COOLIX
uint16_t rawData[199] = {4436, 4386, 568, 1622, 564, 536, 562, 1628, 564, 1622, 564, 534, 562, 536, 562, 1624, 564, 536, 564, 536, 564, 1626, 564, 534, 562, 536, 562, 1624, 564, 1624, 564, 536, 562, 1630, 564, 538, 562, 1624, 564, 1624, 562, 1622, 566, 1622, 566, 534, 562, 1628, 562, 1626, 566, 1628, 564, 536, 562, 534, 562, 534, 562, 534, 562, 1622, 564, 534, 562, 538, 564, 1628, 564, 1624, 564, 1622, 564, 536, 562, 536, 562, 536, 562, 534, 562, 538, 562, 538, 562, 536, 562, 534, 562, 1626, 566, 1622, 564, 1622, 564, 1624, 566, 1624, 580, 5228, 4434, 4380, 564, 1626, 562, 534, 564, 1628, 564, 1622, 566, 534, 562, 534, 562, 1624, 564, 536, 562, 538, 562, 1626, 566, 534, 564, 536, 562, 1622, 564, 1624, 564, 534, 562, 1630, 564, 534, 562, 1624, 562, 1626, 564, 1622, 564, 1624, 564, 536, 562, 1628, 564, 1624, 564, 1628, 566, 534, 562, 536, 564, 534, 562, 534, 564, 1620, 564, 536, 562, 536, 562, 1630, 566, 1620, 564, 1622, 566, 534, 562, 536, 562, 534, 562, 536, 560, 538, 562, 536, 562, 534, 564, 534, 564, 1626, 566, 1622, 564, 1622, 564, 1622, 566, 1626, 578}; // COOLIX B27BE0 I was not able to make the code to send the info I decoded. |
I wasn't able to make my own decoder based on your IR library :( |
Hi Maxim, quick question, what should I modify on your code to work with rawdata?
Also, do you know how could I implement codes for carrier AC found here? http://arduino.fisch.lu/index.php?menu=36&page=&portal=9
this is What I read for example when I turn on in 26 HEAT mode.
Decoded packet (size = 199):
4438 -4387 569 -1621 563 -537 562 -1627 566 -1621 567 -533 564 -534 565 -1621
565 -538 563 -535 565 -1625 567 -532 564 -534 563 -1623 567 -1620 567 -533
563 -1628 568 -1625 565 -536 563 -1625 569 -1618 532 -1656 561 -1626 564 -1624
557 -1632 532 -571 529 -1656 561 -539 556 -541 528 -570 561 -537 528 -570
558 -541 559 -1632 562 -1626 561 -538 562 -1628 562 -1625 564 -1622 562 -538
561 -538 561 -538 560 -538 561 -1629 563 -536 561 -537 560 -538 560 -1628
565 -1623 500 -5296 4434 -4377 568 -1624 563 -535 563 -1627 565 -1622 565 -534
564 -533 564 -1622 566 -536 563 -536 563 -1627 565 -533 565 -534 562 -1622
566 -1621 564 -536 563 -1628 565 -1628 565 -534 564 -1626 567 -1620 565 -1623
566 -1621 565 -1621 567 -1626 563 -535 565 -1620 565 -536 563 -535 562 -534
564 -535 563 -533 564 -536 563 -1628 567 -1621 565 -533 566 -1626 563 -1623
566 -1623 564 -534 563 -535 564 -536 564 -535 562 -1628 564 -534 564 -534
563 -535 562 -1626 566 -1624 500
The text was updated successfully, but these errors were encountered: