JP1 Remotes

[eferz]

Okay dokie. I got my JP1.3 remote and cable, and I thought to give this thing a whirl. Tied to setup the remote with a Sony TV, thinking it would be easy but... yeah, I don't know what I'm doing.

I polled information information from IR Scope but can't get it to match in RM. Uploaded the upgrade through RMIR the lights blink on the cable then stop, I pull out the remote and point the it at the TV push buttons and then I realize... failure. *le sigh*

I zipped up my ICT, RM, and RMIR files and uploaded it, can someone help me; purty pleeze?

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

[3FG]

As far as I can see, your IRScope data matches what you've entered into RM. Note: The EFCs and Hex data should not match--you are using (as you should) a different executor from the one IRScope/DecodeIR are assuming. Frankly, if we didn't need to maintain backwards compatibility, we'd probably remove the EFC/Hex code feature. It causes a lot of confusion.

Now, you've been reading here long enough to know that "doesn't work" isn't useful to those who are trying to help. Neither is "failure".
Please take the trouble to describe what you do see.
Blink twice at the end of the upload?
Any blinks when you press a key?
Not even when you press volume? TV volume perhaps is being reouted to dev1 via VPT., depending on what what VPT status means.
Any other device modes work?

[eferz]

[3FG]

Just shooting from the hip, with that description, I would do a 981 reset to completely clear the remote, and then download into RMIR. That should give a working remote image (the RDF file may not fully specify all of the memory locations correctly--there hasn't been much usage of this remote yet.). The add in the RMDU file(s) and upload to the remote again. Don't delete the RMIR file that you have now; we may be able to compare the raw data from it to the raw data from a working version and deduce which memory locations need to be initialized in the RDF file (if that is what the problem is.)

[mdavej]

HERE's a clean Insignia RMIR file. I haven't come across any errors in the RDF yet.

[eferz]

[3FG]

Looking at the Raw Data tab, it appears that the primary differences are at 61F and 620. Using RMIR File\New\RemoteImage leaves these two values as 00. They both should be 0F. I believe that 620 involves the 984 command that allows one to reassign keys (or something like that), and I suspect it is the one that caused your trouble.

From my point of view it is important to be able to generate a RMIR file for a given remote, even if the author doesn't have the remote available. That way more experienced folks can help out less experienced users. That's one purpose for the feature New Remote Image

The way I got this to work with the RCA RCRP05B was to add three lines to the RDF. Here are the corresponding line for the Insignia remote. I hope you'll be willing to try it to see if it fixes the behavior you saw.
StartReadOnlySettings=21 There are 20 Settings used by the Insignia. This line tells IR to not show the two new lines on the General tab. RMIR doesn't respect this setting yet, but it is still good to have it in the RDF file.
Byte1F=$01F.3.4.$0F.0
Byte20=$020.3.4.$0F.0 These two lines just make IR and RMIR fill in the low byte at 61F and 620 with 0xF.

The modified RDF
If you want to try this, copy it to your RDF folder, and be sure to rename the original RDF to e.g. 31473147.rdf.std (just add the .std to the extension.) You'll need to restart RMIR.

[eferz]

[3FG]

mdavej,
Do you think it is OK to move this modified RDF file into the "RDFs Latest Area - Versions released or awaiting approval" section? Or do we need some other testing?

xnappo,
If Dave agrees this modified RDF is OK, can you upload it to SourceForge?

[xnappo]

[mdavej]

I can't do any testing for a while, but it seems pretty low risk if it worked for eferz. So I'm fine with making it the latest. Thanks for the fix.

[xnappo]

SourceForge is updated with the new version...

xnappo