Help with converting CCF to JP1 (Electrohome protocol)

[jon_armstrong]

OK, I think I see the problem but we also need some help. If you hold a button down, the start frame just keeps getting repeated. The other frames are produced only after a botton release.

This is the IR protocol in irp format:

{42.3k.or 336k,msb}<-376,+376|376,-376>((1:1,31:6,376,^46046)2,(1:1,F:6,376,^46046)+,(1:1,31:6,376,^46046)2)

All frames are the same. The first is the "start frame" repeated twice, the second the data frame should repeat as long as the button is held. The final frame is the same as the first and sent twice at button release. It is in the spec here

There are two versions of the Protocol, one at 42.3KHz and the other at 336 KHz that are otherwise the same.

Here is John Fine's original protocol disassembled with Mike's disassembler in PB:

Code: Select all

Addr	Code	Label	Op	Op Args	Comments
FF00	37 82		DB	37H,82H	;42.3 kHz 30%
FF02	01		DB	01H	;0 dev, 1 cmd
FF03	8B 13		JR	LFF18	
FF05	C4		DB	C4H	;pf0: 11000100=1-cmd,dev-cmd,OffAsTotal
FF06	85		DB	85H	;pf1: 10000101=RptHeld,LI-same,-LO
FF07	10		DB	10H	;pf2: 00010000=0-rev
FF08	08		DB	08H	;pd00: DevBits1=8
FF09	07		DB	07H	;pd01: CmdBits1=7
FF0A	00 BC		DW	00BCH	;pd02/03: 1-burst on=376 uS
FF0C	00 A8		DW	00A8H	;pd04/05: 1-burst off=376 uS
FF0E	00 BC		DW	00BCH	;pd06/07: 0-burst on=376 uS
FF10	00 A8		DW	00A8H	;pd08/09: 0-burst off=376 uS
FF12	59 EF		DW	59EFH	;pd0A/0B: Leadout off=46046 uS
FF14	00 BC		DW	00BCH	;pd0C/0D: Leadin on=376 uS
FF16	03 98		DW	0398H	;pd0E/0F: Leadin off=1880 uS
FF18	58 03	LFF18:	LD	W5,DCBUF	
FF1A	E6 03 BE		LD	DCBUF,#BEH	
FF1D	F6 01 46		CALL	0146H	
FF20	F6 01 46		CALL	0146H	
FF23	59 03		LD	DCBUF,W5	
FF25	56 C5 03		AND	RC5,#03H	
FF28	EB 02		JRNE	LFF2C	
FF2A	5C 0B		LD	W5,#0BH	
FF2C	DF	LFF2C:	SCF		
FF2D	C0 03		RRC	DCBUF	
FF2F	02 55		ADD	W5,W5	
FF31	F6 01 46	LFF31:	CALL	0146H	
FF34	5A FB		DJNZ	W5,LFF31	
FF36	E6 03 BE		LD	DCBUF,#BEH
FF39	F6 01 46		CALL	0146H
FF3C	8D 01 46		JP	0146H

When I initially tested this I used the Tap method since I wanted to see all the different frames using Tommy's original IRAnalyzer. The start bit was being repeated 6 times. Other than that all seemed to work well. I removed:

Code: Select all

FF20	F6 01 46		CALL	0146H

since I thought it was getting three minimum repeats from each pass at the protocol engine and after I did that, it started reliably doing two repeats and Vynce started testing.

To make long story short it was inreliable and it looks like the protocol just repeats the start frame as long as you hold the button down. So my guess is the protocol engine doesn't release it to execute the next steps until the key is released. I think Vynce was getting a little better recognition out of the Taps.

Also, if it will simplify matters, there is a Pronto ccf file that was generated by Guy Kuo and Barry Gordon five years ago, and they simplified the protocol to {42.3k.or 336k,msb}<-376,+376|376,-376>((1:1,31:6,376,^46046)2,(1:1,F:6,376,^46046)+)

John created a protocol that sought to create the exact signal since you can do that with an OFA remote but not a Pronto. Certain commands need 2 minimum repeats of the data frame, most 4 repeats and four commands require 22 repeats. John did that using the bottom bit of OBC as a trigger (0 repeats 22 time and 1 four). However, everyone reported that the Pronto version works well, so that may not be necessary and may simplify fixing the problem.

[jon_armstrong]

let's try these they should be closer:
Low Frequency
Upgrade protocol 0 = 01 E1 (S3C8)
37 82 01 8B 13 C4 84 10 08 07 00 BC 00 A8 00 BC
00 A8 59 EF 00 BC 03 98 58 03 E6 03 BE F6 01 46
F6 01 46 59 03 56 C5 03 EB 02 5C 0B DF C0 03 02
55 F6 01 46 5A FB E6 03 BE F6 01 46 8D 01 46
End

