all learned keys stored as VCR device?

[mrGreg]

hy! i learned some keys from my old remotes to my urc9960 and now want to save them as spreadsheet to get some free memory for new codes. so i connected jp1 via parallel port and started ir6. then downloaded from the remote to find out whats the protocol and so on. but when i click on the "learned signals" property page of ir, all i see are learned keys for VCR. funny that i whether have a VCR nor have learned VCR keys. just audio and tv. what's going wrong here?

the ir file: http://www.greg-bala.de/stuff/gregs9960.ir, a screenshot: http://www.greg-bala.de/stuff/irprob.jpg

[gfb107]

The keys are learned to the active device when you learn them. If you want them learned to a different device mode, you must select that device mode (using the appropriate device button) before learning.

[The Robman]

However, the mode that the remote was in is irrelevant in this case. All you need the learned signals for is to see what the protocol, device code, etc info is so you can use it to build an upgrade.

If the problem is that you don't remember what's what, then like Greg said, you need to put the remote in the right mode before you learn the next signal from a different device.

[johnsfine]

Greg and Rob, did you look at the file mrGreg posted?

I only took a quick look and it looks like an IR or RDF bug in reporting which device mode the learned signals are in. But I'm not on my usual computer, so I haven't retried with the latest IR.EXE nor have I looked at the raw hex of the learned signals.

mrGreg, I assume you learned from several different original remotes and correctly seperated them by device mode and were confused (as I am) why they all display as VCR mode.

[mrGreg]

thank you for the quick help - yes i learned the keys from different original remotes and, of course, to the right modes. means the tv remote to the tv mode and the receiver to the audio mode. but ir shows, that everything is learned to the vcr mode (take a look at the screenshot). or is that normal?

[johnsfine]

I looked at the raw data and it looks like all the learned signals are stored in the same device mode.

But I believe you didn't learn them that way, because each key appears multiple times in the list. If you relearned a key in the same device mode the remote would delete the first learn. Since it didn't, the remote thought the new learn was in a different device mode.

If it were a firmware bug in storing learned signals, I think we would have heard a lot about it by now.

If it's an IR.EXE bug, it looks like it must change the raw data rather than just misreport it. That's unlikely but possible. It sure would help if Rob and Mark would double check my investigation and analysis here.

Are those contents still in the 9960 itself? (You haven't uploaded from IR.EXE to the 9960 nor deleted the learned signals since doing that download?)

If the 9960 still has the unchanged eeprom contents, you could hide all the rdf files for 9960 then download again to IR.EXE and store in a different .ir file. Since it has no matching RDF, IR would not interpret nor modify the raw data at all, just store it. Then we could see what those signals really look like in the 9960.

Since your objective is to decode the original remotes, the wrong device mode is just a minor inconvenience. The list of learned signals is in the original sequence in which you learned them. So if you remember that sequence you don't need IR to tell you device mode.

If you don't remember the sequence of original remotes, you can use the protocol and device numbers to deduce that sequence (that way may need a little help from me or from Rob's devices.xls file.

[johnsfine]

RC5:16 is likely to be an Amp
NEC1:128.38 is likely to be a SAT (or maybe CBL) tuner.
RC5:1 is likely to be a TV
NEC1:0 could be anything, but more likely DVD player.
Pansonic:160.x is an audio device, probably a CD player.

[mrGreg]

yes you're right (are you a clairvoyant?) - i have learned the following devices:
- marantz amp (to audio mode)
- technics cd player (to audio mode, too)
- scantic tv (to tv mode)
- noname sat receiver (to tv mode and cbl mode)
- xoro dvd player (to tv mode and dvd mode)

is it possible that the error is in that i have learned from different remotes to equal modes (for example: tv-keys and sat-channel-keys to the tv mode, amp-keys and cd-keys to the audio mode)?

i have not uploaded the ir data to the remote yet but learned some new signals (the dvd player) so look at these just now downloaded files, if you could compare them:

the newest data fromt the remote: http://www.greg-bala.de/stuff/gregs9960.ir and the same data with the rdf directory hided so that it was not analyzed by ir: http://www.greg-bala.de/stuff/gregs9960withoutRDF.ir

thanks, mrGreg.

[johnsfine]

yes you're right (are you a clairvoyant?)

I've looked at a LOT of IR signals.

- marantz amp (to audio mode)
- technics cd player (to audio mode, too)

I should have typed in those guesses. I thought your RC5:16 Amp signals were most likely Marantz and your Panasonic:160 CD signals were most likely Technics.

- scantic tv (to tv mode)
- noname sat receiver (to tv mode and cbl mode)
- xoro dvd player (to tv mode and dvd mode)

But to guess those brand names, I would have needed to be clairvoyant.

is it possible that the error is in that i have learned from different remotes to equal modes (for example: tv-keys and sat-channel-keys to the tv mode, amp-keys and cd-keys to the audio mode)?

No. You did nothing wrong and your remote's firmware did nothing wrong.

I think the problem is that the format of learned signals has changed slightly and IR.EXE is mishandling them.

and the same data with the rdf directory hided so that it was not analyzed by ir:

Perfect. If I open it in a text editor, I can see the device modes stored in the raw data (in a form that doesn't match the learned format documentation we've been using). But if I open in IR.EXE it immediately changes those bytes of raw data (without any message nor hint that it's changing anything) so the device mode info is gone.

[The Robman]

Greg and Rob, did you look at the file mrGreg posted?

No, I just looked at the screen shot. I didn't have time to dig any deeper.

[mrGreg]

thank you - you really helped me. i have found out the protocols and codes so that i was able to build my spreadsheet with km. i pasted the upgrade code to ir but now i am not sure whether i should upload them to the remote or not... could i damage anything with the ir-misshandled data?

[johnsfine]

now i am not sure whether i should upload them to the remote or not... could i damage anything with the ir-misshandled data?

I think IR is just misshandling the learned signals. It is misshandling them enough that I don't think it is a good idea to upload an image to the remote that includes learned signals.

But I assume your intent is to replace all the learned signals with upgrades and KeyMoves. In that case, I think IR has a good enough understanding of your remote to get it all correct.

You also made a backup of your remote's eeprom image without an RDF file. If anything goes really wrong in IR setting up the upgrades and KeyMoves, I'm pretty sure it is easy to upload (without an RDF) the non RDF image back to the remote to restore everything.

[The Robman]

I've looked at the raw data and it appears that the format of the 2nd byte (of the raw learned data) has changed slightly.

In the standard format, the first nibble (half a byte) is the device index and the second nibble was un-used (AFAIK).

In this new format, the first nibble is hex value '2' (at least, in these examples it is) and the second nibble is the device index. I assume the first nibble serves some purpose, but I can't guess what it might be.

Unfortunately, this isn't something we can fix with a quick RDF tweek, it would require a change to IR.exe itself to accomodate this, and the author of IR spends even less time on the forums these days than I do.

[mrGreg]

yeah fine thank you both! until that i will just upload without any learned codes (that was my plan in any case =) greetings from germany, greg.