JP1 Remotes

[johnsfine]

[gfb107]

[The Robman]

[johnsfine]

I slapped together a simple version of this protocol. I left out both the frequency option and the lead-out option.

I used a simple and direct approach to computing the check nibble and generating the signal. That results in MUCH less code than UEI's method.

Unfortunately, the simple method doesn't let me compensate for the slight timing difference between On and Off durations in the basic signal generation process. So the timing of this version is slightly off from the official. I'm nearly certain the actual device can't detect that slight variation. It could be done a little differently and compensate, I think about 6 bytes longer.

I tested this with CapturIr and it looked right (except for the slight timing difference) on the first try. Someone should test with an actual Russound or DirecTV device.

Anywhere here is the upgrade:

Upgrade protocol 0 = 01 62 (S3C80) DirecTV
40 84 11 8B 09 20 0B B8 02 4E 01 22 01 22 08 04
86 40 C0 28 CB 84 C1 C2 02 C2 06 CB 40 FB F1 90
CC 1C 12 F6 01 4C 38 03 48 04 5C 09 1C 14 90 C3
7B 02 1E 1E F6 01 4C 90 C3 FB 05 1C 16 F6 01 6D
76 C5 03 EB 04 38 C4 48 CC 5A E1 C6 F8 38 4A F6
01 58 C6 12 05 DC F6 01 0A 7B C6 AF
End

Commented source code is available.

[The Robman]

92 bytes, that's not too shabby (I'll take a look at the logic later to see what you're doing). I'm guessing that it uses the same fixed and variable data as the official version, so people can just overlay the official protocol to test it?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[johnsfine]

It ignores the three flag bits in fixed data, but otherwise uses the same.

[The Robman]

Oh yeah, I should point out that the version John posted is the 40 kHz version (which is what pasha needs), here are the other two...

1) 38.3 kHz - for DirecTV D10

Upgrade protocol 0 = 01 62 (S3C80) DirecTV
43 8A 11 8B 09 20 0B B8 02 4E 01 22 01 22 08 04
86 40 C0 28 CB 84 C1 C2 02 C2 06 CB 40 FB F1 90
CC 1C 12 F6 01 4C 38 03 48 04 5C 09 1C 14 90 C3
7B 02 1E 1E F6 01 4C 90 C3 FB 05 1C 16 F6 01 6D
76 C5 03 EB 04 38 C4 48 CC 5A E1 C6 F8 38 4A F6
01 58 C6 12 05 DC F6 01 0A 7B C6 AF
End

2) 56.7 kHz - Russound (the one in the CCF)

Upgrade protocol 0 = 01 62 (S3C80) DirecTV
2C 5D 11 8B 09 20 0B B8 02 4E 01 22 01 22 08 04
86 40 C0 28 CB 84 C1 C2 02 C2 06 CB 40 FB F1 90
CC 1C 12 F6 01 4C 38 03 48 04 5C 09 1C 14 90 C3
7B 02 1E 1E F6 01 4C 90 C3 FB 05 1C 16 F6 01 6D
76 C5 03 EB 04 38 C4 48 CC 5A E1 C6 F8 38 4A F6
01 58 C6 12 05 DC F6 01 0A 7B C6 AF
End

(I didn't check to see what lead-out times each device needs)
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[The Robman]

I was thinking today about how best to support the different carrier frequencies, and one way could be to use the first 2 fixed bytes for this data.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[johnsfine]

[The Robman]

Hey John, how does this command shift the date from RC0 into RC1?

[johnsfine]

[The Robman]

I've been giving some thought to what the best way to support this executor might be and I have come up with a proposal.

In my opinion we are dealing with three seperate protocols here, granted they all have the same format, but they have different carrier frequencies. They're only joined together in one exec because UEI chose to implement them that way.

So, I suggest that we have three seperate entries in protocols.ini for them, which all use the same $0162 p-id. If the remote doesn't have $0162 pre-installed, we can offer John's scalled down version of the code (once somebody verifies that it works). It might also be a good idea to have an entry for the official version, just so that we can do experiments with it.

I suggest calling the 38khz version "DirecTV". The other two freqs both seem to be used by Russound, so I suggest "Russound 40khz" and "Russound 57khz" as their names.

Thoughts?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[johnsfine]

I disagree:

1) I want to make the protocol name in DecodeIr agree with the protocol name in RM.

2) I prefer to avoid having DecodeIr base a protocol name choice on frequency, since frequency is the least reliably available aspect of the signal in various IR capture environments. Sometimes there is no good choice other than basing the protocol name on frequency. But this time I think a single name for all these is better.

3) We have two choices of lead-out and three choices of frequency. The UEI executor supports all six combinations. I don't know how many of those six are in the real world. Do you? I REALLY don't want to base protocol name in DecodeIr on lead-out duration.

I guess DecodeIr should display the lead-out time, when available, in the misc section of the decode.

The documentation for this protocol in DecodeIr should tell the user to pay attention to frequency and lead-out. The help text for this protocol in protocols.ini should as well. I know it's more than some users will actually do, but the whole design of DecodeIr assumes the user should do the agregation of unreliable data (such as frequency) across all the learns from a single original result, to produce an answer more reliable than DecodeIr could get from one learn.

In RM, I don't have a strong opinion on:

A) Do we want an open edit field for frequency and lead-out to let the user put in whatever he wants, or do we want pull downs that offer just the choices we think match actual original remotes.

B) If we have an open edit field for frequency, do we want to make that a generic advanced freature of RM available whenever a protocol upgrade will (can) be provided, and/or do we want to specify it as a standard setup field for specific protocols such as this one.

I still haven't reviewed RM's translator capabilities to determing for either a pull down or an open edit field, whether we can compute and store the lead-out value with translators that exist now or whether we need a little new JAVA code.

If we pick an open edit field for frequency, I think it will be useful enough in other protocols that it should be new Java code, just to make things simpler for people writing protocols.ini entries, even if the existing translators could do it.

[The Robman]

I anticipated that you would disagree, but I was curious as to what grounds you would pick. You'll notice that I did suggest that in addition to the three variations that I specified, I also suggested that we also support the official version, so that people can (if needed) pick a combination that isn't already covered.

Given the difficulty that so many people have understanding how to use JP1 to program their remotes, I anticipate us having to give ALOT of support for this protocol if you chose to impliment it the way you suggest.

In my personal opinion, asking people to not only keep an eye on the frequency but also the lead out time is crazy, you're just asking for trouble. Again, in my personal opinion, that's DecodeIR's job.

I do agree that the names used by DecodeIR should match those used in RM, but the names are changeable in both right? Currently, when I learn the DirectTV signals, DecodeIR reports the protocol as Russound, so there's already a mis-match.

So, bottom line, please spell out the downsides to going with my suggestions?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[johnsfine]