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

oldsports · Post by **oldsports** » Tue Mar 10, 2015 8:01 am

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!

Post by **vickyg2003** » Tue Mar 10, 2015 8:58 am

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.

mdavej · Post by **mdavej** » Tue Mar 10, 2015 9:31 am

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 ... e_id=13101

Post by **ElizabethD** » Tue Mar 10, 2015 10:15 am

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.

oldsports · Post by **oldsports** » Tue Mar 10, 2015 11:28 am

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.

mdavej · Post by **mdavej** » Tue Mar 10, 2015 12:15 pm

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.

oldsports · Post by **oldsports** » Tue Mar 10, 2015 6:45 pm

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 ... e_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!

Post by **ElizabethD** » Tue Mar 10, 2015 8:35 pm

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 ... e_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.

3FG · Post by **3FG** » Tue Mar 10, 2015 9:41 pm

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.

oldsports · Post by **oldsports** » Wed Mar 11, 2015 1:26 pm

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!

Post by **ElizabethD** » Wed Mar 11, 2015 2:07 pm

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.

oldsports · Post by **oldsports** » Wed Mar 11, 2015 4:06 pm

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!

3FG · Post by **3FG** » Sun Apr 12, 2015 12:52 am

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.

Post by **mathdon** » Tue Apr 14, 2015 6:55 am

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: Select all

            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: Select all

            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

). 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.

Post by **ElizabethD** » Tue Apr 14, 2015 9:42 pm

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!