hi,
i'm new to this forum. i ahve an DVD recorder made by samwin china. i have leared all the codes and wanted to find the power on/ off disccreet code.

i am trying to find the dicreet code for power on/ off from the leared code from pronto RU950

the codes below are leared by ru950

power doggle900A 006D 0000 0001 00FF 0AF5
eject900A 006D 0000 0001 00FF 4BB4
rec900A 0068 0000 0001 00FF 13EC
play900A 006D 0000 0001 00FF 1DE2
reverse900A 006D 0000 0001 00FF 19E6
review900A 006D 0000 0001 00FF 58A7
pause900A 006D 0000 0001 00FF 5DA2

can anybody help me to find the code for Power on / off?
thanks

Most likely the discrete codes you are looking for don't exist.

But if you want to test all 256 possible commands and see what each does, that can be done starting with MakeHex plus either IrPanels or Hex2CCF

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

Be sure to read the readme file included in MakeHex.zip

Use the NEC1.irp file, and edit it to set
Device=0

The output from MakeHex should be fed to either IrPanels or Hex2CCF to create a CCF file with 256 numbered buttons. Then convert or merge that into a file for your remote. Then test.

The buttons you posted are:

10 power toggle
75 eject
19 rec
29 play
25 reverse
88 review
93 pause

If those numbered functions don't work from the numbered buttons produced with makehex, then you did something wrong and testing the rest of the makehex codes would be a waste of time.
But if those work then probably every function your DVD can perform is covered by buttons 0 to 31 plus buttons 64 to 95. If those don't include discrete power commands, there probably aren't any. There is a tiny chance the commands you want are in functions 32 to 63 or 96 to 255. I'd bet against it, but if you go to the effort of merging the set of 256 buttons into a file for your remote, you might as well press all of them and see.

thanks john, i could able to find the code for power off (it is 196) but not able to find for power on. any other way to find the code??

Wow. I'm surprised there is a discrete off, surprised there is a code above 95, and surprised you found that so fast.

Did you do the testing that your short reply seems to imply, or am I misunderstanding something and/or you found that discrete off elsewhere?

1) You made the set of 256 signals as I described above?

2) You imported that into your RU950?

3) With DVD power ON, you tested all 256 signals and only 10 and 196 turned the DVD off?

4) With DVD power OFF, you tested all 256 signals and only 10 turned the DVD on?


I don't think so.

BTW, when testing with the DVD on, were there other codes above 95 that did anything?

Yes John, as described by you i followed everything (downloaded Irpanel and so on...)
also some of the keys above 95 did something which i ignored as i was interested only on/ off.

to find "off" sequence, i made the DVD recorder on & tested the codes. for on sequence made the DVD off and tested. (is there an automated way to send these codes one by one??)

also i need on/ off discreet codes for thomson and ZENEGA Sat receievers. the thomson is working with the code set 1073 supplied with pronto edit. but power getting toggled insted of power on /off sequence.

by the way can you tell me what is the meaning for the last two digits in my code. ( like 0AF5- 0A is 10 which is code for Power Toggle, what is this F5 for??)

I'm pretty sure there is nothing you can do with a Pronto to automatically send all those signals.


I can look that up by the code number 1073, but not as easily as decoding a Pronto Hex string. Do you have learned signals for those two devices.

Once again, my basic answer is that the discrete codes you want probably don't exists. But you already found one more than I expected (that discrete Off for your DVD).


It is a check byte. There are four bytes of data in an NEC signal:

The first is a device number.

The second is a second device number for some devices, but is a check byte for the first device number for some devices, including your DVD.

The third is the function number.

The last is the check byte for the function number.

The function number and its check byte always add up to FF.

Knowing that, you could have created the 256 signals in the condensed 900A format rather than in the ordinary Pronto Hex generated by MakeHex. But I don't know any tools that work with full sets of 256 signals in that form, so it is easier with MakeHex and IrPanels. The signal sent by the Pronto is the same for the 900A form as it is for the ordinary Pronto Hex. PENG may have changed that ordinary Pronto Hex to the 900A form anyway (I'm not very sure about what happens when importing a CCF file).

here are the learned signals:

ZENEGA:

