![\"Buy](\"https://www.buymeacoffee.com/assets/img/custom_images/orange_img.png\")
\r\n\r\n# Table of Contents\r\n1. [Overview](#overview)\r\n2. [Library Installation](#library-installation)\r\n3. [API Documentation](#api-documentation)\r\n * [Receive Protocols](#receive-protocols)\r\n * [Setup Receiving](#setup-receiving)\r\n * [Read IRLremote](#read-irlremote)\r\n * [Time Functions](#time-functions)\r\n * [Sending](#sending)\r\n * [Adding new protocols](#adding-new-protocols)\r\n4. [How it works](#how-it-works)\r\n5. [Links](#links)\r\n6. [Version History](#version-history)\r\n7. [License and Copyright](#license-and-copyright)\r\n\r\n## Overview\r\n**The main improvements are:**\r\n* Faster decoding (on the fly)\r\n* Huge Ram improvements (13 bytes ram to decode NEC)\r\n* Huge Flash improvements (less than 1kb flash to decode NEC)\r\n* Receiving and sending possible\r\n* Very accurate even when pointing in different directions\r\n* Easy to use/customizable\r\n* Maximum error correction\r\n* Uses PinInterrupt or PinChangeInterrupts/No timer needed\r\n* Usable on almost any pin\r\n* Perfect for Attinys\r\n* All mainstream protocols supported\r\n* Very accurate hash decoding for unknown protocols\r\n* IDE 1.6.x compatible (not 1.0.5 compatible)\r\n\r\n**Supported Protocols**\r\n* NEC\r\n* Panasonic\r\n* ~~Sony 12~~ (TODO)\r\n* Hash (For any unknown protocol)\r\n* ~~RawIR (For dumping the raw data)~~ (TODO)\r\n* Ask me for more\r\n\r\n**Planned features:**\r\n* Test sending functions (for Panasonic, Sony etc)\r\n* Add more protocols (RC06)\r\n* Improve bit banging PWM?\r\n* Add Raw dump sending option\r\n* Implement Sony 15, 20 properly\r\n\r\n## Library Installation\r\nInstall the library as you are used to.\r\nMore information can be found [here](http://arduino.cc/en/guide/libraries).\r\n\r\n## API Documentation\r\nFor a very fast library example see the\r\n[Receiving example](/examples/Receive/Receive.ino).\r\n\r\n### Receive Protocols\r\nYou can choice between multiple protocols. All protocols are optimized in a way\r\nthat the recognition of the selected protocol is set to a maximum. This means\r\nyou can only decode a single protocol at a time but with best recognition.\r\n\r\n##### Supported Protocols:\r\n* NEC\r\n* Panasonic\r\n* IRHash\r\n\r\n##### Examples:\r\n```cpp\r\n// Choose the IR protocol of your remote\r\nCNec IRLremote;\r\n//CPanasonic IRLremote;\r\n//CHashIR IRLremote;\r\n```\r\n\r\n### Setup Receiving\r\nTo use the receiving you have to choose a **[PinInterrupt](http://arduino.cc/en/pmwiki.php?n=Reference/AttachInterrupt)**\r\nor **[PinChangeInterrupt](https://github.com/NicoHood/PinChangeInterrupt)** pin.\r\nThey work a bit different under the hood but the result for IR is the same.\r\nIn order to use PinChangeInterrupts you also have to [install the library](https://github.com/NicoHood/PinChangeInterrupt).\r\n\r\nYou can also terminate the receiver. This sets pins to input again to safely\r\nremove connections. This is **normally not required**.\r\n\r\n##### Function Prototype:\r\n```cpp\r\nbool begin(uint8_t pin);\r\nbool end(uint8_t pin);\r\n```\r\n\r\n##### Examples:\r\n```cpp\r\n// Choose a valid PinInterrupt or PinChangeInterrupt pin of your Arduino board\r\n#define pinIR 2\r\n\r\n// Start reading the remote\r\n// PinInterrupt or PinChangeInterrupt will automatically be selected\r\n// False indicates a wrong selected interrupt pin\r\nif (!IRLremote.begin(pinIR))\r\n Serial.println(F(\"You did not choose a valid pin.\"));\r\n\r\n// End reading the remote\r\nIRLremote.end(pinIR);\r\n```\r\n\r\n### Read IRLremote\r\nIf there is input available you can read the data of the remote. It will return\r\nthe received data and automatically continue reading afterwards. Check if the\r\nremote is available before, otherwise you will get an empty structure back.\r\n\r\nThe returned data type will differ with the selected protocol. Each protocol has\r\nan address and a command member, but their size may differ. See the protocol\r\nsection for more information.\r\n\r\n##### Function Prototype:\r\n```cpp\r\nbool available(void);\r\n\r\n// Valid datatypes depending on the selected protocol:\r\nNec_data_t read(void);\r\nPanasonic_data_t read(void);\r\nHashIR_data_t read(void);\r\n```\r\n\r\n##### Examples:\r\n```cpp\r\n// Check if new IR protocol data is available\r\nif (IRLremote.available())\r\n{\r\n // Get the new data from the remote\r\n auto data = IRLremote.read();\r\n\r\n // Print the protocol data\r\n Serial.print(F(\"Address: 0x\"));\r\n Serial.println(data.address, HEX);\r\n Serial.print(F(\"Command: 0x\"));\r\n Serial.println(data.command, HEX);\r\n Serial.println();\r\n}\r\n```\r\n\r\n### Time Functions\r\nThe API provides a few interfaces to check some timings between the last Event\r\nor if the remote is currently still receiving. This is especially useful when\r\nyou want to build higher level APIs around the remote or when you have other\r\ninterrupt sensitive code that disables interrupts which affects the IR reading\r\nquality.\r\n\r\n##### Function Prototype:\r\n```cpp\r\nbool receiving(void);\r\nuint32_t timeout(void);\r\nuint32_t lastEvent(void);\r\nuint32_t nextEvent(void);\r\n```\r\n\r\n##### Examples:\r\n```cpp\r\n// Check if we are currently receiving data\r\nif (!IRLremote.receiving()) {\r\n FastLED.show();\r\n}\r\n\r\n// Return relativ time between last event time (in micros)\r\nif (IRLremote.timeout() > 1000000UL) {\r\n // Reading timed out 1s, release button from debouncing\r\n digitalWrite(BUILTIN_LED, LOW);\r\n}\r\n\r\n// Return absolute last event time (in micros)\r\nSerial.println(IRLremote.lastEvent, HEX);\r\nSerial.println(micros(), HEX);\r\n\r\n// Return when the next event can be expected.\r\n// Zero means at any time.\r\n// Attention! This value is a little bit too high in general.\r\n// Also for the first press it is even higher than it should.\r\nif (IRLremote.nextEvent() == 0) {\r\n // We timed out, this is the last event in this series of reading\r\n digitalWrite(BUILTIN_LED, LOW);\r\n}\r\n```\r\n\r\n### Sending\r\n\r\n**For sending see the SendSerial/Button examples.**\r\nSending is currently **beta**. The library focuses more on decoding, rather than sending.\r\nYou first have to read the codes of your remote with one of the receiving examples.\r\nChoose your protocol in the sending sketch and use your address and command if choice.\r\n\r\nSending for Panasonic and Sony12 is not confirmed to work, since I have no device here to test.\r\nLet me know if it works!\r\n\r\n### Adding new protocols\r\n\r\nYou can also ask me to implement any new protocol, just file an issue on Github or contact me directly.\r\nOr you can just choose the hash option which works very reliable for unknown protocols.\r\n\r\nMore projects + contact can be found here:\r\nhttp://www.NicoHood.de\r\n\r\nHow it works\r\n============\r\n\r\n**The idea is: minimal implementation with maximal recognition.\r\nYou can still decode more than one protocol at the same time.**\r\n\r\nThe trick is to only check the border between logical zero and logical one\r\nto terminate space/mark and rely on the lead/length/checksum as error correction.\r\nLets say a logical 0 is 500ms and 1 is 1000ms. Then the border would be 750ms\r\nto get maximum recognition instead of using just 10%.\r\n\r\nOther protocols use different timings, leads, length, checksums\r\nso it shouldn't interfere with other protocols even with this method.\r\n\r\nThis gives the library very small implementation with maximum recognition.\r\nYou can point into almost every possible direction in the room without wrong signals.\r\n\r\nIt saves a lot of ram because it decodes the signals \"on the fly\" when an interrupt occurs.\r\nThat's why you should not add too many protocols at once to exceed the time of the next signal.\r\nHowever its so fast, its shouldn't make any difference since we are talking about ms, not us.\r\n\r\n**In comparison to Ken's lib**, he records the signals (with timer interrupts) in a buffer which takes a lot of ram.\r\nThen you need to check in the main loop if the buffer has any valid signals.\r\nIt checks every signal, that's why its slow and takes a lot of flash.\r\nAnd it also checks about 10~20% from the original value. Lets say a pulse is 100ms. Then 80-120ms is valid.\r\nThat's why the recognition is worse. And he also doesn't check the protocol intern error correction.\r\nFor example NEC has an inverse in the command: the first byte is the inverse of the 2nd byte. Its easy to filter wrong signals then.\r\nSo every protocol has its built in checksums, which we will use. And I also check for timeouts and start new readings if the signal timed out.\r\nThe only positive thing is that with the timer the pin is more flexible. However i will try to implement a PCINT version later.\r\n\r\nFor sending I decided to use Bitbang. This works on every MCU and on any PIN. He used proper timers,\r\nbut only PIN 3 is usable for sending (an interrupt pin). Bitbang might have problems with other interrupts but should work relyable.\r\nYou can turn off interrupts before sending if you like to ensure a proper sending.\r\nNormal IR devices shouldn't complain about a bit intolerance in the PWM signal. Just try to keep interrupts short.\r\n\r\nThis text should not attack the library from Ken. It's a great library with a lot of work and the most used IR library yet.\r\nIt is just worth a comparison and might be still useful like the old SoftSerial against the new one.\r\n\r\nLinks\r\n=====\r\n\r\n* https://github.com/z3t0/Arduino-IRremote\r\n* http://www.mikrocontroller.net/articles/IRMP#Literatur\r\n* JCV/Panasonic/Japan/KASEIKYO\r\n * http://www.mikrocontroller.net/attachment/4246/IR-Protokolle_Diplomarbeit.pdf\r\n * http://www.roboternetz.de/phpBB2/files/entwicklung_und_realisierung_einer_universalinfrarotfernbedienung_mit_timerfunktionen.pdf\r\n* Sony\r\n * http://picprojects.org.uk/projects/sirc/sonysirc.pdf\r\n * http://www.benryves.com/products/sonyir/\r\n * http://www.righto.com/2010/03/understanding-sony-ir-remote-codes-lirc.html\r\n * http://mc.mikrocontroller.com/de/IR-Protokolle.php#SIRCS\r\n* NEC\r\n * http://techdocs.altium.com/display/FPGA/NEC+Infrared+Transmission+Protocol\r\n * http://www.sbprojects.com/knowledge/ir/nec.php\r\n\r\nVersion History\r\n===============\r\n```\r\n2.0.2 Release (08.04.2018)\r\n* Added ESP8266 #20\r\n\r\n2.0.1 Release (16.01.2018)\r\n* Fix makefile compilation\r\n\r\n2.0.0 Release (07.03.2017)\r\n* Focus on single protocol implementation\r\n* Added better keycode definitions #11\r\n* Updated keywords.txt\r\n* Tabs -> Spaces\r\n* Added receive and time interface templates\r\n\r\n1.9.0 Release (Never officially released)\r\n* Added API as class\r\n* Fixed NEC Timeout value\r\n* NEC repeat code now integrated\r\n* Fixed Sony12 address\r\n* Added debounce\r\n* More flexible selection of protocols\r\n* PinChangeInterrupt library dynamically used\r\n* Added F() makro for examples\r\n* Removed older examples\r\n* Removed the general decoding function to improve decoding functionality\r\n* New inputs are generated at runtime, saves flash and ram\r\n* Faster interrupt if valid signal was received\r\n* Improved NEC sending\r\n* Added to Arduino IDE 1.6.x library manager\r\n* Some other complex library structure changes\r\n* Made reading interrupt save\r\n* Improved RawIR\r\n* Added hash function for unknown protocols\r\n\r\n1.7.4 Release (19.04.2015)\r\n* Updated examples\r\n* Added PinChangeInterrupt example\r\n* Removed NoBlocking API and integrated this into the examples\r\n* Added IRL_VERSION definition\r\n* Added library.properties\r\n* Improved Raw Example\r\n\r\n1.7.3 Release (27.11.2014)\r\n* Fixed critical Typo in decoding function\r\n* Fixed weak function variable type\r\n* Updated Raw Example slightly\r\n\r\n1.7.2 Release (18.11.2014)\r\n* Added always inline macro\r\n* Changed duration to 16 bit\r\n* Added easier PCINT map definitions\r\n* Fixed ARM compilation for receiving (sending is still not working)\r\n\r\n1.7.1 Release (15.11.2014)\r\n* Added 16u2 HoodLoader2 example\r\n\r\n1.7 Release (15.11.2014)\r\n* Changed IR bit order from MSB to correct LSB\r\n * This improved the overall handling and also reduced flash usage\r\n* Improved, extended sending function\r\n* Added Receive Send Example\r\n* Added smaller Basic PCINT function\r\n\r\n1.6 Release (14.11.2014)\r\n* Reworked decoding template\r\n* Added Sony 12 protocol\r\n* Added PCINT example for advanced users\r\n\r\n1.5.1 Release (21.09.2014)\r\n* improved Bitbang PWM\r\n* fixed SendSerial example\r\n\r\n1.5.0 Release (20.09.2014)\r\n* huge Ram and Flash improvements\r\n* new library structure\r\n* compacter code/new structure\r\n* more examples\r\n* more than one protocol possible at the same time\r\n* customizable decoding functions\r\n\r\n1.4.7 Release (13.09.2014)\r\n* changed NEC to template\r\n\r\n1.4.6 Release (30.08.2014)\r\n* fixed writing address + command bug\r\n* added sending function for NEC\r\n* added Led example\r\n\r\n1.4.5 Release (30.08.2014)\r\n* fixed raw protocol\r\n\r\n1.4.4 Release (07.08.2014)\r\n* added raw protocol (broken)\r\n\r\n1.4.3 Release (06.08.2014)\r\n* changed and improved a lot of stuff\r\n* rearranged classes\r\n* removed older versions\r\n\r\n1.0 - 1.3 (17.03.2014 - 03.5.2014)\r\n* Release and minor fixes\r\n```\r\n\r\nLicense and Copyright\r\n=====================\r\nIf you use this library for any cool project let me know!\r\n\r\n```\r\nCopyright (c) 2014-2015 NicoHood\r\nSee the readme for credit to other people.\r\n\r\nPermission is hereby granted, free of charge, to any person obtaining a copy\r\nof this software and associated documentation files (the \"Software\"), to deal\r\nin the Software without restriction, including without limitation the rights\r\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\r\ncopies of the Software, and to permit persons to whom the Software is\r\nfurnished to do so, subject to the following conditions:\r\n\r\nThe above copyright notice and this permission notice shall be included in\r\nall copies or substantial portions of the Software.\r\n\r\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\r\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\r\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\r\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\r\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\r\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN\r\nTHE SOFTWARE.\r\n```\r\n"
},
{
"path": "dev/Interpreting Decoded IR Signals (v2.43).htm",
"content": "\r\n\r\n\r\n\r\n
\r\nIntroduction\r\n
\r\n\r\nIntroduction
\r\nThe primary purpose of this document is to explain any peculiarities of the decoding of each protocol.\r\nClick in the list above on each protocol name to get any information specific to decodes with that name.\r\nIf you don't understand the advanced information (IRP notation, etc.) at the start of each of those\r\nentries, don't worry about that and please don't let it stop you from reading the text below that. In many\r\ncases there is important protocol-specific information you will need in order to use the data from\r\nthe decode.
\r\nDecode problems
\r\nThe decoder only looks at one IR signal at a time. Sometimes it gives contradictory\r\nresults for a signal. The best way to determine which result is correct is to\r\ncompare with the decodes of other signals for the same device.\r\nSpurious decodes and non-robust protocols
\r\nMost IR protocols have enough internal consistency checks that the decoder can reliably\r\ntell whether that protocol is present in a learned signal and can reliably decode the\r\ndevice, subdevice and OBC numbers. If the signal is learned badly enough, the decoder\r\nmay fail to find that protocol in the signal. But it is very unlikely to decode it\r\nwith the wrong numbers or to imagine that protocol is a bad learn of something else.\r\nSome protocols are not robust. A totally unrelated IR signal can accidentally \r\n fit the pattern of such a protocol resulting in a spurious decode. When you \r\n get a decode for a non-robust protocol you need to exercise some judgment \r\n about whether to believe or ignore that decode. Usually you can decide based \r\n on decodes of other signals of the same device.
\r\nEFC, JP1, KeyMoves, Upgrades, etc.
\r\nMuch of this document assumes DecodeIr is being used with JP1 or at least with a JP1\r\ncapable remote. But some people will be using DecodeIr with other types of remote.\r\nIf your remote is not OneForAll brand and is not one of the models of Radio Shack (or a few\r\nother brands) that uses the same design as OneForAll, then everything this document says\r\nabout JP1, KeyMoves, Upgrades, KM, RM (RemoteMaster), and EFC numbers has no meaning for\r\nyour use. Just ignore those references and the rest of this doc should apply to your use.\r\nAlso ignore the EFC numbers in the actual output from DecodeIr.
\r\nIf you are using a OneForAll type remote but have neither a JP1 cable nor a remote model\r\nthat can be upgraded by .wav file, then nothing about Upgrades, KM, RM, and OBC numbers\r\napplies to your use. If the decodes you get include EFC numbers and you know (or can\r\nask in a forum) which setup code is right (corresponds to the protocol, device and\r\nsubdevice of the decode) then you can use those EFC numbers in KeyMoves. Note that\r\nthe decoding process cannot directly tell you which setup code is needed to\r\ngenerate the signal. If you post a question in an appropriate forum with the protocol name,\r\ndevice number, subdevice number, and which model OneForAll type remote you have, someone\r\nwill probably identify the setup code for you.
\r\nToggle bits
\r\nSeveral different protocols include something called a toggle bit. This means that each command\r\nhas two or more different forms. Some protocols (e.g. RC5) alternate the toggle on each key press, while\r\nothers change the toggle to indicate a start or end frame.\r\nAn alternating toggle lets the device receiving the commands distinguish between a long press\r\nof a button and two short presses. For example, if you press and hold the '1' button\r\nthe remote continuously sends repeats of a single form of the '1' command. But if you\r\npress '1', release it and press it again the remote will switch to the other form of the\r\ncommand for the second press.
\r\nWhen you learn such a command you are capturing just one form of the command and\r\nevery use will send that same form. If you use that learned signal and press the same button twice\r\nin a row, the device receiving the signal will see that as one long press rather than two\r\nshort ones. For keys, such as digits, where one long press has a different meaning than\r\ntwo short presses, that gets quite inconvenient.
\r\nWith OneForAll type remotes, using an upgrade or KeyMove will solve that problem.
\r\nFor some of these protocols, for some models of Pronto remote, there is a condensed\r\nencoding of the Pronto Hex that will solve the problem.
\r\n\r\nRepeat frames and dittos
\r\nDecodeIR v2.37 and later versions have a look-ahead facility that is not present in earlier ones. \r\n This distinguishes between two styles of data passed to them by the calling application. The \r\n remote control programming applications IR.exe and RMIR pass signals learned by a UEI remote \r\n that has itself performed a partial analysis of the signal. The data is passed in a structured \r\n form, divided into Once, Repeat and Extra sections. The data in each of these sections can be \r\n viewed in IR.exe if the \"Force Learned Timings\" option on the Advanced menu is selected. Because \r\n of this analysis, DecodeIR does not see the original signal in full and cannot determine such \r\n things as the number of repeats of the signal that were sent. Other applications such as the \r\n IRScope software for the IR Widget send the entire signal as unstructured data, which enables \r\n IR.exe to identify the number of repeats.
\r\nThe look-ahead facility checks successive frames within a single signal to see if they are \r\n repeats either identical repeats or, in certain protocols, frames of a repeat sequence \r\n that have a distinctive marker in either the start or end frame, or both, of the sequence. If a \r\n protocol has distinctive start or end frame markers and either or both of the start and end frames \r\n are missing, this is reported in the Misc field of the decode (but at present this may not be \r\n implemented for all protocols with such markers). If the data has been passed in an unstructured \r\n form then the number of repeats in the signal will also be reported in the Misc field in a form \r\n like \"4 frames\", or in version 2.39 and later, \"+ 3 copies\".
\r\nIn the case of unstructured data, DecodeIR v2.38 extends the look-ahead to protocols in which repeat \r\n action is signalled not by a full repeat of the frame but by a much shorter frame that does not carry \r\n the signal data (or occasionally carries just part of this data). These frames serve \r\n as \"ditto marks\". If present then the number of such frames is reported in the Misc field \r\n in a form like \"3 dittos\", or in version 2.39 and later, \"+ 3 dittos\". If there \r\n are no repeat frames or ditto marks, then to avoid ambiguity this is reported as \"no repeat\".
\r\n\r\nMini Combos
\r\nSome UEI protocol executors are \"mini-combos\". This means they support more than one\r\ndevice number within one setup code using single-byte hex commands. There will be more\r\nthan one possible EFC number for each OBC number. DecodeIr can't determine the correct\r\nEFC number by looking at the IR signal, because it isn't a characteristic of the signal.\r\nIt is a characteristic of the fixed data used in creation of the setup code.\r\nDecodeIr will list two or three different EFC numbers for each OBC number.\r\nThe sequence of those two or three EFC numbers is consistent across all the decodes.\r\nSo once you find out which position in that list is correct for one OBC of a given device\r\nnumber and setup code, that position will be correct for the EFC list of any other OBC of\r\nthe same device and setup code (except that for RC-5 the decision of whether or not the OBC\r\nnumber is above 63 is treated as being part of the device number).
\r\n\r\nBrief and incomplete guide to reading IRP
\r\n\r\nGeneral: {carrier frequency, time unit, sequencing rule} \r\nMitsubishi:{32.6k,300}<1,-3|1,-7>(D:8,F:8,1,-80)+
\r\nCarrier Frequency: Hz; e.g. 38.3k; default is 0k--no modulation
\r\nTime Unit: Integer that can represent durations. Suffix u (default) is microseconds, p denotes number of pulses of the carrier.
\r\nSequencing Rule: lsb|msb; lsb (default) means the least significant bit of a binary form is sent first.
\r\nBitSpec: Rule for the translating bit sequences to duration \r\nsequences. <ZeroPulseSeq|OnePulseSeq|TwoPulseSeq....>. Most IR \r\nprotocols use only <ZeroPulseSeq|OnePulseSeq>, and the sequence is\r\n simply OnDuration,OffDuration. Example: NEC uses <1,-1|1,-3>
\r\n\r\nBitfield: D:NumberOfBits:StartingBit. E.g. if D=71= 01000111, D:2:5 means x10xxxxx.\r\n D:2:5 = 10b = 2. ~ is the bitwise complement operator. ~D \r\n=10111000. Specifying the StartingBit is optional. D:6 is equivalent to \r\nD:6:0.
\r\n\r\nIRStream: The sequence of data. Enclosed in parentheses, items separated by commas. \r\nA trailing + means send one or more times. A trailing 3 means send 3 times; 3+ means at least 3 times. \r\nA trailing * means send zero or more times. NEC2: {38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+
\r\n\r\nDurations: no suffix means duration is expressed in Time Units, as defined above. \r\nm is milliseconds, u microsec, p pulses. No prefix means a flash, a preceeding - (minus) means a gap.
\r\n\r\nExtent: A gap which trails a signal. The trailing gap is adjusted to make the total length of signal \r\nplus trailing gap equal to the extent. Notation is like a gap duration, except ^ replaces the minus sign. \r\nRC-5:(1:1,~F:1:6,T:1,D:5,F:6,^114m)+
\r\n\r\nExpressions: names, numbers and bitfields connected by standard symbols for arithmetic and logical \r\noperations. Enclosed in parentheses. 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)+ \r\n
\r\n\r\nPermitted operators in decreasing order of precedence:
\r\n\r\n unary (negation)
\r\n ** (exponentiation)
\r\n * /, % (multiplication, integer division, modulo) (* is also used in IRStreams)
\r\n +, (addition, subtraction (+ is also used in IRStreams)
\r\n & (bitwise AND)
\r\n ^ (exclusive OR) (also used in extents)
\r\n | (OR)
\r\n ~ (complement) is permitted in Bitfields
\r\n\r\nDefinitions: expressions separated by commas, enclosed in curly brackets. \r\nGI Cable: {38.7k,490}<1,-4.5|1,-9>(18,-9,F:8,D:4,C:4,1,-84,(18,-4.5,1,-178)*) \r\n{C = -(D + F:4 + F:4:4)}
\r\nAssignments: For example T=T+1, which can be used to describe the RC-5 toggle bit.
\r\nVariations: Up to 3 expressions enclosed in square brackets. The first variation is \r\nsent on the first transmission, second for middle transmissons, and the third for the final transmission. \r\nE.g. the Zaptor toggle bit is zero until the last frame: [T=0] [T=0] [T=1]
\r\n The IRP specification by Graham Dixon
\r\n Practical explanation of IR signals and IRP by Vicky Getz\r\n\r\n \r\n48-NEC
\r\nIf you get a decode whose protocol name is\r\nsimply \"48-NEC\" that indicates the learned signal is not complete (usually caused by\r\nnot holding the original remote's button long enough during learning). Enough of\r\nthe signal is present to accurately determining the device, subdevice and OBC numbers.\r\nBut not enough is present to determine whether the protocol is 48-NEC1 or 48-NEC2.\r\n\r\n48-NEC1
\r\nIRP notation: {564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,E:8,~E:8,1,-??,(16,-4,1,-??)*) \r\n
\r\nEFC translation: LSB\r\nThis protocol signals repeats by the use of dittos.
\r\n\r\n48-NEC2
\r\nIRP notation: {564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,E:8,~E:8,1,-??)+ \r\n
\r\nEFC translation: LSB\r\n\r\nAdNotam
\r\nIRP notation: {35.7Khz,895,msb}<1,-1|1,-3>(0:1,1:1,D:6,F:6,^114m)+ \r\n
\r\nVery similar to RC5, except AdNotam uses two start bits, and no toggle bit. \r\n\r\n\r\n
AirAsync
\r\nIRP notation: {37.7Khz,840}<1|-1>( 1,B:8,-2 ... )\r\nThis protocol uses asynchronous data transmission that sends an 8-bit byte with 1 start bit, \r\n8 data bits and 2 stop bits. The minimum signal is one byte. The protocol is reported as\r\nAirAsyncn-xx.yy. ...\r\nwhere n is the number of bytes and xx, yy, ... are the byte values in hexadecimal notation. \r\n
\r\n\r\nAirB?-????
\r\nThis is not a robust protocol, so spurious decodes are likely.\r\nIf you see this decode from something other than an IR keyboard, you should probably ignore it.
\r\n\r\nAiwa
\r\nUEI protocol: 005E or 009E\r\n
\r\nIRP notation: {38k,550}<1,-1|1,-3>(16,-8,D:8,S:5,~D:8,~S:5,F:8,~F:8,1,-42,(16,-8,1,-165)*) \r\n
\r\nEFC translation: LSB\r\nThis protocol signals repeats by the use of dittos.
\r\nThe EFC numbering varies among the KM and RM versions of Aiwa. Using OBC numbers is less confusing.
\r\nWhen using a non-combo version of Aiwa in KM, you must combine the device and subdevice numbers as\r\ndevice+256*subdevice to get the number KM calls \"Device Code\". (Since subdevice is usually zero, that\r\ncombination is trivial). In Aiwa combo in KM you use the subdevice as \"parameter\" (on the setup sheet)\r\nand put the device in the byte2 column on the functions sheet. RM follows DecodeIr's naming of Device\r\nand Subdevice.
\r\n\r\nAK
\r\nDocumentation not written yet.\r\n\r\nAkai
\r\nUEI protocol: 000D\r\n
\r\nIRP notation: {38k,289}<1,-2.6|1,-6.3>(D:3,F:7,1,^25.3m)+
\r\nEFC translation: LSB comp prefixed with last device bit\r\nThis is not a robust protocol, so spurious decodes are likely.
\r\nAs of version 8.31, KM does not translate device to fixed data, nor OBC to EFC according to\r\nthe same rules used by DecodeIr. RM does translate consistently with DecodeIr, so you may find\r\nit easier to use RM. If you use KM, you must change the device number as follows:
\r\n\r\n
\r\n- Decoded device 0 or 4 --> KM device 3
\r\n- Decoded device 1 or 5 --> KM device 2
\r\n- Decoded device 2 or 6 --> KM device 1
\r\n- Decoded device 3 or 7 --> KM device 0
\r\nAlso (in KM) you should use the EFC number from the decode not the OBC number. Akai protocol\r\nuses the same EFC numbering across all JP1 remotes, so use of EFC is safe. KM uses different\r\nOBC numbering than RM and DecodeIr, so use of OBCs isn't safe.
\r\n\r\nAmino
\r\nUEI protocol: 019C\r\n
\r\nIRP notation: {56.0k,268,msb}<-1,1|1,-1>[T=1] [T=0] (7,-6,3,D:4,1:1,T:1,1:2,0:8,F:8,15:4,C:4,-79m)+
\r\n-----Variant: {36.0k,268,msb}<-1,1|1,-1>[T=1] [T=0] (7,-6,3,D:4,1:1,T:1,1:2,0:8,F:8,15:4,C:4,-79m)+\r\n
{C =(D:4+4*T+9+F:4+F:4:4+15)&15} [the arithmetic sum of the first 7 nibbles mod 15]\r\n
T=1 for the first frame and T=0 for all repeat frames. \r\n
DecodeIR v2.43 checks T and will report in the Misc field if the start or end frame is missing.\r\nAmino equipment use both 36 and 56KHz, but the duration of the half-bit is\r\nalways 268. Zaptor is a closely related protocol which for which the half-bit duration is 330.\r\nIRDecode v2.43 distinguishes between Amino and Zaptor in order of priority by 1)the position of the toggle bit,\r\n2)the value of the next to last nibble, and 3)the measured duration of a half-bit.\r\n
\r\nEFC translation: MSB\r\n\r\nAnthem
\r\nUEI protocol: 0123
\r\nIRP notation: {38.0k,605}<1,-1|1,-3>((8000u,-4000u,D:8,S:8,E:8,C:8,1,-25m)3, -75m)+ {E=(64*U:2+F:6), C=~(D+S+E+255):8}\r\n
Anthem framing is very similar to NEC, and also uses 32 bits of data. However, the leadout is much shorter.\r\nThe signal is sent at least3 times.\r\n\r\nApple
\r\nUEI protocol: 01E0\r\n
\r\n\r\nIRP notation: {38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,C:1,F:7,I:8,1,-78,(16,-4,1,-173)*)
\r\nC=1 if the number of 1 bits in the fields F and I is even. I is the remote ID.\r\nApple uses the same framing as NEC1, with D=238 in normal use, 224 while pairing. S=135
\r\n\r\nArcher
\r\nIRP notation: {0k,12}<1,-3.3m|1,-4.7m>(F:5,1,-9.7m)+
\r\nEFC translation: 5-bit LSB\r\nThis is not a robust protocol, so spurious decodes are likely.
\r\n\r\nAsync
\r\nThis protocol uses asynchronous data transmission that sends an 8-bit byte with 1 start bit, \r\n8 data bits and 1 stop bit. The minimum signal is four bytes. The protocol is reported as\r\nAsyncn:min-max:aa.bb...yy.zz\r\nwhere n is the number of bytes, min-max is the range of durations\r\n in microseconds that was taken as a single bit and aa.bb...yy.zz are \r\nthe first two and last two byte values in hexadecimal notation. \r\n
\r\n\r\nBlaupunkt
\r\nIRP notation: {30.3k,528}<-1,1|1,-1>(1,-5,1023:10,-39,1,-5,1:1,F:7,D:2,-230) \r\n\r\nBose
\r\nIRP notation: {500,msb}<1,-1|1,-3>(2,-3,F:8,~F:8,1,-???)+
\r\nEFC translation: MSB\r\nThe decode is intended to be consistent with the posted KM file:\r\nBose-Wave-Radio-KM.txt\r\nand PB file:\r\nBose_Wave_Radio-PB.txt\r\n\r\nCanalSat
\r\nUEI protocol: 018C\r\n
\r\nIRP notation: {55.5k,250,msb}<-1,1|1,-1>(1:1,D:7,S:6,T:1,0:1,F:7,-89m)+ \r\n
\r\nEFC translation: 7-bit MSB.\r\nThe repeat frames are not all identical. T toggles within a single signal, with T=0\r\nfor the start frame and T=1 for all repeats. DecodeIR v2.37 and later check T and will report in the Misc\r\nfield if the start frame is missing.
\r\n\r\nDenon, Denon{1} and Denon{2}
\r\nIRP notation: {38k,264}<1,-3|1,-7>(D:5,F:8,0:2,1,-165,D:5,~F:8,3:2,1,-165)+ \r\n
\r\nEFC translation: LSB\r\nA Denon signal has two halves, either one of which is enough to fully decode \r\nthe information. A significant fraction of Denon learned signals contain just \r\none half or have the halves separated so that DecodeIr can't process them \r\ntogether. When one half is seen separate from the other, DecodeIr will name \r\nthe protocol Denon{1} or Denon{2} depending on which half is decoded. Denon, \r\nDenon{1} and Denon{2} all represent the same protocol when they are correct. \r\nBut only Denon is robust. A Denon{1} or Denon{2} decode might be spurious.
\r\n\r\nDenon-K
\r\nUEI protocol: 00CD\r\n
\r\nIRP notation: {37k,432}<1,-1,1,-3>(8,-4,84:8,50:8,0:4,D:4,S:4,F:12,((D*16)^S^(F*16)^(F:8:4)):8,1,-173)+ \r\n
\r\nEFC translation: LSB comp\r\nDenon-K is the member of the Kaseikyo family with OEM_code1=84 and OEM_code2=50.
\r\nDenon-K uses the same check byte rules as Panasonic protocol, but uses the data bits differently.\r\nThe Panasonic Combo protocol in KM can be used with some difficulty to produce Denon-K signals.\r\nThe Denon-K choice in RM uses the same protocol executor as Panasonic combo, but computes the hex commands\r\nbased on Denon's use of the Kaseikyo data bits.
\r\n\r\nDgtec
\r\nUEI protocol: 016A\r\n
\r\nIRP notation: {38k,560}<1,-1|1,-3>(16,-8,D:8,F:8,~F:8,1,^108m,(16,-4,1,^108m)+) \r\n
\r\nEFC translation: LSB comp\r\nThis protocol signals repeats by the use of dittos.
\r\n\r\nDirecTV
\r\nIRP notation: {38k,600,msb}<1,-1|1,-2|2,-1|2,-2>(5,(5,-2,D:4,F:8,C:4,1,-50)+) \r\n{C=7*(F:2:6)+5*(F:2:4)+3*(F:2:2)+(F:2)}
\r\nEFC translation: MSB\r\nThere are six variants of the DirecTV protocol, distinguished in RemoteMaster by the parameter \"Parm\" on\r\nthe Setup page. The Parm value is shown in the Misc field of DecodeIR. The IRP notation above corresponds\r\nto the default Parm=3. The various Parm values correspond to three different frequencies (the 38k in the above) \r\nand two different lead-out times (the -50 in the above). The corresponding values are:
\r\n\r\n
\r\n- Parm=0 : 40k, -15\r\n
- Parm=1 : 40k, -50\r\n
- Parm=2 : 38k, -15\r\n
- Parm=3 : 38k, -50\r\n
- Parm=4 : 57k, -15\r\n
- Parm=5 : 57k, -50\r\n
Portions of a dirty learn of a Sony signal may look like a DirecTV signal. So, if you get a DirecTV\r\ndecode together with a plausible Sony decode, believe the Sony decode and ignore the DirecTV. If you get\r\na DirecTV decode without a Sony decode for some functions of a Sony device, try relearning them; a DirecTV\r\ndecode for a signal meant for a Sony device is not likely to be correct.
\r\nThis protocol was called Russound in versions of DecodeIR earlier than 2.40.
\r\n\r\nDishplayer
\r\nUEI protocol: 010F\r\n
\r\nIRP notation: {38.4k,535,msb}<1,-5|1,-3>(1,-11,(F:6,U:5,D:2,1,-11)+)
\r\nEFC translation: Not available in this version of DecodeIr\r\nThis is not a robust protocol, so spurious decodes are likely.
\r\n\r\nDish_Network
\r\nUEI protocol: 0002
IRP notation: {57.6k,400}<1,-7|1,-4>(1,-15,(F:-6,U:5,D:5,1,-15)+)\r\n
\r\nEFC translation: MSB comp 6 function bits followed by LSB comp low 2 unit bits.\r\nThis is not a robust protocol, so spurious decodes are likely.
\r\nThe unit number shows up in the Subdevice field of DecodeIr's output. In KM, the \"unit code\" is\r\none greater than the unit number. So you must take the Subdevice from the decode and add one to\r\nit and use that as the \"unit code\" in KM.
\r\nThere are two variants of the protocol executor for DishNetwork with different \r\nbut compatible EFC numbering. The decoded EFC should work for both. But the \r\nresults may be less confusing if you use OBC numbers in KM or RM.
\r\n\r\nEchoStar
\r\nUEI protocol: 0182\r\n
As of 2.42 DecodeIR shows this as RC5-7F\r\n\r\nEmerson
\r\nUEI protocol: 0065\r\n
\r\nIRP notation: {36.7k,872}<1,-1|1,-3>(4,-4,D:6,F:6,~D:6,~F:6,1,-39)+
\r\nEFC translation: 6-bit LSB comp with 2-bit mini-combo\r\nLists three different EFCs because this protocol is a mini combo.
\r\n\r\nF12
\r\nUEI protocol: 001A\r\n
\r\nIRP notation: (Toshiba specification) K=(D:3,H:1,A:1,B:2,F:6)\r\n{37.9k,422}<1,-3|3,-1>(K,-34,K) for A=1 or B=1
\r\n{37.9k,422}<1,-3|3,-1>(K,-34,K,-88,K,-34,K)+ for H=1.\r\nExactly one of H, A, or B can have a value of 1. If H=1 the signal can be sent repeatedly, and F can take any 6 bit value.\r\nIf A or B=1, the signal is sent once only per button press, and only a single bit of F can be non-zero.\r\nIRP notation: (JP1) K=(D:3,H:1,F:8)\r\n{37.9k,422}<1,-3|3,-1>(K,-34,K) for H=0.
\r\n{37.9k,422}<1,-3|3,-1>(K,-34,K,-88,K,-34,K)+ for H=1.
\r\nA and B are subsumed into F, and the value of H is computed in the executor. H=A^B.\r\n
EFC translation: lsb, but not computed in DecodeIR.\r\n
DecodeIR reports H as the subdevice. This is useful when making a Pronto Hex file,\r\nor other description based on durations. Remotes with executors (e.g. UEI remotes) normally compute the value of\r\nH in the executor, and the \"subdevice\" is not needed as a parameter.\r\n\r\nFujitsu
\r\nUEI protocol: 00F8\r\n
\r\nIRP notation: {37k,432}<1,-1,1,-3>(8,-4,20:8,99:8,X:4,E:4,D:8,S:8,F:8,1,-110)+ \r\n
\r\nEFC translation: LSB comp\r\nFujitsu is the member of the Kaseikyo family with OEM_code1=20 and OEM_code2=99.
\r\nThere is no check byte, so the risk of an incorrectly decoded OBC is much higher than in\r\nother Kaseikyo protocols.
\r\n00F8 requires 2-byte hex commands, so the decoded EFC number is generally not \r\n useful. Use OBC number in upgrades or to compute Hex commands.
\r\n\r\nFujitsu-56
\r\nIRP notation: {37k,432}<1,-1,1,-3>(8,-4,20:8,99:8,H:4,E:4,D:8,S:8,X:8,F:8,1,-110)+ \r\n\r\nG.I. Cable and G.I. Cable{1}
\r\nUEI protocol: 00C4\r\n
\r\nIRP notation: {38.7k,490}<1,-4.5|1,-9>(18,-9,F:8,D:4,C:4,1,-84,(18,-4.5,1,-178)*) \r\n{C = -(D + F:4 + F:4:4)}
\r\nEFC translation: LSB\r\nThis protocol signals repeats by the use of dittos.\r\nWhen the {1} is shown as part of the protocol name for G.I. Cable, it just means that the repeat\r\npart of the signal is not present. That doesn't indicate any difference in the actual protocol nor\r\neven any unreliability in the decode. It may indicate that use of the learned signal will be less\r\nreliable, so you have more than usual reason to replace it with a KeyMove, Upgrade or cleaned\r\nup version.
\r\n\r\nG.I.4DTV
\r\nUEI protocol: 00A4\r\n
\r\nIRP notation: {37.3k,992}<1,-1|1,-3>(5,-2,F:6,D:2,C:4,1,-60)+
\r\nEFC translation: NONE\r\nThis is a moderately robust protocol, but spurious decodes are still possible.
\r\nThe official (UEI) protocol executor for G.I.4DTV does not support EFC numbers. If you are creating an\r\nupgrade in KM or RM you should use OBC numbers, not EFC numbers. If you need the Hex Cmd for a KeyMove,\r\nyou should use the functions sheet of KM or RM to compute it for you from the OBC and device number.
\r\n\r\nGrundig16 and Grundig16-30
\r\nUEI protocol: Grundig16 0112, Grundig16-30 00AB\r\n
IRP notation for Grundig16: {35.7k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>\r\n(806u,-2960u,1346u,T:1,F:8,D:7,-100)+\r\n
IRP notation for Grundig16-30: {30.3k,578,msb}<-4,2|-3,1,-1,1|-2,1,-2,1|-1,1,-3,1>\r\n(806u,-2960u,1346u,T:1,F:8,D:7,-100)+ \r\n
\r\nEFC translation: MSB but with bit pairs translated data->hex by 00->00, 01->11, 10->01, 11->\r\n10 and off by one position.\r\nThese are two variants of the same protocol, differing only in frequency. The IRP notation is corrected \r\n from previous versions of this document, to bring it into line with what DecodeIR actually does.
\r\n\r\nGXB
\r\nIRP notation: {38.3k,520,msb}<1,-3|3,-1>(1,-1,D:4,F:8,P:1,1,^???)+ \r\nDecoder for a nonstandard Xbox remote.
\r\n\r\nIODATAn and IODATAn-x-y
\r\nUEI protocol: not known.\r\n
\r\nIRP notation: {38k,550}<1,-1|1,-3>(16,-8,x:7,D:7,S:7,y:7,F:8,C:4,1,^108m)+ \r\n{n = F:4 ^ F:4:4 ^ C:4}
\r\nEFC translation: LSB\r\nThis is potentially a class of protocols distinguished by values of n, x and y with \r\n n = 0..15 and x, y = 0..127. If x and y are both zero, they are omitted. The only known example is IODATA1.
\r\n\r\nJerrold
\r\nUEI protocol: 0006\r\n
\r\nIRP notation: {0k,44}<1,-7.5m|1,-11.5m>(F:5,1,-23.5m)+ \r\nThis is not a robust protocol, so spurious decodes are likely.
\r\n\r\nJVC and JVC{2}
\r\nUEI protocol: 0034\r\n
\r\nIRP notation: {38k,525}<1,-1|1,-3>(16,-8,(D:8,F:8,1,-45)+)
\r\nEFC translation: LSB comp\r\nJVC{2} indicates a JVC signal from which the lead-in is missing. The JVC protocol has\r\nlead-in on only the first frame, so it is quite easy to have it missing from a learned\r\nsignal. So when JVC{2} is correct, it means the same as JVC. But JVC{2} is not robust,\r\nso spurious decodes are likely. It\r\nis also very similar in structure and timing to Mitsubishi protocol, so that\r\nDecodeIr has difficulty distinguishing one from the other. The device number, OBC and EFC\r\nare all encoded the same way between the two. So if you have JVC{2}\r\ndecodes that you have reason to suspect should actually be Mitsubishi, you can try using\r\nthem as Mitsubishi without changing the numbers. However, true Mitsubishi signals will not\r\nmisdecode as JVC, just as JVC{2}. So if some of the signals for your device decode as JVC\r\nand others as JVC{2}, you should trust all those decodes and not try Mitsubishi.
\r\n\r\nJVC-48
\r\nUEI protocol: 001F or 00C9 or 00CD\r\n
\r\nIRP notation: {37k,432}<1,-1|1,-3>(8,-4,3:8,1:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+ \r\n
\r\nEFC translation: LSB comp\r\nJVC-48 is the member of the Kaseikyo family with OEM_code1=3 and OEM_code2=31.
\r\nPanasonic protocol uses the same check byte rules as JVC-48, so you might want use the (more flexible)\r\nPanasonic entries in KM or RM to produce a JVC-48 upgrade (by changing the OEM_code1 and OEM_code2 values). For simple\r\nJVC-48 upgrades you get exactly the same results by directly selecting the \"JVC-48\" protocol.
\r\n\r\nJVC-56
\r\nIRP notation: {37k,432}<1,-1|1,-3>(8,-4,3:8,1:8,D:8,S:8,X:8,F:8,(D^S^X^F):8,1,-173)+\r\n \r\nKaseikyo
\r\nKaseikyo is a family of protocols that includes Panasonic, Mitsubishi-K, Fujitsu, Sharp-DVD and Teac-K. Each\r\nprotocol in the Kaseikyo family is identified by two numbers, known as OEM_code1 and OEM_code2.
\r\n\r\n Most members of the family have minor structural differences from the generic \r\n form. In those cases DecodeIR checks for the specific details (based on the \r\n OEM codes) and if they are correct reports the protocol by name (see Panasonic \r\n and Teak-K below).
\r\nIn the few cases where the structure exactly fits my understanding of the Kaseikyo spec,\r\nDecodeIR reports it as Kaseikyo-???-??? replacing the first ??? by the OEM_code1 and the second\r\n??? by the OEM_code2.
\r\n\r\nKaseikyo-???-???
\r\nIRP notation: \r\n{37k,432}<1,-1|1,-3>(8,-4,M:8,N:8,X:4,D:4,S:8,F:8,E:4,C:4,1,-173)+\r\n {X=M:4:0^M:4:4^N:4:0^N:4:4,C=D^S:4:0^S:4:4^F:4:0^F:4:4^E}\r\n
\r\nEFC translation: LSB comp\r\nThis is the nominal form of the Kaseikyo.\r\nIt is most commonly seen with OEM codes 170.90, which\r\nindicates \"Sharp\". I assume (haven't tested) that the SharpDVD protocol in KM generates these\r\nKaseikyo-170-90 signals. \r\nWe have also seen this protocol with OEM codes 3.32. I'm not sure what manufacturer that indicates.
\r\nThe Kaseikyo protocol in KM seems to be designed to produce this nominal form of Kaseikyo for any\r\nspecified OEM codes and any constant value of E. That should be the way to reproduce any Kaseikyo-???-???\r\ndecode other than SharpDVD, and might be better than SharpDVD for the Kaseikyo-170-90 signals.
\r\n\r\nKaseikyo56
\r\nKaseikyo56 is a lengthened version of the Kaseikyo family of protocols. It has the same OEM codes indicating \r\nthe same manufacturers as Kaseikyo, and it has the same variation (by manufacturer) in check byte and other \r\ndetails as Kaseikyo.\r\n\r\nKaseikyo56-???-???
\r\nIRP notation: {37k,432}<1,-1|1,-3>(8,-4,M:8,N:8,H:4,D:4,S:8,X:8,F:8,E:4,C:4,1,-173)+ \r\n\r\nKathrein
\r\nUEI protocol: 0066\r\n
IRP notation: {38k,540}<1,-1|1,-3>(16,-8,D:4,~D:4,F:8,~F:8,1,^105m,(16,-8,F:8,1,^105m)+)\r\n
EFC translation: LSB comp\r\nThis protocol signals repeats by the use of dittos. It is unusual in that the ditto \r\n frame carries part of the signal data, specifically the function code (OBC) but not the device code.
\r\n\r\nKonka
\r\nUEI protocol: 019B\r\n
\r\nIRP notation: {38k,500,msb}<1,-3|1,-5>(6,-6,D:8,F:8,1,-8,1,-46)+
\r\nEFC translation: MSB\r\n\r\nLumagen
\r\nIRP notation: {38.4k,416,msb}<1,-6|1,-12>(D:4,C:1,F:7,1,-26)+ {C = odd parity \r\nfor F}
\r\nEFC translation: MSB prepended with C bit.\r\nThis is a moderately robust protocol, but spurious decodes are still possible.
\r\n\r\nLutron
\r\nIRP notation: {40k,2300,msb}<-1|1>(255:8,X:24,0:4)+
\r\nEFC translation: MSB of decoded signal.\r\nThis is an unusual protocol in that an 8-bit device code and 8-bit OBC are encoded in a 24-bit \r\n error-correcting code as the X of the IRP notation. This is constructed as follows. First two parity \r\n bits are appended to the 16 data bits to give even parity for the two sets of 9 bits taken alternately. \r\n The resulting 18-bit sequence is then treated as 6 octal digits (0-7) expressed in 3-bit binary code. \r\n These are then re-coded in the 3-bit Gray code (also called, more descriptively, the reflected-binary code) \r\n with a parity bit to give odd parity, so giving 6 4-bit groups treated as a single 24-bit sequence. The \r\n whole thing allows any single-bit error in transmission to be identified and corrected.
\r\n\r\nMatsui
\r\nIRP notation: {38K,525}<1,-1|1,-3>(D:3,F:7,1,^30.5m)+
\r\nEFC translation: Not available in this version of DecodeIr\r\nThis is not a robust protocol, so spurious decodes are likely.
\r\n\r\nMCE (RC6-6-32)
\r\nIRP notation: {36k,444,msb}<-1,1|1,-1>(6,-2,1:1,6:3,-2,2,OEM1:8,OEM2:8,T:1,D:7,F:8,-???)+\r\nMCE is a member of the RC6 family. Technically it is RC6-6-32 with the standard toggle bit zero, with the \r\n OEM1 field equal to 128, and with a nonstandard (for the RC6 family) toggle bit added. If all those \r\n rules are met, DecodeIr will display the name as \"MCE\" and with the OEM2 field moved to the \r\n subdevice position. Otherwise it will display RC6-6-32.
\r\nAs of version 8.31, KM does not have built-in support for this protocol, but there are KM format upgrade \r\n files available for Media Center (built by an expert who isn't limited to KM's built-in protocols). Those \r\n upgrades should be adaptable to any RC6-6-32 code set (by changing the fixed data), if the one you have \r\n doesn't already match the upgrade.
\r\nRM version 1.16 has support for RC6-6-32, which can be used for MCE upgrades. Version 1.17 will also have \r\n direct support for MCE
\r\nMetz19
\r\nIRP notation: (37.9K,106,msb)<4,-9|4,-16>(8,-22,T:1,D:3,~D:3,F:6,~F:6,4,-125m)+
\r\nThe toggle bit T is inverted each time a new button press occurs.\r\n\r\nMitsubishi
\r\nUEI protocol: 0014\r\n
\r\nIRP notation: {32.6k,300}<1,-3|1,-7>(D:8,F:8,1,-80)+
\r\nEFC translation: LSB comp\r\nThis is not a robust protocol, so spurious decodes are likely. It\r\nis also very similar in structure and timing to JVC{2} protocol, so that\r\nDecodeIr has difficulty distinguishing one from the other. The device number, OBC and EFC\r\nare all encoded the same way between the two. So if you have Mitsubishi\r\ndecodes that you have reason to suspect should actually be JVC, you can try using\r\nthem as JVC without changing the numbers.
\r\n\r\nMitsubishi-K
\r\nIRP notation: {37k,432}<1,-1|1,-3>(8,-4,35:8,203:8,X:4,D:8,S:8,F:8,T:4,1,-100)+ \r\n
\r\nEFC translation: not available yet\r\nMitsubishi-K is the member of the Kaseikyo family with OEM_code1=35 and OEM_code2=203.
\r\n\r\nNEC
\r\nNEC is a family of similar protocols including NEC1, NEC2, Tivo, Pioneer, Apple, NECx1 and NECx2.\r\nIf you get a decode whose protocol name is\r\nsimply \"NEC\" that indicates the learned signal is not complete (usually caused by\r\nnot holding the original remote's button long enough during learning). Enough of\r\nthe signal is present to accurately determine the device, subdevice and OBC numbers.\r\nBut not enough is present to determine whether the protocol is NEC1 or NEC2.\r\nDifference between NEC1 and NEC2
\r\nThe difference between NEC1 and NEC2 only affects the signal sent by a long\r\nkeypress. A short press sends the same signal in NEC1 and NEC2.\r\n\r\nVariant IRstreams in NEC protocols
\r\nFor NEC1, NEC2, NECx1, and NECx2 protocols, the IRstream contains D:8,S:8,F:8,~F:8
\r\nHowever, some manufacturers (especially Yamaha and Onkyo) are breaking the \"rule\" that the 4th byte should be ~F:8
\r\nVersion 2.42 decodes these variants by adding suffixes to the protocol name depending on the IRstream:
\r\n-y1: D:8,S:8,F:8,~F:7,F:1:7 (complement all of F except the MSB)
\r\n-y2: D:8,S:8,F:8,F:1,~F:7:1 (complement all of F except the LSB)
\r\n-y3: D:8,S:8,F:8,F:1,~F:6:1,F:1:7 (complement all of F except MSB and LSB)
\r\n-f16: D:8,S:8,F:8,E:8 (no relationship between the 3rd and 4th bytes)
\r\n\r\nNEC1
\r\nIRP notation: {38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78,(16,-4,1,-173)*) \r\n
\r\nEFC translation: LSB comp\r\nA few devices use NEC1 protocol at 40Khz, rather than the typical frequency.\r\nWhen getting a decode of NEC1, if you notice that the frequency is closer to 40Khz than to 38Khz,\r\nexamine multiple learns from the same device to estimate whether the 40Khz frequency is a\r\nlearning error or a true characteristic of the device. If the 40Khz is correct, there are\r\nmethods in JP1, or MakeHex (whichever you are using) to reproduce NEC1 at 40Khz rather than the\r\nusual frequency.
\r\n\r\nNEC2
\r\nIRP notation: {38.4k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+
\r\nEFC translation: LSB comp\r\nPioneer is distinguished from NEC2 only by frequency. So if your learning system does not\r\nlearn frequency accurately, it won't accurately distinguish Pioneer from NEC2. All Pioneer signals\r\nshould have a device number in the range 160 to 175 and no subdevice. No NEC2 signal should fit those\r\nrules. So you usually can determine whether the decision (by frequency) was wrong by checking the device numbers.
\r\n\r\nNECx
\r\nIf you get a decode whose protocol name is\r\nsimply \"NECx\" that indicates the learned signal is not complete (usually caused by\r\nnot holding the original remote's button long enough during learning). Enough of\r\nthe signal is present to accurately determining the device, subdevice and OBC numbers.\r\nBut not enough is present to determine the exact protocol, which is probably NECx1 or NECx2. This\r\nincomplete learn also makes it harder to distinguish NEC from NECx, so a decode of \"NECx\"\r\nmight be NEC1 or NEC2 or even Tivo or Pioneer.\r\n\r\nNECx1
\r\nIRP notation: {38.4k,564}<1,-1|1,-3>(8,-8,D:8,S:8,F:8,~F8,1,^108m,(8,-8,D:1,1,^108m)*)
\r\nEFC translation: LSB comp\r\n
Most, but not all NECx1 signals have S=D\r\n\r\nNECx2
\r\nIRP notation: {38.4k,564}<1,-1|1,-3>(8,-8,D:8,S:8,F:8,~F8,1,^108m)+
\r\nEFC translation: LSB comp\r\n
Most, but not all NECx2 signals have S=D\r\n\r\nNokia
\r\nIRP notation: {36k,msb}<164,-276|164,-445|164,-614|164,-783>(412,-276,D:8,S:8,F:8,164,-???)+ \r\n
\r\nEFC translation: MSB\r\n\r\nNokia12
\r\nIRP notation: {36k,msb}<164,-276|164,-445|164,-614|164,-783>(412,-276,D:4,F:8,164,-???)+ \r\n
\r\nEFC translation: MSB\r\n\r\nNokia32
\r\nUEI protocol: 0173\r\n
\r\nIRP notation: {36k,msb}<164,-276|164,-445|164,-614|164,-783>(412,-276,D:8,S:8,X:8,F:8,164,^100m)+ \r\n
\r\nEFC translation: MSB\r\n\r\nNRC16
\r\nDocumentation not written yet.\r\n\r\nNRC17
\r\nUEI protocol: 00BD\r\n\r\nOrtekMCE
\r\nUEI protocol: not known.\r\n
\r\nIRP notation: {38.6k,480}<1,-1|-1,1>(4,-1,D:5,P:2,F:6,C:4,-48m)+
\r\nEFC translation: 6-bit LSB comp\r\nThe repeat frames are not all identical. P is a\r\n position code: 0 for the start frame of a repeat sequence, 2 for the \r\nend frame and 1 for all frames in between. C is a checksum, 3 more than \r\nthe number of 1 bits in D, P, F together. DecodeIR v2.37\r\nand later check P and will report in the Misc field if either the start \r\nor end frame, or both, is/are missing.
\r\n\r\nPace MSS
\r\nIRP notation: {38k,630,msb}<1,-7|1,-11>(1,-5,1,-5,T:1,D:1,F:8,1,^120m)+ \r\n
\r\nEFC translation: Not available in this version of DecodeIr\r\nThis is a moderately robust protocol, but spurious decodes are still possible.
\r\n\r\nPanasonic
\r\nUEI protocol: 001F or 00C9 or 00CD\r\n
\r\nIRP notation: {37k,432}<1,-1|1,-3>(8,-4,2:8,32:8,D:8,S:8,F:8,(D^S^F):8,1,-173)+ \r\n
\r\nEFC translation: LSB comp\r\nPanasonic protocol is the most commonly seen member of the Kaseikyo family
\r\nOEM_code1 is 2 and OEM_code2 is 32 (or DecodeIr won't display the name as \"Panasonic\"). \r\n So those values in KM or RM can be changed from the default 2 and 32 only \r\n when using the Panasonic entry in KM or RM to produce some Kaseikyo variant \r\n OTHER THAN Panasonic. When creating a Panasonic upgrade, don't change those \r\n from the default values.
\r\n\r\nPanasonic2
\r\nIRP notation: {37k,432}<1,-1|1,-3>(8,-4,2:8,32:8,D:8,S:8,X:8,F:8,(D^S^X^F):8,1,-173)+ \r\n\r\nPanasonic_Old
\r\nUEI protocol: 0000\r\n
\r\nIRP notation: {57.6k,833}<1,-1|1,-3>(4,-4,D:5,F:6,~D:5,~F:6,1,-???)+
\r\nEFC translation: 6-bit LSB comp with 2-bit mini-combo\r\nLists three different EFCs because this protocol is a mini combo.
\r\n\r\nPCTV
\r\nIRP notation: {38.4k,832}<0,-1|1,-0>(2,-8,1,D:8,F:8,2,-???) \r\n\r\npid-0001
\r\nUEI protocol: 0001\r\n
IRP notation: {0k,msb}<24,-9314|24,-13486>(24,-21148,(F:5,1,-28m)+)\r\n
EFC translation: 5-bit MSB comp\r\nAs of version 8.31 KM has seriously wrong OBC translation for pid-0001, so use only EFC's with KM.
\r\n\r\npid-0003
\r\nUEI protocol: 0003\r\n
IRP notation: {40.2k,389}<2,-2|3,-1>(F:8,~F:8,^102k)+\r\n
EFC translation: LSB\r\n\r\npid-0004
\r\nUEI protocol: 0004\r\n
IRP notation: {0k,msb}<12,-130|12,-372>(F:6,12,-27k)+\r\n
EFC translation: 6-bit MSB comp\r\n\r\npid-002A
\r\nUEI protocol: 002A\r\n
IRP notation: {0k,10}<1,-5|1,-15>(1,-25, D:5,F:6, 1,-25,1,120m)+\r\n
EFC translation: 6-bit LSB comp\r\n
Used primarily in Barco remotes.\r\nThis is a moderately robust protocol, but spurious decodes are still possible.
\r\n\r\npid-0083
\r\nUEI protocol: 0083\r\n
EFC translation: 5-bit MSB comp\r\n
IRP notation: {42.3K, 3000}<1,-3,1,-7|1,-7,1,-3>(F:5,1,-27)+\r\nThis protocol is a very limited design. We have seen it used only in the UEI setup code TV/0159,\r\nwhich is for some TVs brand named Fisher, Sanyo and Sears. It is not likely that any other code\r\nset uses this protocol. So if you get a correct decode of pid-0083 you probably have a TV that\r\ncan be controlled by the TV/0159 setup code.
\r\nAs of version 8.31, KM does not translate OBC to EFC according to\r\nthe same rules used by DecodeIr. RM does translate consistently with DecodeIr, so you may find\r\nit easier to use RM. If you use KM, you should use the EFC number from the decode not the OBC number.\r\nPid-0083 protocol\r\nuses the same EFC numbering across all JP1 remotes, so use of EFC is safe. KM uses different\r\nOBC numbering than RM and DecodeIr, so use of OBCs isn't safe.
\r\n\r\nPioneer
\r\nIRP notation: {40k,564}<1,-1|1,-3>(16,-8,D:8,S:8,F:8,~F:8,1,-78)+
\r\nEFC translation: LSB comp\r\nPioneer is distinguished from NEC2 only by frequency. So if your learning system does not\r\nlearn frequency accurately, it won't accurately distinguish Pioneer from NEC2. All Pioneer signals\r\nshould have a device number in the range 160 to 175 and no subdevice. No NEC2 signal should fit those\r\nrules. So you usually can determine whether the decision (by frequency) was wrong by checking the device numbers.
\r\nMany Pioneer commands are sent as combinations of two different Pioneer signals. \r\n This version of DecodeIr does not associate the two signals together into \r\n one command. It decodes them separately. If you get more than one of the same \r\n OBC from decoding a learned signal, that just means the learning system failed \r\n to understand the repeat pattern. It does not mean a two part signal. But \r\n if there are two different OBCs (with the same or different device numbers) \r\n you have a two part Pioneer signal.
\r\nIncluding a two part Pioneer signal in a KeyMove or upgrade is a complex process that requires a good\r\nunderstanding of Pioneer signals and of the Pioneer support in KM. The signals don't vary much among related Pioneer models.\r\nSo the best way to get an upgrade or hex cmd including such signals is to look through existing Pioneer upgrades in\r\nthe JP1 group and find one that already includes the same (or nearly same) signal.
\r\n\r\nProton
\r\nUEI protocol: 005C\r\n
\r\nIRP notation: {38k,500}<1,-1|1,-3>(16,-8,D:8,1,-8,F:8,1,^63m)+
\r\nEFC translation: LSB comp\r\nThis is not a robust protocol, so spurious decodes are likely.
\r\n\r\nRC5
\r\nUEI protocol: 00E8\r\n
\r\nIRP notation: {36k,msb,889}<1,-1|-1,1>(1:1,~F:1:6,T:1,D:5,F:6,^114m)+
\r\nEFC translation: 6-bit MSB comp with 2-bit mini-combo\r\nLists three different EFCs because this protocol is a mini combo.
\r\nWhat we call \"device\" is really the \"System\" and what we \r\n call \"OBC\" is really the \"Command\". If you are using ProntoEdit \r\n to create the RC5 signals directly, that GUI uses that correct (System and \r\n Command) Philips terminology.
\r\n\r\n\r\nRC5-7F
\r\nUEI protocol: 0182\r\n
\r\nIRP notation: {36k,msb,889}<1,-1|-1,1>(1:1, D:1:5,T:1,D:5,F:7,^114m)+
\r\nEFC translation: 7-bit MSB comp\r\n\r\nRC5-7F-57
\r\nUEI protocol: 0182\r\n
\r\nIRP notation: {57k,msb,889}<1,-1|-1,1>(1:1, D:1:5,T:1,D:5,F:7,^114m)+
\r\nEFC translation: 7-bit MSB comp\r\n\r\nRC5x
\r\nUEI protocol: 00F2\r\n
\r\nIRP notation: {36k,msb,889}<1,-1|-1,1>(1:1,~S:1:6,T:1,D:5,-4,S:6,F:6,^114m)+ \r\n
\r\nEFC translation: NONE\r\nThe official (UEI) protocol executor for RC5x does not support EFC numbers. If you are creating an\r\nupgrade in KM or RM you should use OBC numbers, not EFC numbers. If you need the Hex Cmd for a KeyMove,\r\nyou should use the functions sheet of KM or RM to compute it for you from the OBC and subdevice number.
\r\nIn the functions sheet in KM you must put the subdevice number in the byte2 column, which KM calls \r\n \"unit code\".
\r\nWhat we call \"Device\" is really the \"System\". What we call \r\n Subdevice is really the \"Command\". What we call \"OBC\" \r\n is really the \"Data\". If you are using ProntoEdit to create the \r\n RC5 signals directly, that GUI uses that correct (System, Command and Data) \r\n Philips terminology.
\r\n\r\nRC5-?-??
\r\nJust ignore this decode. It is almost certainly spurious. In case there is a new \r\nprotocol I don't know about yet in the family with RC5 and StreamZap, it will decode in this form producing \r\ndata to help me understand that protocol.\r\n\r\nRC6
\r\nUEI protocol: 0058\r\n
IRP notation: {36k,444,msb}<-1,1|1,-1>(6,-2,1:1,0:3,<-2,2|2,-2>(T:1),D:8,F:8,^107m)+\r\n
EFC translation: MSB\r\nRC6 is the name used for the first member of the RC6 family of protocols. Technically this is\r\nRC6-0-16, but DecodeIr will always display that as simply \"RC6\"
\r\n\r\nRC6-6-20
\r\nIRP notation: {36k,444,msb}<-1,1|1,-1>(6,-2,1:1,6:3,<-2,2|2,-2>(T:1),D:8,S:4,F:8,-???)+\r\n
EFC translation: MSB\r\nThis protocol is commonly used in Sky and Sky+ remotes. As of version 8.31, KM does not have built-in support\r\nfor this protocol, but there are KM format upgrade files available for Sky and Sky+ (built by an expert who isn't limited\r\nto KM's built-in protocols). RM has built-in support for RC6-M-20n protocol, which can be used to make Sky and Sky+\r\nupgrades (or any other RC6-6-20 upgrades as long as the T bit is the same for all learned signals, as it is with Sky).\r\nTo use RC6-M-20n for RC6-6-20, you must leave the M field in RM's setup sheet with its default value of 6, and you\r\nmust set or leave the T field (if present) to the value shown in all the decodes (which I assume will be 0).
\r\n\r\nRC6-?-??
\r\nIRP notation: {36k,444,msb}<-1,1|1,-1>(6,-2,1:1,M:3,<-2,2|2,-2>(T:1),???:??)+\r\nThis is the generic form for a decode of protocols in the RC6 family. DecodeIr \r\n uses this form for all RC6 decodes, except RC6-0-16 which is displayed as \r\n simply \"RC6\", RC6-6-24 which is displayed as \"Replay\" \r\n and some RC6-6-32 which display as MCE.
\r\nThe first ? in the protocol name is the M value in the RC6 spec. The ending ?? represents the number of data bits\r\nin the signal.
\r\n\r\nRCA and RCA(Old)
\r\nUEI protocols: 00AF (RCA), 002D(RCA(Old)) and 0114 (RCA Combo)\r\n
IRP notation for RCA: {58k,460,msb}<1,-2|1,-4>(8,-8,D:4,F:8,~D:4,~F:8,1,-16)+\r\n
IRP notation for RCA(Old): {58k,460,msb}<1,-2|1,-4>(32,(8,-8,D:4,F:8,~D:4,~F:8,2,-16)+)\r\n
EFC translation: MSB\r\nThese are two very similar forms of RCA protocol which differ only in\r\n that RCA(Old) has an extended lead-in \r\nand a double-length ON pulse before the lead-out. They are so similar \r\nthat most RCA devices will accept either. \r\nBut some RCA devices only accept the one that really matches their own \r\nremote.\r\nIn versions of DecodeIR prior to v2.40, RCA(Old) was decoded as a frame \r\nof RCA{1} followed usually by a frame of RCA. The second frame now no \r\nlonger appears, so the protocol has been renamed to correspond to that \r\nused in KM and RM.
\r\n\r\nRCA-38 and RCA-38(Old)
\r\nUEI protocol: not known\r\n
IRP notation for RCA-38: {38.7k,460,msb}<1,-2|1,-4>(8,-8,D:4,F:8,~D:4,~F:8,1,-16)+\r\n
IRP notation for RCA-38(Old): {38.7k,460,msb}<1,-2|1,-4>(32,(8,-8,D:4,F:8,~D:4,~F:8,2,-16)+)\r\n
EFC translation: MSB\r\nThese are recently discovered variants of the RCA protocol. They differ from RCA and RCA(Old) only in the \r\n frequency, which is 38.7kHz instead of the standard 58kHz.
\r\n\r\nRECS80
\r\nUEI protocol: 0045, 0068, 0090 or ???\r\n
IRP notation for 0045: {38k,158,msb}<1,-31|1,-47>(1:1,T:1,D:3,F:6,1,-45m)+\r\n
IRP notation for 0068: {33.3k,180,msb}<1,-31|1,-47>(1:1,T:1,D:3,F:6,1,^138m)+\r\n
EFC translation: 6-bit MSB comp\r\nRECS80 is a family of related protocols with the same structure, but different timing. See also\r\nVelleman
\r\nThese are moderately non robust protocols, so spurious decodes are possible.
\r\nThe timing differences are not definitive enough for DecodeIr to identify which RECS80\r\nversion is which. Instead it displays the timing information in the \"Misc\" field of the\r\noutput. That will be three numbers formatted as in this example: (157/5048/7572).
\r\nUsing those three numbers and the frequency, you should be able to determine whether\r\nthe signals fit the 0045 version, the 0068 version, the 0090 version or none of them. You should look at all\r\nthe learned signals for your device together when doing that. A single device won't mix\r\nversions of RECS80, so any differences in frequency or timing between learns is\r\ndue to the IR learning process, not due to any differences among the correct signals. You\r\nshould find one RECS80 version that is a good enough fit for all signals of the device.
\r\nFor 0045,
\r\n\r\n
\r\n- frequency should be between 37000 and 39000
\r\n- first timing number between 100 and 200
\r\n- second timing number between 4500 and 5500
\r\n- third timing number between 6800 and 8300
\r\nFor 0068,
\r\n\r\n
\r\n- frequency should be between 32300 and 34300
\r\n- first timing number between 130 and 250
\r\n- second timing number between 5100 and 6300
\r\n- third timing number between 7700 and 9500
\r\nFor 0090,
\r\n\r\n
\r\n- frequency should be 0
\r\n- first timing number between 0 and 40
\r\n- second timing number between 4500 and 5500
\r\n- third timing number between 6800 and 8300
\r\nYou may find decodes that don't quite fit either. If it almost fits, it may\r\nbe worth testing to see if it works, but it's most unlikely to work if the\r\nsecond timing number is above the suggested max or the third timing number\r\nis below the suggested min. For example, I found a decode with frequency\r\n41879 and timing numbers (132,5092,7652). The three timing numbers are\r\nperfect for protocol 0045, but the frequency is quite wrong. I have no\r\ndevice to test with, but my guess is that it would work anyway. For\r\nprotocol 0068, the third number 7652 is below the minimum of 7700 making\r\nit quite unlikely to work. I found a different device with frequency\r\n33333 and timing (450,5770,8656). For 0068 all but the first number are\r\nperfect and I would be quite surprised if it didn't work. For 0045 the second\r\nnumber 5770 is too high for the max of 5500, so it's unlikely to work.
\r\nThe decodes for RECS80 all report EFCs for protocol 0045. These are not\r\ncorrect EFCs if you select a protocol other than 0045, so it is better to\r\nuse OBC numbers when creating a JP1 upgrade based on these decodes.
\r\n\r\nReplay
\r\nUEI protocol: 0092\r\n
IRP notation: {36k,444,msb}<-1,1|1,-1>(6,-2,1:1,6:3,<-2,2|2,-2>(T:1),D:8,S:8,F:8,-???)+\r\n
EFC translation: MSB\r\nReplay is a member of the RC6 family. Technically it is RC6-6-24, but DecodeIr will always\r\ndisplay the name as \"Replay\". ProntoEdit calls this protocol \"RC6 mode 6A\" and KM has it under the\r\nalternate name \"RC-6a\" as well as its primary name \"Replay\". RM has it under the alternate name \"RC6-M-24n\" as\r\nwell as its primary name \"Replay\".
\r\nDecodeIr's Subdevice field in is called \"unit\" in KM
\r\nIn ProntoEdit, DecodeIr's \"Device\" is called \"Customer Code\"; DecodeIr's \"Subdevice\" is called \"System\";\r\nand DecodeIr's \"OBC\" is called \"Command\".
\r\n\r\nSamsung20
\r\nIRP notation: {38.4k,564}<1,-1|1,-3>(8,-8,D:6,S:6,F:8,1,^???)+\r\n
EFC translation: LSB\r\nThis is a moderately robust protocol, but spurious decodes are still possible.
\r\n\r\n\r\nSamsung36
\r\nUEI protocol: 01B5\r\n
IRP notation: {38k,500}<1,-1|1,-3>(9,-9,D:8,S:8,1,-9,E:4,F:8,-68u,~F:8,1,-118)+\r\n
EFC translation: LSB\r\n\r\nSampo
\r\nIRP notation: {38.4k, 833}<1,-1|1,-3>(4,-4,D:6,F:6,S:6,~F:6,1,-39)+\r\n
EFC translation: Not available in this version of DecodeIr\r\nThis is a moderately robust protocol, but spurious decodes are still possible.
\r\n\r\nScAtl-6
\r\nUEI protocol: 0078\r\n
IRP notation: {57.6k,846}<1,-1|1,-3>(4,-4,D:6,F:6,~D:6,~F:6,1,-40)+\r\n
EFC translation: 6-bit LSB comp\r\nScAtl-6 is distinguished from Emerson only by frequency. So if you are using \r\n a learning system that doesn't record the frequency accurately, then DecodeIr \r\n can't accurately select between Emerson and ScAtl-6.
\r\nIn KM, this protocol is named \"Scientific Atlanta\". Most Scientific Atlanta cable tuners use Panasonic_Old\r\nprotocol, not this protocol.
\r\n\r\nSejin-M-38 and Sejin-M-56
\r\nUEI protocol: 0161\r\n
\r\nIRP notation for Sejin-M-38: {38.8k,310,msb}<-1|1>(<8:4|4:4|2:4|1:4>(3,3:2,Dx:8,Fx:8,Fy:8,E:4,C:4,-L))+ \r\n
\r\nIRP notation for Sejin-M-56: {56.3k,310,msb}<-1|1>(<8:4|4:4|2:4|1:4>(3,3:2,Dx:8,Fx:8,Fy:8,E:4,C:4,-L))+ \r\n
\r\nIn both cases E is a checksum seed (0 in all known examples) and C is a checksum given by\r\n
C = Dx:4 + Dx:4:4 + Fx:4 + Fx:4:4 + Fy:4 + Fy:4:4 + E.\r\n
EFC translation: For Sejin-1, MSB. For Sejin-2, EFC translation not available.\r\nThe parameter M is either 1 or 2. It distinguishes two styles \r\nof this protocol that have different purposes and very different \r\nlead-out times L. The 8-bit parameter Dx is a signed integer. If Dx \r\n> 0 then the style is Sejin-1, used for normal buttons of a remote \r\ncontrol. If Dx < 0 then the style is Sejin-2, used for signals of an\r\n associated 2- or 3-button pointing device. E is a checksum seed, E=0 \r\nin the only known examples. The checksum formula reflects that in the \r\nUEI executor, so is\r\npresumed correct.
\r\n\r\nThe protocol parameters Dx, Fx, Fy translate into device parameters \r\nin different ways corresponding to the different uses of the protocol. \r\nIn Sejin-1 the device parameters are a Device Code, a SubDevice code and\r\n an OBC as is common for many protocols. Sejin-2 has two sub-styles. \r\nOne corresponds to the displacement of a cursor or other pointer with \r\ndevice parameters (X, Y) that\r\ngive the horizontal and vertical components of the displacement (and \r\nwhich can be positive or negative). The other signals Button Up or \r\nButton Down for any of the three buttons of the pointing device. The \r\nMisc field of the DecodeIR output displays these device parameters for \r\nthe Sejin-2 signals. The relationship between these and the protocol \r\nparameters is beyond the\r\nscope of this document. The Misc field also displays an RMOBC value for\r\n Sejin-2 signals, which is an artificial OBC value that can be used as \r\ninput to RemoteMaster to create the signal concerned.
\r\n\r\nThe protocol parameters for Sejin-1 include a bit that marks the end frame of a repeat \r\n sequence. DecodeIR v2.37 and later check this and will report in the Misc field if the end frame is \r\n missing. This will normally be due to the key still being held when the learning process ends, so that \r\n the end frame gets omitted from the learned signal. For Sejin-2 signals that represent button operations \r\n the signal does not repeat. A single frame is sent on button down, a different frame is sent once on \r\n button up. Both frames can be detected and distinguished by DecodeIR v2.37 and later but the button up \r\n frame will not normally be present in a learned signal.
\r\n\r\nSharp, Sharp{1} and Sharp{2}
\r\nIRP notation: {38k,264}<1,-3|1,-7>(D:5,F:8,1:2,1,-165,D:5,~F:8,2:2,1,-165)+\r\n
EFC translation: LSB\r\nA Sharp signal has two halves, either one of which is enough to fully decode \r\n the information. A significant fraction of Sharp learned signals contain just \r\n one half or have the halves separated so that DecodeIr can't process them \r\n together. When one half is seen separate from the other, DecodeIr will name \r\n the protocol Sharp{1} or Sharp{2} depending on which half is decoded. Sharp, \r\n Sharp{1} and Sharp{2} all represent the same protocol when they are correct. \r\n But only Sharp is robust. A Sharp{1} or Sharp{2} decode might be spurious.
\r\n\r\n\r\nSharpDVD
\r\nUEI protocol: 00F8\r\n
\r\nIRP notation: {38k,400}<1,-1|1,-3>(8,-4,170:8,90:8,15:4,D:4,S:8,F:8,E:4,C:4,1,-48)+ {E=1,C=D^S:4:0^S:4:4^F:4:0^F:4:4^E:4}\r\n
EFC translation: LSB comp\r\nSharpDVD is the member of the Kaseikyo family with OEM_code1=170 and OEM_code2=90.
\r\n\r\nSIM2
\r\nIRP notation: {38.8k,400}<3,-3|3,-7>(6,-7,D:8,F:8,3,-60m)\r\n\r\nSolidtek16
\r\nIRP notation: {38k}<-624,468|468-624>(1820,-590,0:1,D:4,F:7,S:1,C:4,1:1,-???) \r\n\r\nThis is a KeyBoard protocol. The make/break bit is decoded into the subdevice field.
\r\n\r\nSolidtek20
\r\nIRP notation: {38k}<-624,468|468-624>(1820,-590,0:1,D:4,S:6,F:6,C:4,1:1,-???) \r\n\r\nThis is a mouse protocol. The button press info is included in the Device field. The horizontal motion\r\nis in the Subdevice field, and the vertical motion is in the OBC field.
\r\nThe decode interface does not support returning negative Subdevice or OBC. So negative motions are\r\nrepresented by adding 64 to them. The numbers 1 to 31 represent positive motion. The numbers 32 to 63\r\nare each 64 larger than the true negative motion, so 63 represents -1 and 32 represents -32.
\r\n\r\nSomfy
\r\nIRP notation: {35.7k}<308,-881|669,-520>(2072,-484,F:2,D:3,C:4,-2300)+\r\n
C is reported as SubDevice. It is probably a check nibble {C = F*4 + D + 3}.\r\n
F = 1 for UP or 2 for DOWN.\r\n
D = 1, 2 or 3 for the three observed devices, or D = 0 to control all devices together.\r\n\r\nSony8
\r\nIRP notation: {40k,600}<1,-1|2,-1>(4,-1,F:8,^22200)\r\n
EFC translation: LSB.\r\n\r\nSony12
\r\nUEI protocol: 00CA\r\n
IRP notation: {40k,600}<1,-1|2,-1>(4,-1,F:7,D:5,^45m)+\r\n
EFC translation: LSB.\r\n\r\nSony15
\r\nUEI protocol: 00CA\r\n
IRP notation: {40k,600}<1,-1|2,-1>(4,-1,F:7,D:8,^45m)+\r\n
EFC translation: LSB.\r\n\r\nSony20
\r\nUEI protocol: 00DE\r\n
IRP notation: {40k,600}<1,-1|2,-1>(4,-1,F:7,D:5,S:8,^45m)+\r\n
EFC translation: LSB.\r\n\r\nStreamZap
\r\nIRP notation: {36k,msb,889}<1,-1|-1,1>(1:1,~F:1:6,T:1,D:6,F:6,^114m)+\r\n
DecodeIR V2.43 decodes this as RC5-7F\r\n
EFC translation: 6-bit MSB comp\r\n\r\nStreamZap-57
\r\nIRP notation: {57k,msb,889}<1,-1|-1,1>(1:1,~F:1:6,T:1,D:6,F:6,^114m)+\r\n
DecodeIR V2.43 decodes this as RC5-7F-57\r\n
EFC translation: 6-bit MSB comp\r\n\r\n\r\nSunfire
\r\nIRP notation: (38k,560,msb)<1,-1|3,-1>(16,-8, D:4,F:8,~D:4,~F:8 -32)+\r\n
EFC translation: Not available in this version of DecodeIr\r\n\r\nTDC-38 and TDC-56
\r\nIRP notation for TDC-38: {38k,315,msb}<-1,1|1,-1>(1:1,D:5,S:5,F:7,-89m)+\r\n
IRP notation for TDC-56: {56.3k,213,msb}<-1,1|1,-1>(1:1,D:5,S:5,F:7,-89m)+\r\n
EFC translation: 7-bit MSB.\r\nThere are two variants of this protocol, with different frequencies but with the same number of carrier \r\n cycles in each burst, which makes the duration of a burst also differ. TDC-38 has a 38kHz carrier and is \r\n used by Danish TDC IPTV. TDC-56 has a 56.3kHz carrier and is used by Italian ALICE Home TV box. These \r\n implementations effectively use a 6-bit OBC as bit 0 of F is always the complement of bit 1, but there \r\n are other implementations which do not follow that pattern.
\r\n\r\nTeac-K
\r\nUEI protocol: 00BB\r\n
\r\nIRP notation: {37k,432}<1,-1|1,-3>(8,-4,67:8,83:8,X:4,D:4,S:8,F:8,T:8,1,-100,(8,-8,1,-100)+\r\n{T=D+S:4:0+S:4:4+F:4:0+F:4:4}
\r\nEFC translation: LSB comp, two parts\r\nTeac-K is the member of the Kaseikyo family with OEM_code1=67 and OEM_code2=83.
\r\nTeac-K uses different repeat rules and a different check byte than other Kaseikyo protocols.
\r\n00BB requires 2-byte hex commands. DecodeIr returns both hex cmd bytes through the interface that usually\r\nmeans one or the other (for mini combos) but in this case it means both.
\r\nThis protocol signals repeats by the use of dittos.
\r\n\r\nThomson
\r\nUEI protocol: 004B\r\n
IRP notation: {33k,500}<1,-4|1,-9>(D:4,T:1,D:1:5,F:6,1,^80m)+\r\n
EFC translation: 6-bit LSB comp, or that prepended with extra device bit.\r\nThis is not a robust protocol, so spurious decodes are likely.
\r\nDecodeIR2.42 deprecates Thompson (5 bits of device, and 6 bits of function) and reports these\r\n signals as Thompson7 (4 bits of device and 7 bits of function).
\r\nThomson includes a toggle bit so using learned signals will have\r\noperational problems. You should use KeyMoves or Upgrades based on the decoded values,\r\nrather than continue to use the learned signals.
\r\nThere are two different variants of UEI protocol 004B which have different \r\n EFC numbering. The decode lists both possible EFCs so you could experiment \r\n to discover which is right for your model. But, if you are creating an upgrade \r\n (rather than just KeyMoves) it is better to use RM and use the OBC numbers \r\n from the decode (which are stable across models of JP1 remote). As of version \r\n 8.31, KM does not have support for Thomson protocol, so if you must make an \r\n upgrade in KM you need to use pid:004B. For the URC-8040 and 8060 the second \r\n decoded EFC should be right and the OBC values in KM should be wrong. For \r\n most (maybe all) other models, the first decoded EFC should be right and KM's \r\n default EFC to OBC translation should also be right.
\r\n\r\nThomson7
\r\nUEI protocol: 004B\r\n
IRP notation: {33k,500}<1,-4|1,-9>(D:4,T:1,F:7,1,^80m)+\r\n
EFC translation: 7-bit LSB comp\r\nDecodeIR2.42 deprecates Thompson (5 bits of device, and 6 bits of function) and reports these\r\n signals as Thompson7 (4 bits of device and 7 bits of function).
\r\n\r\nTivo
\r\nIRP notation: {38.4k,564}<1,-1|1,-3>(16,-8,133:8,48:8,F:8,U:4,~F:4:4,1,-78,(16,-4,1,-173)*) \r\n
\r\nEFC translation: LSB comp\r\n\r\nVelleman
\r\nIRP notation: {38k,msb}<700,-5060|700,-7590>(1:1,T:1,D:3,F:6,1,-55m)+\r\n
EFC translation: 6-bit MSB comp\r\nVery similar to RECS80-0045, except on duration is longer
\r\n\r\nVelodyne
\r\nIRP notation: \r\n{38k,136,msb}<210,-760>(<0:1|0:1,-1|0:1,-2|0:1,-3|0:1,-4|0:1,-5|0:1,-6|0:1,-7|0:1,-8|0:1,-9|0:1,-10|0:1,-11|0:1,-12|0:1,-13|0:1,-14|0:1,-15>(S:4:4,C1:4,S:4,15:4,D:4,0:4,F:8,210u,-79m,S:4:4,C2:4,S:4,15:4,D:4,8:4,F:8,210u,-79m)+){C1=-(8+S+S::4+15+D+0+F+F::4),C2=-(8+S+S::4+15+D+8+F+F::4))\r\n
Velodyne is a close relative of XMP. \r\n\r\nViewstar
\r\nUEI protocol: 0021\r\n
IRP notation: {50.5k,337}<1,-8|1,-5>(F:5,1,-17)+\r\n
EFC translation: 5-bit LSB comp\r\nThis is not a robust protocol, so spurious decodes are likely.
\r\n\r\nX10 and X10.n
\r\nUEI protocol: 003F (X10.n), 01DF (X10)\r\n
IRP notation for X10: {40.8k,565}<2,-12|7,-7>(7,-7,F:5,~F:5,21,-7)+\r\n
IRP notation for X10.n: {40.8k,565}<2,-12|7,-7>(F:5,N:-4,21,-7,(7,-7,F:5,~F:5,21,-7)+)\r\n
EFC translation: LSB of 2*OBC+1\r\nThese are two variants of the same Home Automation protocol. They differ in that X10.n has a \r\n distinctive start frame that carries a sequence number, the n of the protocol name, in addition \r\n to the OBC. The repeat frames, and all frames of the X10 version, only carry the OBC. The value \r\n of n runs from 0 to 15 (or some lower value) and then restarts again at 0. It is incremented on \r\n each successive keypress. A valid X10.n signal must have at least one repeat frame. If this is \r\n missing then the Misc column shows \"invalid signal\".
\r\nRemoteMaster has a single protocol, named X10 with PID 003F, that sends X10.n signals. This is \r\n the same as the UEI protocol with that PID. There is no control over the value of n, this is \r\n handled automatically by the remote. The newer UEI protocol, with PID 01DF, sends X10 signals.
\r\n\r\nXMP, XMP-1 and XMP-2
\r\nUEI protocol: 016C\r\n
IRP notation (without final frame): \r\n{38k,136,msb}<210,-760>(<0:1|0:1,-1|0:1,-2|0:1,-3|0:1,-4|0:1,-5|0:1,-6|0:1,-7|0:1,-8|0:1,-9|0:1,-10|0:1,-11|0:1,-12|0:1,-13|0:1,-14|0:1,-15>(T=0,(S:4:4,C1:4,S:4,15:4,OEM:8,D:8,210u,-13.8m,S:4:4,C2:4,T:4,S:4,F:16,210u,-80.4m,T=8)+)){C1=-(15+S+S::4+15+OEM+OEM::4+D+D::4),C2=-(15+S+S:4+T+F+F::4+F::8+F::12)}\r\n
IRP notation (with final \r\nframe):{38k,136,msb}<210,-760>(<0:1|0:1,-1|0:1,-2|0:1,-3|0:1,-4|0:1,-5|0:1,-6|0:1,-7|0:1,-8|0:1,-9|0:1,-10|0:1,-11|0:1,-12|0:1,-13|0:1,-14|0:1,-15>(T=0,((S:4:4,C1:4,S:4,15:4,OEM:8,D:8,210u,-13.8m,S:4:4,C2:4,T:4,S:4,F:16,210u,[-80.4m][-80.4m][-13.8m],T=8)+,T=9)2)){C1=-(S+S::4+15+OEM+OEM::4+D+D::4),C2=-(S+S:4+T+F+F::4+F::8+F::12)}\r\n
XMP uses one burst pair to encode numbers 0 to 15, with an on \r\nduration of 210uS, and off duration of 760uS + n*136uS where n takes on \r\nvalues of 0 to 15.\r\nThe checksum nibble is the complement of 15 plus the sum of the other 7 \r\nnibbles, mod 16\r\n\r\n
The Device code is D, the SubDevice code is S and there are two OBC values. OBC1 is the high byte \r\nof F, OBC2 is the low byte of F. The OEM code is normally 0x44 and is reported in the Misc field only if it \r\nhas a different value. The XMP-1 protocol is XMP with OBC2 = 0. The OBC field in DecodeIR then shows OBC1. \r\nThe XMP-2 protocol is XMP with OBC1 = 0. The OBC field in DecodeIR then shows OBC2.\r\nThis protocol has a 4-bit toggle T that is 0 for the first frame and normally 8 for all repeat frames. \r\n There is, however, a variant in which a further frame with T=9 is sent after the button is released, \r\n separated from the preceding frame by the short leadout of 13.8m that is used between two half-frames \r\n rather than the long lead-out of 80.4m used at the end of all other frames. When this frame is detected \r\n then the Misc field displays \"With Final Frame\". For this to be shown in a learned signal, the \r\n button must be released before the learning process times out, so a short button press is needed.
\r\n\r\nThese are problem decodes because JP1 remotes don't typically learn these signals accurately enough\r\nfor a correct decode. NG Prontos also do a rotten job of learning these signals. Older Prontos seem to do\r\nfairly well. DecodeIR v2.40 includes algorithms that attempt to reconstruct a valid XMP signal from a corrupt\r\nlearn, but it is impossible to correct all learning errors and there can be no certainty that a reconstruction\r\nis actually correct.
\r\nIn a correctly learned or fully reconstructed signal there will be an\r\n \"XMP\", \"XMP-1\" or \"XMP-2\" decode with device, subdevice and OBC values \r\nthat can be used with RemoteMaster or any similar\r\nprogram to regenerate a clean signal. The Misc field shows which \r\nalgorithms, if any, have been applied, as a list in brackets after any \r\ndecode data in this field. There are notes below on the reliability of \r\nthe various algorithms. When the protocol shows as (unqualified) XMP, \r\nboth OBC values are non-zero. The OBC and Hex fields show OBC1. The \r\ncorresponding values for OBC2 are shown in the Misc field.
\r\nThe learned signal itself will certainly not be valid if any reconstruction algorithms have been applied and\r\nit may not be so even if it has been decoded without reconstruction. The possible algorithm indicators in the \r\nMisc field are as follows:
\r\n\r\n
\r\n- End (= Endpoint): The lead-out burst is missing and has been inserted. This is almost certainly correct.\r\n
- Rec (= Recovery): Look-ahead has been used to recover a \r\nmissing burst from the following repeat frame. This is very likely to \r\nbe correct.\r\n
- Cor (= Correction): Two bursts have been coalesced in the \r\nlearning process, e.g. those for hex digits C and D, causing a C to \r\nappear as D or vice versa.\r\nThe error has been identified and corrected. This is probably correct.\r\n
- Cal (= Calculated): A missing digit has been calculated from a \r\nchecksum. The digit is probably correct but it may be in the wrong \r\nplace. The most likely error in the reconstruction is that the two \r\ndigits of the OBC are the wrong way round.\r\n
- Cal2 (= Calculated 2) Two consecutive missing zero digits have\r\n been identified, corresponding to a zero OBC. When this happens, the \r\nsignal will always be shown as XMP-1. The most likely error in the \r\nreconstruction is that it should actually be XMP-2.\r\n
If a learned signal is good enough to be recognised as XMP but not good enough to be fully reconstructed, the\r\nprotocol will display with a name of the form\r\n
\r\n
XMP:136.218-0F0F441A0A800F00\r\n
\r\n In IR.exe you'll need to widen the Protocol column to see the whole thing. This \r\n represents intermediate data from an unsuccessful attempt to decode a XMP signal. \r\n\r\n The number in the position where the 136 is in this example represents the time scale. A number (like this\r\nexample) that is near 137 is reasonable. A number much further from 137 indicates a more serious learning or decoding\r\nproblem.\r\nThe number in the position where the .218 is in this example (it is not part of the 136) represents the level\r\nof inconsistency in the individual hex digit decodes. A value greater than .100 means the hex digits aren't very\r\nreliable.The hex string, where the 0F0F441A0A800F00 is, is the decoded data. At least one digit is almost certainly wrong or\r\nthe whole decode wouldn't be displayed in this form. With a JP1 learning remote, the most common errors are that a\r\ndigit is actually missing, in which case the string will have fewer than 16 hex digits, or that two\r\nor more digits which are decoded the same are actually different, so some of them are correct and some are one value\r\nhigher or lower. Although the reconstruction algorithms attempt to correct these types of errors, it is not always\r\npossible. In this example I happen to know the correct signal. One of the three F's is really an E and one\r\nof the two A's is really a 9. The correct string is 0E0F441A09800F00.
\r\nAlmost all examples we've seen start with \"0E0F441A0\" or \"060F44120\". But we've also seen upgrades from UEI for\r\n\"0D1F441A0\" and \"0C2F441A0\" and \"0B3F441A0\".\r\nThe last 4 digits of the whole 16 digit string (if they are correct) represent the Hex command needed to reproduce\r\nthe signal in a JP1 upgrade or KeyMove. DecodeIR shows them as two 8-bit OBC values, as described with the IRP\r\nnotation above.
\r\n\r\nXX
\r\nDocumentation not written yet.\r\n\r\nZaptor
\r\nUEI protocol: unknown\r\n
IRP notation: {36k,330,msb}<-1,1|1,-1>[T=0] [T=0] [T=1] (8,-6,2,D:8,T:1,S:7,F:8,E:4,C:4,-74m)+ \r\n {C = (D:4+D:4:4+S:4+S:3:4+8*T+F:4+F:4:4+E)&15}\r\n
where T=0 for all frames except the last, T=1 for last frame, E is a checksum seed. There is a 56KHz variant.\r\n
EFC translation: MSB\r\nA protocol so far seen only in the Motorola Zaptor. See also Amino
\r\n\r\nZenith
\r\nUEI protocol: 0022\r\nIRP notation: {40k,520,msb}<1,-10|1,-1,1,-8>(S:1,<1:2|2:2>(F:D),-90m)+\r\n
Before Version 2.43, this document has shown the IRP notation as \r\n{40k,520,msb}<1,-1,1,-8|1,-10>(S:1,<1:2|2:2>(F:D),-90m)+\r\n
EFC translation: MSB \r\nAn unusual protocol, in that the number of bits in the function code is variable. It is represented in \r\n DecodeIR as the device code. There are also two lead-in styles, decoded as subdevice values 0 and 1. \r\n Style 1 aka \"double-start\" is usually used in TV's, other appliances use 0 aka \"single start\". If the \r\n device code is >8 then the bytes given in the Misc field as E = ... follow the OBC in the function \r\n code value.
\r\n\r\n?1-??-??-??
\r\nAn experimental decode I added based on the thread at\r\nJP1-forum\"Unknown \r\n Protocol\"\r\n\r\n
\r\n