JP1 Remotes :: View topic - Convert Learned Codes for Delta Air Cleaner #50-875

JP1 Remotes

FAQ

7 Days

Memberlist

Usergroups

Profile

File Section

File Search

Lookup Tool

Wiki

Convert Learned Codes for Delta Air Cleaner #50-875
Goto page Previous 1, 2

JP1 Remotes Forum Index -> JP1 - Protocol Decodes

View previous topic :: View next topic

Author

Message

mathdon
Expert

Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK

Posted: Sat Feb 05, 2022 10:58 am Post subject:

@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:

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.
_________________
Graham

Barf
Expert

Joined: 24 Oct 2008
Posts: 1414
Location: Munich, Germany

Posted: Thu Feb 10, 2022 9:58 am Post subject:

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

Code:

{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:

Quote:

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:

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

which can be decoded.

mathdon
Expert

Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK

Posted: Thu Feb 10, 2022 1:27 pm Post subject:

Barf wrote:

BTW, the verbal description of 016D:

Quote:

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:

{...}<...>(...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:

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.
_________________
Graham

Barf
Expert

Joined: 24 Oct 2008
Posts: 1414
Location: Munich, Germany

Posted: Fri Feb 11, 2022 2:40 pm Post subject:

Code:

{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
Expert

Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK

Posted: Sat Feb 12, 2022 9:20 am Post subject:

@Barf Thanks, I have made the change. _________________ Graham

Barf
Expert

Joined: 24 Oct 2008
Posts: 1414
Location: Munich, Germany

Posted: Thu Feb 17, 2022 9:21 am Post subject:

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

mathdon
Expert

Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK

Posted: Thu Feb 17, 2022 2:22 pm Post subject:

Barf wrote:

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.
_________________
Graham

Barf
Expert

Joined: 24 Oct 2008
Posts: 1414
Location: Munich, Germany

Posted: Thu Feb 17, 2022 2:26 pm Post subject:

mathdon
Expert

Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK

Posted: Fri Feb 18, 2022 8:11 am Post subject:

mathdon wrote:

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.
_________________
Graham

3FG
Expert

Joined: 19 May 2009
Posts: 3367

Posted: Sat May 06, 2023 1:10 pm Post subject:

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

Code:

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:

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:

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

BTW, the learned signals in http://hifi-remote.com/forums/viewtopic.php?p=146714#146714 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.

Display posts from previous:

	JP1 Remotes Forum Index -> JP1 - Protocol Decodes	All times are GMT - 5 Hours Goto page Previous 1, 2
Page 2 of 2

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum