RC-MM Protocol For IRremoteESP8266 #21

darshkpatel · 2016-04-02T13:10:20Z

I came across a remote which uses RC-MM protocol (probably also known as Nokia 24 ) , I needed help adding that to IRremoteESP8266 library.

here is a sample for the same

This is the dump of the "same button" being pressed 10 times

``Encoding : UNKNOWN
Code : 49EF3073 (32 bits)
Timing[35]:

450, - 250 + 150, - 300 + 200, - 550 + 150, - 600
200, - 250 + 200, - 750 + 200, - 550 + 200, - 250
200, - 250 + 150, - 600 + 200, - 550 + 200, - 450
150, - 600 + 150, - 300 + 150, - 300 + 150, - 250
200, - 250 + 150
unsigned int rawData[35] = {450,250, 150,300, 200,550, 150,600, 200,250, 200,750, 200,550, 200,250, 200,250, 150,600, 200,550, 200,450, 150,600, 150,300, 150,300, 150,250, 200,250, 150}; // UNKNOWN 49EF3073

Encoding : UNKNOWN
Code : 6E277A3 (32 bits)
Timing[35]:

450, - 250 + 150, - 250 + 200, - 600 + 150, - 600
200, - 250 + 150, - 800 + 150, - 600 + 150, - 300
150, - 300 + 150, - 250 + 200, - 600 + 150, - 450
150, - 600 + 200, - 250 + 150, - 300 + 150, - 250
200, - 250 + 200
unsigned int rawData[35] = {450,250, 150,250, 200,600, 150,600, 200,250, 150,800, 150,600, 150,300, 150,300, 150,250, 200,600, 150,450, 150,600, 200,250, 150,300, 150,250, 200,250, 200}; // UNKNOWN 6E277A3

Encoding : UNKNOWN
Code : B70D49E4 (32 bits)
Timing[35]:

450, - 250 + 150, - 300 + 150, - 600 + 150, - 600
200, - 250 + 200, - 750 + 150, - 600 + 200, - 250
200, - 250 + 150, - 600 + 200, - 600 + 150, - 450
150, - 600 + 200, - 250 + 150, - 300 + 150, - 250
200, - 250 + 200
unsigned int rawData[35] = {450,250, 150,300, 150,600, 150,600, 200,250, 200,750, 150,600, 200,250, 200,250, 150,600, 200,600, 150,450, 150,600, 200,250, 150,300, 150,250, 200,250, 200}; // UNKNOWN B70D49E4

Encoding : UNKNOWN
Code : 25D6E01D (32 bits)
Timing[35]:

450, - 250 + 150, - 250 + 200, - 600 + 150, - 600
200, - 250 + 150, - 800 + 150, - 600 + 200, - 250
150, - 300 + 150, - 250 + 200, - 600 + 150, - 450
150, - 600 + 200, - 250 + 150, - 300 + 150, - 300
150, - 250 + 200
unsigned int rawData[35] = {450,250, 150,250, 200,600, 150,600, 200,250, 150,800, 150,600, 200,250, 150,300, 150,250, 200,600, 150,450, 150,600, 200,250, 150,300, 150,300, 150,250, 200}; // UNKNOWN 25D6E01D

Encoding : UNKNOWN
Code : 40033D4D (32 bits)
Timing[35]:

450, - 250 + 200, - 250 + 150, - 600 + 200, - 600
150, - 300 + 150, - 750 + 200, - 600 + 150, - 250
200, - 250 + 200, - 600 + 150, - 600 + 150, - 450
150, - 600 + 200, - 250 + 200, - 250 + 150, - 300
150, - 250 + 200
unsigned int rawData[35] = {450,250, 200,250, 150,600, 200,600, 150,300, 150,750, 200,600, 150,250, 200,250, 200,600, 150,600, 150,450, 150,600, 200,250, 200,250, 150,300, 150,250, 200}; // UNKNOWN 40033D4D

Encoding : UNKNOWN
Code : 6E277A3 (32 bits)
Timing[35]:

450, - 250 + 150, - 250 + 200, - 600 + 150, - 600
200, - 250 + 150, - 800 + 150, - 600 + 150, - 300
150, - 300 + 150, - 250 + 200, - 600 + 150, - 450
150, - 600 + 200, - 250 + 150, - 300 + 150, - 250
200, - 250 + 200
unsigned int rawData[35] = {450,250, 150,250, 200,600, 150,600, 200,250, 150,800, 150,600, 150,300, 150,300, 150,250, 200,600, 150,450, 150,600, 200,250, 150,300, 150,250, 200,250, 200}; // UNKNOWN 6E277A3

