Convert Learned Codes for Delta Air Cleaner #50-875

[mathdon]

@Barf

I don't know if this will meet any of your concerns about my F12x entry, but I have rewritten the description. The original description was simply a copy of what I had used in protocols.ini, but on re-reading it I saw that was not appropriate as a protocol description. The new description is

Code: Select all

This is an extended and slightly modified version of the F12 protocol.  The modifications are that the lead-out gap between frames is only one-fifth of that of the F12 protocol and that the number of repeats does not have to be an even number. The extension is that there is a final frame sent on key release with a different command value. This protocol has been seen in the Delta Air Cleaner #50-875.

As I said in my post above, thanks again for the instructions on how to create a merged IrpProtocols.html for inclusion in RMIR. It works beautifully.

[Barf]

I am sorry to say, but the given IRP for F12x:

Code: Select all

{37.9k,422}<1,-3|3,-1>((D:3,S:1,F:8,-16)+,(D:3,S:1,E:8,-16))[D:0..7,S:0..1,F:0..255,E:0..255]

is unfortunately not decodable.

Not all vaild IRPs can be decoded in IrpTransmogrifier. Basically, it matches actual duration to duration in the IRP, without backtracking. (The exception is of course the parsing of BitFields, which would not be possible to parse without backtracking.)

BTW, the verbal description of 016D:

UEI executor 016D transmits a similar signal but with a leadout time of 6.7mS. One frame of OBC1 and repeating frame of OBC2.

translates to IRP:

Code: Select all

{...}<...>(...OBC1...,(....OBC2....)*)

which can be decoded.

[mathdon]

BTW, the verbal description of 016D:

UEI executor 016D transmits a similar signal but with a leadout time of 6.7mS. One frame of OBC1 and repeating frame of OBC2.

translates to IRP:

Code: Select all

{...}<...>(...OBC1...,(....OBC2....)*)

which can be decoded.

You are quoting from the DecodeIR documentation, which unfortunately is wrong. This is most easily seen from analysis of the MAXQ610 executor with RMPB. There are two signal blocks, the first repeats on held keypress, the second does not. It is the OBC1 signal that repeats, with the OBC2 signal sent once on key release. And IrpTransmogrifier can decode it, if used appropriately. Try posting this signal:

Code: Select all

0000 006E 0030 0000 0030 0010 0030 0010 0010 0030 0030 0010 0030 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0030 0110 0030 0010 0030 0010 0010 0030 0030 0010 0030 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0030 0110 0030 0010 0030 0010 0010 0030 0030 0010 0030 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0130 0030 0010 0030 0010 0010 0030 0030 0010 0030 0010 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0030 0010 0130

into RMIR Learned Signals panel as a new learned signal and pressing Apply. It has the final frame and decodes correctly as F12x with OBC1=129, OBC2=1. See lines 437-455 of the source file LearnedSignal.java to see how RMIR handles decoding of signals that have a final frame sent on key release.

[Barf]

Code: Select all

{37.9k,422}<1,-3|3,-1>((D:3,S:1,F:8,-16)*,(D:3,S:1,E:8,-16))[D:0..7,S:0..1,F:0..255,E:0..255]

(i.e. a * instead of the +) for F12x is decodable and appears to work fine.

Having intro- and repeat sequence equal (like using the +-form) causes problems for decoding.

[mathdon]

@Barf
Thanks, I have made the change.

[Barf]

Great!

Would it be possible to also revert the change of minimum-leadout of F12_relaxed?

[mathdon]

Would it be possible to also revert the change of minimum-leadout of F12_relaxed?

I have previously said no, as despite the presence of a prefer-over, one of hgetz's signals was giving a multiple decode of F12 and F12x. This is a learned signal that has both a repeat section and an extra (final) one, though both are identical. The extra section triggers my special handling of final frames. I have now found that it is this special handling that is responsible for the prefer-over not working. I will fix this and so yes, I will now revert the minimum-leadout of F12_relaxed back to 6000 from my value of 15000.

[Barf]

[mathdon]

I have now found that it is this special handling that is responsible for the prefer-over not working. I will fix this and so yes, I will now revert the minimum-leadout of F12_relaxed back to 6000 from my value of 15000.

Done. Now in SVN.

[3FG]

Graham,
I think the F12x entry in Protocols.ini contains a small error.

Code: Select all

PID=01 6D
DevParms=Device:3=0,Subdevice:1=0,OBC2:8=1
DeviceTranslator=Translator(lsb,0,3,0) Translator(1,1,3) Translator(lsb,2,8,4)
CmdParms=OBC1:8=0
CmdTranslator=Translator(lsb)
FixedData=08 00
Notes=This is an extended and slightly modified version of the F12 protocol.  The modification is that the lead-out gap \
between frames is only one-fifth of that of the F12 protocol.  There are two extensions.  The first is that the Subdevice \
value, which is either 0 or 1, needs to be specified explicitly, while in the F12 protocol it is calculated from the other \
parameters.  The other extension is that there are two OBC values.  The first frame and its repeats are sent with OBC1 \
given as a command parameter, but there is a final frame sent on key release with OBC2 given as a device parameter, \
which is therefore the same for all signals.

I think

Code: Select all

DeviceTranslator=Translator(lsb,0,3,0) Translator(1,1,3) Translator(lsb,2,8,4)

will never fill in the second byte of the fixed data, and it will always have the value 0, even though the default for OBC2 is 1. Instead, I think it should be

Code: Select all

DeviceTranslator=Translator(lsb,0,3,0) Translator(1,1,3) Translator(lsb,2,8,8)

BTW, the learned signals in https://hifi-remote.com/forums/viewtopic ... 714#p146714 decode as F12x, but apparently don't actually contain a different last command, so probably this decode is triggered by the short lead-out time. I suspect F12x will still work in this situation, and the fan will just ignore the last command byte of 0.