JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

DO JP1.3 REMOTES HAVE A PROBLEM WITH IR LED BURNOUT?

 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Hardware
View previous topic :: View next topic  
Author Message
Tommy Tyler
Expert


Joined: 21 Sep 2003
Posts: 405
Location: Denver mountains

PostPosted: Fri Mar 07, 2008 3:30 pm    Post subject: DO JP1.3 REMOTES HAVE A PROBLEM WITH IR LED BURNOUT? Reply with quote

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
Back to top
View user's profile Send private message
Thomas



Joined: 16 Feb 2008
Posts: 87

PostPosted: Wed Mar 12, 2008 7:25 am    Post subject: Reply with quote

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.
_________________
Tom Carlson
Back to top
View user's profile Send private message
johnsfine
Site Admin


Joined: 10 Aug 2003
Posts: 4766
Location: Bedford, MA

PostPosted: Wed Mar 12, 2008 7:52 am    Post subject: Reply with quote

Should we change the software to pause between blocks on JP1.3 to give the IR LED a lower duty cycle?
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Thomas



Joined: 16 Feb 2008
Posts: 87

PostPosted: Sat Mar 22, 2008 9:23 am    Post subject: Reply with quote

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.
_________________
Tom Carlson
Back to top
View user's profile Send private message
Tommy Tyler
Expert


Joined: 21 Sep 2003
Posts: 405
Location: Denver mountains

PostPosted: Mon Mar 24, 2008 12:18 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
toddk63



Joined: 17 Apr 2006
Posts: 8

PostPosted: Wed Jan 12, 2011 9:30 pm    Post subject: RS 15-100 Dead IR-LED Reply with quote

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.
Back to top
View user's profile Send private message
dmoos



Joined: 04 Sep 2007
Posts: 17
Location: Denver Co

PostPosted: Tue Mar 24, 2015 5:45 pm    Post subject: DO JP1.3 REMOTES HAVE A PROBLEM WITH IR LED BURNOUT? Reply with quote

Yup, just happened to me too, same remote 15-100, replaced the IR LED and I'm up and running again
Back to top
View user's profile Send private message Send e-mail
tpaxadpom



Joined: 19 Sep 2007
Posts: 64

PostPosted: Thu Dec 01, 2016 4:52 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Hardware All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


 

Powered by phpBB © 2001, 2005 phpBB Group
Get Smart! the band's official homepage Rockabilly Central