|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 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 |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 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. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 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 |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 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. |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 Location: Cambridge, UK |
Posted: Sat Feb 12, 2022 9:20 am Post subject: |
|
|
@Barf
Thanks, I have made the change. _________________ Graham |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 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? |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 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 |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1417 Location: Munich, Germany |
Posted: Thu Feb 17, 2022 2:26 pm Post subject: |
|
|
|
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4524 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 |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3368
|
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. |
|
Back to top |
|
|
|
|
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
|
Powered by phpBB © 2001, 2005 phpBB Group
|