-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix incorrect frequency used for Panasonic #442
Conversation
All the references I can find indicate that the 48 bit (Kaseikyu-like) Panasonic protocol uses 37kHz, not 35kHz. IR codes from GlobalCache.com confirm it as well. (e.g. "POWER OFF","sendir,1:1,1,37000,1,1,128,63,16,16,16,48,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,48,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,48,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,48,16,48,16,48,16,48,16,48,16,48,16,16,16,16,16,48,16,48,16,48,16,48,16,48,16,48,16,16,16,48,16,2712","0000 0070 0000 0032 0080 003f 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0010 0010 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0010 0010 0030 0010 0a98",,) refs: http://www.hifi-remote.com/wiki/index.php?title=Panasonic http://www.hifi-remote.com/wiki/index.php?title=Kaseikyo http://www.remotecentral.com/cgi-bin/mboard/rc-pronto/thread.cgi?26152
Thanks so much. Just FYI all PRs are on hold pending some issues such as #437 #444 #445 |
I remember some references to 36.7kHz for an older Panasonic protocol. However, as receivers generally come in 36 or 38 kHz frequencies etc....it may be better to pick one of those as the closest ones. However, we should be careful that this is for one particular Panasonic implementation and may not apply to more modern ones. UPDATE: Just did a google search and found this: As this part is now obolete, I would consider changing the value to 36 for the library & maybe add a note to give 36.7 as the precise carrier frequency. Of course, when sending to an old panasonic device with a real 36.7 receiver, 37 would work ever-so-slightly better than 36. |
The code there in is specific to the Panasonic (Kaseikyo) protocol implementation, which looking at other vendors (e.g. Denon-K) use the same basic protocol, format & freq. Of course, they all have other variations to the Kaseikyo protocol. e.g. Checksums & parity etc. As we use Software PWM in IRremote8266 land, the integer math is much of a much-ness for 36-38 (50% duty period yielding 13.x usecs, thus 13 usecs. However 35 tips over to 14.28uS, so 14usec. So, yes, anything 36 to 38 will probably be fine, and perhaps not even be different at the end result. However, 35 is clearly wrong, and actually has a notable result difference. Chose what ever value you want, 37 is the closest integer to 36.7. TL;DR: If a user is going to use this kaseikyo-based send/decode protocol on a non-kaseikyo-based device, they are going to have a much bigger problem than the modulation mismatch. ;-) |
I did a little more research and it seems that Kaseikyo may also be the same as the 'Japanese' protocol. It could be that Panasonic, decided to use 36.7 (because they already had a receiver of that frequency or as a barrier to competition) - because the the Japanese protocol is usually 38kHz. So, it might be better to rename the protocol to 'Kaseikyo' and/or 'Japanese' and make the frequency selectable as a parameter in the function call. Please take my comments as just that, and proceed with the PR as normal. (Usually, it is very difficult to be 100% certian about IR protocols as there is no rigid standard out there) |
As an aside....check out this post on our blog as a method of getting 100% accurate hardware based IR carriers on ESP8266... |
Off-topic. Yeah. I saw that a while ago, we've even had requests to support that. Someday maybe we will support it in IRremote8266, but for now, limiting our library to a single GPIO utilisation is just not on the cards. There is already enough trouble getting users to create working circuits due to or avoiding encumbered pins/GPIOs as is. ;-) |
FWIW (again), I use exclusively Hz in my programs/libraries, like Infrared4Arduino, both in C++ and Java. Among other advantages, it corresponds to the princple "use SI units unless there is a (very) good reason not to do it". FWIW (3rd time); IrScrutinizer's data base (which is mostly identical to DecodeIR) says 37k for the carrier of the protocol Panasonic:
|
+1 for SI units. As for 36700Hz vs 37000Hz, part numbers and oscilloscopes lean to the former more than the latter. |
Although more accurate and in this case reflecting the carrier frequency being used there may be some practical reasons not to take this approach.
FYI: In our own commercial work, we tend to steer towards kHz only for IR Tx. |
@AnalysIR I see we are in violent agreement. :) Please take the following mostly in jest.
Completely agree. It's mostly a placebo.
That may be true for newer/currently sold receivers, but that doesn't mean we should not support (or try to support) old legacy devices. I'm sure most of us have decade(s) old equipment laying around with obsolete IR parts in them. Plus, who are we to second guess what users of our libraries may want to use it for. FYI, and for the record, there are a few fractional kHz protocols out there. Obviously this one(Kayseiko), TCE RCA Code (56.7 kHz), & Grundig Code (30.3kHz). (ref)
Completely concur. However, it's better to try to aim down the middle of that tolerance band if possible, than slightly to the left. ;-) End of the day, I don't expect it to make a significant impact. i.e. Years of using the wrong freq. for this protocol clearly didn't cause too many issues.
Understood. Given the freq. is hard defined in the code, not in user/api/call accessible way etc., it is kind of a moot point, and TBH, I'm making far greater changes in our fork than that, yet still trying to keep things backward compatible with the existing call usage of this library. Of course, my approach of < 1000 == kHz, >= 1000 == Hz is not a massive change and something you lot could easily adopt too. Anyway, this really is just getting to splitting hairs now. We all know when it comes down to it, representing/recreating these frequencies with integer & software based PWM we are compromised far greater than this change, and the other subtle differences discussed. i.e. I propose we paint the bike shed, duck-egg blue. :-P |
FYI, Sharp still makes IR receivers for 36.7, 32.75, and 56.8KHz, in addition to the usual 36/38/40KHz. On https://global.sharp/products/device/lineup/selection/opto/remote_control/index_2.html , they note "36.7/38/40KHz" as being the typical frequencies, but the datasheets offer part numbers for more than those. (As an aside, I am amazed at how many different IR receivers Vishay has, optimized specifically for various data formats, as well as some designed specifically for learning remotes and repeaters!) |
All the references I can find indicate that the 48 bit (Kaseikyu-like) Panasonic protocol uses 37kHz, not 35kHz.
IR codes from GlobalCache.com confirm it as well. e.g.
"POWER OFF","sendir,1:1,1,37000,1,1,128,63,16,16,16,48,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,48,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,48,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,16,48,16,48,16,48,16,48,16,48,16,48,16,16,16,16,16,48,16,48,16,48,16,48,16,48,16,48,16,16,16,48,16,2712","0000 0070 0000 0032 0080 003f 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0010 0010 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0010 0010 0030 0010 0a98",,
Additional refs:
http://www.hifi-remote.com/wiki/index.php?title=Panasonic
http://www.hifi-remote.com/wiki/index.php?title=Kaseikyo
http://www.remotecentral.com/cgi-bin/mboard/rc-pronto/thread.cgi?26152
Might fix #126.
This was discovered as I was reworking https://github.com/markszabo/IRremoteESP8266 for v2.0.