Closed coolacid closed 6 years ago
Reading the links you provided, it seems very likely the "wand" is transmitting at 36kHz, and if you have a typical IR receiver module, it is most-commonly a 38kHz one. This would mean you'd be borderline for getting a good signal. (possible, but not super reliable and far from optimal)
That may be what is going on here. It seems to be seeing roughly the right number of pulses. However, there are some quite unexpected values. e.g. the ones ~12us, and the odd ~2000us ones. Those are completely out-of-whack for how the protocol is defined by other example code and by-hand analysis in the article. Hence a decoder would skip the message.
If you've checked the "wand"s batteries are good, and it works with what ever it is supposed to work with, my guess it is a reception problem. Be it something environmental (noise, too close/too far, etc etc) or more likely the IR module you are using just doesn't like it. If I recall correctly, NEC and Samsung both use 38kHz, so they'd be right down the middle of the acceptable freq. band for the module.
I'd suggest you invest the few dollars in a 36kHz IR de-modulator from ebay/aliexpress/local electronics shop etc and see if that works any better.
TL;DR: Even if we wrote a decode routine for it, with those rawdata capture values as a reference, they wouldn't detect the signal in it. You've got an 'electronics/hardware' reception problem in addition to (lack of) software one. https://github.com/markszabo/IRremoteESP8266/wiki/Troubleshooting-Guide#receiving-an-ir-signal
Yeah, let's belay this issue. I forgot to update this last night. I ended up going back to my "working" setup which is probably a few years old and couldn't get good results with hardware that was working at the time. I've ordered a bunch of new sensors already to see if I can get a good solid result in the old library first.
I was reading the docs and it suggested the 38kHz should pickup enough of the signal, but given all the weird bits I was seeing with the modules I had, I wanted some new better ones anyway.
Thanks for taking a look and will report back as soon as I get the new modules and test them.
Cool, and good luck. In the meantime, I'll think about adding limited support for the device, but without good sample captures, I (and you) can't be sure it's going to work.
Good News Everyone!
So, yeah, even though a lot of the documentation said it would work with the wrong IR Receiver, getting the correct 36kHz one gave me super results.
I'll close this ticket, clean up my code and submit a PR.
Thanks for knocking me over the head and saying what I knew it was ;)
Excellent. Thanks for getting back to us with the results. It's always great to get confirmation that it isn't a library issue for this sort of thing.
Version/revison of the library used
Master
Expected behavior
I've started a fork, and hoping to make this happen on my own, but just can't seem to get the timing down right. This protocol has been implemented a couple times in the Arduino lib version:
When trying to port the code, the wands will send very random results for Raw Length, and time lengths.
Actual behavior
Feature request and I just can't quite get it working.
Output of raw data from IRrecvDumpV2.ino (if applicable)
Other useful information
I don't quite understand why the rawData seems to be inconsistent. I've tested the receiver with other known working remotes and was able to decode NEC and SAMSUNG messages.
You can find my start of the hack on my fork.