Fix incorrect frequency used for Panasonic

[crankyoldgit]

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.

[crankyoldgit]

FYI crankyoldgit/IRremoteESP8266#167

[z3t0]

Thanks so much. Just FYI all PRs are on hold pending some issues such as #437 #444 #445

[AnalysIR]

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.
The library also uses whole numbers. So in this case 36kHz would be a better choice.

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:
https://www.digikey.com/product-detail/en/panasonic-electronic-components/PNA4601M/PNA4601M-ND/

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.

[crankyoldgit]

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.
Yes, there are other protocols they (Denon/Panasonic) use for different devices etc. e.g. Sharp protocol.

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

[AnalysIR]

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.
It could also be that the frequency of the protocol is not mandated?

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)

[AnalysIR]

As we use Software PWM in IRremote8266 land

As an aside....check out this post on our blog as a method of getting 100% accurate hardware based IR carriers on ESP8266...
https://www.analysir.com/blog/2017/01/29/updated-esp8266-nodemcu-backdoor-upwm-hack-for-ir-signals/

[crankyoldgit]

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

[crankyoldgit]

@AnalysIR FWIW, I'm adding support for fractional kHz values to IRremote8266. i.e. Hz instead of/as well as kHz. Sure, it's not going to make much difference due to rounding at the usec integer level, but it at least means we capture the intent, and be as accurate as possible.

[bengtmartensson]

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:

 {37k,432}<1,-1|1,-3>(8,-4,2:8,32:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+ [D:0..255,S:0..255,F:0..255]

[crankyoldgit]

+1 for SI units.

As for 36700Hz vs 37000Hz, part numbers and oscilloscopes lean to the former more than the latter.

[AnalysIR]

@crankyoldgit

I'm adding support for fractional kHz values to IRremote8266

Although more accurate and in this case reflecting the carrier frequency being used there may be some practical reasons not to take this approach.

1. The real world difference between 36.7 & 36/37 kHz is essentially almost nothing.
2. AFAIK, all manufacturers of standard IR receivers only sell products in the following frequencies. 30, 33, 36, 38, 40, 56 kHz. (even the 455kHz do not appear to be manufactured today).
3. Data Sheets tend to run with +/- 5% for frequency responsiveness (or > +/- 1kHz)
4. More importantly here, is that if you do that you will be making the other fork of IRremote less consistant with the 'original', which is of course allowed.

FYI: In our own commercial work, we tend to steer towards kHz only for IR Tx.

[crankyoldgit]

@AnalysIR I see we are in violent agreement. :) Please take the following mostly in jest.

The real world difference between 36.7 & 36/37 kHz is essentially almost nothing.

Completely agree. It's mostly a placebo.

AFAIK, all manufacturers of standard IR receivers only sell products in the following frequencies. 30, 33, 36, 38, 40, 56 kHz. (even the 455kHz do not appear to be manufactured today).

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)

Data Sheets tend to run with +/- 5% for frequency responsiveness (or > +/- 1kHz)

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.

More importantly here, is that if you do that you will be making the other fork of IRremote less consistant with the 'original', which is of course allowed.

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

[tookitogo]

@crankyoldgit

I'm adding support for fractional kHz values to IRremote8266

Although more accurate and in this case reflecting the carrier frequency being used there may be some practical reasons not to take this approach.

1. The real world difference between 36.7 & 36/37 kHz is essentially almost nothing.
2. AFAIK, all manufacturers of standard IR receivers only sell products in the following frequencies. 30, 33, 36, 38, 40, 56 kHz. (even the 455kHz do not appear to be manufactured today).

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!)