Post any one of the commands that are in your file that MakeHex created, NEC1.hex.

I got the protocol and device number(0) from an device upgrade in the JP1 group that I helped someone put together. If you use a JP1 remote with the latest tools, learned commands are decoded by software written by John Fine, who also wrote MakeHex.

The NEC family of protocols are similar, and probably any one of them would work on some commands. NEC1 is probably the most common IR protocol in use. For examle, NEC2 constantly repeats it's data bits and NEC1 doesn't.

Hi jarmstrong,

Here is one of the codes, the first one actually:

Device Code: 0 Function: 0
0000 006D 0022 0002 0157 00AC 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0040 0015 0689 0157 0056 0015 0E94

BTW: I tried running it thru MakeHex with both the -b option and the default (hex function codes) option.

Oh well. Perhaps you will make some headway with this. I appreciate it greatly.

Regards,

K.

I'm not saying that I am any better at IRPanels than you are but, I just emailed my attempt to you.

So give that a try.

Except your email filter rejected me!

Wow, I didn't know I had an email filter!! I am sending you an alternate address. Thanks again.

K.

If you test again after changing something, don't bother trying all the codes initially. Jon listed which function numbers do which functions. If you try a few that have known functions and they don't work, there's no point trying more until the basic problem is fixed.

I looked at the .pcf file that was linked to above (I don't know if Jon has the program to look in those) and I looked at the JP1 file Jon looked at. Both are NEC1, device 0 with the function numbers Jon listed.

The Pronto Hex you extracted after using IrPanels was correct, so I don't think you could have done anything wrong up to that point.

If your Momitsu device really is compatible with the ones we have data on then you must have made the error in getting the data from the CCF file to your remote.


I wrote decoding software that does such things. I used that decoding software on Pronto Hex samples from the .pcf file to verify NEC1 (not NEC2, nor any non NEC protocol). I don't know (or don't remember) how that was done by whoever created that JP1 file, but I assume at some point it also involved using my decoding software on some signal.

Hello John,

First,a thank you! to Jon (Armstrong). I got the file that you emailed.

Well, I guess there may be a problem in the importing of the CCF file into the MX800 editor program. The program, as you are no doubt aware of, has a "Universal Browser" function that as far as I know, exists solely to import CCF files into the program.

I imagine that the numeric buttons that show up in this "browser" each represent one pronto code and one function. I simply drag the desired numeric button to the corresponding button on the picture of my remote and drop. If the transfer is succesfull, the program lets me know it.

I have had no trouble doing this same thing to get codes for some of my other components, and they work.

I will try with the CCF that Jon sent to me, and see how they work.

Perhaps the mistake I am making is in the editing of the nec1.irp file. I simply open it in Notepad and change the device number to 0. I leave everything else unchanged. I save the file and run it thru MakeHex.

Thanks again, gentlemen. I will post results later tonight.

Regards,

K.

I am pretty sure you didn't make a mistake, since you posted the Function=0 command.

I think if IRPanels created 256 buttons, then you probably did everything right to the ccf file. If you have made ccf files work before with MXEditor, then I am at a loss for a simple explanation.

If the commands that I emailed still don't work, then my bet would be some sort of framing error probably caused by the translation program. Not that I am saying it is necessarily defective, just that the real command translated to Pronto hex and that translated to MX800 mave have a cumulative timing error that causes the IR recever to reject the command.

I have had some experience with this sort of thing in the NEC1 protocol with a video switcher and tinkering with the time base in MakeHex ultimately got recognition. In this case someone actually put a scope across the demodulated output of the IR receiver and we knew that the timing was skewed and roughly how much when compared to the OEM remote. If you really want to trouble shoot this, by any chance do you have a JP1 OFA remote? The JP1 software can very accurately display the on and off timing of learned signals. You could compare the learned OEM signal to the same "generated" command from the MX

I went back to the original learned signals from the J1 group. Every properly learned command (and there were 16 of them) all had EXACTLY a frame length of 108,548 uS. The null repeat frames were also exactly 108,534 uS and that is nearly perfect classic NEC1 timing. So if the OEM remote is that accurate (and they usually aren't), then it may have a pretty selective receiver. John, any thoughts?

Jon & John,

Thanks for all your effort to help a newbie like me. Unfortunately the CCF that you emailed, to me did not work either.

I have a JP1 capable remote, one of the OFA remotes. I don't have a JP1 cable yet, so I think the next step is for me to aquire one, and then take on the task of learning how to work in the JP1 world.

Thanks again. When you started talking about the timings and all that, it is almost getting too technical for me, but thanks to you guys, I think I can at least learn something new, even if the ultimate result is going to be that discretes are simply not supportedin the Momitsu v880.

Regards,

K.

What model OFA remote do you have, lets make sure it supports learning although we could load a device upgrade and then test all 256 commands with it, but it wouldn't help resolve the puzzle with the MX.

I know John Fine did figure out that there was a bug in the RTI Theater Touch remote's editor in it's Pronto hex conversion program that wouldn't allow a final gap of greater than 65,536 uS because they had used 16-bits to represent that value or something like that.