Troubleshooting: Able to read, but not write ...

BRiT · Post by **BRiT** » Thu Jan 10, 2008 11:45 pm

Cable: JP1.x USB [Tommy's newest cable: HL-340 Flavor]
Remote: COX 7820 JP1.3 (30463046)
OS: Windows XP 32bit (Local Admin), Vista 32bit (Admin)
Software: IR 7.08 + IR 7.09

I bent down pin 5 to get the interface detected and read.

I am able to download/read from the remote, but unable to upload/write to the remote. When it tries to upload/write, IR produces a dialog box of "Error writing to remote" after about 1.5 - 2 seconds. The remote Cable button flashes twice shortly thereafter. The moved-keys and macro-keys do get uploaded to the remote. Device updates do not seem to make it. I've tried reading from the remote then writing back what was just read. It errors out the same way.

I am using the new RDF file located here:
http://www.hifi-remote.com/forums/dload ... le_id=5226.

The remote only uses 2 batteries. I tried using various combinations of new, used, old, really old batteries which voltage ranged as follows: 1.60, 1.55, 1.35, 1.20. I tried flipping one battery around. I tried with no batteries too.

I tried various transmission delays from 0, 250, 500, 750.

I've tried connecting directly to the PC and through a powered USB HUB.

The Testing JP1 software properly detects the remote and displays the expected information.

Any suggestions?

Thanks.

Evan_s · Post by **Evan_s** » Fri Jan 11, 2008 4:10 pm

first the battery tricks would never have worked. Those are only for the simple parallel cable which is jp1 only. Any other cable will not require these tricks.

Did you try the remote before bending the pin back? It might be a mislabeled jp1.2 remote? I don't know how that would behave tho.

Have you tried a raw download and upload with out the rdf? Wouldn't be able to do much but can narrow down the problem.

Do you have any other jp1.x remotes?

binky123 · Post by **binky123** » Fri Jan 11, 2008 5:50 pm

Your symptoms seem to indicate low voltage on the batteries. The processor has low voltage detection which resets the remote if detected LVD is detected.

BRiT · Post by **BRiT** » Fri Jan 11, 2008 10:15 pm

I tried it both with and without bending pin 5. It only worked with pin 5 bent. What voltage do the batteries have to be? Here are the voltages as measured on a digital multimeter:

1.490 and 1.495 (Set A, both came with remote, 1 month old)
1.594 and 1.586 (Set B, both brand new out of package)
1.275 and 1.267 (Set C, both rechargeable 1.2V 2600mAh)

I uploaded some scans of the printed circuit board from this remote. (PCB Scans)

I'll upload what IR downloaded from the remote soon.

BRiT · Post by **BRiT** » Fri Jan 11, 2008 10:46 pm

RAW Download from remote is located here.

binky123 · Post by **binky123** » Sat Jan 12, 2008 10:03 am

I don't see anything unusual in the raw download. The device/protocol upgrade area looks ok(but empty) and the learned area is ok(all FF's).
It's definitely a JP1.3 remote as it has the S3F80 MCU on it.

Capn Trips · Post by **Capn Trips** » Sat Jan 12, 2008 10:49 am

This RDF has not been tested nor finalized. Binky threw together this rdf based on my raw download of this remote a few weeks ago, but I am working on a different remote and have not yet gotten around to checking it. I would not be surprised if there were many button assignments, button names, and I'm sure other errors in this RDF that have not been identified and corrected.

I sure hope you saved your initial raw download so that you can re-load it.

BRiT · Post by **BRiT** » Fri Jan 18, 2008 4:09 pm

Things are getting more interesting now.

I now also have an Atlas OCAP 1056 JP1.3 remote. After performing the pin-5 bend, I am seeing the same issues. The upload seems to process for longer time before indicating the error. I am able to download from the remote but not upload to it. I'm using the RDF/MAPs from the Atlas RDF's Maps, and Images (updated 05 OCT 2007) fileset.

The system I'm trying this on is a Dual-Core Dell D820 Laptop running Windows XP.

I also noticed a thread in the Software forum IR Problems in Vista with Tommy's USB JP1 interface that indicates others having very similar issues with not being able to upload when they can download fine. I'm not sure if they're using the JP1 or JP1.X interface.

This weekend I will see if I can rebuild an ancient P3 box with Windows XP to see if that helps at all. I'll also try it on a single-core AMD Barton Vista 32bit box to see if that helps any.

