Laser, DFB module: TEC reaction speed

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

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.

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.

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.

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 =^.^=

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.

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.

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.

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.

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..

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.

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

-- snip --

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

Bummer.

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

-- snip --

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

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.

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.

Indeed :-(

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

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 ;-)

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.

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

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.

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

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

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

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

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.

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.

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 :-)

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.

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.

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.

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.

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