RC-MM Protocol For IRremoteESP8266 about irremoteesp8266

[crankyoldgit]

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]

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

[crankyoldgit]

Ping.

[crankyoldgit]

Ping.

[darshkpatel]

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]

@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]

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]

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]

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

[darshkpatel]

Same here, guess we'll have to wait for someone else to confirm On Mar 30, 2017 9:08 AM, "David Conran" <[email protected]> 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]

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]

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]

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]

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]

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> .

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

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

[crankyoldgit]

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.

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.

hatts off to your quick remedy :)

[crankyoldgit]

@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.

[crankyoldgit]

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

[darshkpatel]

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]

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

[darshkpatel]

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" <[email protected]> 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]

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.

[crankyoldgit]

@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]

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]

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]

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]

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]

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

[darshkpatel]

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]

@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

[crankyoldgit]

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]

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

[darshkpatel]

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]

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

[crankyoldgit]

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.