JP1 Remotes

[Mark Pierson]

The latest set of RDF's for the RS 15-2103 seem to be missing the "CD/Audio" entries in both [DeviceTypes] and [DeviceTypeAliases]. This isn't a big deal since the 2103 isn't very popular, but should be fixed anyway.

[DeviceTypes]
Cable = 1
TV = 2
VCR/DVD = 3
CD/Audio = 0

[DeviceTypeAliases]
Cable = Cable,SAT,Video Acc
TV = TV
VCR/DVD = VCR,DVD,Tape,Laserdisc,DAT,PVR
CD/Audio = CD,Home Auto,Phono,Tuner,Misc Audio,Amp
_________________
Mark

[johann83]

Also, maybe I am the only one with the problem, but I get a "bad checksum" error with my 2103 and pretty much any of the RDF's I've downloaded. The bytes of the checksum in my remote are reversed, so I usually end up modifying the RDF to include one more location as below. (For those wondering how/why this works, the checksum is an 'exclusive or' of all the bytes in the range specified. Since the one additional byte I add is FF and an XOR with FF complements or inverts the bits, the two checksum bytes come out in the "right" order. The two bytes of the checksum are always complements of each other to begin with so complementing one byte seems to reverse the two bytes.)

[Checksums]
^$000:$002..$7FE (instead of D)

And if I don't make this change, IR generates the wrong checksum on uploads and the remote will not work correctly. My 2103 is detected as the 2K version, so maybe that is a difference, I don't know. I noticed the 1K version of the RDF uses a checksum which ends at $3FC, and a value of $7FC in the 2K version would also accomplish the same thing as my change above (one less FF also results in the checksum being complemented).

Just thought I'd bring it up here since Mark pointed out the other problem with the new RDF. Has anyone else reported this problem?

[Nils_Ekberg]

I am pretty sure I messed up the devices when I was fixing the [DeviceTypeAliases] since adding the line back for CD/Audio makes RM unhappy. I will fix it. It looks like it was OK in IR321a but not in my distribution.

The checksum has not changed in the two 2103 RDF's for as far back as I can tell. I will have to check it out.
_________________
Nils
Files Section
Diagnosis File Section

[johnsfine]

I'm not absolutely sure, but I'm pretty sure 7FD is correct for a 2K 2103. I'm more certain that the right value for a 2K 2103 is $401 greater than the right value for a 1K.

Am I correct in guessing that all of your eeprom image from 3FC through 7FE is filled with FF's? I suspect the firmware is somehow confused into thinking you have a 1K eeprom and is only doing the checksum up to 3FC. If you add $400 FF's to that the result is right. If you add $401 FF's it's wrong.

The only definitive way find the checksum limit is to patch (in IR'r raw data tab) the last byte that you suspect is part of the checksum, then upload to the remote and see if it fixes the checksum accordingly.

[johnsfine]

Another possibility is that the firmware CORRECTLY detects a 1K eeprom and IR.EXE is confused about the size. Try patching a few bytes in the second half to distinctive values, upload then redownload and see whether the values in the second half stick.

[johann83]

John, I will try out your suggestions when I get home tonight and let you know. You are correct that the upper half of the image is all FF's (I don't use the remote for anything other than learning for my extended 2104)

Thanks for the ideas.

[johann83]

John, I think you were right about IR being confused about the size. I tried changing a few bytes in the second half of the image and doing an upload/download and they went back to FFs. If I remove the 2K RDF from my IR directory, everything seems to work fine with the remote and I don't get any checksum errors.

Does anyone know how IR determines whether a remote has a 1K or 2K EEPROM? It's not a big issue for me, as I just removed the duplicate RDF, but I'm kind of curious. I don't actually use the 2103 as my main remote which I guess is why I never noticed that I don't really have a 2K EEPROM.

Thanks for the tips gentlemen.
Matt