High Frequency
Upgrade protocol 0 = 01 E2 (S3C8)
0A 0A 01 8B 13 C4 84 10 08 07 00 BC 00 A8 00 BC
00 A8 59 EF 00 BC 03 98 58 03 E6 03 BE F6 01 46
F6 01 46 59 03 56 C5 03 EB 02 5C 0B DF C0 03 02
55 F6 01 46 5A FB E6 03 BE F6 01 46 8D 01 46
End

[Vynce]

Those work about the same as the previous ones, maybe slightly less reliably. They both work. The high frequency one works better. It still takes several presses for commands to be recognised.

I might try to use Digitrace to capture some output from the wired remote sometime in the next few days.

[jon_armstrong]

From my testing, those commands send out exactly two start frames, two data frames and two stop frames. Those should be better for L/R/U/D commands, but then I don't have the gear

[jon_armstrong]

OK, try these the second segment appears to now repeat as long as the button is held:

Low Freq

Upgrade protocol 0 = 01 E1 (S3C8+) PB v3.10
37 82 01 8B 13 C4 84 10 08 07 00 BC 00 A8 00 BC
00 A8 59 EF 00 BC 03 98 58 03 E6 03 BE F6 01 46
F6 01 46 E6 29 85 59 03 56 C5 03 EB 02 5C 0B DF
C0 03 02 55 F6 01 46 5A FB E6 03 BE E6 29 84 F6
01 46 8D 01 46
End

High Freq

Upgrade protocol 0 = 01 E2 (S3C8)
0A 0A 01 8B 13 C4 84 10 08 07 00 BC 00 A8 00 BC
00 A8 59 EF 00 BC 03 98 58 03 E6 03 BE F6 01 46
F6 01 46 E6 29 85 59 03 56 C5 03 EB 02 5C 0B DF
C0 03 02 55 F6 01 46 5A FB E6 03 BE E6 29 84 F6
01 46 8D 01 46
End

[Vynce]

Power toggle seems to work perfectly - worked on the first try both times I tried it. Brightness and contrast still require several presses or holding the button down. Arrows don't work at all.

I tried to use Digitrace to grab the output from the wired remote by connecting it to my parallel port. So far I have been unable to get it to work. Digitrace and the parallel port work fine - grounding a data pin causes Digitrace to record. Perhaps the output has a DC offset, so that the lows are too high for parallel port to detect as low.

[jon_armstrong]

The butons now should work correctly. There are exactly two start frames the center data frame repeats as long as you depress the button (sends a minimum of 2) and then two stop frames. Did you try both high and low frequency?

Are you using any sort of IR distribution system? (are you pointing the remote directly at the IR receiver?)

[jon_armstrong]

You might also try tweaking minimum repeat. If you take the "true" OBC values and:
1. Multiply by four you get 22 minimum repeats,
2. Multiply by four and add three you get six minimum repeats,
3. Multiply by four and add one you get two minmum repeats.

True OBC values (you must do 1, 2, or 3 above and then enter into KM Master) for example Power would be 28 for 22 repeats, 29 for two repeats and 31 for 6 repeats:

0 #
2 EXIT
3 HELP
4 SIZE
5 4
7 POWER
8 FAST/SLOW Sync
9 SOURCE
12 KEY
13 7
16 TINT
19 2
20 H Hold
21 6
23 VOL
24 *
25 CONT
26 Up
28 FOCUS
29 9
30 Down
32 DETAIL
33 Power On
34 Power Off
35 3
36 V Hold
37 5
38 Right
39 MUTE
40 PIN
41 BRITE
42 Mute On
43 Mute Off
44 VBLANK
45 8
46 Standby On
47 Standby Off
48 0
50 CONVERGE
51 1
52 BOW
53 STANDBY
54 Left
55 RESET
56 PROJ
57 COLOR
60 MOVE
61 RECALL

[The Robman]

You might also try tweaking minimum repeat. If you take the "true" OBC values and:
1. Multiply by four you get 22 minimum repeats,
2. Multiply by four and add three you get six minimum repeats,
3. Multiply by four and add one you get two minmum repeats.

And just in case you hadn't thought of it, Excel is a great tool for doing this sirt of thing.

[Vynce]

I tried redoing all the OBCs according to your directions and the minimum number of repeats listed in the service manual.

Power toggle still works well. It actually doesn't work every time, but it usually works. Other buttons still require several presses or holding the button down. Arrow buttons don't work at all.

I've been trying both frequency versions all along. They both generally work. The high frequency one works from various distances. The low frequency one only works when the remote is about a foot away - any closer or futher and it doesn't work at all.

I'm not using any distribution system. I'm pointing the remote directly at the sensor or at the wall that the sensor faces - I always try both and at various distances.

