Laser, DFB module: TEC reaction speed

[Joerg]

Hello Folks,

We need to lock onto one side of a sharp but moving resonance similar to
a Fabry-Perot dip. Sharp meaning around 10pm. Long story short, when
scooting the TEC via a ADN8831 chip it's tough to achieve regulation
without overshoot. IOW tuning the PID loop is a bear and the locking
mechanism overshoots the target which shall not happen in this case.
It's a DFB module (JDS and one from Sumitomo).

What is the fastest TEC tuning speed that the laser expert here have
achieved with those modules without "ringing"?

Of course it's possible to move 10C in a couple of seconds but when
checking how professional equipment such as the ILX Lightwave controller
is the lab does that it overshoots by a lot more than 1C and takes
several seconds to stabilize. They seem to really be stepping on it for
the derivative part which is ok in telco apps where you usually set the
wavelength once and then leave it there. In our case we must remain
agile. The total range we need is around 10C (hopefully...). A wee
overshoot of 0.1-0.2C would be ok but when tuning the PID loop towards
that goal the whole thing becomes like molasses.

 

[John Larkin]

Hello Folks,

We need to lock onto one side of a sharp but moving resonance similar to
a Fabry-Perot dip. Sharp meaning around 10pm. Long story short, when
scooting the TEC via a ADN8831 chip it's tough to achieve regulation
without overshoot. IOW tuning the PID loop is a bear and the locking
mechanism overshoots the target which shall not happen in this case.
It's a DFB module (JDS and one from Sumitomo).

What is the fastest TEC tuning speed that the laser expert here have
achieved with those modules without "ringing"?

Of course it's possible to move 10C in a couple of seconds but when
checking how professional equipment such as the ILX Lightwave controller
is the lab does that it overshoots by a lot more than 1C and takes
several seconds to stabilize. They seem to really be stepping on it for
the derivative part which is ok in telco apps where you usually set the
wavelength once and then leave it there. In our case we must remain
agile. The total range we need is around 10C (hopefully...). A wee
overshoot of 0.1-0.2C would be ok but when tuning the PID loop towards
that goal the whole thing becomes like molasses.

Are you using temperature to tune/track wavelength? Nasty!

Considered feedforward? The transient response of wavelength to a step
in tec current has some complex transfer function, likely with lots of
parallel and series tau's and diffusion effects. If you can measure
that, and compute the inverse transfer function, that could be a
feed-beside term in the control loop, or just a black box in the
setpoint path.

Computing the inverse transfer function is the deconvolution process,
formally a member of the class of "ill-posed problems." You could get
lost in the math for months.

If you could measure the wavelength-v-current response, you could
probably make a decent Spice model of that using r's and c's,
something thet ad-hoc behaves close. Then you could sim the loop and
manually futz a feed-forward network into it and tweak by instinct.
I'd try a fast loop that overshoots, and correct it with a tweak
network. Or just build in a tweakable box (several tau's with
adjustable tau and amplitude) and tweak the actual system.

I've had similar problems with precision current shunts. Eddy-current
effects mess up transient response, and they are diffusive, like
thermal effects usually are. Three or four RCs worth of tweaked
feedforward can improve transient settling by 10:1 easily.

But how can you accurately measure laser wavelength vs time? Are there
spectrometers with fast realtime output?

I'm meditating on a similar, likely nastier problem: how to tweak out
the crosstalk on the edges of four nearby logic levels, each a
precision, tunable timing signal.

John

 

[Tim Wescott]

Hello Folks,

We need to lock onto one side of a sharp but moving resonance similar to
a Fabry-Perot dip. Sharp meaning around 10pm. Long story short, when
scooting the TEC via a ADN8831 chip it's tough to achieve regulation
without overshoot. IOW tuning the PID loop is a bear and the locking
mechanism overshoots the target which shall not happen in this case.
It's a DFB module (JDS and one from Sumitomo).

What is the fastest TEC tuning speed that the laser expert here have
achieved with those modules without "ringing"?

Of course it's possible to move 10C in a couple of seconds but when
checking how professional equipment such as the ILX Lightwave controller
is the lab does that it overshoots by a lot more than 1C and takes
several seconds to stabilize. They seem to really be stepping on it for
the derivative part which is ok in telco apps where you usually set the
wavelength once and then leave it there. In our case we must remain
agile. The total range we need is around 10C (hopefully...). A wee
overshoot of 0.1-0.2C would be ok but when tuning the PID loop towards
that goal the whole thing becomes like molasses.

