Automated analysis of IR protocols
Posted: Tue Apr 27, 2010 5:34 am
I have been investigating how far it is possible to take automated analysis of IR protocols. The result is incorporated into ExchangeIR.dll v0.05. I have enhanced IRScope to take advantage of this new capability and have posted it as IRScope 2.01 Beta 3. This package includes ExchangeIR.dll v0.05.
The new analysis appears in the Summary display as a description of the signal in IRP notation. Here is a screenshot showing the Summary screen with a varied collection of protocols:
There is no look-up involved. The IRP form is constructed entirely from an analysis of the signal and should work with a wide variety of signals whose protocols are unknown. I hope it will be a useful tool in the analysis of such protocols. Here is an example of how to interpret the output. The IRP form of signal 1, Pace protocol, shows as
{38.2k,633,msb}<1,-7|1,-11>(1,-5,1,-5,A:10,1,-89)+{A=$304}; Alt leadout form: ^123m
The IRP for the Pace protocol given in DecodeIR.html is:
{38k,630,msb}<1,-7|1,-11>(1,-5,1,-5,T:1,D:1,F:8,1,^120m)+
The correspondence for the most part is obvious. Automated analysis cannot split the data bits into device and function codes, etc, so it shows all the data concatenated as A:10, i.e. the value of A expressed in 10 bits. This value is given in hex form in the curly brackets. Writing $304 as 10 bits gives 1100000100. This corresponds to the T:1, D:1, F:8 of the DecodeIR.html form with (again in binary) T=1, D=1, F=00000100, or in decimal as T=1,D=1,F=4. This agrees exactly with the description of item 1 on the IRScope main screen.
Automated analysis often cannot determine whether the lead-out is an absolute value (the -89 given in the IRP expression) or a cumulative value (the ^123m given as an alternate form), so both are given in this case. Sometimes it is possible for an automated determination, such as when two lead-outs occur which agree in one form but disagree in the other form. This is the case in signal 6, NECx1 protocol:
{38.1k,562,msb}<1,-1|1,-3>(8,-8,A:32,1,^108m,(8,-8,B:1,1,^108m)+){A=$E090F00F,B=$0}
as the main frame and the ditto repeat have lead-outs with different absolute values. The Nokia protocol shows up with a different form to the usual one:
{34.5k,msb}<-164u|174u,-268u>(<1:-1|1:-2|1:-3|1:-4>(424u,-259u,A:24,176u,-91.4m)+) {A=$0E0004}; Alt leadout form: ^99m
In the inner bitspec, 1:-3 (for example) means 1 expressed as 3 bits (001), but the minus sign means that the order is reversed from the msb order specified in the initial curly brackets. This is standard IRP notation, not an invention of mine. So 1:-3 means 100 encoded according to the outer bitspec, i.e. 174u,-268u,-164u,-164u. Adding the consecutive OFF times gives 174u,-596u. The DecodeIR.html form is
{36k,msb}<164,-276|164,-445|164,-614|164,-783>(412,-276,D:8,S:8,F:8,164,-???)+
The slight differences in values are inherent in the signal and are not due to the analysis. It isn't actually necessary to understand the bitspec notation to extract the data, however, as this has already been done in the value A=$0E0004, i.e. D=$0E=14, S=$00=0, F=$04=4, again in agreement with the main IRScope screen.
The analysis works by looking for patterns in the signal, often in a hierarchy of increasing specialization. It outputs the most specialized form that it finds. This can occasionally lead to unexpected results. For example, the Pace protocol above is also represented by
{38.2k,633,msb}<1,-5|1,-7|1,-9|1,-11>(A:24,1,-89)+{$F5575}
which looks very different but which corresponds to the same IR signal. The first form is more specialized, so that is output, but a poor read of the signal might prevent the specialization being recognised, resulting in something close to this second form being shown. It is also possible for accidental patterns in the data to result in a more specialized form being output than is warranted by the protocol as a whole.
The analysis will recognise a straightforward repeating pattern from two occurrences, but less straightforward repeats such as "ditto frames" require three occurrences, i.e. the main signal plus three dittos. DecodeIR is very forgiving of poor signal reads, which can result in spurious identifications. This ExchangeIR analysis has the opposite problem. It requires a good read, as every burst is examined, so DecodeIR may show an identification when the ExchangeIR analysis returns "Undetermined".
Because some protocols unknown to DecodeIR result in spurious decodes which can potentially upset the automated analysis (by breaking the signal at the wrong points), there is a new option on the Advanced menu of IRScope, to Disable Decoder. All signals then show as "<unknown>" but the Summary still shows the analysis and IRP form of the signal.
Finally, it is not necessary to have a Widget in order to use this analysis as IRScope now has the ability to import signals in either Pronto or UEI Learned forms.
I think this should be enough to enable the output to be understood. I await comments with interest!
________________
Graham
The new analysis appears in the Summary display as a description of the signal in IRP notation. Here is a screenshot showing the Summary screen with a varied collection of protocols:
There is no look-up involved. The IRP form is constructed entirely from an analysis of the signal and should work with a wide variety of signals whose protocols are unknown. I hope it will be a useful tool in the analysis of such protocols. Here is an example of how to interpret the output. The IRP form of signal 1, Pace protocol, shows as
{38.2k,633,msb}<1,-7|1,-11>(1,-5,1,-5,A:10,1,-89)+{A=$304}; Alt leadout form: ^123m
The IRP for the Pace protocol given in DecodeIR.html is:
{38k,630,msb}<1,-7|1,-11>(1,-5,1,-5,T:1,D:1,F:8,1,^120m)+
The correspondence for the most part is obvious. Automated analysis cannot split the data bits into device and function codes, etc, so it shows all the data concatenated as A:10, i.e. the value of A expressed in 10 bits. This value is given in hex form in the curly brackets. Writing $304 as 10 bits gives 1100000100. This corresponds to the T:1, D:1, F:8 of the DecodeIR.html form with (again in binary) T=1, D=1, F=00000100, or in decimal as T=1,D=1,F=4. This agrees exactly with the description of item 1 on the IRScope main screen.
Automated analysis often cannot determine whether the lead-out is an absolute value (the -89 given in the IRP expression) or a cumulative value (the ^123m given as an alternate form), so both are given in this case. Sometimes it is possible for an automated determination, such as when two lead-outs occur which agree in one form but disagree in the other form. This is the case in signal 6, NECx1 protocol:
{38.1k,562,msb}<1,-1|1,-3>(8,-8,A:32,1,^108m,(8,-8,B:1,1,^108m)+){A=$E090F00F,B=$0}
as the main frame and the ditto repeat have lead-outs with different absolute values. The Nokia protocol shows up with a different form to the usual one:
{34.5k,msb}<-164u|174u,-268u>(<1:-1|1:-2|1:-3|1:-4>(424u,-259u,A:24,176u,-91.4m)+) {A=$0E0004}; Alt leadout form: ^99m
In the inner bitspec, 1:-3 (for example) means 1 expressed as 3 bits (001), but the minus sign means that the order is reversed from the msb order specified in the initial curly brackets. This is standard IRP notation, not an invention of mine. So 1:-3 means 100 encoded according to the outer bitspec, i.e. 174u,-268u,-164u,-164u. Adding the consecutive OFF times gives 174u,-596u. The DecodeIR.html form is
{36k,msb}<164,-276|164,-445|164,-614|164,-783>(412,-276,D:8,S:8,F:8,164,-???)+
The slight differences in values are inherent in the signal and are not due to the analysis. It isn't actually necessary to understand the bitspec notation to extract the data, however, as this has already been done in the value A=$0E0004, i.e. D=$0E=14, S=$00=0, F=$04=4, again in agreement with the main IRScope screen.
The analysis works by looking for patterns in the signal, often in a hierarchy of increasing specialization. It outputs the most specialized form that it finds. This can occasionally lead to unexpected results. For example, the Pace protocol above is also represented by
{38.2k,633,msb}<1,-5|1,-7|1,-9|1,-11>(A:24,1,-89)+{$F5575}
which looks very different but which corresponds to the same IR signal. The first form is more specialized, so that is output, but a poor read of the signal might prevent the specialization being recognised, resulting in something close to this second form being shown. It is also possible for accidental patterns in the data to result in a more specialized form being output than is warranted by the protocol as a whole.
The analysis will recognise a straightforward repeating pattern from two occurrences, but less straightforward repeats such as "ditto frames" require three occurrences, i.e. the main signal plus three dittos. DecodeIR is very forgiving of poor signal reads, which can result in spurious identifications. This ExchangeIR analysis has the opposite problem. It requires a good read, as every burst is examined, so DecodeIR may show an identification when the ExchangeIR analysis returns "Undetermined".
Because some protocols unknown to DecodeIR result in spurious decodes which can potentially upset the automated analysis (by breaking the signal at the wrong points), there is a new option on the Advanced menu of IRScope, to Disable Decoder. All signals then show as "<unknown>" but the Summary still shows the analysis and IRP form of the signal.
Finally, it is not necessary to have a Widget in order to use this analysis as IRScope now has the ability to import signals in either Pronto or UEI Learned forms.
I think this should be enough to enable the output to be understood. I await comments with interest!
________________
Graham
