JP1 Remotes

[alanrichey]

Running this through IRScope the protocol is decoding as:

??Kaseikyo-84.87

Does this map to a standard protocol in RM ? or do we need to do a full learn and build a new protocol ?

I've done a sample of 4 buttons at http://www.hifi-remote.com/forums/dload.php?action=file&file_id=11582

[The Robman]

In the end you will need to learn all the buttons anyway, so could you make an ICT file that includes all of them now? The thing is, it's the same amount of work for us to decode 4 buttons as it is to decode 24, but to do 4 now and 20 later is twice the work.
_________________
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 decided to take a look anyway and this was was tough because 2 of the buttons wouldn't export and none of them would import into IR.exe, so I had to decode them all by hand.

Anyway, these look like standard Kaseikyo signals, except for the fact that the checksums aren't in the right place. I haven't tried to figure out the checksums yet, but that shouldn't be needed to get these into the $00F8 executor, but we would need a new protocols.ini entry that doesn't do any checksum calculations for you and instead lets you supply the 2 variable bytes of data.

Here's what I got from the 4 learns presented...

[vickyg2003]

Is this post related to the last time we did the Kaseiko with a seed?
http://www.hifi-remote.com/forums/viewtopic.php?p=104056#104056
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

[3FG]

Here's the IRP for ??Kaseikyo: {37k,432}<1,-1,1,-3>(8,-4,M:8,N:8,X:4,D:4,S:8,G:8,F:8,1,-173)+

IRScope displays M, N, D, S, F, and G, so it already gives us a complete decode (X is always determined by XORs of the nibbles of M and N). I agree with Rob that this protocol will require a different entry in protocols.ini, but no decoding is necessary.

I think we should change the existing Kaseikyo entry in protocols.ini so that it doesn't attempt to calculate the check sum, since it varies among implementations of Kaseikyo. We do need to verify the operation of the variants of the F8, 1F, C9, and CD executors, so that RM can select a suitable executor (if available) depending on the individual remote.

[alanrichey]

Actually the OBC codes were giving discrete, logical values. That was why I thought we might get away with just 4 to figure out the protocol and I could then use the OBCs.

Right or wrong ?

[3FG]

I don't understand. How do you get the OBCs? From capturing, right?

Anyway, both the OBC values and the "G" value that IRScope returns in the Misc field will be needed to make an upgrade. Also, we need an revised entry in protocols.ini. I should be able to do that tonight.

[The Robman]

[alanrichey]

The 'G' value varies with each button. So I assume that you still need a full ICT file ?

[alanrichey]

OK, I'll get on it.

[3FG]

Here's the protocols.ini entry that will generate these signals. Your captures seem to show a lead out time of 50mS. The 00F8:3 executor can send 4 different lead outs, and it looks like you have a choice of 44 or 70mS. I suspect either one will be fine.

[alanrichey]

Thanks, I've added it to my Protocols.ini. But now I am even more confused This looks as though I can now build the BIN files myself without having to post a full ICT file ?

And having put it in to the Protocols.ini I see that were already 3 entries for [Kaseikyo] although only one option shows up in RM.

Why the duplication ? Have I done it or does the standard Protocol.ini have 3 in as well. If so, why ?

Al

[3FG]

Al,
You haven't made a mistake.

Blame history for the confusion, both from the JP1 community and from UEI. UEI has built numerous variants of the 00F8 executor, and we have chosen to categorize these as variant 1, 2 or 3. All of the variants use the same 5 byte fixed data organization, and most of them can select among 4 leadout times, but a subset of variant 1 can only send 20mS or 72mS, and some variant 2 remotes can only send 20, 43 or 75mS. The good news for most of us is that any remote made in the last 7 or 8 years is variant 3, and these all act the same way.

Protocols.ini thus needs three different entries for 00F8; one entry per variant. RMIR will only display one instance of these executors, and selects the entry based on the variant specified for the target remote in its RDF file.

Next piece of history: In the beginning, there was Panasonic. Over time, it was realized that Panasonic is just one example of the Kaseikyo class of protocols: Fujitsu, SharpDVD, Denon-K, Mitsubishi-K, Teak-K, and JVC-48. However, we tried to describe a generic Kaseikyo protocol before all of these protocols were known, and also tried to describe it with just 8 bits of variable data, while actually valid Kaseikyo allows 16 bits of variable data.
So the Kaseikyo entry in protocols.ini is only suitable to describe a subset of Kaseikyo class protocols. Similarly, DecodeIR shows Kaseikyo if the protocol fits a narrow definition or ??Kaseikyo if it fits the more general structure.

The Kaseikyo-G entry posted above has two bytes of variable data, so it is usable with ??Kaseikyo. In fact, it could be used to make an upgrade for any of the Kaseikyo class protocols, if one wants to go to the trouble of re-arranging the device, subdevice, etc numbers.

For this particular case, we don't need the full ICT file, because ??Kaseikyo is a robust decode, in spite of the name.

[alanrichey]

Amazing stuff. incredible you actually figured it out

[alanrichey]

Good news with a slight caveat The user reports it works well so the protocol is fine and the codes are all correct. Unfortunately he is getting the 'double-skipping' with the Channel and Number buttons. Can you tell me which byte(s) need changing in the S3C80 setting to set the repeat to zero ? I can then add a [Kaseikyo-G (no repeat)] prototcol to my special collection in the Slingbox file area.

Code.S3C80=45 91 52 8B 18 8F 45 08 08 00 DA 00 C6 00 DA 02 7D 27 70 06 D1 03 40 40 F8 92 68 55 26 20 01 08 03 37 03 0B 37 00 13 56 28 F7 C4 22 1C 8B 0B 37 00 05 C4 26 1C 8B 03 C4 24 1C 8D 01 46

Cheers

Al