ADI says: "The ADN8831 is a highly integrated solution for controlling
the TEC in a laser module used in optical communications systems."

So why should it work for you?

My laser expertise doesn't extend much beyond knowing to put on those
funny goggles before I defeat the interlock. But as a control guy, I
can tell you that just tuning a PID loop isn't going to get you the best
possible performance.

There are two reasons for this. First, any controller that features an
integrator is almost guaranteed to give you overshoot without the
careful application of clever feed-forward schemes or nonlinearities in
the controller. Second, while you can, in theory, achieve near-perfect
control of a second-order system using a PID with clever feed-forward,
thermal systems are, in general, continuous-state systems. So you may
not be able _at all_ to use a PID to do this, even _with_ clever
nonlinearities as well as clever feed-forward.

If this task can be accomplished with clever application of the PID
controller, the first thing you're going to have to do is to pitch that
chip. I'd suggest replacing it with the microcontroller of your choice,
so you don't have to stand on your head to implement the necessary
control rule in hardware and so you're not constrained by the hardware
when you need to change it -- but once you have a control rule in hand
you can certainly implement it with analog circuitry, should that be
your preference.

At any rate, you need a PID controller that looks just like any other
PID controller _except_ for two things. First, set the feed forward and
feedback gains separately for the proportional and differential stages,
such that

prop_term = k_pf * command - k_pb * output
diff_term = d/dt(k_df * command - k_db * output)

Second, instead of using the traditional integrator anti-windup that
just limits the state of the integrator to fixed values, use
output-based integrator limiting. This means you should choose an
output value to limit to, then adjust the integrator state to hold that
value. This is fully discussed in my book, and I'm feeling lazy today,
so I'll just refer you to pp 213 and 214, equation 8.40, and the
surrounding text (Tim Wescott, "Applied Control Theory for Embedded
Systems", Elsevier 2006). Using this sort of integrator limiting will
dramatically reduce, or completely eliminate, the overshoot from
integrator windup, at the cost of having a much slower 'tail' to the
response -- and there are things you can do about that tail.

There's a good chance that using these two techniques together will get
you close enough. Certainly they'll get you much closer than you are
now. If they don't then reflect on this:

In principal you want a controller that puts just the right input into
the plant so that the plant stops where you want and then doesn't move.
For a linear system the output of the controller will be a function of
your desired behavior* filtered by the inverse transfer function of the
plant. You can, in theory at least, generate this sort of result with a
linear discrete-state plant of arbitrary order by implementing a
controller of similar order to push it around. In practice you run into
trouble if you get too ambitious, because your plant model is rarely
kind enough to match what you think it is.

I have had some success in the past using systems that are largely feed
forward with just enough feedback to fix things up at the end of the
excursion. My results with this have been mixed, largely due to folks
not allowing enough time to fix all of the interesting 2nd- and 3rd-
order effects that pop up as soon as you address the 'main' problem. If
you really need this to work, however, and you can spare the development
time, it's a way to go.

* if you have realistic desires, which means not asking for anything
that the plant's going to filter out to any degree.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[Joerg]

Are you using temperature to tune/track wavelength? Nasty!

It's nasty but we have to tune over roughly a 1nm range. LD current only
gives you up to 100pm and that's already a stretch because the output
power sags a lot at low currents. This is a dual-loop system but the
faster LD current loop gets messed up if the overshoot exceeds its limits.

Considered feedforward? The transient response of wavelength to a step
in tec current has some complex transfer function, likely with lots of
parallel and series tau's and diffusion effects. If you can measure
that, and compute the inverse transfer function, that could be a
feed-beside term in the control loop, or just a black box in the
setpoint path.

That is what I'll probably try next week when the guys are back at the
lab. But I have to come up with something that is versatile enough to
accommodate different brand DFB modules, preferably without re-tweaking.

Computing the inverse transfer function is the deconvolution process,
formally a member of the class of "ill-posed problems." You could get
lost in the math for months.

))


