Hi guys,

I've been trying to create my first ever IRP file for makehex, and have failing spectacularly so far. The idea was to get the discrete codes for a Bel-Canto DAC3 device in hex format. They gave me the description of the IR protocol they use, and I tried to do the IRP file based on that, but nothing works so far. Can somebody help please?

I posted the IR protocol definition for their remote at [Link: magyars.us]

My IRP attempt is below. If anyone can tell me what I'm doing wrong, I'd much appreciate it.

Thank-you,

--Imre M.

Device=26 'IDH
Function=62 'Standby On
Protocol=BELCANTO
Frequency=38000
Time Base=1000
MessageTime=49
First Bit=MSB
One=-1,1
Zero=1,-1
Prefix=-7000u,2800u,0:1
Suffix=(0+D+F)^1,2
R-Prefix=-7000u,2800u,1:1
R-Suffix=(1+D+F)^1,2
Form=*,D:8,F:8,_;*,D:8,F:8,_

First you have the polarity backwards, because the pdf file you quoted documents the signal in a counterintuitive way (unless you are experienced in IR hardware).

The low portion of the pictured waveform is the active part of the signal (no minus sign in the .irp file).
The high portion of the pictured waveform is the inactive part of the signal (minus sign in the .irp file).

Second, you seem to have misunderstood the way they document the '0' and '1' bits. The picture seems clear to me that a zero bit is 500uS active followed by 1000uS inactive and a one bit is 500uS active followed by 500uS inactive. In .irp format, that is:

Time Base=500
One=1,-1
Zero=1,-2

For most of the rest, I can't even tell what you intended. I expect you copied some things from other .irp files that you didn't really understand.

The last time I recall discussing this specific protocol was here:
[Link: remotecentral.com]

In that post I gave a .irp file that I thought matched the DAC4 documentation, and I explained each part of that .irp file. The device number was different there than the device 1A hex (26 decimal) that you seem to want. I don't recall whether I ever found out whether the result worked.

Hi johnsfine,

Sorry about my bad IRP attempt and any confusion it created.

Anyway, I did try your version of the IRP, with your original device code, as it matches the mini remote the manufacturer supplied, and that I captured. The new IRP file I used then was:

Device=79
Function=0..7
Frequency=38100
Zero=500,-1000
One=500,-500
define X=(D+F)^1
define Y=(1+D+F)^1
First Bit=MSB
Form=7000,-2800,0:1,D:8,F:8,X:8,500,-60m;7000,-2800,1:1,D:8,F:8,Y:8,500,-60m

The hex codes this generates should be the comparable to the ones I originally captured. In any case, the generated codes don't work. Here are the two versions of the Power Toggle (command 0):

Generated by makehex:

0000 006D 001B 001B 010A 006B 0013 0026 0013 0026 0013 0013 0013 0026 0013 0026 0013 0013 0013 0013 0013 0013 0013 0013 0013 0026 0013 0026 0013 0026 0013 0026 0013 0026 0013 0026 0013 0026 0013 0026 0013 0026 0013 0013 0013 0026 0013 0026 0013 0013 0013 0013 0013 0013 0013 0026 0013 08EA 010A 006B 0013 0013 0013 0026 0013 0013 0013 0026 0013 0026 0013 0013 0013 0013 0013 0013 0013 0013 0013 0026 0013 0026 0013 0026 0013 0026 0013 0026 0013 0026 0013 0026 0013 0026 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0026 0013 0026 0013 0013 0013 08EA

What my capture tool reports:

0000 006D 001B 001B 00EB 006C 000E 0027 000E 0027 000E 0015 000E 0027 000E 0027 000E 0015 000E 0015 000E 0015 000E 0015 000E 0027 000E 0027 000E 0027 000E 0027 000E 0027 000E 0027 000E 0027 000E 0027 000E 0027 000E 0015 000E 0027 000E 0027 000E 0015 000E 0015 000E 0015 000E 0027 000E 08C9 00EB 006C 000E 0015 000E 0027 000E 0015 000E 0027 000E 0027 000E 0015 000E 0015 000E 0015 000E 0015 000E 0027 000E 0027 000E 0027 000E 0027 000E 0027 000E 0027 000E 0027 000E 0027 000E 0027 000E 0015 000E 0027 000E 0027 000E 0015 000E 0015 000E 0015 000E 0027 000E 08C9

The reported frequency, by the way, is 38.1 KHz.

Can you make any sense of the discrepnancies?

Thank-you,

--Imre

The time scale is a little different. The captured signal is a little faster than the documented 500uS. I doubt if it matters, and if it does matter the difference might be a timing inaccuracy in your capture of the original signal.

The bigger difference I see is the checksum of the repeated part. The documentation very clearly states that R "must be included in the checksum calculation". But in the captured signal you just quoted, R is not included in the checksum calculation.

With that change, the .irp would be:

Device=79
Function=0..7
Frequency=38100
Zero=500,-1000
One=500,-500
define X=(D+F)^1
First Bit=MSB
Form=7000,-2800,0:1,D:8,F:8,X:8,500,-60m;7000,-2800,1:1,D:8,F:8,X:8,500,-60m

Thanks johnsfine, but still no success, I'm afraid.

At the risk of asking something dumb, if I look at the waveforms in the spreadsheet, are the timings for that initial burst accurate? It says, for example, 7000us for the first burst, but if you count the gridmarks (at 500us per mark, per the notation elsewhere), shouldn't that initial duration be 8500 us?

There's got to be something else wrong somewhere....

--Imre

Let me make sure I understand: The Pronto Hex string you gave above as "What my capture tool reports" was a capture from the original DAC remote?

So excluding any minor distortion that could be introduced by the capture tool, that must be the correct power toggle command?

And that works as the power toggle command?

But the makehex version of power toggle (after the above correction) doesn't work?


I don't see any gridmarks in that pdf. I see numbers from -2 through 49 written above the waveform, but I can't imagine what those are supposed to represent. They can't represent units of time, because a zero bit (1500uS) is 2 counts and a one bit (1000uS) is also two counts.

In case the captured timing is correct and the small difference in timing actually matters, I tweaked the numbers in the .irp file so it perfectly duplicates the captured signal:

Device=79
Function=0..255
Frequency=38000
Zero=370,-1030
One=370,-550
define X=(D+F)^1
First Bit=MSB
Form=6180,-2830,0:1,D:8,F:8,X:8,370,-59130;6180,-2830,1:1,D:8,F:8,X:8,370,-59130

That one did the trick. I can now duplicate all the functions off that "mini-remote" with device code 79.

Unfortunately, if I change the device code to 26 (i.e., hex 0x1a, to generate codes for their "multi-device" remote), the device ignores everything. It looks like the device code should be the only parameter that's different. Bel-Canto says that the device will respond to these codes also, so if I take them at their word, do you have any suggestions as to what could I try next?

And many thanks for your continued help, by the way!

--Imre