JP1 Remotes

Posted: **Fri Jun 11, 2004 3:04 pm**

BTW, here is the original message from Dan about learning problems. When I looked at his original learns they looked like Mark's. He describes his technique in the message for finally getting it to learn.

Posted: **Fri Jun 11, 2004 4:42 pm**

jon_armstrong wrote:the original message from Dan

Thanks for finding what I couldn't.

He describes his technique in the message for finally getting it to learn.

I just tried Dan's method for learning from the OEM remote, and 2 quick button presses did the trick. All 6 commands decoded as Kaseikyo-170.90, Dev=12, Sub=16, E=1.

I assume that long gap Jon mentioned is confusing to both DecodeIR and IR's built-in decoding logic. Since all we ever really hear about learning is to either press and hold, or do a quick press, I never would have thought about doing the double quick press on my own.

Thanks for all the help!

Posted: **Fri Jun 11, 2004 6:25 pm**

Mark Pierson wrote:I assume that long gap Jon mentioned is confusing to both DecodeIR and IR's built-in decoding logic.

Actually, I think it's confusing the remote itself as the learned signals don't work.

Posted: **Fri Jun 11, 2004 6:33 pm**

The original signals have too long a gap (between frames), so the remote can't learn the correct repeat pattern (two quick taps shortens that gap). I don't understand why the remote didn't learn the frame as a one-time signal. That would have worked (to replay the learned signal) and I assume it would decode correctly.

The initial JP1 to JP1 learned signals had the wrong lead-out, which would confuse DecodeIR as Jon said.

I still don't fully understand the causes for what worked and what didn't.

Posted: **Sat Jun 12, 2004 9:15 am**

John and Rob, Mark is still having problems with the shorter gap between frames being interpreted as multiple commands using the Kasiekyo protocol (the generic version below):

Upgrade Protocol 0 = 01 C9 (S3C8+) Kaseikyo (KM v8.22)
46 90 51 8B 12 87 45 08 08 00 D7 00 B5 00 D7 02
6A 88 B8 06 AA 03 41 08 08 E4 07 08 09 07 F0 C0
B4 07 C0 56 C0 0F B4 C0 08 8D 01 46
End

and needs to know which byte(s) to change to get a gap of ~127 mS.

Mark, failing that working, if you add a command with hex AB 7D to the original KM Master device upgrade with two variable bytes that (7D) is the correct calcualtion of the checkbyte.

Posted: **Sat Jun 12, 2004 9:23 am**

jon_armstrong wrote:Upgrade Protocol 0 = 01 C9 (S3C8+) Kaseikyo (KM v8.22)
46 90 51 8B 12 87 45 08 08 00 D7 00 B5 00 D7 02
6A 88 B8 06 AA 03 41 08 08 E4 07 08 09 07 F0 C0
B4 07 C0 56 C0 0F B4 C0 08 8D 01 46
End

F8 0C should give a leadout off time of about 127 mS.

Posted: **Sat Jun 12, 2004 9:35 am**

Rather than look up all the details, I trusted PB and pasted the original into PB's decode block and decoded, then changed the lead-out duration and looked for the first things that changed in the generated code (of course the generated code is missing all the interesting features of this protocol, but PB still decodes and computes the basic header fields right).

That gave me the answer, so I came back here to discover Mike already posted the answer. But maybe this tells Jon how to tweak header fields in future cases.

Posted: **Sat Jun 12, 2004 9:39 am**

I did exactly what John said, except I used the Disassembly feature of PB to identify which bytes were the ones to change.

Posted: **Sat Jun 12, 2004 10:15 am**

Amazing, I just tried it. I had thought that feature had been "disabled." Thanks!

Posted: **Sat Jun 12, 2004 10:31 am**

mr_d_p_gumby wrote:F8 0C should give a leadout off time of about 127 mS.

I tried the F8 0C but saw no noticeable difference. It still sends mulitple commands with normal presses.

Posted: **Sat Jun 12, 2004 10:51 am**

Then try setting it to no repeat:

Upgrade Protocol 0 = 01 C9 (S3C8+) Kaseikyo (KM v8.22)
46 90 51 8B 12 87 45 08 08 00 D7 00 B5 00 D7 02
6A 88 B8 06 AA 03 41 08 08 E4 07 08 09 07 F0 C0
B4 07 C0 56 C0 0F B4 C0 08 8D 01 46
End

Change to 44

BTW, did the old upgrade not do the 'repeat'?

Posted: **Sat Jun 12, 2004 12:55 pm**

There's a .CML file at R/C that has a Sharp Comfort Touch air conditioner listed. The EFCs seem to match, and most timings seem consistent with the protocol we're using, but the leadout off time is shorter. It's 70 mS in the KM protocol (with 88 B8 values), but the .CML file shows it at 32.5 mS.

Code: Select all

Power On/Off		(Kaseikyo-170.90):12.16:26 EFC=247 {E=1}
[38001];3346-1700 401-401 401-1278 401-401 401-1278 401-401 401-1278 401-401 401-1278 401-401 401-1278 401-401 401-1278 401-1278 401-401 401-1278 401-401 401-1278 401-1278 401-1278 401-1278 401-401 401-401 401-1278 401-1278 401-401 401-401 401-401 401-401 401-1278 401-401 401-401 401-401 401-401 401-1278 401-401 401-1278 401-1278 401-401 401-401 401-401 401-1278 401-401 401-401 401-401 401-1278 401-1278 401-1278
401-401 401-32540

Think there's any chance that a shorter leadout time would work?

Posted: **Sat Jun 12, 2004 1:12 pm**

Oops, forgot to give the values to try!

32.5 mS would be 3F 7A.

Posted: **Sat Jun 12, 2004 1:44 pm**

mr_d_p_gumby wrote: Think there's any chance that a shorter leadout time would work?

That's fairly common. The symptom of rapid repeating of a function can be caused by a lead out too short in some devices and the same symptom can be caused by lead out too long in other devices.

Posted: **Sat Jun 12, 2004 1:56 pm**

jon_armstrong wrote:Then try setting it to no repeat

That works, and I can probaly live with it. It's only the TEMP UP and DOWN commands that would really need to repeat, but a bunch of button presses isn't the end of the world.

BTW, did the old upgrade not do the 'repeat'?

The old upgrade repeated in a "normal" fashion. It didn't send rapid-fire signals the way the new upgrade does.

mr_d_p_gumby wrote:32.5 mS would be 3F 7A

No change with this. If anything, the rapid-fire might be just a tad faster, though it's hard to tell.

JP1 Remotes

Sharp air conditioner