JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Help writing IRP for iMON SoundGraph PAD Remote

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Protocol Decodes
View previous topic :: View next topic  
Author Message
seanyoung
Guest





PostPosted: Tue Mar 10, 2020 2:40 am    Post subject: Help writing IRP for iMON SoundGraph PAD Remote Reply with quote

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

PostPosted: Tue Mar 10, 2020 5:10 am    Post subject: Reply with quote

Hi Sean, nice to see you here. Very Happy

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 Wink ) 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... Crying or Very sad

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
View user's profile Send private message Send e-mail Visit poster's website
Barf
Expert


Joined: 24 Oct 2008
Posts: 1084

PostPosted: Tue Mar 10, 2020 10:02 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
seanyoung
Guest





PostPosted: Tue Mar 10, 2020 3:40 pm    Post subject: Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Protocol Decodes All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
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
Get Smart! the band's official homepage Rockabilly Central