New Inteset / Insignia / Sanyo / Nexus JP1 remote
There's a version of this remote, with different button colouring, being sold on ebay at the moment - US$13.99:
http://www.ebay.com.au/itm/281296364762 ... 1423.l2649
http://www.ebay.com.au/itm/261436650691 ... 1423.l2649
Branded 'AOC' model #67100BA1-017-R they are presumably not backlit but unlike some other ebay deals these have free international shipping to countries other than the US.
http://i.imgur.com/pwQa1j3l.jpg
http://i.imgur.com/PYECYYPl.jpg
http://www.ebay.com.au/itm/281296364762 ... 1423.l2649
http://www.ebay.com.au/itm/261436650691 ... 1423.l2649
Branded 'AOC' model #67100BA1-017-R they are presumably not backlit but unlike some other ebay deals these have free international shipping to countries other than the US.
http://i.imgur.com/pwQa1j3l.jpg
http://i.imgur.com/PYECYYPl.jpg
The Insignia NS-RC06A-11 is NOT backlit. See http://www.hifi-remote.com/forums/viewt ... 253#101253 in this thread.
Just discovered a source for backlit:
Inteset INT-422. Even comes with a sheet of button labels.
http://shop.inteset.com/multi-function- ... ing-remote
Inteset INT-422. Even comes with a sheet of button labels.
http://shop.inteset.com/multi-function- ... ing-remote
Last edited by mdavej on Wed Sep 03, 2014 7:41 pm, edited 1 time in total.
-
roadking00
- Posts: 18
- Joined: Wed Sep 03, 2014 8:05 am
- Location: Charlotte, NC Area
Just ordered one ($24.07 shipped) this will be my 1st JP1 programmable remote to get me started with this new venturemdavej wrote:Just discovered a source for backlit:Inteset INT-422. Even comes with a sheet of button labels.
http://shop.inteset.com/multi-function- ... ing-remote
Just posted RDF/Map/Image for the Inteset INT-422:
http://www.hifi-remote.com/forums/dload ... e_id=12748
http://www.hifi-remote.com/forums/dload ... e_id=12748
I am a total beginner at JP1.x.mdavej wrote:Just posted RDF/Map/Image for the Inteset INT-422:
http://www.hifi-remote.com/forums/dload ... e_id=12748
I recently bought a Inteset INT-422. I have a JP1.x cable. When I use the above RDF in IR.exe and Download From Remote, I get "Bad checksum at address $0200. Expected $06 $F9, but found $05 $FA." Based on a few google searches, I played around with the RDF and changed one of the Checksum lines from "^$200:$202..$3FF" to "^$200:$208..$3FF". That seemed to make that error message disappear but I have no idea whether that change is going to cause problems in the future. Any opinions?
One other thing - I ran the jp1xserial.exe test and I "passed." On IR.exe, the Check Interface also passes. However, on IR.exe, when I check the Driver Status, I get the following message: "The serial/parallel driver is functioning properly. Delcom USB Error: Unable to find Delcom device driver." I am assuming that because I have never used JP1 (as opposed to JP1.x), that this error message is fine - i.e., I don't need a Delcom device driver because I'm not using JP1. Just checking though.
I'm looking forward to playing around more with my new remote. I appreciate all the work that was done setting up the infrastructure, so thanks everyone.
As you have surmised, the error message about the Delcom driver is literally correct, but it isn't significant to you. I do think you would be better served to use RMIR rather than IR.exe. It's been 4 years since any features have been added to IR.exe, and development is only being done on RMIR.
The first byte of a UEI checksum is the XOR of all the bytes in the stated range. The second byte is the bitwise complement of the first. When our software downloads from the remote it calculates the checksum and compares it to the one stored in the remote. Here the read checksum and the calculated checksum are different by 1-- $06 versus $05. I expect that changing the checksum range in the RDF provides a coincidental and fragile workaround. When you upload to the remote, the checksum which will be written into memory is likely to be incorrect. Then, when the remote comes out of communication mode, it will inspect the checksum and if it doesn't match it will do a full reset.
I don't know why the downloaded data doesn't match. Are you starting from 981 reset?
The first byte of a UEI checksum is the XOR of all the bytes in the stated range. The second byte is the bitwise complement of the first. When our software downloads from the remote it calculates the checksum and compares it to the one stored in the remote. Here the read checksum and the calculated checksum are different by 1-- $06 versus $05. I expect that changing the checksum range in the RDF provides a coincidental and fragile workaround. When you upload to the remote, the checksum which will be written into memory is likely to be incorrect. Then, when the remote comes out of communication mode, it will inspect the checksum and if it doesn't match it will do a full reset.
I don't know why the downloaded data doesn't match. Are you starting from 981 reset?
Thank you for the RMIR tip, I will look into that.3FG wrote:I don't know why the downloaded data doesn't match. Are you starting from 981 reset?
I had done a factory reset of the remote but I was following the instructions in the Interset manual which was a 977 factory reset. I did the 981 reset and there were no checksum errors. Thank you.
I've played around with my Inteset INT-422 remote and have learned a lot in the process (I'm now using RMIR). I've also come to the conclusion that I would like to play around with an extender for my particular setup. I am assuming that I can't just grab an extender for a remote that looks like mine (i.e., here: http://www.hifi-remote.com/forums/dload ... cat_id=150). I would have to wait for an extender specifically made for the Inteset INT-422 (or make one myself). Is that correct?
Can you brick a remote permanently by trying to create extenders for it?
Can you brick a remote permanently by trying to create extenders for it?
-
vickyg2003
- Site Admin
- Posts: 7104
- Joined: Sat Mar 20, 2004 12:19 pm
- Location: Florida
- Contact:
Extenders are remote specific. And yes you can brick a flash based remote if you misstep when writing an extender. I bricked a couple trying to do a jp1.3 extender
The old eeprom remotes were harder to kill, although I killed a few of those when writing simple protocols where I burned out the ir emitter by going into an infinite loo .
The old eeprom remotes were harder to kill, although I killed a few of those when writing simple protocols where I burned out the ir emitter by going into an infinite loo .
Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
The Insignia, Nexus, and Sanyo are internally identical (other than the blacklight and labelling).
I expect the Intset INT-422 is also.
Can anyone verify whether it is or not?
Would be nice to be able to use the same extender for all of these.
I expect the Intset INT-422 is also.
Can anyone verify whether it is or not?
Would be nice to be able to use the same extender for all of these.
-- 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'm just a beginner but when I bring up Raw Data on RMIR for the Inteset INT-422, it shows Signature: 34943494, Processor: Samsung S3F8, Interace: JP1.3.gfb107 wrote:The Insignia, Nexus, and Sanyo are internally identical (other than the blacklight and labelling).
I expect the Intset INT-422 is also.
Can anyone verify whether it is or not?
Would be nice to be able to use the same extender for all of these.
The extender works on Signature: 31473147.
I don't know if that is enough of a difference to make the extender not compatible though.