Help debugging Toshiba AC decoding mishaps

[njoyard]

Version/revision of the library used

v2.8.6

Describe the bug

I'm trying to understand (and ideally fix) issues decoding messages sent by my Toshiba AC remote (WH-TA12LE - not currently listed as supported).

From what I understand, apart from some specific features that generate unsupported messages (eg. weekly scheduling), this remote generates correct (ie. supported) 72 bit messages. When testing with IRrecvDumpV2 compiled with -DDECODE_HASH -DDECODE_TOSHIBA_AC, using the same controls repeatedly on the remote, some messages are correctly decoded while some others are not.

Here is an example serial output. Those two messages have identical payloads (they were generated by repeatedly pressing the on/off button on the remote, and I'm omitting an 'off' message in between those two 'on' messages):

Timestamp : 000222.526
Library   : v2.8.6

Protocol  : UNKNOWN
Code      : 0x18C05F5F (148 Bits)
uint16_t rawData[295] = {4458, 4396,  584, 1578,  588, 1578,  582, 1578,  588, 1578,  584, 500,  584, 506,  584, 1578,  588, 496,  588, 502,  584, 500,  588, 500,  588, 504,  584, 1578,  584, 1578,  588, 506,  588, 1586,  584, 500,  584, 502,  584, 504,  584, 504,  584, 510,  584, 500,  584, 1584,  586, 1574,  588, 1578,  584, 1578,  528, 1646,  580, 1600,  584, 1578,  584, 1586,  584, 504,  584, 510,  584, 500,  588, 500,  584, 506,  582, 506,  588, 500,  584, 514,  588, 506,  588, 1574,  588, 522,  584, 502,  584, 1596,  584, 1592,  588, 502,  584, 518,  584, 506,  588, 510,  584, 1592,  584, 504,  584, 1590,  584, 506,  588, 506,  584, 502,  584, 1582,  588, 1578,  584, 500,  584, 502,  584, 500,  584, 502,  588, 506,  584, 506,  584, 508,  584, 506,  584, 1582,  528, 578,  584, 504,  584, 1578,  584, 500,  584, 502,  588, 1580,  582, 502,  588, 5586,  4462, 4406,  582, 1582,  588, 1586,  584, 1590,  588, 1590,  588, 506,  584, 510,  584, 1578,  584, 506,  584, 502,  588, 500,  584, 506,  584, 504,  588, 1578,  584, 1582,  588, 506,  588, 1582,  528, 578,  584, 504,  584, 506,  584, 506,  584, 504,  588, 506,  584, 1582,  584, 1578,  588, 1582,  582, 1586,  584, 1594,  584, 1596,  584, 1578,  584, 1578,  588, 502,  582, 502,  584, 500,  584, 504,  584, 504,  584, 504,  584, 506,  588, 506,  584, 510,  584, 1582,  528, 578,  584, 506,  584, 1578,  584, 1590,  584, 500,  584, 502,  588, 506,  584, 510,  584, 1584,  582, 502,  584, 1590,  584, 506,  588, 506,  582, 506,  588, 1578,  584, 1586,  588, 500,  584, 508,  584, 506,  584, 506,  584, 506,  586, 506,  584, 510,  582, 510,  584, 1578,  588, 500,  584, 500,  584, 1586,  588, 504,  584, 506,  588, 1574,  588, 502,  584};  // UNKNOWN 18C05F5F

Timestamp : 000225.654
Library   : v2.8.6

Protocol  : TOSHIBA_AC
Code      : 0xF20D03FC0130A30092 (72 Bits)
Mesg Desc.: Temp: 20C, Power: On, Mode: 3 (Heat), Fan: 4 (UNKNOWN), Turbo: Off, Econo: Off, Filter: Off
uint16_t rawData[295] = {4468, 4392,  588, 1582,  588, 1578,  528, 1646,  606, 1572,  588, 496,  588, 496,  588, 1582,  588, 496,  588, 500,  584, 510,  584, 506,  584, 506,  588, 1574,  588, 1582,  588, 506,  588, 1574,  588, 498,  588, 496,  588, 500,  588, 500,  588, 504,  588, 506,  584, 1582,  588, 1574,  588, 1578,  588, 1574,  588, 1578,  588, 1574,  588, 1574,  588, 1578,  588, 496,  588, 496,  588, 500,  584, 500,  588, 502,  588, 502,  588, 506,  588, 506,  584, 500,  588, 1586,  588, 496,  588, 500,  588, 1574,  588, 1586,  588, 496,  588, 506,  588, 506,  588, 506,  588, 1574,  588, 500,  584, 1578,  588, 506,  588, 506,  588, 506,  584, 1578,  588, 1574,  588, 506,  588, 502,  588, 502,  588, 500,  588, 500,  588, 506,  588, 504,  588, 504,  588, 1578,  588, 496,  588, 502,  584, 1590,  588, 506,  588, 496,  588, 1582,  582, 506,  588, 5584,  4462, 4396,  588, 1582,  588, 1582,  588, 1578,  584, 1578,  588, 510,  584, 504,  588, 1574,  588, 502,  584, 500,  588, 496,  588, 502,  584, 506,  588, 1578,  588, 1592,  586, 506,  584, 1578,  588, 518,  588, 500,  586, 502,  588, 502,  588, 506,  584, 504,  588, 1578,  584, 1578,  588, 1574,  588, 1572,  588, 1586,  604, 1574,  588, 1574,  588, 1582,  588, 502,  588, 506,  588, 502,  588, 502,  582, 506,  582, 506,  584, 506,  588, 496,  588, 518,  588, 1574,  588, 518,  586, 502,  588, 1590,  588, 1590,  584, 506,  588, 496,  588, 518,  584, 510,  588, 1588,  588, 500,  588, 1586,  588, 504,  584, 504,  588, 506,  584, 1578,  588, 1572,  588, 496,  588, 500,  584, 500,  588, 496,  588, 500,  588, 506,  588, 504,  588, 500,  588, 1578,  528, 578,  588, 500,  588, 1574,  588, 496,  588, 496,  588, 1578,  588, 502,  584};  // TOSHIBA_AC
uint8_t state[9] = {0xF2, 0x0D, 0x03, 0xFC, 0x01, 0x30, 0xA3, 0x00, 0x92};

I was initially thinking that there could be a tolerance issue when decoding, but manually decoding the raw data using the same parameters as IRrecv::decodeToshibaAC does produces the same results for both messages.

Here is a google sheet with the decoding, using (hopefully correct) values from ir_Toshiba: https://docs.google.com/spreadsheets/d/1FiUfnScaGxqL5kcyYkxIEdsQ-onuoPvEDNaQlR4xVXY/edit?usp=sharing

Computing some stats from the auto_analyse_raw_data.py script over many messages gives the following values (ref are values from ir_Toshiba.cpp, dev/ref is the std deviation from that reference):

Protocol TOSHIBA_AC (38 messages):
key        min  max  average stddev ref  dev/ref dev/ref %
---------- ---- ---- ------- ------ ---- ------- ---------
kHdrMark   4446 4476 4464    4.5    4400 64.1    1%
kHdrSpace  4378 4419 4395.9  6.5    4300 96.1    2%
kBitMark   563  590  587.1   4.2    580  8.2     1%
kOneSpace  1573 1604 1577.9  5      1600 22.6    1%
kZeroSpace 497  525  500.7   4.5    490  11.6    2%
kSpaceGap  5580 5618 5589.8  7      4600 989.8   22%
---------- ---- ---- ------- ------ ---- ------- ---------

Protocol UNKNOWN (26 messages):
key        min  max  average stddev ref  dev/ref dev/ref %
---------- ---- ---- ------- ------ ---- ------- ---------
kHdrMark   4434 4477 4461.5  9.1    4400 62.2    1%
kHdrSpace  4381 4429 4399.9  10.1   4300 100.4   2%
kBitMark   563  588  584.4   7.3    580  8.5     1%
kOneSpace  1575 1605 1581.1  7.9    1600 20.5    1%
kZeroSpace 499  525  504.6   7.3    490  16.3    3%
kSpaceGap  5560 5616 5589.6  12.1   4600 989.7   22%
---------- ---- ---- ------- ------ ---- ------- ---------

Overall unrecognized messages are spread further apart from the average but that's still minuscule compared to the 25% tolerance.

I will dig a bit more into it, but in the mean time if anyone has an idea what could be going wrong here...

[crankyoldgit]

It is a tolerance issue. There are values (e.g. 578) which are slightly out of spec/expected. If you increase the tolerance by about 7 or more. It will match correctly. I've tested that with your above data.

[njoyard]

Indeed. However it's not enough to decode all messages.

I ended up changing the excess parameter, from 50us to 25us (marks are not really shorter than expected, and spaces not longer than expected) and I have yet to find a single case where the signal is not properly decoded.

Thanks!

[runemoennike]

Hi @njoyard

Could you hint at where this excess parameter is in the code? 😁 I'm trying to get my Toshiba HVAC with a similar looking remote to work with tasmota-ir. I believe it uses this library.

Thanks, Rune

Update: Nvm, found it 😊

[njoyard]

For reference for other people:

diff --git a/src/ir_Toshiba.cpp b/src/ir_Toshiba.cpp
index c9672bca..1557f5ba 100644
--- a/src/ir_Toshiba.cpp
+++ b/src/ir_Toshiba.cpp
@@ -32,6 +32,8 @@ const uint16_t kToshibaAcZeroSpace = 490;
 const uint16_t kToshibaAcMinGap = 4600;    // WH-UB03NJ remote
 const uint16_t kToshibaAcUsualGap = 7400;  // Others

+const uint16_t kToshibaAcMarkExcess = 25;
+
 using irutils::addBoolToString;
 using irutils::addFanToString;
 using irutils::addIntToString;
@@ -523,7 +546,7 @@ bool IRrecv::decodeToshibaAC(decode_results* results, uint16_t offset,
                     kToshibaAcBitMark, kToshibaAcOneSpace,
                     kToshibaAcBitMark, kToshibaAcZeroSpace,
                     kToshibaAcBitMark, kToshibaAcMinGap, true,
-                    _tolerance, kMarkExcess)) return false;
+                    _tolerance, kToshibaAcMarkExcess)) return false;
   // Compliance
   if (strict) {
     // Check that the checksum of the message is correct.

I have a PR cooking to add support for some features, I'll add this inside (but keeping the default 50us values, just to make it easier for people to change it)

[runemoennike]

Great, thanks!

After trying a bunch of things, I upgraded to tasmota-ir 13.x from 10.x that the Athom AR01 came with. It now reads the messages from my remote flawlessly, woho! Although I can't be sure if it's that upgrade, or if Athom had made other changes to the original firmware, I guess.

I also changed SetOption48 to 50 before the upgrade, which didn't help. I haven't changed it back yet with the upgraded firmware to check if that changes anything.

Out of curiosity, what features have you added? :)