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

Help with Atlas OCAP 1056-B01 and Pioneer receiver/DVD

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - General Forum
View previous topic :: View next topic  
Author Message
oldsports



Joined: 24 Dec 2011
Posts: 21

PostPosted: Tue Mar 10, 2015 9:01 am    Post subject: Help with Atlas OCAP 1056-B01 and Pioneer receiver/DVD Reply with quote

Hi - I need some help as I am switching from my RCA RCU810 remote to an Atlas OCAP 1056-B01 remote. The system it will control contains a Pioneer XV-HTD540 receiver/DVD player. Several years ago I used my RCU810 to learn the signals from my Pioneer remote from which I created a device upgrade file; I loaded this file into my RCU810 and it worked perfectly! I was also able to load the upgrade into a URC-6131 device I used to own. This was all done using a parallel cable and the older IR/RM applications (if that matters).

I would like the 1056-B01 remote to control the Pioneer device. I first tried to used the built-in Pioneer codes but none of them worked. I then decided to use my old device upgrade file from the RCU810 to create an upgrade file for the 1056-B01. I used RMIR (v2.03 Alpha 27c) to upload the old device upgrade file, load the 1056-B01 RDF, assign the buttons and load the new device into the 1056-B01 remote.

Although the process seemed to work, the remote does not control the Pioneer device - none of the programmed buttons work. I assume that something got lost in the translation between the old RCU810 file and the new 1056-B01 file but I am not sure where to start looking. Rather than post a bunch of data here, I thought I would bring my issue forward and then respond with any additional information folks would need to help me troubleshoot this. Thanks in advance for your help!
Back to top
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7057
Location: Florida

PostPosted: Tue Mar 10, 2015 9:58 am    Post subject: Reply with quote

Well quite right, we don't want a bunch of data here, what we do want is to see the relevant files zipped together, and then uploaded to the diagnosis section, and then post a link in this thread.

There are lots of things that could have gone wrong, from user error to software bugs. It is so much easier to diagnose the problem if we have the various files that are in use.
Back to top
View user's profile Send private message Visit poster's website
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4144

PostPosted: Tue Mar 10, 2015 10:31 am    Post subject: Reply with quote

No need to upload just yet. You need the very latest version of RM and RDFs included with it. 27c won't cut it with this remote.

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13101
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2333

PostPosted: Tue Mar 10, 2015 11:15 am    Post subject: Reply with quote

oldsports,
Confirm that Atlas remote, and not RCA, shows up in RMIR, RMIR->Device upgrade.
If not do it like this: load your old KM file into RM, now switch remote to Atlas, save as .rmdu and reload in RMIR.
If that fails to control your Pioneer, then post, for Vicky, all 3 files.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
oldsports



Joined: 24 Dec 2011
Posts: 21

PostPosted: Tue Mar 10, 2015 12:28 pm    Post subject: Reply with quote

All - thanks for the quick replies! A couple of responses:

mdavej - There was a file for the 1056-B01 JP1.3 remote in the RDF folder I was using. There wasn't one for the 1056-B03 JP2 remote (I have one of those as well) but I found an RDF file for that one in the download section. In any event, I just downloaded Alpha 28 per your suggestion and I will try it again.

ElizabethD - I can confirm that the Atlas remote shows up in RMIR. When I load the old KM file into RM, it shows the RCA remote. I switched it to the Atlas remote, made the changes to the button map and saved the result as a .rmdu file. I then uploaded that file into my remote. Unfortunately, it will not control the Pioneer. I am going to try it again with Alpha 28 as per mdavej's suggestion. If that does not work, I will post the files for Vicky.
Back to top
View user's profile Send private message
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4144

PostPosted: Tue Mar 10, 2015 1:15 pm    Post subject: Reply with quote

oldsports.

Don't use the RDF you found in the download section. The newest one is in the alpha 28 package and handles both B02 and B03.

I mistakenly thought you were having issues with the B03, not the B01. Older RM should have worked. So go ahead and upload your files since alpha 28 won't fix this.
Back to top
View user's profile Send private message
oldsports



Joined: 24 Dec 2011
Posts: 21

PostPosted: Tue Mar 10, 2015 7:45 pm    Post subject: Reply with quote

I tried again using Alpha 28 with no success. I posted 3 files; here is a link to them: http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13239

The folder contains the original device file that I made for my RCA remote, the device file that I made for my Atlas remote using the RCA file as a base and a download from my remote after loading the new device file. Please let me know if there is anything else you need. Thanks!
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2333

PostPosted: Tue Mar 10, 2015 9:35 pm    Post subject: Reply with quote

