IR Beacon circuit optimizations (8-7.2v unreg, 5v reg)

[Dale(294engr]]

Engineer Dale recommends for:

all beacons: add ESD protection to the Logic level MOSFET gate:
10K series + 1M parallel; optional 15V zener cathode to gate, anode gnd)

EDU controller, exclusive use with (8v charged) to 7.2V unreg battery:

wire 4 IR Beacon LEDs all in series w/15 ohms for.11Apk, or 10ohms for.2Apk
(1.34v forward Vdrop measured across each LED at .111A_avg)

benefit: fewer parts, lower pk/avg current power w/ identical operation AND
lower power = less inefficiency (less generated heat)
= longer battery life

Note if the EDU program corrupts & PWM pin stays 100%ON LEDs get vy HOT
due to the highest ON duty cycle (100% fault Vs 5% @1mS, 10% @2mS)

(1mS on *50% 40kHz duty =.5mS on, 9.5mS off @100Hz =100*.5/10 = 5%)
(2mS on*50% 40kHz duty =1mS on, 9mS off @100Hz = 100*1/10 = 10%)

OR if the MOSFET source and drain are crossed, int. Fwd biased body diode
keeps LEDs ON, ignoring gate drive input from EDU, anyone been there !

some engineering calcs:
Vfwd LED =1.34V (.11A =33 ohms @5-1.34v, my init assumption for Beacon)

Discovery:
NOTE EDU PWM connector = Unreg Battery =8V charged to 7.2V discharged
For 5V regulated use must break out Red lead and connect to DIG +5 pin !!

(2 cases: unknown if Orig design assumes 8to7.2Unreg or 5v Reg EDU use)

UnReg: Orig design I per LED=8-1.34v/33=.202Apk*4 LEDsParallel=.808Apk !
Power used = IE = .804*1.34 =1.08Wp (*2mS*.5=.1dutyCycle= .11Wavg
Power consumed as heat in resistors = I^2R = 21.54Wp * .1 = 2.2Wavg

Reg: Orig design I per LED =5v-1.34v/33=.11Apk*4 LEDsParalleled =.44Apk !!
Power used = IE = .44*1.34 =.6Wp (*2mS*.5=.1dutyCycle= .06Wavg
Power consumed as heat in resistors = I^2R = 14.5Wp * .1 =1.5Wavg

4 LEDs in series: one R justification 4 *1.34 = 5.36v > 7.2 to 8v batt supply
Ipk per LEDseries = .202A Rnew=7.2v(end.of.life)-5.36/.212A=9.1 ohms

Ipk per LEDseries = .111A Rnew=7.2v-5.36/.111A=16.6 ohms

To replace EDU contoller with Hardware Timer design:
for use w/3 AA alkalines (4.5v) or 4 NiCads/NiMH (4.8 to 5.3v)

use ICM7556 dual timer
Optional add CMOS timer, auto power off ~15 min after button press

2 series IR LED strings w/15 ohms each, strings in parallel

R_led.string.1opt =4.5-2.68v/.111A =16.4 ohms
R_led.string.2opt =4.5-2.68v/.202A = 9 ohms

R_led.string.1opt =5-2.68v/.111A =21 ohms
R_led.string.2opt =5-2.68v/.202A =11.5 ohms

(allows varying 40KHz to check 4840 sensivity to frequency)

[Kevin Watson]

Originally Posted by Dale(294engr]

Engineer Dale recommends for:

all beacons: add ESD protection to the Logic level MOSFET gate:
10K series + 1M parallel; optional 15V zener cathode to gate, anode gnd)

I think I disagree with this. The added resistance will just slow down the switching, causing the MOSFET to spend more time in its linear region. This has two side-effects: 1) More energy will be dumped into the MOSFET, which is not what you want to do. 2) the MOSFETS output slew-rate will suffer, causing loss of signal fidelity in the beacon waveforms. The zener won't help much if the gate gets hit with a 15KV shock (Human ESD model).

Originally Posted by Dale(294engr]

EDU controller, exclusive use with (8v charged) to 7.2V unreg battery:

wire 4 IR Beacon LEDs all in series w/15 ohms for.11Apk, or 10ohms for.2Apk
(1.34v forward Vdrop measured across each LED at .111A_avg)

benefit: fewer parts, lower pk/avg current power w/ identical operation AND
lower power = less inefficiency (less generated heat)
= longer battery life

Doesn't the beacon already run for a few hours on one battery? Isn't consistant infrared intensity important?

Originally Posted by Dale(294engr]

Note if the EDU program corrupts & PWM pin stays 100%ON LEDs get vy HOT
due to the highest ON duty cycle (100% fault Vs 5% @1mS, 10% @2mS)

(1mS on *50% 40kHz duty =.5mS on, 9.5mS off @100Hz =100*.5/10 = 5%)
(2mS on*50% 40kHz duty =1mS on, 9mS off @100Hz = 100*1/10 = 10%)

OR if the MOSFET source and drain are crossed, int. Fwd biased body diode
keeps LEDs ON, ignoring gate drive input from EDU, anyone been there !

This isn't a problem because the resistors are already sized for continuous operation of the LEDs

Originally Posted by Dale(294engr]

Discovery:
NOTE EDU PWM connector = Unreg Battery =8V charged to 7.2V discharged
For 5V regulated use must break out Red lead and connect to DIG +5 pin !!

No, this isn't true. While there is unregulated battery voltage on the fourth pin of the header, if a PWM cable is attached as intended, there is +5 volt regulated power on the red lead.

