The demise of LEDs occurs typically not due to overcurrent, so much as overheating due to the overcurrent.
Cree XLamp LEDs, as also some other high intensity LEDs (e.g. Piranha), are designed with special consideration for rapidly drawing heat away from the light-emitting semiconductor junction within the LED package. This allows for higher pulsed currents than designs with less effective heat extraction.
If the overcurrent pulse duration is short enough, and blanking duration for cooling off long enough, even the cheapest and most commonplace nameless LEDs can be driven with pretty extreme currents, well beyond specification.
The point to note is that duty cycle alone isn't enough to determine safe current limits, as even 1% duty cycle could be catastrophic if individual on-pulses are long enough to fry the LED, even before the blank pulse comes along to cool off the junction.
To determine how far an LED can be driven, experimentation up to the point of letting out the Magic Smoke on at least a few LEDs of a batch, would be the way to go.
I have successfully pulsed nameless 3 mm red 20 mA rated LEDs with as much as 100 mA, using on-pulse duration of 100 microseconds at 1% duty cycle, but there isn't really any practical reason to drive LEDs that hard, is there?
Simplest would be to include an oscillator in the LED circuit. The output from the microcontroller then turns the oscillator on and off. It doesn't matter then if the signal is shorted - it will still provide the proper duty cycle.
If your processor is driving the LED at various frequencies then that suggestion won't help.
In that case, use a one shot that can be reset. The one shot should have a time period longer than the lowest pulse rate you need to generate, but short enough not to burn out the LED. The one shot needs to be resettable so that it turns off the LED when the processor sends the signal to turn the LED off.
You can use a 555 Timer - data and example schematics all over the web. Normally a one shot will have the reset pin (pin 4) tied to VCC. You'll need to invert the signal from your microprocessor and use that to drive the reset pin. Drive the trigger (pin 2) with your microprocessor signal, and reset (pin 4) with the invers of that.
When your trigger goes low, the 555 triggers its output. When your trigger goes high, the 555 will reset its output. If you pull the input low and keep it there, the 555 will trigger its output and then reset it when the timer runs out.
The output is inverted from what you need - triggered is high, reset is low. You'll either have to invert it or use a different FET to drive your LED.
Given R is the resistor connected from pin 7 to VCC and C is the capacitor from pin 6 to ground then the pulse length in seconds is 1.1*R*C where R in in ohms and C in in Farads.
NOTE:
All of this assumes that your LED driver is an enclosed unit and won't be tested in parts. If your tester goes in and shorts the FET gate to ground, then nothing will save you except some kind of low power fuse (if there is such a beast.) If the test point is only where the microprocessor drives the LED driver, then this will work.
This schematic is more or less what I mean (R7 should be 10K:)
simulate this circuit – Schematic created using CircuitLab
Best Answer
SPO2 calculations are a "black art".
While they are based on the optical characteristics of haemoglobin at two wavelengths, there are a range of other parameters which make a simple calculation impractical.
The basic theory can be simplistically described as: At one optical "reference" wavelength, blood is about equally 'transparent' regardless of its degree of oxygenation, whereas at a second wavelength the 'transparency' varies with the degree of oxygenation in an analytically understood manner. By comparing the optical attenuation at the two wavelengths the losses due to mechanical issues can be eliminated and the loss due to change in oxygenation level can be determined.
In practice, a range of additional factors greatly complicate the system. Developers make various assumptions and derive their own proprietary methods and algorithms to cope. Your main choices are to either become another 'developer' carrying out your own investigations , or to "pickyback" on prior work by intelligent "curve fitting" of your measured optical results with the reported SpO2 levels from commercial systems when your system and theirs are measuring the same "target". I'll assume that the latter "stand on the shoulders of giants" approach will be preferred.
You say that you have referred to many papers that discussed calibration - which is an essential starting point. You now need to make your own decisions based on what others have done and applying some practical reasoning. Depending on the purpose of your device (student project or commercial product or ....) you may be able to get a 'good enough' result by simple means.
You may be able to get access to a commercial machine either on a loan basis or perhaps by persuading a local clinic or hospital to come in and "play" with one in an unused treatment room when they are not busy. All you then need is your machine, their machine , a means of measuring the output of your machine AND, importantly, a source of varyingly oxygenated blood inside a finger or whatever target you are using. The last requirement is both the hardest and easiest. The easiest method is to have a willing "target" who is able to vary SpO2 levels on demand. You or a friend/candidate/guinea pig are a good choice.
By varying my own breathing, I personally can reduce my SpO2 level to the point where a typically set monitoring alarm will sound. From memory this is often about 80% but whatever figure it is, it's not too hard by breathing slowly and retaining air as long as possible and controlling breath size to lower SpO2 to alarm level in perhaps (from memory) 20-30 seconds. Return to high levels (95% +?) is rapid when breathing normally. With a small amount of practice and "optical feedback" from a calibrated machine one can hold SpO2 at any desired level between trigger point and close to fully saturated. (Ask me how I know :-) ).
SO if you have the two machines (yours and a commercial one for comparison) you can vary the SpO2 levels easily and widely, and record data output by your machine plus recorded SpO2% from the commercial machine under various conditions. Being able to do this with several brands of commercial equipment would be even better. Doing this with different users, different fingers, varying conditions (temperature, user mild inebriation, fasting, post glucose 'spike', .... ) would allow you to see what if any difference these things make.
It is useful, fun and important to note that altitude alters the result due to the affect of absolute oxygen mass per litre of inhaled air and the body's consequent adjustment of its operating point on the haemoglobin takeup / release curve (which is the main factor affecting altitude climatization).
If you are using an Arduino or similar it would be easy to log your results - and not quite so easy to record the commercial machines SpO2 values. If it has a USB or serial output that can be logged. If not you may need to use manual keyboard input of displayed SpO2 levels.
Long ago (10-20 years) I read an utterly superb Hewlett Packard Journal with a number of related articles. It covered equipment and sensor design and decisions and more. Should be findable.
Possible use:
Hewlett Packard Journal, 1997
Volunteer Study for Sensor Calibration
A New Family of Sensors for Pulse Oximetry
Neonatal Sensor Clinical Validation
Hewlett Packard Journal, 1976
Haha wow !!!
http://www.ncbi.nlm.nih.gov/pubmed/9635666
_____________________________________________
Philips 22 pages !!! Understanding Pulse Oximetry SpO2 Concepts
Maybe
http://www.iosrjournals.org/iosr-jeee/Papers/Vol8-issue1/D0812226.pdf?id=7592