Addendum 2: another possibility: Can someone (johnsfine perhaps :) ) tell me what values he would ideally want to see, to easily generate proper hex without having to do additional math. Do you need Hz'es? uSes? binary codes with base encoding rules? Wavelength settings? ..

I think I understand the basics of the format 'HIP' is using, though I'm not sure of the time scale. I'll look through it more carefully, when I have more time, in order to see how it compares to the info you have in other forms.

Based on just a quick look:

In the body of the signal, each pair that is approximately equal to 88 15 represents a '0' bit an each pair that is approximately 89 0A represents a '1' bit. (It doesn't matter whether the first number is 88 or 89. It doesn't matter whether the second is 13, 14 or 15. Those are all the same, all '0'. But when the second number is 0a or 0B, you have a '1').

So the first chunk you quoted, 89 14 88 14 89 0A 89 13 89 14 89 0A 88 0B 89 0A 89 0A 89 13 89 14 88 14 89 13 89 14 88 14 88 0B 88 0B 89 13 89 0A 89 14 88 0B 88 14 89 14 88 0B 88 0A
Represents: 0 01001111 00000011 01010011
Which is the 4F 03 53 you expected.

Regarding signal repetition, Im pretty sure that HIP (or MCE) heard my remote too often. As said, volume plus works, but if I tell HIP to send 'volume +' to my DAC, it actually increases volume quite a bit.. (equivalent of say 4-5 keypresses). The atomic volume up signal therefore is probably just one or two of those cycles.

As a general point, HIP is - as far as I can tell - becoming the de-facto freeware alternative for remote control stuff. If we could make some system that translates HIP to CCF (vice versa isnt necessary, HIP understands CCFs), then it would become much easier to share this stuff. The codes I pasted you come from some tiny 'learned IR' window, and isn't very practical.

Instead, HIP created the following file in its MCE dir (I mention the dirname since it -might- indicate there is some Windows MCE Remote 2005 specific stuff in this file here).

[Link: arago4.tnw.utwente.nl] (yes, I suspect the DAC3 'extention' is really just the name it took from my naming of the remote set)

Maybe in the future we can build a 'HIP to CCF' translator? It'd save you a bit of time ;)

I still haven't had a chance to take a better look at this.

I don't recall anything that tells us the modulation frequency of these signals.

Do you know whether your USB IR detector and HIP can capture the modulation frequency of the original signal? I'm pretty sure the hex string you posted from HIP does not include anything representing the modulation frequency.

If I understand you correctly, you can translate from Pronto Hex to the HIP format. One thing I can't tell from the HIP string is the time scale. The time scale (unlike the frequency) is given very clearly in that XLS file you quoted, but I'm not sure we should trust it. If you convert any ordinary signal from Pronto Hex to HIP format, comparing the two would tell me the time scale of HIP.


That file appears to contain exactly and only the information you posted earlier for VolPlus.

There are many problems with the idea of a HIP to CCF translator. The lack of modulation frequency is one of them, but there are others. If HIP really is common, then a HIP signal decoder would be easy and useful. That would pass the info from HIP to DecodeIR.dll to get decodes of any of the IR protocols that DecodeIR has been programmed to understand. That doesn't (yet) include the protocol we're talking about here, but it includes almost all protocols that other people are likely to need.

With the decode info, it is easy to use MakeHex to produce clean Pronto Hex to put in a CCF file (or for other purposes). For almost all common protocols, the decode can be done without knowing the modulation frequency, then the .irp file used with MakeHex has the correct frequency, so the Pronto Hex can have the correct frequency, even if the HIP file does not.

Nope, of course the DAC3.xls mentions this, it seems. Additionally, while a bit messy, this documentation also should provide us with enough clues as to what timing 'assumptions' HIP means.


Hmm. The only other file I can find is [Link: arago4.tnw.utwente.nl] which seems to tie a few things together but doesn't provide much of a clear picture to me..


Correct, HIP can import a CCF file, I can select a IR code and tie it to a send action. Then my remote's IR blaster (IR sender) can beam that into space. Kinda cool.

With this in mind, a little trial and error could go a long way, if you wish you can send me a few CCF files with a few different frequencies but identical and I can see what changes in the resulting configfiles..

One thing I can't tell
from the HIP string is the time scale. The time scale
(unlike the frequency) is given very clearly in that XLS
file you quoted, but I'm not sure we should trust it.
If you convert any ordinary signal from Pronto Hex to
HIP format, comparing the two would tell me the time scale
of HIP.

Well, the DAC4 xls does seem to give a fairly accurate wavelength timing so that looks 'worthwhile'.

That file appears to contain exactly and only the information
you posted earlier for VolPlus.

*nod*

There are many problems with the idea of a HIP to CCF
translator. The lack of modulation frequency is one of
them, but there are others. If HIP really is common,
then a HIP signal decoder would be easy and useful.

As far as I know the only alternative to HIP is Girder. (which is pricey and complex).

That
would pass the info from HIP to DecodeIR.dll to get decodes
of any of the IR protocols that DecodeIR has been programmed
to understand. That doesn't (yet) include the protocol
we're talking about here, but it includes almost all protocols
that other people are likely to need.

With the decode info, it is easy to use MakeHex to produce
clean Pronto Hex to put in a CCF file (or for other purposes).
For almost all common protocols, the decode can be done
without knowing the modulation frequency, then the .irp
file used with MakeHex has the correct frequency, so the
Pronto Hex can have the correct frequency, even if the
HIP file does not.

