Add MITSUBISHI_HEAVY_64 basic protocol support (RYD502A003B)#2265
Add MITSUBISHI_HEAVY_64 basic protocol support (RYD502A003B)#2265bluebirdlboro wants to merge 1 commit into
Conversation
| kZepealZeroMark LITERAL1 | ||
| kZepealZeroSpace LITERAL1 | ||
| kZoneFollowStr LITERAL1 | ||
| sendMitsubishiHeavy64 KEYWORD2 |
There was a problem hiding this comment.
This file should not be included in this PR, it is only updated as part of the release process.
| @@ -1,6 +1,6 @@ | |||
| <!--- WARNING: Do NOT edit this file directly. | |||
| It is generated by './tools/scrape_supported_devices.py'. | |||
| Last generated: Fri 02 Jan 2026 11:00:57 +0000 ---> | |||
There was a problem hiding this comment.
This file should not be included in this PR, it is only updated as part of the release process.
| return true; | ||
| } | ||
|
|
||
| /// Send a complex (>= 64 bits) IR message of a given type. |
bluebirdlboro
force-pushed
the
feat/add-mitsubishi-heavy-64
branch
from
1fa2fff to
5a99606
Compare
|
Thanks @NiKiZe — addressed all three:
I also re-captured a clean full temperature sweep (18–30 °C) + on/off from the remote and updated the four unit-test captures to match it. The complete raw captures are now posted in #2262 for reference. |
crankyoldgit
left a comment
crankyoldgit
left a comment
There was a problem hiding this comment.
In general, this is fine to be added. Just a couple of minor issues to resolve first.
There was a problem hiding this comment.
As it's now using a state instead of value, you need to add it here.
There was a problem hiding this comment.
Good catch — added DECODE_MITSUBISHI_HEAVY_64 to the DECODE_AC block now that it decodes into result->state.
| const uint16_t kMitsubishiHeavy64BitMark = 508; | ||
| const uint16_t kMitsubishiHeavy64OneSpace = 3454; | ||
| const uint16_t kMitsubishiHeavy64ZeroSpace = 1496; | ||
| const uint16_t kMitsubishiHeavy64Gap = 7422; |
There was a problem hiding this comment.
This seem's awfully short for a gap for between messages. How was this calculated? Just checking?
e.g. how big a gap is there between repeats messages?
There was a problem hiding this comment.
Not a guess — it's the measured gap between repeats. Each raw capture ends with a trailing space of ~7422–7426 µs, after which the leading mark of the next repeat appears, so the capture caught that leading edge and it isn't a timeout artifact. It is short because this remote uses a short inter-repeat gap — it's about the same as the header space (7475 µs).
Example tail of a Cool-18 °C capture: ..., 506, 3464, 506, 7424, 532 where 7424 is the inter-repeat gap and 532 is the start of the next frame. I've added a comment documenting this; the full raw dumps are in #2262.
Adds basic send & decode support for the 64-bit Mitsubishi Heavy Industries IR protocol used by the RYD502A003B remote (SRKxxAJ-S A/C, the Chinese "Jinling" joint-venture units). Scope is basic protocol support only (no IRac / AC-specifics), as discussed in issue crankyoldgit#2262. Details: - Lives in ir_MitsubishiHeavy.cpp/.h alongside the 88/152-bit variants and named MITSUBISHI_HEAVY_64, per maintainer request. - Array/state style (uint8_t[8]) rather than a uint64_t, reusing the existing irutils::checkInvertedBytePairs() helper. The whole 8-byte frame is four inverted byte pairs (FF 00 | B2 ~B2 | B4 ~B4 | 2A D5), so there is no separate checksum byte. - Bytes are sent/decoded LSB-first (MSBfirst=false), matching the remote's on-air byte values. - Unit tests: 4 real captures (Cool 18/24/30C, Off) + a send/decode round-trip + a bad-frame rejection test. The full temperature sweep (18-30C) + on/off raw captures are recorded in issue crankyoldgit#2262 for reference. See crankyoldgit#2262
bluebirdlboro
force-pushed
the
feat/add-mitsubishi-heavy-64
branch
from
5a99606 to
dadb8ba
Compare
3 participants
Resolves the basic-protocol part of #2262.
Adds basic send & decode support for the 64-bit Mitsubishi Heavy Industries IR protocol used by the RYD502A003B remote (SRKxxAJ-S A/C — the Chinese "Jinling" joint-venture units). Scope is basic protocol only, no
IRac/ AC specifics, as agreed in the issue.Addressing the review feedback in #2262
MITSUBISHI_HEAVY_64(not a separate "Jinling" family), per @crankyoldgit's suggestion.ir_MitsubishiHeavy.cpp/.hnext to the 88/152-bit variants, so people looking at a "Mitsubishi Heavy" labelled device find it in the expected place.uint8_t[8]state array rather than auint64_t, and the compliance check reuses the existingirutils::checkInvertedBytePairs()helper.Protocol notes
The whole 8-byte frame is four inverted byte pairs — there is no separate checksum byte:
FF 00header and2A D5footer are fixed;B2/~B2carries fan andB4/~B4carries temperature + mode. Bytes are sent/decoded LSB-first (MSBfirst=false), matching the remote's on-air byte values. The exact temperature/mode/fan bit semantics are deliberately left out of this PR and will follow in a separate AC-specifics PR.Tests
test/ir_MitsubishiHeavy_test.cpp:TestMitsubishiHeavyhousekeeping testFull lowest→highest temperature sweep + on/off raw captures are recorded in #2262 for future reference.
make runpasses locally andcpplintis clean.SupportedProtocols.mdregenerated viatools/scrape_supported_devices.py.