Encoding : UNKNOWN
Code : 9A2A2562 (32 bits)
Timing[35]:

450, - 250 + 150, - 250 + 200, - 600 + 150, - 600
200, - 250 + 150, - 800 + 150, - 600 + 150, - 300
150, - 250 + 200, - 600 + 150, - 600 + 200, - 400
200, - 600 + 150, - 300 + 150, - 250 + 200, - 250
200, - 250 + 150
unsigned int rawData[35] = {450,250, 150,250, 200,600, 150,600, 200,250, 150,800, 150,600, 150,300, 150,250, 200,600, 150,600, 200,400, 200,600, 150,300, 150,250, 200,250, 200,250, 150}; // UNKNOWN 9A2A2562

Encoding : UNKNOWN
Code : DF6C1994 (32 bits)
Timing[35]:

450, - 250 + 200, - 250 + 150, - 600 + 200, - 600
150, - 300 + 150, - 750 + 200, - 600 + 150, - 250
200, - 250 + 200, - 250 + 150, - 600 + 200, - 400
200, - 600 + 150, - 300 + 150, - 250 + 200, - 250
200, - 250 + 150
unsigned int rawData[35] = {450,250, 200,250, 150,600, 200,600, 150,300, 150,750, 200,600, 150,250, 200,250, 200,250, 150,600, 200,400, 200,600, 150,300, 150,250, 200,250, 200,250, 150}; // UNKNOWN DF6C1994

Encoding : UNKNOWN
Code : 2EA1533E (32 bits)
Timing[35]:

450, - 200 + 200, - 250 + 200, - 600 + 150, - 600
150, - 300 + 150, - 750 + 200, - 600 + 150, - 300
150, - 250 + 200, - 600 + 150, - 600 + 200, - 400
200, - 600 + 150, - 250 + 200, - 250 + 200, - 250
150, - 300 + 150
unsigned int rawData[35] = {450,200, 200,250, 200,600, 150,600, 150,300, 150,750, 200,600, 150,300, 150,250, 200,600, 150,600, 200,400, 200,600, 150,250, 200,250, 200,250, 150,300, 150}; // UNKNOWN 2EA1533E

Encoding : UNKNOWN
Code : 915E804D (32 bits)
Timing[35]:

450, - 250 + 150, - 300 + 150, - 600 + 200, - 550
200, - 250 + 200, - 750 + 150, - 600 + 200, - 250
200, - 250 + 150, - 300 + 150, - 600 + 200, - 400
200, - 550 + 200, - 250 + 200, - 250 + 200, - 250
150, - 300 + 150
unsigned int rawData[35] = {450,250, 150,300, 150,600, 200,550, 200,250, 200,750, 150,600, 200,250, 200,250, 150,300, 150,600, 200,400, 200,550, 200,250, 200,250, 200,250, 150,300, 150}; // UNKNOWN 915E804D

Encoding : UNKNOWN
Code : 7B255A09 (32 bits)
Timing[35]:

400, - 250 + 200, - 250 + 200, - 550 + 200, - 600
150, - 300 + 150, - 750 + 200, - 600 + 150, - 250
200, - 250 + 200, - 600 + 150, - 600 + 150, - 450
200, - 550 + 200, - 250 + 200, - 250 + 150, - 300
150, - 300 + 150
unsigned int rawData[35] = {400,250, 200,250, 200,550, 200,600, 150,300, 150,750, 200,600, 150,250, 200,250, 200,600, 150,600, 150,450, 200,550, 200,250, 200,250, 150,300, 150,300, 150}; // UNKNOWN 7B255A09

Encoding : UNKNOWN
Code : AD737632 (32 bits)
Timing[35]:

450, - 250 + 150, - 250 + 200, - 600 + 150, - 600
200, - 250 + 200, - 750 + 150, - 600 + 200, - 250
150, - 300 + 150, - 250 + 200, - 600 + 150, - 450
150, - 600 + 200, - 250 + 200, - 250 + 150, - 300
150, - 250 + 200`

crankyoldgit · 2017-03-18T14:44:43Z

The protocol is documented here: http://www.sbprojects.com/knowledge/ir/rcmm.php

Seems fairly straight forward, yet a little odd compared to other common protocols.

crankyoldgit · 2017-03-18T16:16:25Z

@darshkpatel Care to give https://github.com/crankyoldgit/IRremoteESP8266/tree/philips-rc-mm a try?

crankyoldgit · 2017-03-22T10:16:58Z

Ping.

crankyoldgit · 2017-03-30T02:43:01Z

Ping.

darshkpatel · 2017-03-30T03:20:26Z

Sure, let me see

…

On Mar 30, 2017 8:13 AM, "David Conran" ***@***.***> wrote: Ping. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKvJrhmXJIXzdIjHusVcQVthjBZ_NQ8dks5rqxa2gaJpZM4H-Rsj> .

darshkpatel · 2017-03-30T03:25:56Z

@crankyoldgit
Sorry for the long day
I checked it on my bench and the lib
Could identify the protocol , but still gives different codes for the same button

darshkpatel · 2017-03-30T03:32:49Z

I enquired with a few colleagues , came to know it's not the protocol, but the wrong receiver for the frequency the IR transmitter is transmitting at.

I suppose someone with the right receiver can try it out ?
The 38KHz receiver doesn't work well

crankyoldgit · 2017-03-30T03:33:59Z

Um, let me check/confirm. Are you trying to send RC-MM or receive it?

I only added sending btw. If you are getting different results from something for each send, can you share them please? It should produce the same signal when sending the same data., but seeing the different outputs might help me work out what's not working.

crankyoldgit · 2017-03-30T03:38:46Z

Ah, yeah. 38kHz vs 36kHz might be an issue. Don't know. I've only got 38kHz ones myself. :-(

darshkpatel · 2017-03-30T11:37:35Z

Same here, guess we'll have to wait for someone else to confirm On Mar 30, 2017 9:08 AM, "David Conran" <notifications@github.com> wrote: Ah, yeah. 38kHz vs 36kHz might be an issue. Don't know. I've only got 38kHz ones myself. :-( — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKvJrmA09ubr9H3UWXmL1mjsdYL4ORQGks5rqyPHgaJpZM4H-Rsj> .

crankyoldgit · 2017-03-30T11:56:06Z

I might add what I've got to the library as is, and label it untested/experimental etc. That way someone might be able to check it.

Or, you could probably order a 36kHz receiver module off ebay for a couple of dollars etc.

crankyoldgit · 2017-03-30T12:09:20Z

Actually, can you describe what the testing setup is? I didn't add a decode for rc-mm, just the sender.

but still gives different codes for the same button

the 'unknown' code values should be taken with a grain of salt. It is a hash of the raw data, not an indication of the actual code signal. A minute change in a timing length will produce a very different 'unknown' code even if the underlying pattern is the same. The underlying pattern in your earlier examples however looks fine/the same. So, I can probably try to add a decode routine we might have some luck.

crankyoldgit · 2017-03-30T13:09:39Z

Decoding one of your captures by hand:

unsigned int rawData[35] = {450,250, 150,300, 150,600, 150,600, 200,250, 200,750, 150,600, 200,250, 200,250, 150,600, 200,600, 150,450, 150,600, 200,250, 150,300, 150,250, 200,250, 200};

HEADER + 00 + 10 + 10 + 00 + 11 + 10 + 00 + 00 + 10 + 10 + 01 + 10 + 00 + 00 + 00 + 00 + FOOTER
== B00101000111000001010011000000000 == 32 bits of data (which the protocol says should only be 12 or 24 bits???) == 0x28e0a600

crankyoldgit · 2017-03-30T13:57:05Z

Hey @darshkpatel, care to try the latest update to my 'philips-rc-mm' branch?
Based on the data you provided, I think I now understand the RC-MM protocol better than the limited reference docs I could find. i.e. There is a footer mark that wasn't documented.

It also has my very first attempt at writing a decode routine. No promises etc. Completely untested. No warranties etc etc.

darshkpatel · 2017-03-31T02:28:43Z

Sure, I'll check it as soon as I get home on 15th Apologies for the delay

…

On Mar 30, 2017 7:27 PM, "David Conran" ***@***.***> wrote: Hey @darshkpatel <https://github.com/darshkpatel>, care to try the latest update to my 'philips-rc-mm' branch? Based on the data you provided, I think I now understand the RC-MM protocol better than the limited reference docs I could find. i.e. There is a footer mark that wasn't documented. It also has my very first attempt at writing a decode routine. No promises etc. Completely untested. No warranties etc etc. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKvJrribJ6m2nGqpgd8qk_kDHoPcBjmKks5rq7SygaJpZM4H-Rsj> .

ghost · 2017-04-06T18:30:07Z

I have got it working with 38khz tsop38338, tested this with stb remote with success, was looking for this for a long! thanks and kudos

ghost · 2017-04-06T18:31:01Z

I have tested the decoding (receiving), will confirm the send too tomorrow.

ghost · 2017-04-06T18:32:35Z

crankyoldgit · 2017-04-06T23:41:54Z

Many thanks for that @tejipal
However, I think I have a bug. Decoding by hand, that middle dump should decode to:
B00100110000000000010011100000010 (0x26002702)
yet my code is getting:
B00010101000000000001011000000001 (0x15001601)

I think it is not matching the spaces well, in that it is matching a lower 2-bit value when it should be matching a higher 2-bit value per mark/space pair.

Looking at the code MATCH code, the tolerances for it matching are too wide. We need to reduce the tolerances for this to accurately match values received.
e.g.
a space of 550us (which should equal to B10 (0x2) for which we expect has a space of 611us) has a lower tolerance of 611*0.75 = ~458us and an upper of 611*1.25 = ~764ms. This also matches the recorded space of 750us (which should be B11 (0x3) which has an expected value of 777us).

I'll need to work out a nice way to reduce the tolerances for this protocol and not for all the others for this to work correctly.

**Completely untested.** Based on timings and protocol descriptions from: http://www.sbprojects.com/knowledge/ir/rcmm.php For issue #21

ghost · 2017-04-07T15:37:22Z

the tolerance thingy looks promising, I will test it again and get back with results. I also ordered 36khz decoder, will share results after testing.

ghost · 2017-04-07T15:38:29Z

hatts off to your quick remedy :)

crankyoldgit · 2017-04-07T16:04:52Z

@tejipal I'm currently developing in my personal fork under this branch https://github.com/crankyoldgit/IRremoteESP8266/tree/rework-match

But beware, I haven't tested it at all yet. It's flat out compiling. ;-) i.e. Expect things to break.

…ing. (#156) * Move the match routines inside the irrecv object. * Relocate some defines to a more appropriate location. * Change the match routines have runtime definable tolerance and excess. * Match routines now return boolean, rather than int. * Add plenty of comments. * Change the way DEBUGing is handled for the match routines. * Turn the TICKS_LOW & TICKS_HIGH macros into proper functions. * Use a tolerance of +/-10% for matching the data 'spaces' as the default tolerance was to high and caused mismatches. (#21) * Allow for different excesses to be used in the matching functions. * Fix the incorrect RC-MM '0' space value * Enforce the minimum gap between RC-MM codes per spec.

…ing. (#150) * Move the match routines inside the irrecv object. * Relocate some defines to a more appropriate location. * Change the match routines have runtime definable tolerance and excess. * Match routines now return boolean, rather than int. * Add plenty of comments. * Change the way DEBUGing is handled for the match routines. * Turn the TICKS_LOW & TICKS_HIGH macros into proper functions. * Use a tolerance of +/-10% for matching the data 'spaces' as the default tolerance was to high and caused mismatches. (#21) * Allow for different excesses to be used in the matching functions. * Fix the incorrect RC-MM '0' space value * Enforce the minimum gap between RC-MM codes per spec.

crankyoldgit · 2017-04-23T03:51:14Z

@tejipal & @darshkpatel Care to test the current master branch? Should be better/working, I think. (famously wrong/last words.)

darshkpatel · 2017-04-23T12:04:37Z

I gotta wait until another ESP is shipped.

…

On Apr 23, 2017 9:21 AM, "David Conran" ***@***.***> wrote: @tejipal <https://github.com/tejipal> & @darshkpatel <https://github.com/darshkpatel> Care to test the current *master* branch? Should be better/working, I think. (famously wrong/last words.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKvJrvrpqczrf0V4CND1GciMb7b7dczJks5rysqygaJpZM4H-Rsj> .

crankyoldgit · 2017-05-16T09:17:19Z

@darshkpatel Did your next ESP arrive? Care to test master and/or v2.0-dev branch?

darshkpatel · 2017-05-16T12:02:43Z

I'm sorry, It just slipped out of my mind I'll test it this week for sure On May 16, 2017 2:47 PM, "David Conran" <notifications@github.com> wrote: @darshkpatel <https://github.com/darshkpatel> Did your next ESP arrive? Care to test master and/or v2.0-dev branch? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKvJrhKXSzQhrgzJHLezA9UuFPADkq6oks5r6WmfgaJpZM4H-Rsj> .

crankyoldgit · 2017-05-16T12:51:43Z

No worries. I'm writing some test-cases for the code now. So, in a day or so I should be more confident if it will work or not, but nothing beats real-world tests.

- Unit test coverage for sendRCMM() and decodeRCMM() - Update status for those to Beta as tests now work on them. - Minor code/ordering optimisation. - [Fix] Removed special tolerence for the bit mark which caused issues in decoding. - Bring RC-MM up to 64bit support. - Add repeating to sendRCMM. This should address issue #21 when v2.0 is released.

crankyoldgit · 2017-05-17T07:20:47Z

@darshkpatel & @tejipal The v2.0-dev tree should have an updated & working version for both sending and decoding.

I think I've ironed out the remaining bugs when I wrote the unit tests for them, but real hardware is different etc.

Note: You'll need to call it via sendRCMM(0xb01dface, 32); etc if you want to send your 32-bit messages you've listed in this issue. It defaults to 24-bits.

Feedback etc most welcome. Good or bad. :)

I'm hoping to have a release candidate out for v2.0 by the end of the month.

darshkpatel · 2017-05-17T15:37:46Z

I tried it with my existing receiver tsop1738 but it seems like 38khz TSOP38338 is needed, it still gives different codes for same button presses

…

On Wed, May 17, 2017 at 12:50 PM, David Conran ***@***.***> wrote: @darshkpatel <https://github.com/darshkpatel> & @tejipal <https://github.com/tejipal> The v2.0-dev <https://github.com/markszabo/IRremoteESP8266/tree/v2.0-dev> tree should have an updated & working version for both sending and decoding. I think I've ironed out the remaining bugs when I wrote the uinit tests for them, but real hardware is different etc. Note: You'll need to call it via sendRCMM(data, 32); if you want to send your 32-bit messages you've listed in this issue. It defaults to 24-bits. Feedback etc most welcome. Good or bad. :) I'm hoping to have a release candidate out for v2.0 by the end of the month. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKvJriFldjn7VKqfGa9kosR_trVd4SuYks5r6p_QgaJpZM4H-Rsj> .

crankyoldgit · 2017-05-18T00:37:46Z

Out of curiosity, any chance you can include the dumps here please?

I would have thought the tsop1738 would have worked fine as it is also a 38kHz receiver.

darshkpatel · 2017-05-18T02:44:16Z

Next time I set it up I'll dump it here

…

On May 18, 2017 6:07 AM, "David Conran" ***@***.***> wrote: Out of curiosity, any chance you can include the dumps here please? I would have thought the tsop1738 would have worked fine as it is also a 38kHz receiver. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKvJrjYmu32TF9DDCHjL3NWvx5NNMy8eks5r65LbgaJpZM4H-Rsj> .

darshkpatel · 2017-05-18T02:44:36Z

This week maybe

…

On May 18, 2017 8:14 AM, "Darsh Patel" ***@***.***> wrote: Next time I set it up I'll dump it here On May 18, 2017 6:07 AM, "David Conran" ***@***.***> wrote: > Out of curiosity, any chance you can include the dumps here please? > > I would have thought the tsop1738 would have worked fine as it is also a > 38kHz receiver. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#21 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AKvJrjYmu32TF9DDCHjL3NWvx5NNMy8eks5r65LbgaJpZM4H-Rsj> > . >

crankyoldgit · 2017-05-18T02:52:14Z

Just checking. You used the latest v2.0-dev branch in your latest tests?

darshkpatel · 2017-05-18T03:39:20Z

Yeah, i pulled the v2.0dev

…

On May 18, 2017 8:22 AM, "David Conran" ***@***.***> wrote: Just checking. You used the latest v2.0-dev branch in your latest tests? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKvJrrwFcd7ZSZkAUHV4O764_WZK98LQks5r67JfgaJpZM4H-Rsj> .

darshkpatel · 2017-05-18T16:42:51Z

@crankyoldgit I am attaching the dump for my Tatasky remote , looks like this

First two are pressing the same button and the third is for another button on the number pad.

also the last two cases are while sliding the finger actoss the touchpad ( not sure what it's called , but remote blasts out a lot of codes while sliding the finger , similar to scrolling with fingers )

Encoding  : MITSUBISHI
Code      : 0 (0 bits)
Timing[35]: 
     + 450, - 250     + 200, - 300     + 200, - 650     + 200, - 650
     + 200, - 300     + 200, - 800     + 200, - 650     + 200, - 300
     + 200, - 300     + 200, - 300     + 200, - 650     + 200, - 450
     + 200, - 650     + 200, - 300     + 200, - 300     + 200, - 300
     + 200, - 450     + 200
uint16_t  rawData[35] = {450,250, 200,300, 200,650, 200,650, 200,300, 200,800, 200,650, 200,300, 200,300, 200,300, 200,650, 200,450, 200,650, 200,300, 200,300, 200,300, 200,450, 200};  // MITSUBISHI 0
uint64_t  data = 0x0;

Encoding  : MITSUBISHI
Code      : 0 (0 bits)
Timing[35]: 
     + 450, - 250     + 200, - 300     + 200, - 650     + 200, - 650
     + 200, - 300     + 200, - 800     + 200, - 650     + 200, - 300
     + 200, - 300     + 200, - 650     + 200, - 650     + 200, - 450
     + 200, - 650     + 200, - 300     + 200, - 300     + 200, - 300
     + 200, - 450     + 200
uint16_t  rawData[35] = {450,250, 200,300, 200,650, 200,650, 200,300, 200,800, 200,650, 200,300, 200,300, 200,650, 200,650, 200,450, 200,650, 200,300, 200,300, 200,300, 200,450, 200};  // MITSUBISHI 0
uint64_t  data = 0x0;


Encoding  : MITSUBISHI
Code      : 0 (0 bits)
Timing[35]: 
     + 500, - 250     + 200, - 300     + 200, - 650     + 200, - 650
     + 200, - 300     + 200, - 800     + 200, - 650     + 200, - 300
     + 200, - 300     + 200, - 300     + 200, - 650     + 200, - 450
     + 200, - 650     + 200, - 300     + 200, - 300     + 200, - 300
     + 200, - 650     + 200
uint16_t  rawData[35] = {500,250, 200,300, 200,650, 200,650, 200,300, 200,800, 200,650, 200,300, 200,300, 200,300, 200,650, 200,450, 200,650, 200,300, 200,300, 200,300, 200,650, 200};  // 
 MITSUBISHI 0
uint64_t  data = 0x0;




Encoding  : UNKNOWN
Code      : EA0E5282 (4 bits)
Timing[7]: 
     + 400, -3700     + 150, -1300     + 150, -2950     + 200
uint16_t  rawData[7] = {400,3700, 150,1300, 150,2950, 200};  // UNKNOWN EA0E5282

Encoding  : UNKNOWN
Code      : A8B55377 (9 bits)
Timing[17]: 
     + 450, - 300     + 200, - 300     + 150, - 700     + 150, - 700
     + 150, -2100     + 150, - 500     + 200, -1550     + 150, -1000
     + 150
uint16_t  rawData[17] = {450,300, 200,300, 150,700, 150,700, 150,2100, 150,500, 200,1550, 150,1000, 150};  // UNKNOWN A8B55377

- Unit test coverage for Mitsubishi "normal" devices, and Air-Conditioning. - [bugfix] decodeMitsubishi() falsely matched RC-MM due to having no length requirement. #21 - [bugfix] Unit tests uncovered failure to clear previous state in setFan() & setVane(). - [Compiler warning] C++11-ism removed. - Updated MitsubishiAC to v2.0 spec. - Comments and style improvements. - Turned on strict compliance in decodeMitsubishi() to help stop false detecting on RC-MM messages. #21

crankyoldgit · 2017-05-19T07:27:45Z

Nice. Thanks for the data.
Not sure about the UNKNOWN's, but your results have highlighted a bug in how I've re-done decodeMitsubishi(). It shouldn't be grabbing and claiming those messages.

crankyoldgit · 2017-05-19T07:35:58Z

@darshkpatel Once #214 is merged into v2.0-dev, I think it should decode RC-MM for you,

darshkpatel · 2017-05-19T07:37:50Z

Sure, I'll try that

…

On May 19, 2017 1:05 PM, "David Conran" ***@***.***> wrote: @darshkpatel <https://github.com/darshkpatel> Once #214 <#214> is merged into v2.0-dev, I think it should decode RC-MM for you, — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKvJrnLAfzc5V6083z_Zt0jyQu0276krks5r7UZegaJpZM4H-Rsj> .

crankyoldgit · 2017-05-19T07:39:31Z

You could try the branch https://github.com/markszabo/IRremoteESP8266/tree/v2.0-dev-mitsubishi-unittests in the meantime.

- Unit test coverage for Mitsubishi "normal" devices, and Air-Conditioning. - [bugfix] decodeMitsubishi() falsely matched RC-MM due to having no length requirement. #21 - [bugfix] Unit tests uncovered failure to clear previous state in setFan() & setVane(). - [Compiler warning] C++11-ism removed. - Updated MitsubishiAC to v2.0 spec. - Comments and style improvements. - Turned on strict compliance in decodeMitsubishi() to help stop false detecting on RC-MM messages. #21

crankyoldgit · 2017-05-28T14:43:02Z

This should now be working in v2.0-RC0. Marking this closed. Please either re-open if there are issues, or create a new issue.

roidayan added the enhancement label Mar 8, 2017

crankyoldgit self-assigned this Mar 30, 2017

darshkpatel mentioned this issue Mar 30, 2017

[RC6] seems not sending the right signal? #122

Closed

crankyoldgit mentioned this issue Apr 5, 2017

Initial check-in of code for the Philips RC-MM IR protocol. #140

Merged

crankyoldgit added a commit that referenced this issue Apr 7, 2017

Initial check-in of code for the Philips RC-MM IR protocol. (#140)

55f1fbb

**Completely untested.** Based on timings and protocol descriptions from: http://www.sbprojects.com/knowledge/ir/rcmm.php For issue #21

This was referenced Apr 10, 2017

Significantly change how matching is performed and improve RC-MM matching. #150

Merged

Significantly change how matching is performed and improve RCMM matching. #156

Merged

crankyoldgit mentioned this issue May 17, 2017

Unit tests and improvements for the RC-MM protocol. #211

Merged

crankyoldgit mentioned this issue May 19, 2017

Unit tests for Mitsubishi devices. #214

Merged

crankyoldgit closed this as completed May 28, 2017

Repository owner locked as resolved and limited conversation to collaborators Jun 1, 2018

RC-MM Protocol For IRremoteESP8266 #21

RC-MM Protocol For IRremoteESP8266 #21

Comments

darshkpatel commented Apr 2, 2016

crankyoldgit commented Mar 18, 2017

crankyoldgit commented Mar 18, 2017

crankyoldgit commented Mar 22, 2017

crankyoldgit commented Mar 30, 2017

darshkpatel commented Mar 30, 2017 via email

darshkpatel commented Mar 30, 2017

darshkpatel commented Mar 30, 2017

crankyoldgit commented Mar 30, 2017

crankyoldgit commented Mar 30, 2017

darshkpatel commented Mar 30, 2017 via email

crankyoldgit commented Mar 30, 2017

crankyoldgit commented Mar 30, 2017 • edited

crankyoldgit commented Mar 30, 2017

crankyoldgit commented Mar 30, 2017

darshkpatel commented Mar 31, 2017 via email

ghost commented Apr 6, 2017

ghost commented Apr 6, 2017

ghost commented Apr 6, 2017

crankyoldgit commented Apr 6, 2017

ghost commented Apr 7, 2017

ghost commented Apr 7, 2017

crankyoldgit commented Apr 7, 2017

crankyoldgit commented Apr 23, 2017

darshkpatel commented Apr 23, 2017 via email

crankyoldgit commented May 16, 2017

darshkpatel commented May 16, 2017 via email

crankyoldgit commented May 16, 2017

crankyoldgit commented May 17, 2017 • edited

darshkpatel commented May 17, 2017 via email

crankyoldgit commented May 18, 2017

darshkpatel commented May 18, 2017 via email

darshkpatel commented May 18, 2017 via email

crankyoldgit commented May 18, 2017

darshkpatel commented May 18, 2017 via email

darshkpatel commented May 18, 2017 • edited

crankyoldgit commented May 19, 2017

crankyoldgit commented May 19, 2017

darshkpatel commented May 19, 2017 via email

crankyoldgit commented May 19, 2017 • edited

crankyoldgit commented May 28, 2017

crankyoldgit commented Mar 30, 2017 •

edited

crankyoldgit commented May 17, 2017 •

edited

darshkpatel commented May 18, 2017 •

edited

crankyoldgit commented May 19, 2017 •

edited