JP1 Remotes

Many thanks to member Tom Carlson for bringing the following matter to my attention. Tom recently fried the infrared LED in a JP1.3 remote during a period of extensive downloading. He thinks the burnout may have resulted from excessive activity on the infrared LED during download. He suggests members use caution and give their JP1.3 remotes a rest between successive downloads so the LEDs don't get overheated.

The infrared LEDs in a remote are most often driven by bursts of a 38KHz to 60KHz carrier frequency that results in the LEDs being turned on only half the time or less. The short on-times and low average duty cycle ensure the LEDs are not driven beyond their power rating. JP1.3 remotes are unique in that the processor I/O pin used to turn on the infrared LED driver transistor is the same I/O pin used for transmitting data in serial comm mode. So during upload or download, the infrared LED is driven uselessly by the same serial data signal the remote is sending to the PC. Users are unaware of this because there's no flashing of the red LED on the remote that normally indicates transmission. Furthermore, even if you pointed the remote at a device during this time nothing would happen because the LED is not transmitting a normal carrier burst pattern.

The amount of power that an LED dissipates during upload/download depends on the pattern of the RS232 data signal, i.e., what percentage of the time the LED is turned on, and for how long. Even though a download is all over in just a couple of seconds, that's plenty of time to overheat the tiny chip in an LED if there's too much on-time. Download is worse than upload because that's when the remote does most of the talking. Interestingly enough, the baud rate of the remote's serial comm, 38400, is about the same as a typical carrier frequency. So the serial data often looks somewhat like a burst of carrier frequency, but not always.

Each byte of serial data consists of a start bit, eight data bits, and two stop bits, for a total of 11 bits. When the line is at rest the infrared LED is off, and it is turned on during the start bit and every "0" data bit. The LED is turned off during each "1" data bit and the two stop bits. If the received character is "FF" (all "1" bits) the LED is turned on during only the first (start) bit of the 11 total bits, for a duty cycle of 9%. If the character is "00" (all "0" bits) the LED is turned on during 9 of the 11 bits, for a duty cycle of 82%. The average duty cycle for all 256 possible characters is about 46%, so portions of "real" data (not 00 or FF filler characters) during download might be expected to have that duty cycle. That also happens to be a very typical duty cycle for infrared carriers.

The download of my Atlas JP1.3, which has not been extensively programmed, consists of 5120 bytes, transmitted in about two seconds as 40 groups of 128 bytes each. The first 38 or so characters are "real" data, and the rest are all "FFs" (not counting address bytes and checksum bytes in each of the 40 groups). So the entire download includes 76mS at about 46% duty cycle, and the rest at about 10%. This is probably safe for the LEDs. What I don't know is under what conditions the remote uses "FFs" or "00s" to fill unused memory. A download of a few thousand bytes of "00" characters could be a serious problem. Excessive power dissipation in an infrared LED can deteriorate light output even if it doesn't cause catastrophic failure.

In conclusion, I don't have enough facts to evaluate the magnitude of the problem or comment on the merit of Tom's advice. One can always hope that UEI, when they designed this quirky circuit, considered all the possibilities and decided the potential for LED burnout was acceptably low. Of course, they could have based that judgment on an expectation of not downloading repeatedly in rapid succession. Tom feels very confident this is a serious problem based on when his LED failed and what it looked like after the failure. He also made several careful tests to positively confirm that there was zero light output from the LED before he replaced it.

One thing's for sure. There's absolutely nothing we can do about this in terms of modifying either the interface or the remote itself. Let this serve as a request to anyone who burns out an infrared LED in a JP1.3 remote to post a message to the forum so we can track whether others suffer the same experience that Tom did.

Tommy

Additional info:
The infrared LED failure occurred on my RS 15-100 remote, which has a 6 volt power supply. I had found that Tommy's advanced JP1.x interface was not functioning with RMIR, so I ran the 'download' function repeatedly with RMIR and IR while capturing the signals on pins 2, 4, and 6 (Reset, Rx, Tx) for analysis. This required perhaps 15-20 minutes of nonstop activity.

The LED failure was probably due to exceeding its duty cycle rating, though perhaps it was just defective. It is possible that 3-volt remote LEDs are not
as susceptible to burnout, but I would still recommend caution and frequent cool-down periods to avoid having to replace the LED.

Should we change the software to pause between blocks on JP1.3 to give the IR LED a lower duty cycle?

I discussed this with Tommy Tyler, and agree with him that inserting a short delay between blocks will probably not protect the LED from damage, because a single block with data mostly as zeroes might exceed the max duty cycle for the LED. Whether the LED could withstand this depends on a lot of uncontrollable factors.

Since the time that I experienced a LED burn-out (and replaced it successfully with a LED from my junk/spare parts collection) I have been careful to wait several minutes between 'download' sessions. So far, the LED failure has not recurred. Of course, YMMV.

I would suggest a rule-of-thumb pause of five minutes between download sessions, and testing the remote after each download. In any case, users shold be aware that there is some risk involved.

If the LED does fail, it can be replaced - a job that some may not care to tackle without expert help. Note, however, that the rest of the remote's circuitry is at much less risk, so the LED failure is more of an annoyance than a complete catastrophe.

