Thanks

Just tried the code you generated but that does not work unfortunately. Looks like the .irp needs to be modified further?

Any chance of some understandable details about where/how you got the Pronto Hex you decoded that way? (So far you haven't answered most of the questions we asked while trying to help you).

Do you have some learning method that gave Pronto Hex? Or did you test working Pronto Hex and also decode it? Or did you just decode Pronto Hex from some thread that someone said was for a similar model? Or what?


I'm pretty sure the .irp posted in this thread is correct. So I assume you made some error in testing it.

If a signal that operates your device decodes as you said above, then I'm quite confident the signals generated by that .irp also operate your device.

There is a small chance some trivial difference between the learned signals posted in this thread and the generated signals could affect the way your remote transmits them. That could be investigated if we had a clear idea how you are testing things.

But more likely, there is no significant difference and if we had a clear enough idea how you are testing things we could figure out what you're doing wrong while testing.

I am not using a Pronto so I dont think my hex is pronto hex. I only downloaded the Pronto software to see if the codes for my device was in their database. It wasnt.

When I have the codes I need I intend to learn them onto my Harmony One.

I am getting the codes using the 'IR Server Suite' software that I mentioned. This allows me to learn the signals from the keys pressed on a remote control (via the Media Centre receiver/blaster hardware plugged into the USB port)
[Link: htpc.pandagor.com]

This software also allows me to blast any IR codes - this is how I test them


I pasted the learned hex into IRTool and this gave me the Teac-K details above.


I created an irp file using your posting and it generated a file with a full set of codes and I tested code 0 which should be the power toggle but it didnt work. As a double check I looked at what MikitaMark posted and he generated the same codes and that did not work either


Here is the code for power on/off button learned as described above. Pasting it into IRTool should hopefully confirm the protocol details that I got

0000 007A 0032 0000 005D 0047 0011 002A 0011 002A 0011 000F 0011 000E 0011 000F 0011 000F 0011 002A 0011 000E 0011 002A 0011 002A 0011 000F 0011 000E 0011 002A 0011 000F 0011 002A 0011 000E 0011 002A 0011 000F 0011 000F 0011 000F 0011 000E 0011 000F 0011 000F 0011 000F 0011 000F 0011 000E 0011 002A 0011 000F 0011 000F 0011 000F 000F 000F 0011 000F 0011 000F 0011 000F 0011 000F 0011 000E 0011 000F 0011 000F 0011 000F 0011 000F 0011 000E 0011 000F 0011 002A 0011 000F 0011 000F 000F 000F 0011 000F 0011 000F 0011 09F4


Is it possible for you to compare the signal generated above with those generated by makehex? I suspect you have more sophisticated equipment?


I am fairly new to all of this, so it is possible that I have got something wrong. Any further help is most appreciated!

thanks
Bill

The hex you included in that post is Pronto Hex.


I don't understand what that is, but obviously it is able to display a learned signal in Pronto Hex.


Have you tried pasting back a Pronto Hex string that you got from it?

The signal that you got from 'IR Server Suite' and included in your post above:
Did you test it? Did it work? Did you test it exactly the same way you tested the signal generated by MakeHex? Or is there some more direct path to blast a signal that it learned itself, that doesn't require pasting in the Pronto Hex?


Most IR receivers would consider that to be the same signal the one generated by MakeHex, so if one works the other should as well.

But there are few differences worth investigating. The two most significant are the repeat part and the frequency.

Your learned signal has no repeat part. The signal generated by MakeHex has one. The repeat part of the signal is generated by the end part of the .irp file starting with ;
;8,-8,1,-100
If you remove that end part of the .irp file, MakeHex will generate the signal without a repeat part.

I'm nearly sure the repeat part generated by MakeHex is correct (but it isn't normally necessary). If it isn't correct, I'm nearly sure sending it anyway wouldn't bother the Samsung receiver.

So the reason I'm even guessing it might help to remove it, is I'm guessing there may be a bug in the 'IR Server Suite' software. When you paste in Pronto Hex that software must translate it to an internal form in order to blast it. Some bug in that translation might be triggered by the correct repeat part, wrecking the translation of the more important part of the signal. So leaving out the repeat part might help.

Your learned signal has a frequency of 34KHz. I'm nearly sure 34KHz is incorrect and the correct value is very near the 37.9KHz specified in that .irp file. If 34KHz is correct then I expect 37.9KHz would also work, but I'm not very sure of that.

My best guess regarding frequency is another possible bug in the 'IR Server Suite' software translation to and from Pronto Hex. If they used the wrong value for one key constant, they would systematically lower the frequency when generating Pronto Hex from an internal signal and systematically raise the frequency when translating to internal form from pasted Pronto Hex. So the learned signal they display at 34KHz might get blasted at 37.9 and you may need to paste in Pronto Hex as 34KHz to have it blasted at 37.9.

So try changing the 37900 in the .irp file to 34000

Thanks for this.

I have tried the new irp file at 34000, 34800, 38000. None seem to work. There may well be issues with the Server Suite software so I plan to work though some tests tomorrow to see if that is the issue. I can use a more common remote for another device and see if it all works end to end or not.