BRiT · Post by **BRiT** » Sat Jan 19, 2008 12:48 am

I dragged out my ancient beater box that is a P3 500Mhz Windows XP SP2 and amazingly enough I am able to download and upload to the Atlas OCAP 1056 remote. Once I get it loaded with the needed device updates, I'll try to program the Cox 7280B JP1.3 remote.

BRiT · Post by **BRiT** » Sat Jan 19, 2008 5:41 am

On the ancient P3 500Mhz Windows XP system, I'm also able to program the Cox 7820B JP1.3 remote.

The systems I'm unable to program either remote is a Dual-Core Windows XP system, and a Single Core Windows Vista 32bit system. I'll try reinstalling the software on both of them to see if I can get it working all around.

It's damn nice to finally have some success. I uploaded codes for an Onkyo HT-SR800 (HT-R550) and a Toshiba A30. Now I can put away those extra remotes.

Between the COX 7820B and Atlas OCAP 1056 remote, I prefer the extra buttons on the Atlas. It's really nice having the F1 and F2 along with the DAY buttons, not to mention the D button!

Thanks to those who tried to help and those who created and refined this science.

Tommy Tyler · Post by **Tommy Tyler** » Sat Jan 19, 2008 11:29 am

BRiT,

Let me say at the outset that I am determined to dog this problem until the cause and solution are found, or die trying.

While testing some USB JP1X interfaces on an XP yesterday I ran into the EXACT same symptoms you described, and I also tried changing batteries with no success. As you so well stated, here are the key facts:

1. The interface passes the test program and correctly identifies the remote signature, either JP1.1 or JP1.2 (I don't have a JP1.3).

2. The interface always downloads with no problems.

3. The interface fails (about 90-95% of the time for me) to upload, and posts an "Error writing to remote" message.

4. If you open a COM utility such as HyperTerminal or Comtest, and stick a jumper wire between pins 4 and 6 of the Interface connector, it passes a loop-back test with no problem.

These facts suggest that the interface is working properly. The transmit and receive circuits and the RESET circuit are all functional, or you would not be able to download. So what is marginal about the upload that cause a write error? I don't think a low voltage reset is the answer because if the processor was reset it would not wake up remembering it was trying to write and post that error message. And I think we can rule out any contribution from RDFs or raw download data or anything remote-specific because it's happened on too many different remotes (a URC-1058 and two different URC-10820s for me as well as your COX 7820 and Atlas OCAP 1056).

If we had the slightest clue what causes IR to post that message we might be able to get to the bottom of it.

I am reluctant to add the following information because it smacks of the kind of hit-or-miss, "try anything", desperate, irrational type of trouble-shooting measures I so deplore, and may not be relevant at all.

During my tests yesterday, as you can imagine I was plugging and unplugging USB interfaces fast and furious, usually looking at Hardware Manager or Comtest to verify that the interface was recognized by Windows, and to see what virtual COM port number had been assigned. (Before going to my grave, which won't be long now, I hope to learn who or what decides the COM port number when the device enumerates. It is NOT as simple as just picking the lowest unused port number.) (Yes it is. TNT)

In my PC, the USB JP1X interfaces I've been selling usually enumerate at COM6. At one point I noticed Windows had assigned COM21. That concerned me because the Comtest utility I like to use won't recognize ports that high, and I had been told that IR only looked as high as COM19. When I looked at the Advanced Settings for COM21 under Hardware Manager, which lists all possible COM ports from COM1 to COM256, EVERY port number from 1 to 21 was shown as "(in use)"!!!

After struggling with this for a while, I went ahead and changed the COM Port Number from "21" to "6 (in use)". Windows didn't like that, and popped up a warning that said in effect "This COM name is being used by another device ... Using duplicate names can lead to [problems] ... Do you want to continue?" After clicking yes I rebooted and then COM6 was assigned each time I plugged in the interface.

Well, somewhere about there the uploads started working. Is there a connection? Was it the COM port or the reboot that made a difference? I honestly don't know. I know only that three of my interfaces started uploading OK and I've had no problems since. But I wonder how any of that can cause IR to fail trying to write to flash, while reading it flawlessly.

Tommy

gtg · Post by **gtg** » Mon Jan 21, 2008 2:59 pm

TT - You have checked "view hidden devices" in device manager in safe mode which should show you com ports that have been used at some point but are not connected at this time? You should then be able to remove them.