Difference between revisions of "Protocol decoder:Ir irmp"
(start ir_irmp decoder page) |
|||
| Line 24: | Line 24: | ||
Detection results are not identical for protocol specific decoders and the IRMP approach (or their current implementations). Both cases were observed: The IRMP decoder covers more protocols and yields results that were unavailable with other decoders. And e.g. NEC decoders showed all frames of a burst sequence while IRMP missed some (cause yet to get determined). It's probably most appropriate to combine the available decoders, and attach multiple of them to the input signal. IRMP is convenient to detect a protocol type and interpret data when no specific decoder is available, while specific decoders can help in diagnosing issues with one protocol in more detail. | Detection results are not identical for protocol specific decoders and the IRMP approach (or their current implementations). Both cases were observed: The IRMP decoder covers more protocols and yields results that were unavailable with other decoders. And e.g. NEC decoders showed all frames of a burst sequence while IRMP missed some (cause yet to get determined). It's probably most appropriate to combine the available decoders, and attach multiple of them to the input signal. IRMP is convenient to detect a protocol type and interpret data when no specific decoder is available, while specific decoders can help in diagnosing issues with one protocol in more detail. | ||
<gallery widths=800px> | |||
File:irmp_rc5_compare.png|<small>comparison of IRMP and RC5 decoders</small> | |||
File:irmp_first_details.png|<small>details of a button press (first)</small> | |||
File:irmp_repeat_details.png|<small>details of a repeated button press</small> | |||
File:irmp_repeat_sequence.png|<small>compact presentation of a repeat sequence (see flags)</small> | |||
</gallery> | |||
== Resources == | == Resources == | ||
Revision as of 08:49, 18 July 2020
 | |
| Name | IR IRMP |
|---|---|
| Description | Infrared remote control multi protocol |
| Status | in progress |
| License | GPLv2+ |
| Source code | decoders/ir_irmp |
| Input | logic |
| Output | — |
The IRMP project originated as AVR firmware and was ported to other MCU types. A single firmware image contains support for a wide set of protocols. Some 50 protocol types are supported by the project, up to some 35 of them can get enabled at the same time (compile time configuration). A wrapper library lets a sigrok decoder use the IRMP core logic to detect infrared remote control frames.
Decoder
Important: An implementation detail limits the current version to one decoder instance. This is a consequence of keeping state in global variables, which is necessary for execution on resource constrained microcontrollers. Concentrating state in structs and adding support for multiple instances is rather intrusive, would heavily deviate from the upstream IRMP project, and would not be desirable upstream either (affects runtime behaviour and firmware size, breaks existing features).
A minor constraint which is easy to satisfy: The IRMP core gets configured at compile time to a samplerate of 20kHz. An implementation detail in the Python decoder assumes that input data comes at a rate which is an integer multiple of this fixed rate. It's easy to capture data at rates of several 100kHz or 1MHz, this should not be an issue.
Because the IRMP core supports multiple protocols at the same time, and currently provides detection results in a unified compact presentation, the decoder's annotations are not as fine grained as the annotations of protocol specific decoders are. Most details are there, but they get combined into a single annotation. Which results in both more visibility at coarser zoom levels, but also more attention needed to "parse" the output by humans. A future implementation could split detection results into more fields.
Detection results are not identical for protocol specific decoders and the IRMP approach (or their current implementations). Both cases were observed: The IRMP decoder covers more protocols and yields results that were unavailable with other decoders. And e.g. NEC decoders showed all frames of a burst sequence while IRMP missed some (cause yet to get determined). It's probably most appropriate to combine the available decoders, and attach multiple of them to the input signal. IRMP is convenient to detect a protocol type and interpret data when no specific decoder is available, while specific decoders can help in diagnosing issues with one protocol in more detail.
comparison of IRMP and RC5 decoders
details of a button press (first)
details of a repeated button press
compact presentation of a repeat sequence (see flags)
Resources
- the IRMP project homepage at mikrocontroller.net, and its English incarnation