JP1 Remotes

jon_armstrong · Posted: Fri Jun 11, 2004 4:04 pm Post subject:

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.
_________________
-Jon

Mark Pierson · Posted: Fri Jun 11, 2004 5:42 pm Post subject:

The Robman · Posted: Fri Jun 11, 2004 7:25 pm Post subject:

johnsfine · Posted: Fri Jun 11, 2004 7:33 pm Post subject:

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.

jon_armstrong · Posted: Sat Jun 12, 2004 10:15 am Post subject:

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.
_________________
-Jon

mr_d_p_gumby · Posted: Sat Jun 12, 2004 10:23 am Post subject:

johnsfine · Posted: Sat Jun 12, 2004 10:35 am Post subject:

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.

mr_d_p_gumby · Posted: Sat Jun 12, 2004 10:39 am Post subject:

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

JP1 Group at Yahoo!, JP1 Files Area

jon_armstrong · Posted: Sat Jun 12, 2004 11:15 am Post subject:

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

Mark Pierson · Posted: Sat Jun 12, 2004 11:31 am Post subject:

jon_armstrong · Posted: Sat Jun 12, 2004 11:51 am Post subject:

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'?
_________________
-Jon

mr_d_p_gumby · Posted: Sat Jun 12, 2004 1:55 pm Post subject:

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.

mr_d_p_gumby · Posted: Sat Jun 12, 2004 2:12 pm Post subject:

Oops, forgot to give the values to try! Embarassed

32.5 mS would be 3F 7A.
_________________
Mike England

JP1 Group at Yahoo!, JP1 Files Area

johnsfine · Posted: Sat Jun 12, 2004 2:44 pm Post subject:

Mark Pierson · Posted: Sat Jun 12, 2004 2:56 pm Post subject: