Hi zenwheel! Thanks for your changes. I'm in the middle of a (very slow) rewrite, so don't be alarmed if I don't pull your changes for a while.

Hi Scott! Thanks for adding these protocols. I have a couple questions, just to make sure I understand the changes. Why did you change MATCH, MATCH_MARK, and MATCH_SPACE from macros to functions? Did this same memory? Also, you changed the tolerance from 25% to 35%. Were you having decode problems with 25%

Thanks,
Ken

These changes were for recognizing the Panasonic protocol. It wouldn't recognize my Panasonic remote without the 35% and the other change had to do with increasing the buffer size, I just copied it from your blog, a post from Jon. After I implemented that, it would recognize the Panasonic protocol, but I had to change the data to be 64bits instead of 32 to handle the length. After that it was recognizing properly (when compared to the LIRC file for my remote), but the sending didn't work, that's about the point I gave up on the Panasonic remote. My Samsung TV worked with the changes. I didn't have any JVC equipment to test.

Jon said...
Awesome library!

I've confirmed that the Panasonic code posted above works but there are a few quirks.

You need to modify the raw buffer size in IRremote.h to accommodate the long input as follows:

#define RAWBUF 100 

After that it worked fine in debug mode.

Then I had to remove the match macros and add standard functions in IRremote.cpp as follows:

#ifndef DEBUG
int MATCH(int measured, int desired) {return measured >= TICKS_LOW(desired) && measured <= TICKS_HIGH(desired);}
int MATCH_MARK(int measured_ticks, int desired_us) {return MATCH(measured_ticks, (desired_us + MARK_EXCESS));}
int MATCH_SPACE(int measured_ticks, int desired_us) {return MATCH(measured_ticks, (desired_us - MARK_EXCESS));}
#endif

Before the modification it would only successfully decode a panasonic signal in debug mode. I assume this is because Macros are not type safe nor do they handle expressions entered as arguments perfectly in all cases. I didn't look too deeply into the failure but this fix worked for me.

Why havn't you added those protocol to the original github yet? :) I can confirm that both the panasonic and JVC protocol works great, both regarding to sending and decoding.

Problems reading Panasonic codes. Changing TOLERACNE to 35% solved the problem.

Hi Ken!
Is there anyhow that you or even I could put the new version of your lib with the support for JVC, Panasonic and, specially, Samsung remotes (from zenwheel or Chris Targett)? All those raw 68 positions arrays are taking me so much memory...

If I could merge them by myself and don't have to deal with a lot of bugs, let me know.

Cheers!

Ditto. Although it seems Panasonic and JVC protocols are in the code, but Panasonic might need some tweaking (not working for me). Seems like some bits have been added and others haven't. The Samsung protocol hasn't been added but is available on the blog and does work for me with multiple Samsung remotes tested so far. It would be good to have a merge / update with everything learned and added so far. Cheers

@pmgration, I tried to merge the codes to get Samsung protocol to work (the one that I need the most), where they're different from each other, but I couldn't do it. It didn't work. Can you post your working version with this protocol or mail me the library?

About the Panasonic, @webapps wrote that "changing TOLERACNE to 35% solved the problem" up above.

Thanks!

@mariocarta, in the comments from Ken's post is this:
http://www.righto.com/2009/08/multi-protocol-infrared-remote-library.html?commentPage=1#c971506768374074772