Favorites:
0000 0049 0000 000B 0030 0030 0030 0030 0030 0030 0060 0030 0030 0030 0030 0060 0060 0060 0030 0030 0060 0060 0030 0030 0060 05E0
Power toggle:
0000 0042 0000 000B 0069 0069 0069 0038 0635 0038 0032 0038 0032 0038 0032 0069 0032 0038 0032 0038 0069 0069 0069 0038 0032 006A
number key 1:
0000 0049 0000 000A 0030 0030 0060 0060 0060 0030 0030 0030 0030 0060 0060 0060 0060 0030 0030 0030 0030 0060 0060 05E0
number Key 2
0000 0048 0000 000A 0031 0031 0060 0060 0060 0031 0031 0031 0031 0060 0060 0060 0060 0031 0031 0060 0060 0031 0031 05F8
number Key 3:
0000 0049 0000 000C 0030 0030 0030 0030 0030 0030 0060 0030 0030 0030 0030 0060 0060 0060 0060 0030 0030 0060 0030 0030 0030 0030 0030 05C0


For thomson, the codes are from Proto database. is there a way to look at the HEX of these codes??

For the Zenega use Streamzap.irp and set
Device=34
There are only 128 commands, rather than the usual 256.

Streamzap includes something called a "toggle bit" that usually stops the device from accepting the same learned command twice in a row. That is most likely to be a problem in tasks such as tuning channel 11. Have you had trouble with that?

Streamzap.irp has a line
Define T=
setting the toggle bit to 0 or 1.
You can use that to create two sets of signals. For ordinary use, either set will work. But when you need the same signal twice in a row, you may need one from one set and the next from the other set. That is easy when you are building macros, but much harder for ordinary button presses. There are some complicated work arounds. But for discrete codes (if they exist) it shouldn't be a problem at all, and I don't yet even know whether your device even has the underlying problem.

For the Thomson, I don't know a way to look at the Hex in the database. But the database is licensed from UEI and each PENG setup code number is 27 more than the corresponding UEI setup code number. So your SAT/1073 is UEI SAT/1046, which I was able to look up in a speadsheet from a different remote.

For that use the thomsom.irp file and set
Device=34
There are only 64 signals instead of the usual 256.

Thomson protocol also has a toggle bit. I see I left the
Define T=0
line out of the released copy of thomson.irp by mistake. If you need to create two sets you can add that line and change it to 1 for the other set.

I have a similar problem with an OEM LCD TV (Infocus TD40p), evidently based on electronics from Harsper R&D. The remote has a single ON/OFF key, which I have learned as:
0000 0067 0000 002a 016c 00b5 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0044 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0044 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0017 0044 0017 0044 0017 0044 0017 0044 0017 0044 0017 0044 0017 0044 0017 0044 0017 075c 016c 005a 0017 0f2a 016c 005a 0017 0f2a 016c 005a 0017 0f2a 016c 005a 0017 9d1d
The TV has a serial interface with separate ON (MPO00) and OFF (MPO01) codes, which leads me to believe that the IR interface must also support discrete ON/OFF. However, I haven't been able to make sense of the learned code.
IRTool gives the following interpretation:
Protocoll: NEC12
Device: 32.64
OBC: 0
EFC: 181
but NEC12 doesn't correspond to any of the protocols supported by MAKEHEX, nor to those listed in the README for DecodeIR.DLL, unless the "x" in NECx2 is a wild card.
How should I proceed?

What devices did you use for that learning. You posted Pronto Hex, so one might guess you used some sort of Pronto to learn onto. But lots of other devices translate to of from Pronto Hex, so I don't want to guess. One might also guess you learned from the original remote, but maybe you used some other working remote to learn from.

The reason I ask all that is I think you posted a distorted signal. It may help to know what the real signal is. (But see below, you may be able to do the discrete search perfectly without knowing the exact signal structure).


Sorry. Lots of TV's have discrete codes via RS232 that they don't support via IR.


Usually that is a distorted learn of NEC1. I'm not certain it is ever anything other than a distorted learn of NEC1. I don't have access to most of the original remotes that DecodeIR can decode. I'm working primarily from learned data posted in various online sources and NEC12 is a rare but recurring pattern and exists in places where I can't tell whether the real signal was actually learned.

For most devices expecting NEC1 and/or most commands of a specific such device, NEC12 would work correctly despite not being exactly correct. So if it is all a learning error, ordinary users would likely never notice.

Anyway, the difference between NEC1, NEC2 and NEC12 can't matter to discrete codes (it can matter in non discrete codes and might matter a lot in incremental commands, such as CH+). But for discrete codes searching, NEC1 will be best. If NEC12 was a learning error NEC1 is correct. IF NEC12 is the true signal, NEC1 will still work right for any discrete command and any short press of a non discrete command.