If you could measure the wavelength-v-current response, you could
probably make a decent Spice model of that using r's and c's,
something thet ad-hoc behaves close. Then you could sim the loop and
manually futz a feed-forward network into it and tweak by instinct.
I'd try a fast loop that overshoots, and correct it with a tweak
network. Or just build in a tweakable box (several tau's with
adjustable tau and amplitude) and tweak the actual system.

I am quite new to the laser biz and I must say I was a bit disappointed
about the lack of data that comes with these rather expensive parts. A
simple five-cent transistor comes with half a dozen pages chock full of
S-parameter plots and whatnot. DFB modules show one page of data and
most of that is typical only without min-max guarantees. The rest is all
ordering info. I had hoped that there'd been some kind of hint as to how
the TEC reaction would be. Nope, zilch. Well, at least we didn't blow up
anything when I fired up my prototype. Whew...

With a uC as the loop controller I'd have more wiggle room here but the
client wanted an analog solution first. I still think we can get that
licked and possibly even leave it analog for production.

I've had similar problems with precision current shunts. Eddy-current
effects mess up transient response, and they are diffusive, like
thermal effects usually are. Three or four RCs worth of tweaked
feedforward can improve transient settling by 10:1 easily.

But how can you accurately measure laser wavelength vs time? Are there
spectrometers with fast realtime output?

We have an HP optical spectrum analyzer at that client's site. Nice and
heavy. I haven't yet tried how fast it could be.

I'm meditating on a similar, likely nastier problem: how to tweak out
the crosstalk on the edges of four nearby logic levels, each a
precision, tunable timing signal.

That looks like single-trace pattern recognition and FETs as controlled
resistors. Or maybe Mini-Circuits DBMs used as controlled impedances.
Or, gasp, dual-gate FETs? Haven't gone that far yet. The toughest case
was a while ago when the clocks to several ADCs had to be
precision-ganged down to the psec range. Promised Rick Lyons to write an
article about it but right now I just don't know when there'll be time
for that.

 

[colin]

Hello Folks,

We need to lock onto one side of a sharp but moving resonance similar to
a Fabry-Perot dip. Sharp meaning around 10pm. Long story short, when
scooting the TEC via a ADN8831 chip it's tough to achieve regulation
without overshoot. IOW tuning the PID loop is a bear and the locking
mechanism overshoots the target which shall not happen in this case.
It's a DFB module (JDS and one from Sumitomo).

<snip>

can you dynamically monitor the overshoot ?
If you can then determin the step response you could drive it with the
inverse to get the fastest response and settling time.

Colin =^.^=

 

[Joerg]

ADI says: "The ADN8831 is a highly integrated solution for controlling
the TEC in a laser module used in optical communications systems."

So why should it work for you?

There isn't much else available in TEC controllers. In the end all I
need from it is to do the PWM thing because a bunch of linear drivers
for the various paths would consume a lot of power. A nice feature
versus other (cheaper) PWM chips is that it has the H-bridge driver
integrated.

My laser expertise doesn't extend much beyond knowing to put on those
funny goggles before I defeat the interlock. But as a control guy, I
can tell you that just tuning a PID loop isn't going to get you the best
possible performance.

There are two reasons for this. First, any controller that features an
integrator is almost guaranteed to give you overshoot without the
careful application of clever feed-forward schemes or nonlinearities in
the controller. Second, while you can, in theory, achieve near-perfect
control of a second-order system using a PID with clever feed-forward,
thermal systems are, in general, continuous-state systems. So you may
not be able _at all_ to use a PID to do this, even _with_ clever
nonlinearities as well as clever feed-forward.

If this task can be accomplished with clever application of the PID
controller, the first thing you're going to have to do is to pitch that
chip. I'd suggest replacing it with the microcontroller of your choice,
so you don't have to stand on your head to implement the necessary
control rule in hardware and so you're not constrained by the hardware
when you need to change it -- but once you have a control rule in hand
you can certainly implement it with analog circuitry, should that be
your preference.

At any rate, you need a PID controller that looks just like any other
PID controller _except_ for two things. First, set the feed forward and
feedback gains separately for the proportional and differential stages,
such that

prop_term = k_pf * command - k_pb * output
diff_term = d/dt(k_df * command - k_db * output)

