|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
seanyoung Guest
|
Posted: Tue Mar 10, 2020 2:40 am Post subject: Help writing IRP for iMON SoundGraph PAD Remote |
|
|
Hi,
I'm trying to learn IRP, and as an exercise I thought I would write the IRP for the iMON PAD remote. The protocol is slightly bizarre:
- start by single pulse
- bit is encoded by single pulse or space
- between each bit there is a pulse or space (call that chk)
for some positions chk is always space
for other positions chk is space iff bit before and after are 0, else pulse.
I wrote an handwritten encoder/decoder: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/rc/ir-imon-decoder.c
So after some reading and parsing I wrote:
Code: |
{38k, 416, msb}<-1|1>(1, C:30:29, F:30:29, 0, F:29:28, 0, F:28:27, 0, F:27:26, 0, F:26:25, C:25:24, F:25:24, C:24:23, F:24:23, 0, F:23:22, C:22:21, F:22:21, C:21:20, F:21:20, C:20:19, F:20:19, C:19:18, F:19:18, C:18:17, F:18:17, C:17:16, F:17:16, C:16:15, F:16:15, 0, F:15:14, C:14:13, F:14:13, C:13:12, F:13:12, C:12:11, F:12:11, C:11:10, F:11:10, C:10:9, F:10:9, C:9:8, F:9:8, 0, F:8:7, 0, F:7:6, 0, F:6:5, 0, F:5:4, 0, F:4:3, 0, F:3:2, 0, F:2:1, 0, F:1:0) {C=F|(F/2)}
|
However, if I add that to the src/main/resources/IrpProtocols.xml in IrpTransmogifier, and then execute:
Code: |
$ ./irptransmogrifier.sh render --raw -n "F=1" iMON
Exception in thread "main" org.harctoolbox.ircore.ThisCannotHappenException
at org.harctoolbox.irp.EvaluatedIrStream.mkIrSequence(EvaluatedIrStream.java:50)
at org.harctoolbox.irp.EvaluatedIrStream.toIrSequence(EvaluatedIrStream.java:92)
at org.harctoolbox.irp.RenderData.toIrSequence(RenderData.java:40)
at org.harctoolbox.irp.Protocol.toIrSequence(Protocol.java:352)
at org.harctoolbox.irp.Protocol.toIrSignal(Protocol.java:289)
at org.harctoolbox.irp.NamedProtocol.render(NamedProtocol.java:306)
at org.harctoolbox.cmdline.CommandRender$Renderer.render(CommandRender.java:148)
at org.harctoolbox.cmdline.CommandRender$Renderer.render(CommandRender.java:132)
at org.harctoolbox.cmdline.CommandRender$Renderer.access$1(CommandRender.java:118)
at org.harctoolbox.cmdline.CommandRender.render(CommandRender.java:103)
at org.harctoolbox.irp.IrpTransmogrifier.run(IrpTransmogrifier.java:196)
at org.harctoolbox.irp.IrpTransmogrifier.main(IrpTransmogrifier.java:89)
at org.harctoolbox.irp.IrpTransmogrifier.main(IrpTransmogrifier.java:95)
|
So I decided to simply.
Code: |
<irp:protocol name="iMON">
<irp:irp><![CDATA[{38k,416,msb}<-1|1>(1,1) [F:0..31]]]></irp:irp>
<irp:documentation>Used by the iMON SoundGraph remote, which was later rebranded to Antec Veris</irp:documentation>
</irp:protocol>
|
Still broken (ThisCannotHappenException).
Is my IRP plain wrong or should I post the IrpTransmogrifier github issues page? |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1418 Location: Munich, Germany |
Posted: Tue Mar 10, 2020 5:10 am Post subject: |
|
|
Hi Sean, nice to see you here.
The fundamental problem is that implicitly all IrSequences are assumed to end with a space (or "gap" as it is called in the IRP, "leadout"). If you add such a leadout, you will see that it renders:
Code: |
$ target/irptransmogrifier.sh --irp "{38k,416,msb}<-1|1>(1,1,-100m) [F:0..31]" render -r -n F=31
Freq=38000Hz[+832,-100000][][]
|
Having said that, I agree that this requirement is not well (or not at all ) documented, and that the error message is all but helpful.
Lirc/Linux ends the IR sequences without an ending space (there is a GAP parameter in lircd.conf though), here we consider the lead-out as a part of the signal, as does Pronto, GlobalCache etc. The Arduino IRremote library does it the Lirc/Linux way. Sigh...
More remarks:
* Just a number in the IRP denotes a duration, a number to be encoded ("BitField") must be given with colons. In particular, "0" is meaningless: it means send a flash ("mark", "pulse") of zero length.
* Probably you mean C:1:29 instead of C:30:29. |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1418 Location: Munich, Germany |
Posted: Tue Mar 10, 2020 10:02 am Post subject: |
|
|
Yes, that is a bizarre protocol. Here is my attempt (not tested):
Code: |
{38k,416,msb}<-2,(p=0) | 1,-1,(p=1) | -1,1,(p=0) | 2,(p=1)>
(
1,
<(2*p):2|3:2>(F:1:30),
<0:2|1:2>(F:4:26),
<(2*p):2|3:2>(F:2:24),
<0:2|1:2>(F:1:23),
<(2*p):2|3:2>(F:7:16),
<0:2|1:2>(F:1:15),
<(2*p):2|3:2>(F:6:9),
<0:2|1:2>(F:9),
-10m
)
{p=0}
[F:0..0x7FFFFFFF]
|
(The parentheses are necessary for correct parsing.)
While goes through the parameter, the current bit is saved in the variable p ("previous"). The inner bitspec translates the current bit and the p into a number current + 2*chk, and the outer then makes durantions of that, as per your description.
BTW, in your C code, it appears that you are processing 31 bits in the for statement, still you say "30 bits". |
|
Back to top |
|
|
seanyoung Guest
|
Posted: Tue Mar 10, 2020 3:40 pm Post subject: |
|
|
Barf thank you very much, all your hints really help.
The irp looks really good, it needs some minor tweaks to make it correct, but I really like the idea. Much shorter and clearer than what I wrote. I'll spend some time fixing it up and testing it.
Quote: | BTW, in your C code, it appears that you are processing 31 bits in the for statement, still you say "30 bits". |
Yes, thanks for that, that's not right. Actually bit 31 should always be zero (checked elsewhere) but it shouldn't be referenced. |
|
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
|