The frequency might be a more serious difference. You signal is at Frequency=40000, but NEC1.irp has Frequency=38000.

Probably the frequency is a learning error and the original remote is really 38000.

Probably the actual device doesn't care whether the signal is 38000 or 40000 and either will work perfectly.

But, in the unlikely event that both the learning wasn't wrong, and the device cares, then you'll need to change the frequency line in NEC1.irp to make that work.

First test that function 0 as output from MakeHex does the power toggle (based on the decode of OBC 0 for the Pronto Hex you posted). If that works, the protocol and frequency are OK and you can try the other functions for discrete codes.


No NECx is a similar protocol, but different enough that using NEC instead of NECx or vice versa often fails. NEC12 is not NECx.

Thanks, John, for your detailed response. I am using Pronto emulation SW (TV Remote Controller 5 from pdawin.com) running on an iPAQ 3900 Pocket PC instead of a real Pronto. I learned the code form the OEM remote control. Following your advice, I generated a CCF file using MakeHex and HEx2CCF from NEC1.irp:
Device=32.64
Frequency=40000
and found that function 0 does indeed correspond to the ON/OFF function, as you surmised above.
Testing the remaining functions turned up most (if not all) of the original RC functions in the ranges 0-32 and 64-96 as you had supposed in your earler response to sekar.
Unfortunately, I found no discrete ON /OFF codes. I was also hoping to find discrete codes for the different screen formats, which can also be controlled directly via RS-232, but no luck here either. All I succeeeded in doing was to reset the TVs channel assignment programming, which will cost me quite a bit of time to reconstruct.
Thanks anyway for your very competent and prompt assistance!

hi john,

the streamzap.irp is not available in the zip archive makehex.zip. any other file will do the same coding??

Sorry. My list of what was in Makehex.zip includes streamzap.irp, but I'm not too organized about makehex.zip releases and might have goofed somehow.

Until I can investigate and fix MakeHex.zip, copy the following into a new file named streamzap.irp

Device=34
Function=0..127
Define T=0
Frequency=59000
Time Base=889
Zero=1,-1
One=-1,1
Message Time=114
First Bit=MSB
Form=;1:1,~F:1:6,T:1,D:6,F:6

sorry john

both streamzap.irp and thomson.irp not at all creating any responces from these (Zenega and Thomsan) recievers. none of the key is responding. tried to adding line Define T=0 and 1 in thomsan.irp without any luck. believe the codes are not matching??

In post 7 of this thread, you gave some ZENEGA signals. The digit 1 looked cleanest. I decoded it as Streamzap device 34, function 34, with T=0.

0000 0049 0000 000A 0030 0030 0060 0060 0060 0030 0030 0030 0030 0060 0060 0060 0060 0030 0030 0030 0030 0060 0060 05E0

I used MakeHex to create the full set for Device 34, with T=0 and pulled out function 34, which is:

0000 0046 0000 000A 0035 0034 0069 006A 0069 0035 0035 0034 0035 0069 0069 006A 0069 0035 0035 0034 0035 0069 0069 11B0

That may look to you very different from your learned signal, but it is really nearly identical. If we decide, it needs to be closer, we can tweak some values in the .irp file (slightly lower frequency and/or slightly shorter timebase and/or much shorter message time). But I'm not yet convinced we need to.

Please recheck that your learned signal above really works and check to see whether the MakeHex version I made works and whether the MakeHex version you made (device 34, function 34, T=0) matches the one I made.

If you want to experiment with values in a .irp file, lowering the frequency will raise the second number in the Pronto Hex string (and change other numbers, but ignore that). Your cleaner learned signals have 0048 or 0049 in that position. The correct value does NOT vary by command. It just isn't learned very accurately and doesn't need to be exactly correct (46 vs. 49 should be close enough. Even the 42 in your bad learn of power toggle should be close enough).

BEFORE you can compare the rest of the numbers (between to Pronto Hex strings), the second number must match exactly, so even though a perfect match on that won't matter to the final device, you'll need that perfect match before you will know how to tweak other values.

The second largest value in each of your learns is 0060. After the second value matches, you can compare that to the second largest value in the MakeHex signals. Again, the correct value doesn't vary by command and an exact match doesn't matter. If you want it closer, lower the TimeBase to lower that value.

The largest value is last in any reasonably clean learn (your power toggle is not a good learn). The largest value shouldn't even need to be close. But if you want it closer, lowering the Message Time will lower that largest value.

For Thomson, can you learn a signal from the original remote?