It has a samsungSend function (which I must admit I can't remember if I have tried this or not) but the receiving part is linked to in the same comment and also has the definitions for the marks and spaces. Hope this helps..let me know.

I haven't looked into the panasonic issue yet, I did a quick test at the weekend and found I had one panasonic remote that did get decoded and one that didn't, not sure what's going on there. What is the tolerance change that I would be looking for?

Cheers

Thank you @pmgration. I will reset my library to the latest original and try the changes you told me to. Soon I tell you. But it seems that it's lacking the #defines for the SAMSUNG_HDR_MARK, SAMSUNG_HDR_SPACE etc. in the IRremoteInt.h. I have these numbers from another branch that tried to implement Samsung protocol, does it works?:

#define SAMSUNG_HDR_MARK 4500
#define SAMSUNG_BITS 32
#define SAMSUNG_HDR_SPACE 4500
#define SAMSUNG_BIT_MARK 560
#define SAMSUNG_ONE_SPACE 1600
#define SAMSUNG_ZERO_SPACE 600

About the TOLERANCE, I don't know, but I think he meant this line in IRremoteInt.h:
#define TOLERANCE 25 //change it to 35

I didn't try it because I don't have any Panasonic around here. But good luck and let me know if it fixed its issues!

Cheers!

OK, without the proper dump function on the library for Samsung there is no way to know the code for the functions I want. And I didn't find my control (AA59-00511A) on the LIRC database. End of the line. Anyone?

@mariocarta, does the samsung functions not work? There may be a remote similar in lirc, a lot use the same codes or have you got a receiver to use irrecord?

@pmgration, I merged the library with @targettio version, only getting the functions that concerns Samsung's send/dump (and the send function is the same to that one from the comments you sent me). It seems to identify the code rightly when I try to dump:

(using the serial monitor running IRrecvDump.ino)
Decoded SAMSNUNG E0E040BF (32 bits)
Raw (68): 18686 4600 -4450 600 -1650 600 -1600 650 -1600 650 -500 600 -500 650 -500 600 -500 650 -500 600 -1600 650 -1600 650 -1600 650 -500 600 -500 650 -500 600 -500 650 -450 650 -500 650 -1600 600 -500 650 -500 600 -500 650 -500 600 -500 650 -500 600 -1650 600 -500 600 -1650 600 -1650 600 -1600 650 -1600 650 -1600 650 -1600 650 

But when I use the same code with sendSamsung(0xE0E040BF, 32), I know some code is sent (because I have a USB IR receiver on my mac that has a red led that blinks when receive some IR pulse). But it doesn't work with the TV neither my other arduino with an IR receiver (with the dump sketch) recognizes as any valid code. That's really strange.

So, I don't know what's not to be trusted: the dump function or the send one. But I have the feeling that is the send one.

Did you really try it? Let me know if you got this to work.
And how about the TOLERANCE, did it made any effect on your project?

EDIT:

I seems it was the delay in the

for (int i = 0; i < 3; i++) 
  {
    irsend.sendSamsung(code, 32);
    delay(70);
  }

that was too low (usually 40ms), I changed it up to 70ms and it worked fine. What's happening now is that I have a IRCodes.h as a database for all my remotes with a bunch of #defines so I don't need to paste the codes everytime I need to send something. But for the 32 bits of the Samsung it seems to ignore the upper case of the code and only give me 0x40BF for the

#define IR_TV_ONOFF 0xE0E040BF

when IR_TV_ONOFF is called. Does this have anything to do with the number being so high? Is there something with the compiling logic that it needs to ignore those upper bits?

What I'm doing to bypass this is using something like this:

irsend.sendSamsung((0xE0E00000 | code), 32);

but I'd rather not to. Anyone with a more elegant idea?

That samsung code is for power and to trigger on usually needs to be done up to 4 times in a row with correct spacing but seems your delays are working for you. Not sure about the send command for samsung I haven't tried it yet but not sure why it should be different and not work with the pre data and code as you've used it above. I'll try to do some testing as well when I can. Not tried the panasonic tolerance change yet but will try that too.

"That samsung code is for power and to trigger on usually needs to be done up to 4 times in a row with correct spacing"

Thank you for this! I didn't know. With the delay it was working for 80% of the time and that was bugging me.
Forget about the send command. Now with these tweaks it's working fine. The only thing that's strange behavour with the 32bits define. (It also "forget the upper bits" when calling Serial.println(IR_TV_ONOFF, HEX)). There is no reason for it! It should just replace the references with the defined values for them, shouldn't it?

http://pastebin.com/SGP9NYGP

Works for me, is this what you're doing? Are you converting types anywhere?

As strange as it seems, no I'm not typecasting or anything like that anywhere. But I did try to force it to be (unsigned long) either in Serial.println as in send function passing as parameter without any effect. I'm puzzled! :P

As you may guess: your code worked fine. And so as mine now - without changing anything. I've just uploaded again now and it worked. Quite strange.

Hi shirriff,
I don't know I am at the write place or not. if this is the place to clear my doubts. I am here to ask help on LIRC IR Remote codes.
little bit confuse on the concept of Pre-data & post-data.
where,

1. in LIRC IR code for samsung - bn59-01039a pre-data bits is 16 & pre data is 0xE0E0 i want to know where this data gets added & how.
   2.for Sony VCR Remote RMT-V102 post-data bits is 5 & post-data is 0x8 here 0x8 means 1000 it contains 4-bits where does the remaining 1-bit adds before 1000 or after 1000 & the remaining 1-bit is either '1' or '0'. the same doubt apply for pre-data if pre-data bits and pre-data doesn't match.
   3.I want to know about Flags,eps, aeps, ptrail, plead in LIRC code.

I am asking so many quires because i am trying to make remote of my own kind which contains some 100 remotes in one & i would like to contribute new device protocol which i am working on.

I will be happy if i get some help on this particular issue.

pls don't mind if any comments is wrong I am new to use github.

Pls reply to my mail manuswey@gmail.com i don't know that i can keep track on my doubt posted here.

Can someone please confirm that this still needs to be merged. Does the library not already support this?

I recently became the maintainer and am still trying to get up to speed.

If anyone is interested in helping, feel free to rebase this on the master branch, other wise I will eventually get to adding these protocols.

@zenwheel Your contribution is greatly appreciated.

From what I can tell these were merged somewhere along the way...