In KM I converted your RCA file to be for Atlas. Then brought it into RM and saved as .rmdu. It matches KM data, specifically functions such as station up and down (hex 18 03 and 98 03).
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13240
Your conversions missed everything about byte 2 and ov/b2 so the 2 hex values I mentioned come out as 18 02 and 98 02.
Don't ask me why. RM just doesn't like your file. And I have no idea what to put into parameters in your file (or several of mine!!) when the titles are all different from KM.
Anyway, try the .rmdu file. It might work. I hope.

In case anyone else is reading - this device uses Pioneer MIX.

Edit:When your KM RCU file is loaded into RM, it drops the important data - I just repeated it again and again. So conversion to Atlas could not have worked for you. Sounds like some kind of a protocol issue in RM.

Edit2:Since I didn't know how to deal with some of those parameters in your RM file, my translation in KM needs work on your part - that is of functions to button assignments the way you want them in Atlas.
So open the KM file I posted, do the buttons, save and then push it into RM and save. Let's hope it works.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3283

PostPosted: Tue Mar 10, 2015 10:41 pm    Post subject: Reply with quote

The issue here is the 007E executor and the hash that both UEI and the JP1 community have made of it.
    The original 007E executor was called PioneerDVD and takes 3 bytes of fixed data
    007E:2 is called PioneerDVD, and unfortunately is also called Pioneer MIX. These two 007E:2 executors are not the same, even though they both take 4 bytes of fixed data. In fact only the RCU810, the URC-7541, and URC-7544 share the same 007E:2 executor (Pioneer DVD), while every other JP1 remote which we've labeled as 007E:2 have a different executor-- the actual Pioneer MIX.
    007E:3 is in the Slingobx chips and the 6131; 6 bytes of FD
    007D:4 is used in S3F80 remotes like the Atlas; 6 bytes of FD
    007E:5 is used in RCRP05B and newer as well as JP1.4 remotes (and in MAXQ processors); 6 bytes of FD

Actually I believe there have been 8 different 007E executors for the Samsung processors with 6 different behaviors. UEI did a lousy job of keeping the executors straight, and we mis-identified one of the 007E:2 variants. I doubt there is any way to straighten this out now. Fortunately, the confusion only affects users of the three above remotes.

BTW, it is only recently that we were able to straighten out the more recent remotes. When UEI changed to variant 5 of the executor we were slow to notice it.
Back to top
View user's profile Send private message
oldsports



Joined: 24 Dec 2011
Posts: 21

PostPosted: Wed Mar 11, 2015 2:26 pm    Post subject: Success!! Reply with quote

ElizabethD - Success!! Your file worked with just one modification. I had to put the device codes (166, 175) and OBC codes (161, 160) in the right order in the Protocol Parameters section and I was all set. Apparently turning the RCU810 device file into a 1056-B01 device file in KM before importing it into RMIR did the trick. RMIR did not import the original RCU810 file properly.

Everyone - Thanks for all of the great help!
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2333

PostPosted: Wed Mar 11, 2015 3:07 pm    Post subject: Reply with quote

Great news, oldsports.
Question to you - what did you have to change? Swap deviceOBC1 and deviceOBC2 or put 160 in the bottom row? I suspected something like that might happen because of the slightly different sequence of fixed bytes between KM and RM, but didn't know what/why/how to change. I'm glad you figured it out.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
Back to top
View user's profile Send private message
oldsports



Joined: 24 Dec 2011
Posts: 21

PostPosted: Wed Mar 11, 2015 5:06 pm    Post subject: Reply with quote

Liz - Here is how things mapped out:

KM Device1 = RM Device 0 = 166
KM OBC1 = RM devOBC1 = 161
KM OBC2 = RM devOBC2 = 160
KM Device2 = RM DevP2 = 175

I left RM devOBC3 and devOBC4 as blank which defaulted to 89 and 92 respectively.

Thanks again!
Back to top
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3283

PostPosted: Sun Apr 12, 2015 1:52 am    Post subject: Reply with quote

It's probably worth pointing out that this approach--loading a variant 3 upgrade into KM, changing the remote type to Atlas 1056 (which carries variant 4), saving the file and then importing it into RM--isn't generally applicable, only partially worked here, and depends on a bug in KM.

The reason RM doesn't fully convert the variant 3 upgrade to a variant 4 is that variant 3 has 4 bytes of fixed data while variant 4 has 6. And, the correspondence between fixed data and the possible device and/or commands are different between the two variants. KM wouldn't have "converted" either, and in fact didn't convert because KM doesn't know that an Atlas 1056 has a variant 4 executor and mistakenly thinks it has variant 3. It doesn't know about variants 4 or 5 at all. The result of the "conversion" here is a KM file which KM intends for use by a variant 3 remote but which is described as coming from an Atlas. RM knows the Atlas has a variant 4 executor, and assigns the device numbers from the fixed data on that basis. As oldsports found out, tricking RM in this way leads to scrambled device and prefix command numbers.

