1. Device: Nec LCD 3000
2. Type of device: TV
3. JP1 Remote model: URC 9910
4. JP1 user? yes
5. Still have original remote? yes
6. Checked Yahoo file section? yes
7. Checked Pronto file section (at R/C)? yes
Trying to get this remote working. I learned all of the keys. IR.exe decodes them to :
Gap-496-1159-8?
Proton
Gap-496-1159-8?
I tried using the Proton protocol but the TV did not respond to the codes.
I uploaded the learned codes in the diagnostic section as NecLCD3000.ir
Below are the orginal remote buttons and where I learned them.
I appreciate any help in getting this working.
Thanks,
-Dave
power: power
mute: mute
vol up: vol up
vol down: vol down
picture mode: 1
size: 2
audio input: 3
input: 4
PIP on/off: 5
PIP input: 6
PIP change: 7
STILL on/off: 8
STILL capture: 9
display: info
menu: menu
auto set up: guide
exit: prev
up: up arrow
down: down arrow
-: left arrow
+: right arrow
set: select
Code/Protocol for NEC LCD3000
Moderator: Moderators
When you upload a file, and you want someone to look at it, you should always post a link, rather than just give the name of the file. It makes it easier for someone to help you.
-- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST)
I looked at your file at
http://www.hifi-remote.com/forums/dload ... le_id=1643
The learned signals are very clean and the Proton decodes are correct.
The frequency of the learned signals is 40.2 and the frequency of a Proton upgrade is 37.9. Some devices are picky about that size difference, so there is a small chance that is the problem. But more likely something else is wrong.
I'm using a new, unreleased, version of DecodeIr and it gives just the Proton decode, device 244 for each of your signals. It doesn't give Gap decodes for any of those signals. I think you are using a DecodeIr that is several versions older. The last released version is always at:
http://john.fine.home.comcast.net/ir/Decode_IR_DLL.zip
I don't recall making any unreleased changes that would affect these signals nor any such changes in the previous release. Sometime before that, I made changes that got rid of the spurious Gap decodes you are seeing. None of those changes should affect the Proton decodes themselves (since they are such clean learns), so I expect you are getting the same device 244 decodes with the older version of DecodeIr that I'm getting. But upgrading to the last released copy still would eliminate one factor to worry about.
Since I think you already have correct decodes, and the frequency shouldn't matter, I think there must be an error in the KM or RM upgrade you made or in the way you transferred it to IR, or the way you loaded into your remote for testing.
I hope you saved the KM (.txt file) or RM (.rmdu file) when creating the upgrade, and the IR.EXE (.ir file) just before uploading it to the remote for testing. Redo the whole test if you didn't save those files.
Please upload that .txt or .rmdu file and that .ir file (preferably combined into one .zip file) to diagnosis, and then post its URL back here.
In rarely used protocols (such as Proton) there is often some incompatibility between DecodeIr and KM that we either never noticed or forgot about. I just now took a quick look at DecodeIr and KM to see if there was an obvious problem with Proton. I don't see a problem, but we can never be sure there isn't one until some expert makes a Proton upgrade and learns that from one JP1 remote to another and decodes the result. I think it's more likely someone will spot the problem in those files I asked you to post. But if no one does, the next step will be that test to make sure we're doing Proton right, and the next step after that would be making a patched version of pid-005C that transmits at 40.2Khz.
http://www.hifi-remote.com/forums/dload ... le_id=1643
The learned signals are very clean and the Proton decodes are correct.
The frequency of the learned signals is 40.2 and the frequency of a Proton upgrade is 37.9. Some devices are picky about that size difference, so there is a small chance that is the problem. But more likely something else is wrong.
I'm using a new, unreleased, version of DecodeIr and it gives just the Proton decode, device 244 for each of your signals. It doesn't give Gap decodes for any of those signals. I think you are using a DecodeIr that is several versions older. The last released version is always at:
http://john.fine.home.comcast.net/ir/Decode_IR_DLL.zip
I don't recall making any unreleased changes that would affect these signals nor any such changes in the previous release. Sometime before that, I made changes that got rid of the spurious Gap decodes you are seeing. None of those changes should affect the Proton decodes themselves (since they are such clean learns), so I expect you are getting the same device 244 decodes with the older version of DecodeIr that I'm getting. But upgrading to the last released copy still would eliminate one factor to worry about.
Since I think you already have correct decodes, and the frequency shouldn't matter, I think there must be an error in the KM or RM upgrade you made or in the way you transferred it to IR, or the way you loaded into your remote for testing.
I hope you saved the KM (.txt file) or RM (.rmdu file) when creating the upgrade, and the IR.EXE (.ir file) just before uploading it to the remote for testing. Redo the whole test if you didn't save those files.
Please upload that .txt or .rmdu file and that .ir file (preferably combined into one .zip file) to diagnosis, and then post its URL back here.
In rarely used protocols (such as Proton) there is often some incompatibility between DecodeIr and KM that we either never noticed or forgot about. I just now took a quick look at DecodeIr and KM to see if there was an obvious problem with Proton. I don't see a problem, but we can never be sure there isn't one until some expert makes a Proton upgrade and learns that from one JP1 remote to another and decodes the result. I think it's more likely someone will spot the problem in those files I asked you to post. But if no one does, the next step will be that test to make sure we're doing Proton right, and the next step after that would be making a patched version of pid-005C that transmits at 40.2Khz.