[jon_armstrong]

The only thing I can think of is tweaing the framing or a skewing of On/Off times due to the higher frequency. Lets tackle framing first:

Low Freq

Upgrade protocol 0 = 01 E1 (S3C8+) PB v3.10
37 82 01 8B 13 C4 84 10 08 07 00 BC 00 A8 00 BC
00 A8 58 78 00 BC 03 98 58 03 E6 03 BE F6 01 46
F6 01 46 E6 29 85 59 03 56 C5 03 EB 02 5C 0B DF
C0 03 02 55 F6 01 46 5A FB E6 03 BE E6 29 84 F6
01 46 8D 01 46
End

High Freq

Upgrade protocol 0 = 01 E2 (S3C8)
0A 0A 01 8B 13 C4 84 10 08 07 00 BC 00 A8 00 BC
00 A8 58 78 00 BC 03 98 58 03 E6 03 BE F6 01 46
F6 01 46 E6 29 85 59 03 56 C5 03 EB 02 5C 0B DF
C0 03 02 55 F6 01 46 5A FB E6 03 BE E6 29 84 F6
01 46 8D 01 46
End


The two bytes in bold control the degment lenth of all segments. According to the spec it's 46046 uSec. The previous value 59 EF is decimal 23023 and is in two second increments (or 46046).

When I tested the low frequency version (and I have no way to test the high frequency version) it was about 400uS too long so I have adjusted this number to be closer to the Pronto files.

Try these and if that doesn work you could keep shortening it untill it gets more reliable or less reliable and then try the opposite.

[Vynce]

I haven't given up on getting this working yet

Good news...
The reseller that I bought my projector from sent me a URC-8811 which he taught several ECP commands to. I have tested it with my projector and all the commands work perfectly, so hopefully we can use it to develop a working protocol. Here are the contents of the remote that I grabbed with IR v5.15: Learned ECP commands.

According to IR, the learned commands seem to be the low frequency type.

Here is the key mapping:

Code: Select all

URC            ECP
---            ---
Power          Power
Arrows         Arrows
Menu           Crosshatch pattern
Guide          Converge
Exit           Exit
Numbers        Numbers
Channel Up     Brightness
Channel Down   Tint
Volume Up      Contrast
Volume Down    Color
Prev           Move

[jon_armstrong]

I just posted a new device and protocol upgrade based on the learned commands. I have assigned very few keys in the buttons tab and it is set for a 6131 PVR remote but if you are using the extender you apparently select a different remote type in the setup tab, cell C2, "6131 PVR Extender".

Please do not use this with any prior KM upgrades since I started over.

Based on my limited testing it is sending the same commands as those that were learned. I have added the other commands that were in the Pronto file for the ECP (as those were consistent with what I decoded.)

[Vynce]

Cool! I tested several commands and they all seem to work just as well as the learned commands! I'll do some more testing over the next few days.

I'm interested in what the differences are between this protocol and the previous one.

Thanks!

[jon_armstrong]

Here is the long answer to what's different:

The spec in the manual that we saw was:

{42.3k,msb}<-376,+376|376,-376>((1:1,31:6,376,^46m)2,(1:1,F:6,376,^46m)+,(1:1,31:6,376,^46m)2)

and what was learned was:

{42.3k,msb}<-376,+376|376,-376>((1:1,31:6,376,^24m),(1:1,F:6,376,^46m)+)

What this means is:
{42.3k,msb} ==> 42KHz carrier frequency, the bits are sent most significant bit first, which is the normal way we think of binary
<-376,+376|376,-376> ==> these are the Zero|One definitions + means carrier On, - means off

(1:1,31:6,376,^46m)2 ==>1 decimal expressed in 1 bit (1:1), 31 in 6-bits (011111), 376 uSec of On time followed by a long off period (gap) such that the interval between frames is 46 mS. The final 2 means two repeats of the first frame.

The data frames are all (1:1,x:6,376,^46m) and in the the first two frames x=31. The third and subsequent frames (as long as the button is held) have x=OBC. In the spec when the key is released, you get another two frames where x=31. The plus at the end of the expression in the center means that it repeats when the button is held. So in theory it would be 1-1-2-2-2- ... 2-1-1.

The learned command was simpler. One frame with x=31 and a repeating frame where x=OBC. However, I think the most significant difference is the gap between the between the leading pulse of the first to second frame (24 mS) compared to 46 mS thereafter. There were no repeated first frames that I saw either.

The learned command may well have a release command but if you hold the key being learned down, until the remote being taught double-blinks, you never see the release command in the learn.

At this point if it's reliable, the release command probably isn't very important (if it even exists). It usually isn't that important and will only show up in fast macros, where the IR receiver is looking for a release flag before being ready to move on to another command. But much of that that is conjecture on my part, based on keyboards.