JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

Ruark R2 radio
Goto page Previous  1, 2, 3  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Protocol Decodes
View previous topic :: View next topic  
Author Message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL

                    
PostPosted: Sat Aug 05, 2023 3:40 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
rh100605



Joined: 27 Jul 2023
Posts: 8

                    
PostPosted: Sun Aug 06, 2023 6:00 am    Post subject: Reply with quote

The Robman wrote:
Thanks, this is good because it confirms that the first learn posted was just a bad learn, the signal doesn't normally look like that. And yeah, looking at this, I would totally assume this was just a normal NEC1 signal, I am surprised that your device doesn't respond to it. It will take some time to tweak the NEC1 executor because you have to tweak it, load it into a remote, learn it with another remote, and see how it came out.


We have come at this problem from 2 different directions.
1.Using learned signals to establish a protocol.
2.Using the specification for the NEC protocol from NEC

I wanted to tell RMIR exactly what was in the udp6121 datasheet page11 which I have uploaded to save you time.
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=26770

This would eliminate any quantisation errors due to learning
I was unable to do that due to the CF/C7 problem
Are you saying that my approach is wrong?
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL

                    
PostPosted: Sun Aug 06, 2023 9:24 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK

                    
PostPosted: Mon Aug 07, 2023 4:20 am    Post subject: Reply with quote

The Robman wrote:
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.

I have traced the changing of CF to C7 to an issue that I suspect is unique to the NEC protocols. I further suspect that no-one else has tried to edit these protocols. The problem is that the protocol header bytes give the number of device/command bytes as 3/1 but the PF (protocol format) bytes give it as 3/2.

The first determines the numbers when the protocol code is parsed, the second determines the numbers encoded by the protocol. The code does this because of its versatility. All NEC protocols transmit two command bytes, but in the common ones like NEC1 the second is the complement of the first, so there is need for only one argument byte. But to handle cases where the two bytes transmitted are independent, the code requires both bytes to be specified. So it converts NEC1 to use two potentially independent argument bytes but sets the second to be the complement of the first. I am not aware of any other protocol that does this, which is why I think this is a unique case.

I intend to fix this as soon as I have time to do so. In the meantime you can avoid the issue by selecting the PF Details tab before pressing Update, as I suggested earlier.
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL

                    
PostPosted: Mon Aug 07, 2023 8:20 am    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
mathdon
Expert


Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK

                    
PostPosted: Wed Aug 09, 2023 11:45 am    Post subject: Reply with quote

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

Even 005A does that, it sends the command followed by its complement, but that is not what I meant. I don't know why UEI has done this, but the 005A executor converts the single command byte into two BEFORE it parses it, so in principle it can handle the two bytes being independent, not just a byte and its complement. There are NEC protocols like this but they have a different executor. It looks like a bit of advance planning that was never used, and it is this that I think is unique.
_________________
Graham
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL

                    
PostPosted: Wed Aug 09, 2023 1:52 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
pej



Joined: 05 Aug 2023
Posts: 7

                    
PostPosted: Wed Aug 09, 2023 4:12 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL

                    
PostPosted: Wed Aug 09, 2023 4:38 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
pej



Joined: 05 Aug 2023
Posts: 7

                    
PostPosted: Thu Aug 10, 2023 2:39 pm    Post subject: Reply with quote

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.


Last edited by pej on Sat Aug 12, 2023 3:40 pm; edited 1 time in total
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL

                    
PostPosted: Thu Aug 10, 2023 3:12 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
pej



Joined: 05 Aug 2023
Posts: 7

                    
PostPosted: Thu Aug 10, 2023 3:58 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3367

                    
PostPosted: Thu Aug 10, 2023 4:25 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL

                    
PostPosted: Thu Aug 10, 2023 6:02 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message Visit poster's website
rh100605



Joined: 27 Jul 2023
Posts: 8

                    
PostPosted: Sat Aug 12, 2023 12:08 pm    Post subject: Reply with quote

mathdon wrote:
rh100605 wrote:
If I download my remote programmed using RMIR and then click devices then double click NEC1 protocol and immediately click update, then line FF05 changes from CF to C7 which breaks the protocol.

Thanks for pointing this out. It appears to be a bug in RMIR which I will look into, but in the meantime you can avoid it by clicking on the PF Details tab, without changing anything, before pressing Update as then it does not happen.

Graham
If you have time when looking at the RMPB code, could you look at the updating of fields as you change tab focus.
I enter a number in the first tab which if I do not hit enter after and then navigate to the PB tab it does not appear which I missed a few times... It remains different in the two tabs
Happy programming
Rob
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Protocol Decodes All times are GMT - 5 Hours
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control