In the meantime, i have captured a signal from my remote (same remote button as used in my earlier post) onto my pocket pc. This does give the repeat code you mentioned and is as follows:
0000 0077 0032 0002 0060 0049 0011 002C 0011 002C 0011 0010 0011 0010 0011 0010 0011 0010 0011 002C 0011 0010 0011 002D 0011 002C 0011 0010 0011 0010 0011 002C 0011 0010 0011 002C 0011 0010 0011 002C 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 002C 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 002C 0011 0010 0011 0010 0011 0010 0011 0010 0011 0010 0011 06B9 0060 0080 0011 0691

It does give me the same Teac-K protocol and 0.4 device. I dont know if that sheds any more light?

I will post back tomorrow with more info after my investigations!

Bill

or just buy this.......
[Link: cgi.ebay.co.uk]
in the long term if you plan to search for IR codes a proper learning remote is invaluable and provided you get it for a good price you can't go wrong.

1) With the 'IR Server Suite' did you try using hex codes generated without the repeat part? Clearly the repeat part is correct, but maybe it confuses the 'IR Server Suite' and should be left out.

2) I hope those tests you will run involve pasting various signals into it to see if any pasted signals work. I'd still like to hear the answers to questions I asked earlier about what works or doesn't with 'IR Server Suite' .

3) With the pocket pc have you tried pasting individual signals from MakeHex? If I understood you correctly, it couldn't handle the file you created for it with IrPanels and you dropped that whole line of investigation there. There should be many other ways to get the MakeHex samples into it for testing.

I have done numerous tests with some positive results. Firstly, you were right that there is an issue with IR Server Suite.  The part where I pick up the signals doesnt work correctly if I paste a new signal in and blast it. It learns new signals correctly (they show up immediately in the hex format pasted earlier), but if I pasted in a different command it doesnt blast it correctly. However there is another part of the program where I can create individual text files for each command and blast them that way - that does work. I created files for different learned commands and they all work (including all 5 codes pasted earlier by galileo01 - they work too)

In terms of an end to end test, I used my Samsung DVD recorder. This came back form IR Tool as a Aiwa protocol, device 102. I used the aiwa.irp file (no change needed) and it worked immediately. I was able to blast codes using the text file method above and generated codes from makehex worked correctly.

I then got the pocket pc back out... I used an app called 'Remote Control II' to blast the generated Aiwa codes and they worked correctly on the DVD recorder.

I then generated a ccf file using irpanels. I used an app call 'TV Remote Control' on the pocket pc which loaded in the aiwa ccf file and again this worked perfectly on the DVD Recorder


Yes I have tried this and it didnt make any difference. I now think that IR Server suite does cope with the repeat signal from my tests above.


Yes I have pasted a good many signals in now, using the different frequencies and with and without the repeat part.

I have proved that IR Server Suite works (using individual text files containing makehex generated commands from aiwa.irp). It didnt blast using the quick learn tool I was initially using. It does work with repeat codes and it does work with learned codes.


Yes I have now tried pasting codes generated with makehex. 'Remote Control II' allows me to paste in the signals and try them. It also allows me to learn signals (like the one I pasted above that included the repeat signal). It also gives a bit more technical detail on a learned code:
Code Format: 1
AvgBurstLen: 17
Carrier: 35109kHz
OneTimeLen: 50Bst
RepeatTimeLen: 2Bst
Duration: 164ms
Signal Len: 604170tks

This ppc application worked correctly with learned signals and with the output from the Aiwa makehex on my DVD recorder.

Unfortunatly non of the new Teac-K codes worked on my Samsung Receiver, whichever blaster method or frequency I used.


What do the following lines mean?
define M=67
define N=83
I am assuming that they are parameters along with
Device=0.4
Function=0..255
Frequency=37900

The Kaseikyo protocol is used (in slightly different forms) by several different manufacturers based on a published standard (I forget where published).

The protocol encodes 48 bits of data.

The standard specifies the first two bytes of those 48 bits as a manufacturer ID. The values 67 and 83 form the manufacturer ID for this set of signals.

BTW, the 4 bits after the manufacturer ID are a check nibble for that ID. The next 32 bits are permitted by the standard to encode whatever the Manufacturer wants and my read of the standard is that the last four bits must encode a check nibble on those 32 bits (but many manufacturers don't seem to interpret it that way).


Like Device and Function, M and N specify values that are encoded in the IR signal. Frequency is a different kind of parameter.

In the form line, notice the part that say:

M:8,N:8,X:4,D:4,S:8,F:8,T:8

That describes the 48 bits in sequence
M: 8 bits
N: 8 bits
Check nibble for M and N: 4 bits
D (the 0 from device=0.4): 4 bits
S (the 4 from device=0.4): 8 bits
Function: 8 bits
Check byte for D, S and F: 8 bits.

I have an irp that works for the receiver but did not find any discrete power codes for the receiver I have.



Device=0.4
Function=0..255

define M=67
define N=83
Frequency=38600
Time Base=432
Zero=1,-1
One=1,-3
Default S=0
Define X=M^N^(M:4:4)^(N:4:4)
Define T=D+(S:4)+(S:4:4)+(F:4)+(F:4:4)
Form=6,-4,M:8,N:8,X:4,D:4,S:8,F:8,T:8,1,-100;8,-8,1,-100