Right now I can add analog stages. A uC could be in the cards later but
we want to try to avoid it if possible. Next week I am definitely going
to try feed-forward but first I have to try my best to measure plant
behavior of that DFB module.

It did get it stable (with the ADN8831) but it was really slow. The
thermal mass in the DFB module seems to be a lot higher than what
everyone had anticipated.

Second, instead of using the traditional integrator anti-windup that
just limits the state of the integrator to fixed values, use
output-based integrator limiting. This means you should choose an
output value to limit to, then adjust the integrator state to hold that
value. This is fully discussed in my book, and I'm feeling lazy today,
so I'll just refer you to pp 213 and 214, equation 8.40, and the
surrounding text (Tim Wescott, "Applied Control Theory for Embedded
Systems", Elsevier 2006). Using this sort of integrator limiting will
dramatically reduce, or completely eliminate, the overshoot from
integrator windup, at the cost of having a much slower 'tail' to the
response -- and there are things you can do about that tail.

The integrator driving it (that one is not part of the ADN8831 circuit)
already has min-max hold values. They are selectable and it won't ever
go past these.

There's a good chance that using these two techniques together will get
you close enough. Certainly they'll get you much closer than you are
now. If they don't then reflect on this:

In principal you want a controller that puts just the right input into
the plant so that the plant stops where you want and then doesn't move.
For a linear system the output of the controller will be a function of
your desired behavior* filtered by the inverse transfer function of the
plant. You can, in theory at least, generate this sort of result with a
linear discrete-state plant of arbitrary order by implementing a
controller of similar order to push it around. In practice you run into
trouble if you get too ambitious, because your plant model is rarely
kind enough to match what you think it is.

I have had some success in the past using systems that are largely feed
forward with just enough feedback to fix things up at the end of the
excursion. My results with this have been mixed, largely due to folks
not allowing enough time to fix all of the interesting 2nd- and 3rd-
order effects that pop up as soon as you address the 'main' problem. If
you really need this to work, however, and you can spare the development
time, it's a way to go.

* if you have realistic desires, which means not asking for anything
that the plant's going to filter out to any degree.

It's not just the plant's filtering, it's also changes that happen when
all this is some day mounted inside a system with airflow. That can
really throw us a curve.

 

[Joerg]

<snip>

can you dynamically monitor the overshoot ?
If you can then determin the step response you could drive it with the
inverse to get the fastest response and settling time.

It's not that easy. When it begins to overshoot it'll keep going in that
direction for a while no matter what you do because these things have
more thermal mass than anticipated. The other limitation is the maximum
allowed TEC current. Usually around an amp or two and I don't (yet) know
what happens if that is exceeded for brief periods.

 

[Robert Baer]

It's not that easy. When it begins to overshoot it'll keep going in that
direction for a while no matter what you do because these things have
more thermal mass than anticipated. The other limitation is the maximum
allowed TEC current. Usually around an amp or two and I don't (yet) know
what happens if that is exceeded for brief periods.

They can overheat internally and thus warm up the cold side...
I once saw a "solution" that used an impulse of overcurrent that gave
cooling; the step width chosen so that the internal heating was not a
large factor; those ipulses were added to a nominal DC drive.
Presumedly that allowed an increase of cooling.
The article was seen a long time ago and what i mentioned is all i
can remember.
It would not hurt to try that; a little modelling might give some
limits: I*I*Rmodule gives input or impulse heating, thermal resistance
from internal to air for removal, and finally the thermal time constant
of the module.

Just a thought..

 

[Joerg]

They can overheat internally and thus warm up the cold side...
I once saw a "solution" that used an impulse of overcurrent that gave
cooling; the step width chosen so that the internal heating was not a
large factor; those ipulses were added to a nominal DC drive.
Presumedly that allowed an increase of cooling.
The article was seen a long time ago and what i mentioned is all i can
remember.
It would not hurt to try that; a little modelling might give some
limits: I*I*Rmodule gives input or impulse heating, thermal resistance
from internal to air for removal, and finally the thermal time constant
of the module.

Just a thought..

That is interesting. In this case I would have to have that blessed by
the DFB module manufacturer though and from experiences to date I doubt
that's going to happen.

 

[Tim Wescott]

There isn't much else available in TEC controllers. In the end all I
need from it is to do the PWM thing because a bunch of linear drivers
for the various paths would consume a lot of power. A nice feature
versus other (cheaper) PWM chips is that it has the H-bridge driver
integrated.

IOW you've tossed any compensation it offers and you're just using the
amplifier and protection stuff?
-- snip --

Right now I can add analog stages. A uC could be in the cards later but
we want to try to avoid it if possible. Next week I am definitely going
to try feed-forward but first I have to try my best to measure plant
behavior of that DFB module.

That should help substantially. Trying to progress on these difficult
problems without measurements can be futile.

It did get it stable (with the ADN8831) but it was really slow. The
thermal mass in the DFB module seems to be a lot higher than what
everyone had anticipated.
Bummer.

The integrator driving it (that one is not part of the ADN8831 circuit)
already has min-max hold values. They are selectable and it won't ever
go past these.

The performance difference is in the way that the integrator limits, not
just the fact that it limits.-- snip --

It's not just the plant's filtering, it's also changes that happen when
all this is some day mounted inside a system with airflow. That can
really throw us a curve.

But you'll know how to tune it out by that point...

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

 

[Joerg]

IOW you've tossed any compensation it offers and you're just using the
amplifier and protection stuff?

In the end most likely yes. The chip has a couple of uncommitted opamps
inside but considering that it also generates the PWM I might not be too
inclined to use them. Those "system" solutions often feel like trying to
listen to a Mozart tape in a hardrock cafe.

-- snip --



That should help substantially. Trying to progress on these difficult
problems without measurements can be futile.

Yes, except that the only way to measure the true temperature is to
measure the wavelength. The optical spectrum analyzer they've got is
fast but not that fast I think. The thermistor has a time lag which, of
course, is not mentioned anywhere in the datasheet. Just like all the
other interesting parameters that aren't mentioned. I could rig up a
concoction of etalons and photodiodes to measure at distinct spots but
the guy who is the expert for the optics side of things will be with his
folks over the holidays so that might have to wait until 2007.

Bummer.

Indeed :-(

The performance difference is in the way that the integrator limits, not
just the fact that it limits.

It's rigged so I can wegde pillows into that as needed

-- snip --

But you'll know how to tune it out by that point...

Hopefully, but we really want to achieve max auto-tune speed yet remain
conservative enough so it doesn't slip off the rocker when someone opens
the window ;-)

 

[John Larkin]

It's nasty but we have to tune over roughly a 1nm range. LD current only
gives you up to 100pm and that's already a stretch because the output
power sags a lot at low currents. This is a dual-loop system but the
faster LD current loop gets messed up if the overshoot exceeds its limits.



That is what I'll probably try next week when the guys are back at the
lab. But I have to come up with something that is versatile enough to
accommodate different brand DFB modules, preferably without re-tweaking.



I am quite new to the laser biz and I must say I was a bit disappointed
about the lack of data that comes with these rather expensive parts. A
simple five-cent transistor comes with half a dozen pages chock full of
S-parameter plots and whatnot. DFB modules show one page of data and
most of that is typical only without min-max guarantees. The rest is all
ordering info. I had hoped that there'd been some kind of hint as to how
the TEC reaction would be. Nope, zilch. Well, at least we didn't blow up
anything when I fired up my prototype. Whew...

With a uC as the loop controller I'd have more wiggle room here but the
client wanted an analog solution first. I still think we can get that
licked and possibly even leave it analog for production.

Imagine eight pots (or software equibalents), 4 tau and 4 amplitude,
with the amplitude pots possibly bipolar. If you can somehow display
the step response (ie, wavelength reaction to a square wave loop
drive) in anything like real time, you will get the hang of tuning the
pots pretty quick. Too bad it's a slow loop... that makes learning
harder.

We have an HP optical spectrum analyzer at that client's site. Nice and
heavy. I haven't yet tried how fast it could be.


That looks like single-trace pattern recognition and FETs as controlled
resistors. Or maybe Mini-Circuits DBMs used as controlled impedances.
Or, gasp, dual-gate FETs? Haven't gone that far yet. The toughest case
was a while ago when the clocks to several ADCs had to be
precision-ganged down to the psec range. Promised Rick Lyons to write an
article about it but right now I just don't know when there'll be time
for that.

The product is a digital delay generator, and I can set all the edge
timings with ps precision. The trick would be, I guess, for each
output to have a victim matrix that applies a time correction as a
function of the timings of all its neighbors. If the neighbor is far
away in time, more than a few ns, no correction is needed. Closer in,
there would be a lookup table based on delta-t between the victim edge
and each of its aggressors. Amplitudes are thankfully constant (all
TTL or equivalent) but any combination of rising/falling edges can
happen, even simultaneously, like a victim rising edge straddled by a
narrow aggressor pulse. Yuk.

Empirical tweaks like this, your laser or my delay box, are
disgusting, but a 5:1 improvement in an important spec is not to be
easily dismissed.

John

 

[[email protected]]

Hello Folks,

We need to lock onto one side of a sharp but moving resonance similar to
a Fabry-Perot dip. Sharp meaning around 10pm. Long story short, when
scooting the TEC via a ADN8831 chip it's tough to achieve regulation
without overshoot. IOW tuning the PID loop is a bear and the locking
mechanism overshoots the target which shall not happen in this case.
It's a DFB module (JDS and one from Sumitomo).

What is the fastest TEC tuning speed that the laser expert here have
achieved with those modules without "ringing"?

Of course it's possible to move 10C in a couple of seconds but when
checking how professional equipment such as the ILX Lightwave controller
is the lab does that it overshoots by a lot more than 1C and takes
several seconds to stabilize. They seem to really be stepping on it for
the derivative part which is ok in telco apps where you usually set the
wavelength once and then leave it there. In our case we must remain
agile. The total range we need is around 10C (hopefully...). A wee
overshoot of 0.1-0.2C would be ok but when tuning the PID loop towards
that goal the whole thing becomes like molasses.

This sounds a bit like an aspect of the "variable gain" problem you get
with Peltier coolers.

I've got a couple of useful documents on the subject - one referring to
the ADB8830 chip - which I could e-mail to you - send me an e-mail (to
billdotslomanatieeedot org) and I'' send you the .pdf files. It's easy
enough to fix once you know what's going on.

 

[Phil Hobbs]

Hello Folks,

We need to lock onto one side of a sharp but moving resonance similar to
a Fabry-Perot dip. Sharp meaning around 10pm. Long story short, when
scooting the TEC via a ADN8831 chip it's tough to achieve regulation
without overshoot. IOW tuning the PID loop is a bear and the locking
mechanism overshoots the target which shall not happen in this case.
It's a DFB module (JDS and one from Sumitomo).

What is the fastest TEC tuning speed that the laser expert here have
achieved with those modules without "ringing"?

Of course it's possible to move 10C in a couple of seconds but when
checking how professional equipment such as the ILX Lightwave controller
is the lab does that it overshoots by a lot more than 1C and takes
several seconds to stabilize. They seem to really be stepping on it for
the derivative part which is ok in telco apps where you usually set the
wavelength once and then leave it there. In our case we must remain
agile. The total range we need is around 10C (hopefully...). A wee
overshoot of 0.1-0.2C would be ok but when tuning the PID loop towards
that goal the whole thing becomes like molasses.

Joerg,

A big part of the problem with TECs is the (very slow) lateral thermal
conduction in the face plates. A little bit of copper helps.

The phase shift of heat flow doesn't behave like RC lowpass poles, the
way it's usually modelled--the phase shifts are really horrible.
There's a thermal control chapter that didn't make it into my book,
which talks about this (see http://www.electrooptical.net) ahd has some
illuminating plots of phase and amplitude vs frequency for heat flow.

You can get at least an order of magnitude improvement in speed by using
a very small heater mounted right at the laser can, and controlling that
instead of the TEC. Leave the TEC running more or less full blast, and
use the heater to do the work. With the high bandwidth you'll get from
the heater-controlled loop, you can use a slow compensation to reduce
the TEC current at high temperatures. That'll save power and not mess
up your loop dynamics.

Temperature sensor speed is also an issue. The smallest glass bead
thermistors are much faster than 1s themselves, but need careful
mounting--if you just imbed them in glue, they slow down dramatically.
I like to use the forward voltage of the monitor photodiode--which works
fine if you can turn off the laser every 10 ms or so during slew. The
monitor PD is brazed to the same metal header that the laser sits on, so
you can't do much better than that except by using the laser's own
forward voltage--which takes a bit of bravery since its temperature
dependence is not as accurately known as the PD's.

Cheers, and Merry Christmas,

Phil Hobbs

 

[Phil Hobbs]

Hello Folks,

We need to lock onto one side of a sharp but moving resonance similar to
a Fabry-Perot dip. Sharp meaning around 10pm. Long story short, when
scooting the TEC via a ADN8831 chip it's tough to achieve regulation
without overshoot. IOW tuning the PID loop is a bear and the locking
mechanism overshoots the target which shall not happen in this case.
It's a DFB module (JDS and one from Sumitomo).

What is the fastest TEC tuning speed that the laser expert here have
achieved with those modules without "ringing"?

Of course it's possible to move 10C in a couple of seconds but when
checking how professional equipment such as the ILX Lightwave controller
is the lab does that it overshoots by a lot more than 1C and takes
several seconds to stabilize. They seem to really be stepping on it for
the derivative part which is ok in telco apps where you usually set the
wavelength once and then leave it there. In our case we must remain
agile. The total range we need is around 10C (hopefully...). A wee
overshoot of 0.1-0.2C would be ok but when tuning the PID loop towards
that goal the whole thing becomes like molasses.

Joerg,

A big part of the problem with TECs is the (very slow) lateral thermal
conduction in the face plates. A little bit of copper helps.

The phase shift of heat flow doesn't behave like RC lowpass poles, the
way it's usually modelled--the phase shifts are really horrible.
There's a thermal control chapter that didn't make it into my book,
which talks about this (see http://www.electrooptical.net) ahd has some
illuminating plots of phase and amplitude vs frequency for heat flow.

You can get at least an order of magnitude improvement in speed by using
a very small heater mounted right at the laser can, and controlling that
instead of the TEC. Leave the TEC running more or less full blast, and
use the heater to do the work. With the high bandwidth you'll get from
the heater-controlled loop, you can use a slow compensation to reduce
the TEC current at high temperatures. That'll save power and not mess
up your loop dynamics.

Temperature sensor speed is also an issue. The smallest glass bead
thermistors are much faster than 1s themselves, but need careful
mounting--if you just imbed them in glue, they slow down dramatically.
I like to use the forward voltage of the monitor photodiode--which works
fine if you can turn off the laser every 10 ms or so during slew. The
monitor PD is brazed to the same metal header that the laser sits on, so
you can't do much better than that except by using the laser's own
forward voltage--which takes a bit of bravery since its temperature
dependence is not as accurately known as the PD's.

Cheers, and Merry Christmas,

Phil Hobbs

 

[[email protected]]

This sounds a bit like an aspect of the "variable gain" problem you get
with Peltier coolers.

I've got a couple of useful documents on the subject - one referring to
the ADB8830 chip - which I could e-mail to you - send me an e-mail (to
billdotslomanatieeedot org) and I'' send you the .pdf files. It's easy
enough to fix once you know what's going on.

Come to think of it, Linear Technology's data sheet for their LTC1923
chip tells you that closing the thermal feedback loop s tricky, and
their application note AN-89 goes into more detail.

Jim Williams hasn't include the quadratic formula relating heat
transferred through the Peltier junction to current driven through the
junction and the temperature difference across the junction, all of
which interact, such that the current-to-heat transferred "gain of the
junction is rather variable - enogh to make a system which is
critically damped at one temperature difference either over-damped or
underdamped at another.

My two papers do include the formula, and describe systems that can
remain critically damped over a range of temperatures.

 

[Joerg]

Imagine eight pots (or software equibalents), 4 tau and 4 amplitude,
with the amplitude pots possibly bipolar. If you can somehow display
the step response (ie, wavelength reaction to a square wave loop
drive) in anything like real time, you will get the hang of tuning the
pots pretty quick. Too bad it's a slow loop... that makes learning
harder.

It's nine pots by now if you don't count the safety limit settings. They
will all be replaced with DACs for the finals but sometimes I wish I had
used a uC. Then again, doing the RS232 terminal spiel would have gotten
old as well.

The product is a digital delay generator, and I can set all the edge
timings with ps precision. The trick would be, I guess, for each
output to have a victim matrix that applies a time correction as a
function of the timings of all its neighbors. If the neighbor is far
away in time, more than a few ns, no correction is needed. Closer in,
there would be a lookup table based on delta-t between the victim edge
and each of its aggressors. Amplitudes are thankfully constant (all
TTL or equivalent) but any combination of rising/falling edges can
happen, even simultaneously, like a victim rising edge straddled by a
narrow aggressor pulse. Yuk.

Empirical tweaks like this, your laser or my delay box, are
disgusting, but a 5:1 improvement in an important spec is not to be
easily dismissed.

Well, at least you can measure things easily. I always have to wait
about ten seconds until one seek-and-lock sequence is over. They do brew
a good coffee there though

 

[Joerg]

Joerg,

A big part of the problem with TECs is the (very slow) lateral thermal
conduction in the face plates. A little bit of copper helps.

The phase shift of heat flow doesn't behave like RC lowpass poles, the
way it's usually modelled--the phase shifts are really horrible. There's
a thermal control chapter that didn't make it into my book, which talks
about this (see http://www.electrooptical.net) ahd has some illuminating
plots of phase and amplitude vs frequency for heat flow.

I am going to read your site again from A-Z, plus the LTC app note that
Bill mentioned. Right now temp-controlling this DFB module feels like
driving a half-full tanker truck on an icy road where several tons of
water are sloshing around in the back.

You can get at least an order of magnitude improvement in speed by using
a very small heater mounted right at the laser can, and controlling that
instead of the TEC. Leave the TEC running more or less full blast, and
use the heater to do the work. With the high bandwidth you'll get from
the heater-controlled loop, you can use a slow compensation to reduce
the TEC current at high temperatures. That'll save power and not mess
up your loop dynamics.

Temperature sensor speed is also an issue. The smallest glass bead
thermistors are much faster than 1s themselves, but need careful
mounting--if you just imbed them in glue, they slow down dramatically. I
like to use the forward voltage of the monitor photodiode--which works
fine if you can turn off the laser every 10 ms or so during slew. The
monitor PD is brazed to the same metal header that the laser sits on, so
you can't do much better than that except by using the laser's own
forward voltage--which takes a bit of bravery since its temperature
dependence is not as accurately known as the PD's.

Maybe I should try the PD in forward bias. We are most likely not going
to need the MPD anyhow because we don't have to push the laser anywhere
close to its limit.

The problem here is that all this is embedded in a DFB module so I don't
have any chance to optimizes the Peltier or thermistor mounting method
in there. It's all in the can.

 

[Joerg]

Thank you for the offer. I just wrote you an email. FYI: This email
address shows up non-munged in the newsreader, might want to mung it a
bit to cut down on spam.

Come to think of it, Linear Technology's data sheet for their LTC1923
chip tells you that closing the thermal feedback loop s tricky, and
their application note AN-89 goes into more detail.

The concerning detail in there is that they state the time constants in
minutes and not seconds. You can achieve a swing of 10C within a couple
of seconds but at the expense of very serious overshoot and ringout.

Jim Williams hasn't include the quadratic formula relating heat
transferred through the Peltier junction to current driven through the
junction and the temperature difference across the junction, all of
which interact, such that the current-to-heat transferred "gain of the
junction is rather variable - enogh to make a system which is
critically damped at one temperature difference either over-damped or
underdamped at another.

My two papers do include the formula, and describe systems that can
remain critically damped over a range of temperatures.

We could be slow at the outset but after a minute of so we need to be
able to scoot over a few degrees as fast as possible.

How's Australia? Must be nice to enjoy summer while most of us are
loading their wood stoves every few hours.

 

[John Larkin]

I am going to read your site again from A-Z, plus the LTC app note that
Bill mentioned. Right now temp-controlling this DFB module feels like
driving a half-full tanker truck on an icy road where several tons of
water are sloshing around in the back.



Maybe I should try the PD in forward bias. We are most likely not going
to need the MPD anyhow because we don't have to push the laser anywhere
close to its limit.

The problem here is that all this is embedded in a DFB module so I don't
have any chance to optimizes the Peltier or thermistor mounting method
in there. It's all in the can.

At least bond it to a serious heat sink. The last thing you need is
another complex tau on the hot end of the tec.

John