Help writing IRP for iMON SoundGraph PAD Remote

[seanyoung]

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/ke ... -decoder.c

So after some reading and parsing I wrote:

Code: Select all

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

$ ./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: Select all

    <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?

[Barf]

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: Select all

$ 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.

[Barf]

Yes, that is a bizarre protocol. Here is my attempt (not tested):

Code: Select all

  {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".

[seanyoung]

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.

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.