JP1 Remotes

[The Robman]

Just as background, the regular NEC executor is way more complicated than what you need for this, because it supports many different variations of NEC. So I have created a really simple NEC1 executor for you. I don't know how to use RMPB, so I created it using the original PB (Protocol Builder). I then created an upgrade using KM and converted that into an RMDU file. I then added that to your RMIR file. I've put all of these files into a zip in the file below.

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26769

You can now edit this protocol to tweak any of the timings to make it work for your Ruark device.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[rh100605]

[The Robman]

I am saying that I have created a simple executor that does NEC1 signals, and you should be able to edit this executor. I don't know enough about RMPB to know if it will make any un-wanted edits to the code like it did for you last time. If you find that it does, use PB instead.

Personally, I have never worked from a datasheet, I've always used the learned signals as my driver, but you can do whichever way works for you.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[mathdon]

[The Robman]

What about the various combo executors? Those often send a different number of bytes compared to the number of bytes passed into the executor.

But I agree, the vast majority of users will not have any need to edit executors.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[mathdon]

[The Robman]

The 005A executor is probably UEI's oldest executor and it supports several different variants of NEC. I imagine that it's a "group effort" if you know what I mean, with several different people contributing, and you know how that goes.

One thing that I don't understand why they did it this way is this: as you know, the first byte is a control byte that dictates which version of NEC is to be used, but they use different codes for the versions where the 2nd fixed byte is the complement, to the versions where it isn't. Why not just treat them all as 2 different fixed bytes and calculate the complement when you create the fixed data? It seems like a waste of code to me, but what do I know.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[pej]

Thank you for looking at this odd fault.

Learned signals appear to have excellent timing - no problem there.

But once the values go into the device upgrade editor, it is only then the whole binary sequence gets clocked out a bit more quickly than the learned signals. Some fussy devices don't seem to like the early repeat pulses which should occur at 108 ms. But many NEC1 devices don't mind the repeat pulses coming in a little early.

I can only guess there might be two separate NEC1 algorithms here one for learned signals and another for device upgrade.

I have found by customising NEC1 using RMPB (once you figure how to get it working), I can get the timing very close to the original remote. I might have thought the answer would have been to slow the NEC1 binary down that is used by the device upgrade editor. Learned signals are perfect.

For your interest I post my full working solution here for Ruark R2:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26773

Hopefully you can see exactly what I have done to NEC1 timing under the device upgrade.

Many thanks again and hope it helps.

[The Robman]

Congrats on getting it working, but it looks like you edited the full 005a executor to do it, which has way more code in it than you need. Any reason you didn't try using the minimal executor that I created for you?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[pej]

Robman
I modified the full 005A executor to fix the problem on the 2 Jul 2023. That was before this topic was raised. That's why I had not tried the minimal executor that you have very kindly just put together.

This is not my area of expertise. At the time, I thought the way forward must surely be to modify 005A - the protocol that should have worked. Eventually I figured something odd was happening with the RMPB assembler (which I am grateful to mathdon looking into). When I figured the way around the assembler, the rest was easy to add 1.03% to ALL the timings. But I wondered why I was having to do this.

I was not going to bother any of you with this, but was persuaded otherwise - Remote Master is excellent software and I am lucky to use it. So why not contribute?

1. The original 005A executor works perfectly the newer R2i Ruark.
2. The original 005A executor only partially worked older R2 Ruark - repeat/push and hold function not working.
3. But an original Ruark remote works BOTH R2 and R2i sets perfectly.
4. My modified 005A executor, which you have now seen, worked perfectly BOTH R2 and R2i. Great - fixed.

Today I have downloaded your RMIR file to a URC1240 remote.

I confirm your RMIR file does indeed work both sets R2 and R2i perfectly. I did not know you could use manual settings for the protocol.

Next, I looked at the binary of three remotes on a storage oscilloscope:

1. Original Ruark remote repeat pulse occurs at 108.1 ms.
2. Your RMIR solution on URC1240 - repeat occurs at 108.2 ms
3. My modified 005A - repeat occurs at 108.025 ms.

The overall binary sequence waveforms on all of the above looks very close to the original. We have full working solutions for the Ruark R2. I don't know what will happen with 005A - whether it will be modified or left. 005A just might be more complicated than it looks to modify. Hoping you have found this useful with thanks to all.

[The Robman]

We won't change the 005A for everybody based on your experience with the Ruark because this executor is built into every JP1 remote and this is the first case that we've heard of where the device is so picky about the timings. So, bottom line, there's no need to force everyone to use a protocol upgrade.

Bottom line, most devices are built to be quite flexible on the timings of the remote signals because various factors, especially batteries, can result in the timings being a bit off.

Did you modify my executor? I ask because, I just took the standard 005A executor and stripped out all the excess, I didn't mess with the timings. Perhaps the copy that I started with was slightly different that the version in your remote, not sure.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[pej]

Understood. 005A will remain unchanged for the reasons given.

I have not modified your 01FF executor to the best of my knowledge. That surely defeats the object. But this is interesting:
Taking the Lead out Off time:
Standard 005A is showing as 107960us.
Your 01FF is showing 109050us
My modified 005A is 108988us

Other timings are also different too.

I assumed you had modified the timings. Perhaps you are using another version. But the timings you have provided must be why it works the Ruark R2.

[3FG]

Instead of doing what I should be doing, I looked at the executors. I don't own these remotes and just used RMPB to get the timings.
Rob's cut down version shoots 37.735kHz with a total repeat time of 109.05ms, in principle.
The executor in the 1240 is typical of UEI remotes of the last 10 years or so (I think) and shoots (again in principle) 38.095kHz, and repeat time of 107.96ms.

Looks pretty similar to pej's measurements.

[The Robman]

I have a simple NEC1 executor that only handles 1 device code (it uses the dev/comp/obc/comp option) and I think I used that as a starting point for the one that I created here, so maybe that has slightly different timings. It's funny that it worked right out of the box.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

[rh100605]