JP1 Remotes

If you downloaded the file already, re-download it as I just fixed something.

I did some testing this evening and fixed a few bugs and now it appears to be working, in both S3C8 and HCS08 remotes.

http://www.hifi-remote.com/forums/dload ... le_id=8467

Alright, I think we got it.

Here's the RM file I created. It appears to be device 2 for all 256 commands.

When I used IR8.03s new Pronto import of the learned signal and compared the new protocol generated signal, they match up almost exactly. IRScope is sweet!

Thanks Rob for your help on the executor.

you can grade my work in the RM file if you wish...

Should we name this protocol and add it to decodeIR? I just check the IRF files for other elan devices and it is the same format just different device numbers. They seem to pack in 256 codes for each of their products.

I'm OK with calling it Elan, if Graham wants to add it to DecodeIR.

In another thread

The Robman wrote:The automated analysis tool may prove to be useful, but when we're dealing with an undocumented protocol I tend not to trust tools, I like to decode them by hand. For example, the tool interpreted the Elan v883 protocol that we saw recently as a base-4 signal, when in fact it's a binary signal with a mid-frame burst. Looking at just one signal at a time, base-4 was a reasonable guess, but looking at all of the signals together, the mid-frame burst was the obvious choice.

Don't be too disparaging about automated tools, Rob. If you take the first of jetskier's initial Pronto examples and set the data format for IRP output to base-4, the natural choice since the analysis identifies it as a base-4 protocol, you get:

{40.2k,398,msb}<1,-1|1,-2|2,-1|2,-2>(3,-2,A:66,1,-14.0m)+{A=0q000000101111110130000000111111110}; Alt leadout form: ^50m

A quick glance shows that there are 16 zeroes and ones on either side of the middle 3, a format which holds also in the other initial examples. So of the four base-4 digits, digit 3 is serving as a mid-frame break in data otherwise composed of 0's and 1's. The IRP can therefore be rewritten as:

{40.2k,398,msb}<1,-1|1,-2>(3,-2,A:16,2,-2,B:16,1,-14.0m)+{A=0b0000001011111101,B=0b0000000111111110}; Alt leadout form: ^50m.

If you take this together with jetskier's remark that it looks something like NEC2, you get the entire protocol as

{40.2k,398,msb}<1,-1|1,-2>(3,-2,D:8,~D:8,2,-2,F:8,~F:8,1,-14.0m)+

which is, I think, what you found it to be. You can also read off the values of D and F. In the above case they are D=2, F=1. The lead-out could be ^50m instead of -14.0m, but that is immaterial since the complements mean that changing D or F does not change the frame length. It also need not be msb, but it seems to be so in this case.
______________
Graham

I hear ya Graham, and I bet the tool will be great for un-documented protocols that are true binary and don't have any twists and twurls, but I guess I'm old fashioned enough that I will always want to decode a new protocol by hand the first time, just to be sure.

So, what do you think, do you want to add the Elan protocol is DecodeIR?

The Robman wrote:I hear ya Graham, and I bet the tool will be great for un-documented protocols that are true binary and don't have any twists and twurls, but I guess I'm old fashioned enough that I will always want to decode a new protocol by hand the first time, just to be sure.

Everyone to their own taste, I suppose, but my taste would be to make use of this new tool - it is a tool, a step towards a solution, not necessarily the solution itself - and then to verify it against the raw data if you are doubtful. I can only make tools, I can't force anyone to use use them. BTW I was surprised to see, in another thread, that you are now using IRScope. That was something I never expected to see!

So, what do you think, do you want to add the Elan protocol to DecodeIR?

Yes, I'll do that for a later version. I will also put the protocol IRP, as I have given it above, in DecodeIR.html.
________________
Graham

I never needed IRScope as I didn't have a widget and I do have learning remotes, but as more people get widgets and start posting ICT files that need decoding, I have to use it to read their files. Plus, as I now have a widget I can use it to capture signals too.

As for the analysis tool, I imagine that it will be useful in getting non-expert folks involved in that if it gets the protocol right, they might be able to use the info to set up a new executor in PB without my help. But typically, when people ask for my help with a protocol there's usually a twist of some sort that needs an expert to sort out.

Keep in mind also that decoding signals is very easy for me, at least it has been since the rounding feature was added to IR, so I wasn't asking for a tool.

There are plenty of other things here where we could use tools, so if you want to create tools that you know will get used, ask me and I'll write something up.