RC5.
UEI protocol: 00E8
IRP notation: {36k,msb,889}<1,-1|-1,1>(1:1,~F:1:6,T:1,D:5,F:6,^114m)+
EFC translation: 6-bit MSB comp with 2-bit mini-combo
Lists three different EFCs because this protocol is a mini combo.
What we call "device" is really the "System" and what we call "OBC" is really the "Command". If you are using ProntoEdit to create the RC5 signals directly, that GUI uses that correct (System and Command) Philips terminology.
UEI protocol: 0182
IRP notation: {36k,msb,889}<1,-1|-1,1>(1:1, D:1:5,T:1,D:5,F:7,^114m)+
EFC translation: 7-bit MSB comp
UEI protocol: 0182
IRP notation: {57k,msb,889}<1,-1|-1,1>(1:1, D:1:5,T:1,D:5,F:7,^114m)+
EFC translation: 7-bit MSB comp
UEI protocol: 00F2
IRP notation: {36k,msb,889}<1,-1|-1,1>(1:1,~S:1:6,T:1,D:5,-4,S:6,F:6,^114m)+
EFC translation: NONE
The official (UEI) protocol executor for RC5x does not support EFC numbers. If you are creating an upgrade in KM or RM you should use OBC numbers, not EFC numbers. If you need the Hex Cmd for a KeyMove, you should use the functions sheet of KM or RM to compute it for you from the OBC and subdevice number.
In the functions sheet in KM you must put the subdevice number in the byte2 column, which KM calls "unit code".
What we call "Device" is really the "System". What we call Subdevice is really the "Command". What we call "OBC" is really the "Data". If you are using ProntoEdit to create the RC5 signals directly, that GUI uses that correct (System, Command and Data) Philips terminology.
Just ignore this decode. It is almost certainly spurious. In case there is a new protocol I don't know about yet in the family with RC5 and StreamZap, it will decode in this form producing data to help me understand that protocol.
