John, or anyone:

I have a ccf for the Lumagen HDP scaler but it contains learned codes. I can't see the hex. Can any of you gurus take a look at this file and tell me the protocol, device id and device code that I can use in make hex?

Here's the ccf:
edited - see reply below for correct link

Thanks,
Scott

This message was edited by shorton on 06/29/05 22:39 ET.

Why do you have a problem seeing the hex for those learned signals?

But using DecodeCCF.exe (with DecodeIr.dll) on the whole ccf file is easier and better than looking at individual hex strings (with IrTool.exe or otherwise).

Lumagen uses an IR Protocol that I think is their own (so I called it "Lumagen" when I added DecodeIr support for it). My (minimal) description of it is in the DecodeIr documentation at:
[Link: john.fine.home.comcast.net]

I never got around to adding it to MakeHex. Anyone who knows IRP notation could make an .irp file based on that entry in DecodeIr documentation. Maybe I'll have time to do that tomorrow.

Hi John:

Thanks for that (link), but it looks a little greek to me . I see that the link might have failed, here it is fixed just in case it's any help:
[Link: av-rs232.com]

And here's a doc Lumagen sent me today. Nothing you don't apparantly already know:

Sorry about the jpg, thats what I got.

And FYI, I gathered from Lumagen the IR isn't theirs. Becasue they didn't know any more about it than the doc they sent above, and they seemed excited about me helping create a non-learned .ccf and .mxd. Don't know who's it is, maybe a subcontract.

I know how to use makehex, then prontoedit to create a ccf (you taught me). Even if it's tedious, I do understand the process so I'm OK with it. If you have time to make a .irp for it, that would be outstanding and sincerely appreciated as always.

And oh yeah, can tell the device number from what they sent, or the ccf I linked?


Best, Scott

This message was edited by shorton on 06/29/05 22:47 ET.

After using MakeHex, its usually easier to use IrPanels to create the CCF than doing it the tedious way with ProntoEdit.

I might tweak the timing values in DecodeIr's doc and/or in the .irp (when I get around to writing it) based on the nominal values from that Lumagen doc (which may be more accurate than the learned signals on which I based my analysis). But their description of the structure was not helpful (wouldn't have been enough if I didn't already know the structure and wasn't needed since I did).

I made a .irp file. Its contents are

Device=2
Function=0..63
Frequency=38000
Time Base=416
First Bit=MSB
Zero=1,-6
One=1,-12
define X=F^(F:4:4)
define C=X^(X:1:1)^(X:1:2)^(X:1:3)
Form=;D:4,~C:1,F:7,1,-26

The Lumagen doc says the part of the signal I call "device" is always 2, so don't change that.

They say each button is described by its column (1 to 4) and its row (1 to 16). MakeHex uses function numbers (which match those displayed by DecodeCCF for that CCF file). To translate Lumagen's row and column number into function number, use

function = row*4 + column - 5.

Taking their example ( row 4, column 3) it would be 4*4+3-5 = 14. Notice that 14 decimal is 0001110 in 7-bit binary, which matches the binary answer they give for that example.

They actually documented (row-1)*4+(column-1) but that has the same value as row*4+column-5.

More importantly, if you use MakeHex and Irpanels, the button marked 14 in the CCF created by IrPanels would be the Lumagen button for row 4 column 3.

Thanks John! I'll give it a spin this afternoon when I get home (to PC/remote/Lumagen) and see if I can get it going. I'll go see if I can see how to use IrPanels, too.

Thanks again, Scott

Wow, tried IrPanels. Had no idea what to do, so I simply pasted the output from makehex into it's "big" panel, and pressed the only button. The "little" panel line reported "63" which matched the number of codes in the makehex file, so it was looking good. I opened the resulting ccf file (once I found it in program files ) Checked a button's hex and voila, there it was so it appears to ahve worked properly. Man what a timesaver that was if it did. Can't wait to test later. THANKS!!!

Is working. Thanks. I will upload the final result when I get it fixed up. For example:

I did notice the Hex code that is in their website's ccf with the learned code (linked above) is significantly longer than the code produced via makehex. Both work.

Their code, (ccf says learned) for 4:3 mode:
0000 006b 0024 000d 0010 0062 0010 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 0061 0010 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 01af 0010 0061 0010 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 0061 0010 0061 0010 06a8 0003 006f 0006 0008 0002 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 0061 0010 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 01af 0010 0061 0010 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 0061 0010 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 01af


My code, made with make hex for 4:3
0000 006d 0000 000d 0010 005f 0010 005f 0010 00be 0010 005f 0010 005f 0010 005f 0010 005f 0010 005f 0010 00be 0010 005f 0010 005f 0010 005f 0010 019b

Interesting. Does the learned code contain a bunch of garbage, or is mine missing something, why the difference?

Best, Scott

Their copy is a really crappy learn. One can disect it as:

0000 006b 0024 000d

The header says the frequency is 38.7Khz. MakeHex has a lower frequency, but that amount of frequency difference doesn't matter.

The header also says the signal starts with a one-time section consisting of 36 bursts, before the repeating signal of 13 bursts. The true signal is just 13 bursts repeating. Their initial 36 bursts start with of one and a half good copies of the signal:

0010 0062 0010 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 0061 0010 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 01af 0010 0061 0010 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 0061 0010 0061 0010 06a8

then an interruption as the aiming between the two remotes was abruptly disturbed, then one copy of the signal that starts dirty and ends clean, implying the aiming was fixed less abruptly than it was broken:

0003 006f 0006 0008 0002 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 0061 0010 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 01af

Finally they have the repeating part, which is clean, showing the learning process continued with stable aiming long enough for the Pronto to see the pattern of the real signal:

0010 0061 0010 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 0061 0010 0061 0010 00d0 0010 0061 0010 0061 0010 0061 0010 01af

But the Pronto doesn't have a way to know that the crap at the beginning was bad learning. It has to assume the signal has a legitimate one-time part before the beginning of the repitition (some IR protocols do).

The bad signal starts with one correct frame. It MAY work because the device actually needs only one frame and is already performing the action before the garbage starts. The bad signal also ends correctly, so it MAY work because you don't notice the fraction of a second while the garbage goes by before the signal becomes stable and activates the device.

I'm pretty sure whowever learned that signal was just holding the source remote while pressing the button. The act of pressing the button pushed the whole remote a little out of proper aim for a fraction of a second. It works much better to put both learning and source remote on a table (or other firm hard surface) properly aimed before pressing the button.

Excellent. Exactly what I hope that reprecented. Now I have the desired clean code, thanks to your help. VERY appreciated.

Best, Scott