On the other hand, when using RM to load and convert the variant 3 upgrade, it knows that there is an incompatibility in the structure of the fixed data and "loses the data".

The KM conversion approach did succeed in retaining the double style signal data on the functions tab (good), but directly converting in RM did not (bad). I'm not sure why RM lost the double style data; it does retain it when converting to variant 5 remotes like the RCRP05B. Anyway, here's how I handle this using RM only--and this approach is applicable to many situation in which conversions across disparate executors is needed.

Open RM twice so that two instances of RM are available on the screen. Load the variant 3 upgrade into both instances. On one instance (I'll call it B) change the remote type (or in other situations, the protocol). It sometimes is necessary to click to a different tab and back to the Setup tab to force RM to refresh the labels on B's Setup tab. In B, manually enter the device and prefix command numbers, just as oldsports did. Then on A, highlight and copy the entire column of prefix device. On B, highlight the first cell in the prefix device column and paste. This will fill in the correct prefix device in instance B. Similarly, copy the prefix command from A and paste into B's prefix command column. Now B has the complete and correct upgrade. It took me longer to type these instructions than to perform them.

This two instance approach is also useful when changing an upgrade from, for example, NEC Combo to NEC 4DEV Combo.
Back to top
View user's profile Send private message
mathdon
Expert


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

PostPosted: Tue Apr 14, 2015 7:55 am    Post subject: Reply with quote

3FG wrote:
The KM conversion approach did succeed in retaining the double style signal data on the functions tab (good), but directly converting in RM did not (bad). I'm not sure why RM lost the double style data; it does retain it when converting to variant 5 remotes like the RCRP05B.

The command parameter names are the same for variants 2 and 4, so RM preserves the parameter values in the conversion. In variant 2, in a double style signal then parms[2]=1 always. In variant 4, in a double style signal then parms[2]=4 always, with values <4 used only by single style signals. In variant 5, both single and double style signals can use parms[2] < 4, double style signals can also have parms[2] = 4.

RM lost the double style signal in converting to variant 4 since the conversion left parms[2]=1. RM regarded this as an error for a double style signal and so changed it to single style, where this is a valid value. As parms[2]=1 is valid for variant 5, it left it as double style.

There is nothing wrong in the code for variant 4, but it seems from 3FG's comment of "(bad)" that it would be preferable for the conversion to variant 4 to handle the inconsistency between double style signal and parms[2]=1 by treating the parms[2] value rather than the signal style as being the error. I have therefore changed the relevant code from

Code:
            else if (execVariant == 4) {
              if (val < 4)  // 1 part signal   
                flag = (flag & 0xF8) | (val << 1); // bits 1 and 2
                else
                  if (val == 4)  // 2 part signal
                    flag |=0x01;   
            }

to
Code:
            else if (execVariant == 4) {
              if (val < 4  && !hasPrefix)  // 1 part signal   
                flag = (flag & 0xF8) | (val << 1); // bits 1 and 2
              // if hasPrefix then nothing further is encoded in flag, so ignore
              // val, though conversion of hex back to params will return val = 4

I have put this in the SVN but it doesn't seem worth posting a new jar file just for this (though shout if you want me to Smile ). As before, Dave (3FG), feel free to change it back, or make some other change, if you think it desirable.

With this change, to perform the conversion in RM from RCU810 to Atlas URC-1056, all that is needed after changing the remote in RM is to set the correct device parameters. As the names and structure of the device parameters are so different between variants 2 and 4, there is no way that software can perform that conversion and 3FG has explained why RM responds by blanking out the values.
_________________
Graham
Back to top
View user's profile Send private message
ElizabethD
Advanced Member


Joined: 09 Feb 2004
Posts: 2333

PostPosted: Tue Apr 14, 2015 10:42 pm    Post subject: Reply with quote

The complexity of this stuff is mind boggling.
Thank you 3FG for your earlier, Mar 10, 2015 10:41 pm blurb which I finally understood, and that it affects only two remotes. Ouch.
And for your later explanation plus a possible procedure we could have used. Not sure why you discussed variant 3, but that's ok, the concepts were similar.

Finally, even though none of this is mine, thank you Graham for further explanation. I've learned a lot. Lets hope it sticks in my brain. And this thread might be useful to someone else.

Great work all!
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile
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 - General Forum All times are GMT - 5 Hours
Page 1 of 1

 
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
Get Smart! the band's official homepage Rockabilly Central