Difference between revisions of "Protocol decoder:Ir irmp"
(comment on annotation spans which can extend beyond other decoders' output) |
|||
| Line 21: | Line 21: | ||
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. | 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. | ||
Annotations of the IRMP based decoder appear to span longer periods of time for some of the protocols, due to the inner organization of the IRMP core. Since multiple protocols are supported, and more constraints get checked to resolve ambiguities or decode several candidates in parallel until a final result becomes available, the signal might get inspected for a longer time until a result becomes available, and the annotation happens to span the period from the start of a frame to the availability of the detection result. | |||
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. | ||
Revision as of 08:54, 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.
Annotations of the IRMP based decoder appear to span longer periods of time for some of the protocols, due to the inner organization of the IRMP core. Since multiple protocols are supported, and more constraints get checked to resolve ambiguities or decode several candidates in parallel until a final result becomes available, the signal might get inspected for a longer time until a result becomes available, and the annotation happens to span the period from the start of a frame to the availability of the detection result.
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