Sounds like a decent approach. Let me know how things progress!

What would you do with a CCF file? I assume you don't have a Pronto. If you had one, I expect you would be using its learning, since you seem to have an original remote to learn from.

I will provide (below) Pronto Hex generated by MakeHex, as well as instructions for using MakeHex yourself to try other combinations. You can use IrPanels.exe or Hex2CCF.exe to convert the output of MakeHex to a CCF file. You should get these programs and read their instructions:

[Link: john.fine.home.comcast.net]
[Link: remotecentral.com]
[Link: remotecentral.com]


That gives frequency and timing and details of the signal structure. It is just fails to tell us the value of the Customer Code. But since it is totally inconsistent with the signal you captured by HIP, it isn't actually relevent to your current task.


That one seems to tell us everything but frequency and repeat rate. That one is consistent with the signal captured by HIP. But since the timing isn't the same between DAC3 and DAC4, it is questionable whether the frequency is the same.


I'm a bit curious how you came to all those conclusions. But anyway, I don't think you can conclude anything in the DAC3 file is wrong. Just that your signals are the type described by DAC4, not DAC3. DAC3 describes LSB/MSB the opposite of DAC4 and your signals have that feature matching DAC4. But the signals described by DAC3 likely match the DAC3 documentation.


The easiest way to do all of that is using the MakeHex program (see details below).

Looking more closely at the HIP timing, we see the value you call AGCLow is about 124 units. The value you call AGCHigh is about 56 units. A '1' bit (1000uS) is about 19 units. A '0' bit (1500uS) is about 29 units. The gap between frames (which is not specified by DAC4.xls) is about 1200 units.

If we assume the XLS is correct about timing and HIP measured things roughly correct, we can guess a HIP unit is 50uS, so we see AGCHigh was measured seriously short 6200uS instead of 7000. AGCLow is perfect, and '0' and '1' bits are slightly short. Alternately we might guess units at 53uS each, so '0' and '1' bits are near perfect, AGCHigh is a little closer and AGCLow is too long. Most likely the device receiving the signal doesn't care about that level of accuracy.

Using 50uS as a unit, the HIP data gives us a gap between frames of 60 milliseconds (info we didn't have from any other source).

I put all that together into a .irp file for use with MakeHex:

Device=79
Function=0..255
Frequency=38000
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

You can copy that block of text into a file (which ought to be named DAC4.irp) and drag/drop it onto MakeHex.exe to get a .hex file generated with a full set of codes.
Here is the meaning of the individual parts of that .irp file:

Device=79
I'm using the IDL value (4F hex is 79 decimal) as the device number.
Function=0..255
Tells MakeHex to generate all 256 possible functions
Frequency=38000
Just a wild guess. You may need to try other values.
Zero=500,-1000
A '0' bit is encoded as 500uS of signal followed by 1000uS of quiet.
One=500,-500
Similar for a '1' bit
define X=(D+F)^1
Compute the checksum for the first frame (where R is 0)
define Y=(1+D+F)^1
Compute the checksum for the rest of the frames (where R is 1)
First Bit=MSB
Tell MakeHex the bit sequence
7000,-2800,0:1,D:8,F:8,X:8,500,-60m
The first frame is 7000uS of signal, followed by 2800uS of Quiet, followed by a '0' encoded in one bit, followed by the device number encoded in 8 bits, etc., ending with 60 milliseconds of quiet
;7000,-2800,1:1,D:8,F:8,Y:8,500,-60m
All repeat frames are like the first frame except that R is now 1 instead of 0 and we use the checksum Y instead of X.

You should be able to run that .irp through MakeHex yourself and get Pronto Hex. You may need to if you need to test multiple possible changes (frequency, etc.) to the .irp file. But to get you off to a faster start, I ran that through MakeHex myself and these are the first few signals generated:
Device Code: 79 Function: 0
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
Device Code: 79 Function: 1
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 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0026 0013 0026 0013 0013 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 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0026 0013 0026 0013 0026 0013 08EA
Device Code: 79 Function: 2
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 0013 0013 0026 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0026 0013 0026 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 0013 0013 0026 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0026 0013 0013 0013 0013 0013 08EA
Device Code: 79 Function: 3
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 0013 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0026 0013 0013 0013 0013 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 0013 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0026 0013 0013 0013 0026 0013 08EA
Device Code: 79 Function: 4
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 0013 0013 0026 0013 0026 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0026 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 0013 0013 0026 0013 0026 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 08EA
Device Code: 79 Function: 5
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 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 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 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0026 0013 08EA
Device Code: 79 Function: 6
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 0013 0013 0013 0013 0026 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 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 0013 0013 0013 0013 0026 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0013 0013 0013 0013 08EA
Device Code: 79 Function: 7
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 0013 0013 0013 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0013 0013 0013 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 0013 0013 0013 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0026 0013 0013 0013 0013 0013 0026 0013 08EA


I'd prefer if you learned how to make CCF files yourself with MakeHex and either IrPanels or Hex2CCF. Then you can edit the frequency in the .irp file and make a new CCF file and know that only the frequency changed.

BTW, you might want to take the .irp and/or hex I gave above and import into HIP format and see how it compares to the the data captured from the original remote.