Protocol Request: Mitsubishi Heavy Industries (Jinling) SRK-AJ — undocumented 64-bit A/C IR protocol

[bluebirdlboro]

Protocol / device

• Brand: Mitsubishi Heavy Industries (made by the MHI–Jinling JV for the Chinese market)
• Indoor unit: SRKAJ35H1VB
• Outdoor unit: SRCAJ35H1VB
• Remote model: RYD502A003B
• Year: 2017
• Refrigerant: R410A

Why this is not already supported

The library already has the Japanese MHI protocols (MITSUBISHI_HEAVY_88 = 11 bytes, MITSUBISHI_HEAVY_152 = 19 bytes). This Chinese MHI–Jinling unit uses a completely different, much shorter 64-bit (8-byte) frame that none of the existing Mitsubishi / MitsubishiHeavy decoders match. I confirmed against v2.9.0 that the smallest Mitsubishi A/C state length in the library is 11 bytes, so there is no overlap.

Frame structure (reverse-engineered)

8 bytes, sent as 4 pairs of [data][~data] (each pair sums to 0xFF — built-in checksum):

Byte	Value	Meaning
B0 / B1	0xFF / 0x00	fixed header
B2 / B3	data / ~data	Fan: High 0xFF/0x00, Med 0xBF/0x40, Low 0x9F/0x60
B4 / B5	data / ~data	B4 = ((32-temp) & 0xF) << 4 | mode; mode Cool=6 Dry=5 Fan=4 Heat=3, bit3 = power-off. B5 = 0xFF - B4
B6 / B7	0x2A / 0xD5	fixed trailer (0x2A+0xD5 = 0xFF)

Timing (µs, 38 kHz, frame repeated 3× with 50 ms gap)

• Header mark / space: 5950 / 7475
• Bit mark: 508
• One space: 3454, Zero space: 1496
• Trailer mark / space: 508 / 7422

What I currently have / scope

• Fully working send (sendRaw-based) for temperature, mode, fan — verified against the real unit.
• Decode + checksum validation also working in my own firmware.
• Not yet captured: sleep, timer, swing, etc. (I only reverse-engineered the 3 fields above.)

Questions before I open a PR

1. Would you accept this as a new protocol? If so, how would you prefer it named/grouped (a new MitsubishiHeavyJinling family, or extend the existing MitsubishiHeavy file)?
2. Is "temp/mode/fan only" acceptable to start, or do you require the full remote feature set before merging?
3. Do you want raw IRrecvDumpV3 captures attached for the test cases? I can provide them.

I have working hardware and am happy to do the full protocol class + unit tests + docs if this is something you'd merge.

[NiKiZe]

As covered by FAQ, first step is basic protocol support without AC specifics, the usual test to get this right is to get the full dump of lowest to highest temp values + on/off, a few of those in unit tests but maybe not all, still good to have the raw captures (in issue) for future reference.

[crankyoldgit]

@bluebirdlboro Try following the steps of https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-IR-protocol & https://github.com/crankyoldgit/IRremoteESP8266/wiki/Adding-support-for-a-new-AC-protocol

Once you share that (raw) data and such, people can work to add it to the library.

[crankyoldgit]

(each pair sums to 0xFF — built-in checksum)

While that looks true (because it is in a way), it's easier and probably more correct to say the second byte is the XOR of the first byte (and vice versa) ie. The bitwise complement.

B4 = ((32-temp) & 0xF) << 4 | mode; mode Cool=6 Dry=5 Fan=4 Heat=3, bit3 = power-off.

My guess is you've probably got the 1s & 0s reversed. Try treating the zeros as ones, and vice versa. You might find the temperature values fall out nicely and simply. Another common sign is all most all the AC protocols have a single bit that is On(1) when the device is meant to be running, rather than being a Zero(0) when it's on/running.

Hope that helps.

[bluebirdlboro]

Hi NiKiZe,

Thanks for the green light. I've prepared a basic protocol implementation for the Mitsubishi Heavy Jinling series remote (RYD502A003B).