It all boils down to how much an LED heats up when subjected to high current, and that depends on the current and how long it is applied. Infrared LEDs typically rated for 100mA continuous are often specified to handle a current surge of 1A to 3A for 10uS. Repetitive pulse handling capability is sometimes shown in a graph that plots current versus pulse duration, with a series of curves for duty cycles of 0.5%, 1%, 2%, 5%, and so on up to 50%. Here is some data taken from one of these graphs for a typical infrared LED rated 100mA continuous current:

For a pulse width of 10uS and a 5% duty cycle (that means 10uS on, 190uS off) the pulse current can be 1.2A. But change that to a 50% duty cycle (10uS on, 10uS off) and the pulse current can be only 200mA. To put that into perspective, consider that in a Sony carrier signal, the LED is turned on for about 8uS every 25uS. At the other extreme, for a pulse width of 100mS and a 5% duty cycle, the allowable current pulse is only 250mA. Change that to 50% duty cycle and the allowable current drops to 140mA. The most revealing fact is the average current allowed for various pulse widths. For example, for 10uS pulses at 5% duty cycle, the average current is 1.2A/20 = 60mA. For 100mS pulses at 5% duty cycle, the average current is 250mA/20 = 13mA.

So you can see what's going on here. When the on and off times are relatively short, the LED may reach an equilibrium temperature below its maximum allowable junction temperature, where it cools off between pulses as much as it heats up during pulses. But as you extend the on-time pulse width, it is in danger of heating up too much before it gets a chance to cool off.

The trouble with evaluating the problem of transmitting a series of "00" bytes is (1) determining the LED current when turned on, and (2) determining the allowable duty cycle at that current. I've often credited UEI as experts in applying LEDs, but sometimes I wonder. I've got a Comcast URC-1167BG3 that drives its two LEDs in parallel via a 2.2 ohm current limiting resistor, and a Comcast URC-1067BG0 that drives its two LEDs in parallel via a 4.7 ohm current limiting resistor. Both are 3-volt remotes, so the LEDs in one are being driven twice as hard as in the other. Why?

During download, a data block lasts 38mS, with a 10mS pause between blocks. That's an 80% duty cycle. In the absence of data for duty cycles greater than 50%, one would have to treat that as continuous duty. On that basis, John's suggestion to put more delay between blocks might help if it reduced the duty cycle to 20% or less, but that would slow download speed accordingly. I think the suggestion of cool-off periods between downloads may not be the answer because the damage is all over by then. Since nobody has spoken up regarding the chances of a download consisting of a large number of "00" bytes, I suggest we declare this an un-problem until and unless we get more reports of burned out LEDs.

Wow. Dead IR LED just happened to me. Thanks to this post, I had it fixed in under 10 minutes (yes, I just happened to have some spare IR-LED's laying around).

Here's what led up to it I think:

I recently bought and added the JP1 jumper to two RS 15-100's. I sort of programmed one of them manually and have been using it for a few days while waiting on my JP1.3 serial cable to come in the mail. The cable came today. It was not immediately obvious what was pin1 on the serial cable (you need to fix that DIYGADGET), so I tried it both ways on the check interface. No joy. I then got out a schematic of the serial cable and a VOM and verified what was pin 1 on the serial cable. Hooked it up again and failed check interface. For some unknown reason I tried to "Download" even though it failed the interface check. My daughter came and got it and later said it wasn't working. But I didn't know that yet. So now I hooked it up to the second 15-100 and it passed check interface! So I took apart the first one to check the JP1 header work I did and found that the wire to pin4 was not making good contact to circuit board. Fixed that, put it back to together and now both of them passed interface check and would download, Yay! But, like my daughter told me, it wasn't working on the TV. Everything seemed to work fine, except the IR LED.

So somewhere in the checking interface or the download it failed. I don't know if it had to do with plugging in the cable backwards or the bad contact on pin4 or both. But its fixed now.

Todd K.

Yup, just happened to me too, same remote 15-100, replaced the IR LED and I'm up and running again

count me in as well. I was debugging other issues. I couldn't get cable to work using serial port on the docking station at work. When I plugged it in the LCD display had all characters light up simultaneously. Perhaps when it was doing that it put LED in continuous transmit mode. Regardless of what it was, thanks to Tom, I was able to debug it rather quickly.

Tommy Tyler wrote: One thing's for sure. There's absolutely nothing we can do about this in terms of modifying either the interface or the remote itself.
Tommy

Long time since I have been here, I'm having trouble opening an URC 11-6810 remote that is built for combat that is in need of a sticky membrane cleaned.

EDIT: I managed to open the remote, not sure how it got so dirty, I did buy is used at a flea market for a few euros so perhaps it was tea bagged in the past. Simply apply lots of force to bend the case back and the IR-LED end clip released and allowed for insertion of screwdriver, a thin pry tool got the other clips open.

However I have a sort of work around to this problem if you do have to do a repair more than once you can pre-empt it by disconnecting the IR-LED when you do programming. The easy way is not for free but it is not expensive either. After opening the remote to replace the IR-LED you connect a SPDT magnetic reed switch in series from NC-COM terminals. In future should you need to program the remote (the sensitive sort that fails often) you place a strong magnet next to the case where the reed switch is located and simply disable the IR-LED during the procedure. When the magnet is not there it will work exactly as normal.

Sometimes you can find reed relays that include such a reed switch, if they are not fully potted you may be able to remove the switch.

https://en.wikipedia.org/wiki/Reed_switch

https://www.newark.com/littelfuse/mdrr- ... dp/38X7473