Originally Posted by Dale(294engr]

(2 cases: unknown if Orig design assumes 8to7.2Unreg or 5v Reg EDU use)

As all the documentation shows, the circuit is designed to operate from five volts.

With just a couple of weeks left, the last thing we need to be doing is, as my (also an engineer) wife says, "keep fixing it until it's broken".

-Kevin

[Dale(294engr]]

Hi Kevin,
1. Are you saying the logic level FET is not extra ESD sensitive ?

How then is it protected ?
(logic level gate threshold =very thin gate oxide =lower destruct V/energy)

My suggested 10K ohm in series with the gate does NOT slow down
the FET (check it out on a scope)
Series resistance isolates the gate a bit & if used aids zener effectiveness.
The 1M parallel keeps the FET gate drained, i.e. off.

A very much higher series resistor than 10k would indeed slow turn on,
but I do not suggest that.

Zener (or even a reversed diode)
presents junction protection of HiZ MOSFET unprotected gate
offering a reasonable and increased degree protection given likely frequent
handling / unplugging of EDU from plastic Beacon connector to bare gate FET.

2. Our Beacon doesn't get turned off much
so depleats 800 mAHr batteries fast.

I was not suggesting using a variable unreg source.

Just suggesting ways to better use it based on assumption it was used.
Assumption was made using measuremnet of our EDU controller
(according to your reply is miswired - thanks for enlightenment)
having unreg battery power on the red lead.

Inspection reveals that the LED current was set at the lowest
Battery voltage equal to the FRC current at 5V regulated.

But I agree varying the IR intensity is undesirable but not likely a problem.
(is FRC using the LEDs distributed to Teams or the more powerful Sony?)

3. I agree that it is of little consequence
re: LEDs getting HOT when not pulsed

Was just presenting some enlightening duty cycle data.

The DUTY cycle thus LED heating goes WAY up if the switching stops...

Our EDU occassionally drops the programming (reason UNK).

4. Thanks for pointing out the correct 4 pin wiring. We'll correct it.

5. Post purpose was to suggest some tech options to solve our
and perhaps others battery life problem.

We use two series LED Strings, two resistors, and 5V regulated.
Two series strings same Ipk = 1/2 current switched by FET.

Thanks for taking time to reply,
appologies to your wife; I didn't know it wasn't broken,
was trying to assure Beacon lives long & prosperous life

Dave et al apparently has plans for IR for some time to come.

[Kevin Watson]

Originally Posted by Dale(294engr]

Are you saying the logic level FET is not extra ESD sensitive...

For a few reasons this is a non-issue. I've seen more than a few semiconductor devices fried due to mishandling, but never have I seen a fried power MOSFET (well, due to ESD anyway ). I originally specified a different N-channel device for the low-side switch, but the folks at IFI suggested switching to this device because they're bulletproof (they have a lot of experience with this device).

Your scheme would make more sense if the beacon were in a sealed box that prevented folks from handling the circuitry. Any electrostatic discharge that happens will be to the unprotected beacon circuitry, on the gate side of the resistor, not on the completely insulated PWM cable side of the resistor. Moreover, if the MOSFET were susceptible to ESD damage, wouldn't you imagine it would be more likely damaged before it was wired into the circuit?

The mating/de-mating of the PWM cable doesn't induce any triboelectric charging because the impedances are far too low.

Originally Posted by Dale(294engr]

My suggested 10K ohm in series with the gate does NOT slow down the FET (check it out on a scope) Series resistance isolates the gate a bit & if used aids zener effectiveness. The 1M parallel keeps the FET gate drained, i.e. off. A very much higher series resistor than 10k would indeed slow turn on, but I do not suggest that.

It's an RC circuit, so it does slow it down. It's a common practice to maximize gate drive in MOSFET power switches, so it makes no sense to slow the switching down and increase complexity at the same time. The IFI controllers have ~2.2K series resistors to prevent damaging the PIC in the event the outputs get shorted. We spent a lot of time evaluating MOSFETs to ensure that this wouldn't be a problem.

The megaohm resistor doesn't help because the IFI controller has a built-in pull-up resistor that's a few orders of magnitude lower in resistance.

Originally Posted by Dale(294engr]

Our Beacon doesn't get turned off much so depleats 800 mAHr batteries fast.

How much time are you getting? Should be several hours. How 'bout using a ~7.2 volt wall-wart for power?

Originally Posted by Dale(294engr]

(is FRC using the LEDs distributed to Teams or the more powerful Sony?)

Where does it say a Sony device was used? As far as I know, all documentation says a Lumex OED-EL-1L2 device is used.

Originally Posted by Dale(294engr]

...I agree that it is of little consequence re: LEDs getting HOT when not pulsed...

...The DUTY cycle thus LED heating goes WAY up if the switching stops...

Again, the resistors are sized for continuous operation of the LEDs.

Originally Posted by Dale(294engr]

We use two series LED Strings, two resistors, and 5V regulated. Two series strings same Ipk = 1/2 current switched by FET.

This does make sense, not because it lowers current through the MOSFET, but because it lowers the power losses in the resistors. This was considered for the beacon, but I wasn't sure how consistant Vdrop across each LED would be (and didn't have any time for testing), so went with the more conservative approach.

I guess my point really is that with all of the infrared beacon & tracking documentation problems, the last thing we should be doing is to make it even harder for teams to experiment with this technology.

-Kevin