Scope confirmation: This PR covers only basic protocol support (sendXxx() + decodeXxx() + enum registration + unit tests), without AC specifics (IRac integration / setTemp/setMode etc.) as discussed. AC specifics can follow in a separate PR.

Implementation details:

• Protocol: 64-bit custom, MSB-first, timing 5950/7475/508/3454/1496/508/7422
• Frame: FF 00 B2 ~B2 B4 ~B4 2A D5 (B2=fan, B4=temp|mode with checksum)
• Based on captured dumps from the actual remote, sampled across 18–30°C (even steps), all modes (Cool/Dry/Heat), and on/off
• Template: ir_Doshisha.cpp was used as reference
• Unit tests: 5 tests (4 real frame decode + 1 round-trip), all passing

One naming question: I've tentatively used MITSUBISHI_HEAVY_JINLING as a new protocol family (since the frame structure is completely different from existing MitsubishiHeavy 88/152-bit variants). But please let me know if you prefer a different name, or if I should extend an existing file instead.

Raw captured dumps are available for reference.

Thanks,
bluebird

[crankyoldgit]

One naming question: I've tentatively used MITSUBISHI_HEAVY_JINLING as a new protocol family (since the frame structure is completely different from existing MitsubishiHeavy 88/152-bit variants). But please let me know if you prefer a different name, or if I should extend an existing file instead.

This protocol looks remarkably similar to the other MitsubishiHeavy protocols, so it really should go in the existing file.
e.g. You may even be able to reuse code from them. i.e. To verify the checksum.
see the following for example:

IRremoteESP8266/src/ir_MitsubishiHeavy.cpp

Lines 326 to 337 in 936f5e0

	/// Verify the checksum is valid for a given state.
	/// @param[in] state The array to verify the checksum of.
	/// @param[in] length The length/size of the state array.
	/// @return true, if the state has a valid checksum. Otherwise, false.
	/// Note: Technically it has no checksum, but does have inverted byte pairs.
	bool IRMitsubishiHeavy152Ac::validChecksum(const uint8_t *state,
	const uint16_t length) {
	// Assume anything too short is fine.
	if (length < kMitsubishiHeavySigLength) return true;
	const uint8_t kOffset = kMitsubishiHeavySigLength - 2;
	return checkInvertedBytePairs(state + kOffset, length - kOffset);
	}

Given how similar it is, I'd name it MITSUBISHI_HEAVY_64. Also, I know you've coded it as a uint64_t type structure, but AC code typically is easier for people to follow the array structure style for handling bit & byte addressing. Plus you get to reuse some code ;-)

But, as the MARKs & SPACEs are different, having it in it's own file is cool too. Just people looking at a device labled Mitsubish Heavy etc people will tend to look in that file first.
Not always a great solution. See the Daikin file as a counter example. A zillion protocol versions, all sort-of alike, but not. And a mess. ;-)

[bluebirdlboro]

Thanks @crankyoldgit, that's all really helpful. I've opened #2265 with the changes:

• Renamed to MITSUBISHI_HEAVY_64 and moved it into ir_MitsubishiHeavy.cpp/.h alongside the 88/152-bit variants.
• Switched from a uint64_t to an array (uint8_t[8]) style, and the compliance check now reuses irutils::checkInvertedBytePairs() — the whole frame is four inverted byte pairs (FF 00 | B2 ~B2 | B4 ~B4 | 2A D5), so there's no separate checksum byte.

On the "1s & 0s reversed" hint: I went back over the captures. The on-air bytes give a clean temp = 32 - value relationship across the whole sweep (18→0xE, 24→0x8, 30→0x2, etc.), and complementing that nibble yields value = temp - 17, which isn't actually simpler — so I've kept the on-air byte values as-is for this basic-protocol PR. You're right that the power bit reads as active-low here, which is unusual; I'll pin down the exact temp/mode/fan/power polarity in the follow-up AC-specifics PR rather than guess at it now.

Full lowest→highest temperature sweep + on/off raw captures are in the dumps above for reference.

[NiKiZe]

Sorry, but where are the raw dumps?, can you post them as a code block to this issue so it is easy to view, if you have a proposed decoding feel free to have that included.