Setting Up JP1 Apps...?

[SysTech_Larry]

Remove & reapply power?
Take the batteries out and put them back in?

[HamburgerHelper1]

Take the batteries out and push/hold a button to discharge capacitor then put them back in and do reset procedure
I did 981 reset and as expected those conflicting upgrades are gone
weird thing though is that the setup codes are still set to those upgrades
so it appears maybe they were testing something?
I planned on ordering a couple more of these remotes so i will see what they bring to the table

[SysTech_Larry]

I was still having the same conflicts after the reset. Some of those files had custom codes in them. I just reloaded each in the Charter URC layout and they were all converted and accepted.

[HamburgerHelper1]

upload your RMIR of the 3660 to the diagnoses area and post a link to it here

[SysTech_Larry]

Is that the rmaster.err file, or something else?

[HamburgerHelper1]

download your 3660 then file>save as
you should save the first download of any remote you do so as that you can return it to the way it was if some of your changes screw it up

[SysTech_Larry]

I saved the original contents before I did anything else.

Where is the diagnostic area I should send it to?

[HamburgerHelper1]

Look at the top of this page you will see link to file section you will find diagnoses there

[The Robman]

My "Notepad" upgrades are working fine. I have not tampered with their auto-generated protocols.

The failures have shown up in
some Convert Learned Signals* to Upgrade and
at least three files from here,
Emerson LC320EM8A-81.rmdu ,
Digital Stream DTX9950 Liz.rmdu &
WDTV Live SMP.rmdu

The last three were easily accepted into the Charter URC. They just had conflicts with the 3660 configuration. According to the error message, they are in conflict with the previous downloaded upgrades,
Magnavox MDTR20 TV-VCR-DVD combo.rmdu &
Toshiba SD-V392SU2 DVD Player- VCR Combocc.rmdu
for having the same PID.

*not a feature on Charter URC.

Larry, given how much work Graham and others have put into RMIR to not only show you what can be done, but stopping you from doing bad stuff to your remote, please explain why you felt it necessary to bypass it and edit your files using Notepad? That's something only an expert should feel comfortable doing, and I think you would agree, based on how much help you've needed from us just to do some of the most simple things, you're not an expert?

Also, just posting the names of files that you've downloaded is absolutely useless to us, it's not like we've all downloaded every single file and know where they all are. If you want to make a reference to a file that you've downloaded, you need to post a LINK to the file, not just the name of it.

[SysTech_Larry]

I did not mean to offend.
I am a retired, certified electronic tech & programmer. I just do not know many of the particulars of your system.

The reason that I used Notepad is because the relationship between OBC & Hex are easier for me to spot when the OBC is given in hex. Your file reader only gives OBCs in decimal. (Most programmers at that level do not convert to decimal until it becomes absolutely necessary.)

Since all of those files worked fine on my Charter URC and fine when I pulled them in that format, I am guessing that the problem occurred when I read those files directly into the 3660 format.

[The Robman]

The concept of OBC is completely derived and subjective. The data that actually gets fed into the remotes is in hex format, and the concept of how to read the OBCs varies from protocol to protocol. In some cases we read the binary "as is" (ie, MSB) but in most cases we have to read the binary backwards (ie, LSB). Then there's the question of whether the author of the executor got the 1s and 0s the right way around, which is also subjective. When they got it wrong, or backwards, which is the case with most UEI executors, the hex is the complement of what it should be (eg, FF means zero). All of this is handled by RMIR so you don't need to worry about it.

You are very unusual as a user in that you want to deal with OBCs but you want them in hex format, the hex being the decimal converted to hex, rather than the hex used by the executor. In fact, I've never encountered this before, and I've been doing JP1 for 24 years.

Bottom line, if you edit the files by hand, you should expect things to break, in which cases PLEASE do not come here saying something's broke. The chances are VERY high that you broke it. Had you done it using the tool, it would almost certainly have converted anything that needed converting.

Actually, now that I think about it, when you edit an RMDU file using Notepad, the hex code that you see *IS* the hex code used by the executor, not the decimal value presented in hex, and that hex code is also displayed in RMIR. So, I'm back to not understanding what you're doing.

Given your technical background, I'm sure you understand how complicated tech things can be, and I'm sure you've encountered over enthusiastic beginners in your trade before, who tried to run, before they'd learned how to walk, and got into trouble.

So, back to the case at hand. I assume you've gathered a bunch of upgrades that you have loaded into your Charter remote. Hopefully you did all of that using the tool properly with no Notepad edits. Then, you wanted to program the 3660 to have the same upgrades. Am I right so far? Then, the ONLY way to do this is to download the memory of the 3660 using RMIR and add each of the upgrades via the Devices tab. RMIR will do LOTS of conversions in this process, which would be skipped if you tried to do it manually. For starters, do you know which processor each of your remotes uses, and are they different? I bet you don't, but RMIR knows this. Which of your upgrades requires a protocol upgrade? RMIR knows which protocols are in each remote, and which version. Let's say that you have an upgrade that uses a protocol that is not in either remote, and let's assume that both remotes have different processors, RMIR will add the version of the protocol that uses the right assembler language for your remote. If you copied a protocol that uses the Samsung S3F8 assembler into a remote that uses a Motorola processor, for example, you can probably imagine what might go wrong.

[SysTech_Larry]

Files containing my external edits are working fine. I have only reported errors where no such edits have been performed.

(I thought that you would want to know about those.)

I may be able to repeat the failure sequence, if you are interested.

[HamburgerHelper1]

Earlier on in this thread you stated
When I tried to create another device upgrade from learned keys, the opening page said, "PID in use. Alt PID not available."
What now?
Both Rob and I have asked you to upload your RMIR so that we can see what is going on
with your 3660
Would you please do that

[The Robman]

And you said you chose to edit the files in Notepad so you can see the hex codes, even though the hex codes are displayed in RMIR, so I still need some additional clarity on that one.

[SysTech_Larry]

Can we stick to the problem at hand?
The two files that I "touched up" are working fine.
The two plus files that gave the reported error were not so "touched up" and seemed worthwhile to report.

Further, the Charter URC layouts never had such a problem. And importing them seemed to solve the 3660 problem. (I have some theories about where to look, if you want me to pursue them.)

Since this is a newer release of RMIR, you should consider that possibility.