thermostat v2.0

[hartytp]

We've had some problems recently with a common commercially available temperature controller, which we've tracked down to inadequate EMI filtering in the temperature controller AFE and use of unscreened cabling in the wiring harness provided by a different vendor (the 10k NTC has a 100uA sense current so is a high-impedance node which is very prone to pickup even at 50Hz).

To solve this, I'd like to swap out these temperature control units for Thermostat, but there are two annoyances:

1. The specified temp co of the Thorlabs chip is quite high and likely to be problematic if we don't temperature stabilise Thermostat, which is a pain
2. We use a resistive heater rather than a TEC for this project. AFAICT there is no software option to make the Thorlabs chips run unipolar (AFAICT the designers didn't consider resistive heaters as an option so didn't bother to implement this in firmware). So, if any transient reduces the heater current below 0 then it will go into thermal run away.

So, I'd like to revive the discussion about replacing the Thorlabs chip with something along the lines of @cjbe's design based on a 24-bit ADC and the Maxim TEC driver IC. As a reminder, the big win from using a 24-bit sigma-delta ADC is that the sample rate is high and the ADC includes very good digital filtering (including extreme rejection of 50/60Hz signals). Combined with a basic CM/DM analog RFI filter, this provides a level of EMI rejection that is essentially impossible to achieve in the analog designs that seem to be used in almost all COTS units. Using @cjbe's prototypes of this design, we were able to achieve stabilities better than 100uK long term without issue.

As I see it, the main challenge here is software. The hardware redesign is very easy and I'd be happy to do that myself using @gkasprow's Altium library. The more involved part is writing decent software: command handler; simple PI(D?) loop; some basic features like thermal runaway detection, current limiting, anti-wind up, etc. I don't have time to do that part. @gkasprow do you have a student who might be interested in doing that? (otherwise, if anyone is potentially interested in funding M-Labs to do this then let us know!)

[gkasprow]

@hartytp I can add AD7191 to existing design. @cjbe how did you couple the PIC processor with MAX1968 CTLI input? Using PWM?

[gkasprow]

We can ask the student to port the PIC code to the TI CPU.

[hartytp]

We can ask the student to port the PIC code to the TI CPU.

Which PIC code do you mean?

[gkasprow]

https://github.com/sinara-hw/Thermostat/issues/5#issuecomment-357445261

[cjbe]

@gkasprow yes - I generate the CTLI signal from a PWM output and a two-pole reconstruction filter (10k,100n).

[gkasprow]

@hartytp I'm preparing second version of the PCB, without Wiznet module and Thorlabs modules. We will produce both versions at the time. Fitting both configurations in single design would cost too much work.

[hartytp]

@gkasprow perfect! I agree: these should be two separate designs rather than trying to fit everything on one board. The Thorlabs version gives us something we can use with minimal effort/risk of hardware bugs, the ADC version should work better in the long run but will need software development and careful hardware characterisation.

[gkasprow]

@hartytp please have a look Thermostat.PDF

[hartytp]

@gkasprow wow! Thanks for turning that around so fast!

@cjbe any thoughts? Things you'd want to change if you did this design again?

Basically that looks good to go as far as I'm concerned. Small thoughts/comments:

• Cosmetics could be improved but that's non-crucial e.g. would be nice to neaten things up a little, add a power budget, etc. (e.g. I find the fact that the signal flow is R->L on the 3v3->vcc->vref block on the adc makes things a bit hard to follow)
• @cjbe's design is a bit long in the tooth now and there are newer better ADCs around. However, based on his design notes, it seems that the ADC isn't really a limitation here. The only way I can see where the ADC comes close to being a limitation is the +-1ppm/K gain drift. The best ADCs on the market are still only a factor of two better than that, so the overall improvement is relatively small. Probably not worth the hassle of switching ADCs.
• what are the inductors on the TEC driver? Let's use ones that retain their inductance at 1.5A and pick ones that won't radiate like crazy!

[gkasprow]

I used tiny SMD shielded inductors that saturate at 3A.

[jordens]

As a humorous side remark: I've heard talks by high profile representatives of well known companies in all seriousness claiming that inductors are what's limiting miniaturization, integration, scaling, and technological progress in laser current and TEC drivers.

[hartytp]

@gkasprow what capacitors (voltage rating, case size, dielectric) are you using for IC1? That reg needs 1uF for stability, so we need to make sure we don't use a cheapo ceramic which gives far less capacitance when biassed.

[gkasprow]

You won't find 1uF NPO. I used X7R.

[hartytp]

Yes, X7R is good for this, but we need to watch the case size and voltage rating or the capacitance can be way lower than expected. Since this is required for stability, I'd probably make it a slightly higher capacitance and use a decent voltage rating and case size.

[hartytp]

Can you add an annotation that the 5k11 resistors must be 5ppm/K temp co?

(if you upload the altium files I'm happy to do this).

[hartytp]

@cjbe's design is a bit long in the tooth now and there are newer better ADCs around. However, based on his design notes, it seems that the ADC isn't really a limitation here. The only way I can see where the ADC comes close to being a limitation is the +-1ppm/K gain drift. The best ADCs on the market are still only a factor of two better than that, so the overall improvement is relatively small. Probably not worth the hassle of switching ADCs.

If we swapped the AD7191 for something like AD7172-2 then the typical gain temp co is a factor of 5 lower (0.2ppm/K typical). That eliminates the ADC from the error budget. Still, however, that only makes a factor of <2 change in the overall temp co since the 5ppm reference resistors give a 0.1mK/K temp co.

[hartytp]

@gkasprow let's tie the ADC CLKSEL high to ensure the internal clock is correctly enabled.

[hartytp]

let's connect the ADC TEMP pin to the microprocessor to allow access to the ADC's on-board temperature sensor.

[hartytp]

ADC NC should be tied to GND according to the data sheet.

[hartytp]

We're driving the ADC AVDD and DVDD from the same supply. Usually, I would expect to provide separate supplies for these (e.g. connect the DVDD to P3V3A via an independent 33R resistor with a 1uF||100nF capacitor). @cjbe I guess the reason you chose not to do that in your design is that we keep the digital interface inactive during sampling so we don't need to worry about noise on DVDD. Is that correct, or is it worth isolating?

[hartytp]

I used tiny SMD shielded inductors that saturate at 3A.

Since the MAX1968 max output current is +-3A isn't it worth using inductors that saturate at something a bit higher than 3A. We don't want to operate the converter with the inductors close to saturation do we?

[hartytp]

@gkasprow it's definitely worth adding some schottky diodes to protect the ADC inputs in case the user messes up the wiring harness and connects the TEC outputs to the thermistor input. That would put 5V across the ADC inputs, resulting in an ADC input current beyond the 10mA abs maximum rating. Just use the same diodes on Sampler (to be extra sure, we can split the 100R into 50R->diodes->50R->ADC).

[hartytp]

not that it really matters, but afaict it's more natural to connect LX2 to tec_n and LX1 to tec_p (i.e. swap the _p and _n around on the tec connectors).

[hartytp]

Is it worth having a CMC on the TEC outputs to reduce EMI (there is quite a lot of common-mode noise on those outputs)?

[hartytp]

The TEC driver recommends having a 100uF electrolytic somewhere on the supply to smooth out ripples. Worth adding one?

[hartytp]

The TEC driver recommends having a 100uF electrolytic somewhere on the supply to smooth out ripples. Worth adding one?

NB on @cjbe's design this wasn't necessary since we had an external 5V supply with a big output capacitor. However on Thermostat the 5V is sourced from an internal 5V SMPS.

[hartytp]

Okay, that's everything I can think of for this design. @gkasprow not all those suggestions need to be implemented; they're just thoughts. Do what you think is best.

One closing comment, however: this design will be fairly robust to damage from various ways the output connectors could be mis-wired. There is only one thing I can see that will kill the design: shorting the LX2 output to ground. This is because the current limit measures the current from the LX1 pin (so shorting that pin to Vcc or GND shouldn't be an issue since the current limit protects it) but it doesn't check the return current. There's no way easy way around that with this TEC driver, and I think that's fine, but seems worth mentioning...

[gkasprow]

We have to relay on 5V supply itnernal protection then.

[hartytp]

We have to relay on 5V supply itnernal protection then.

That can supply 8A, which is more than enough to trash one of the max chips.

I don't think there is any way of getting around this; mis-wiring the connector so that TEC_N, but not TEC_P, is shorted to V+ or GND will always kill this chip.

[hartytp]

@gkasprow anyway, I don't think this needs to turn into a multi-round review. Do what you think is best based on my feedback, and let me know when you're happy with the design. Once that's done I'll order a few boards from TS to play with.

[jordens]

Just a heads up: we will want a version of Thermostat with an STM32 at some point in the near future.

[hartytp]

Just a heads up: we will want a version of Thermostat with an STM32 at some point in the near future.

You mean you prefer a STM32 over the TI chip in this design? Do you want/care about the Thorlabs chip or the ADC option?

[gkasprow]

@jordens I remember discussion about CPU selection and @sbourdeauducq was against STM32 + Ethernet PHY and preferred TM4C. That's why we switched to it. We already used in Booster design STM32 chip.

[jordens]

I'd prefer a STM32 for the custom PWM solution for various reasons and IMHO the WizNet+MTD is a nice simple solution. TM4C/STM32+MTD is probably a lot of development investment that may not be worth it given the other approaches. I'm not too worried about the external classic PHY instead of an integrated one.

[hartytp]

Just a heads up: we will want a version of Thermostat with an STM32 at some point in the near future.

What's your plan firmware-wise? Write your own (open source/public?) or wait for Greg's student to post something?

I'd prefer a STM32 for the custom PWM solution for various reasons

Sounds good. Other than that, are you happy with the design discussed here?

[hartytp]

For the microprocessor here, shall we pick the one that makes most sense to use on the servo card and use the same one here?

[jordens]

Depending on funding and software state by then we might write our own firmware, probably open. But in the current projects this is not really urgent yet and it's still a while until we'd need to look into it. I'm happy with the general design but haven't had time to do a detailed schematic and layout review. Yes. using the same µC for the servo and this would be wise. We're also using the STM32 µCs with MTS/WMS modulating/demodulating servos so it's a nice fit.

[hartytp]

Good, thanks for clarifying.

Let's see how Greg's student gets on then.

[gkasprow]

My student wrote the code for TM4C for first version of Thermostat. It is based on FreeRTOS. It should be possible to move it to STM32. But the student needs to finish his engineering thesis soon. If we are going to develop firmware using students, I'd stick with TM4C because some work is already done. @jordens what is the difference in PWM implementation on TM4C and STM32? They are essentially same architecture. Is TM4C PWM so complicated?

[hartytp]

@gkasprow that's fine. TM4C is a useful stop gap until we have the firmware ready for the custom solution.

I'd still like to get the new boards ready for manufacture reasonably soon if possible while this is all still fresh in my mind.

[gkasprow]

If @jordens wants to play with it, he will have working solution to start with including PWMs.

[jordens]

As mentioned elsewhere, the STM32F4xx have flight heritage, we already have explored ADC/DAC mod/demod and servoing code for them, tweaked quite a bit out of it, they are used on the satellite platforms we are working with, there is a lot of code already existing, the rust community for them is the liveliest, and finally the students here know them and like them. No, I don't think TM4C PWM is complicated.

[gkasprow]

@hartytp protection diodes may kill the temperature stability. We have to use ones with extremely well matched reverse current or with very low leakage like BAS416

[hartytp]

hmmm let's see @gkasprow. Here is a really crude analysis (correct me if I'm wrong here):

• 3V3 across 20K ohm. Let's call it 100uA (1e-4A) sense current
• Assume standard NTC with approx -4%/K, so -4e-5/mK
• So, a 4e-9A leakage gives a 1mK error
• So to match the circuit's stability of something like 0.1mK/K we need a max leakage temperature coefficient of approx 0.4nA/K

That's easily doable with appropriate diodes. However...

The more I think about it, the more I think the diodes were a bad idea. On second thoughts (as I pointed out above) given the design of the TEC controller IC, we can never make this circuit robust to all kinds of shorts between the various pins on the connector. So, is there any point in working hard to make some combinations work if it still dies when the TEC controller is shorted to GND?

Better to keep it simple and rely on some common sense from the user not to kill it.

[gkasprow]

The diode I proposed has only 0.5pA of leakage current It will achieve 0.4nA current at roughly 100degrees.

[gkasprow]

I already added the diodes. If we discover that they ruin our temp stability, we can always remove them.

[hartytp]

Sounds good @gkasprow. Anyway, am I right in thinking that the leakage will be significantly lower when the reverse bias is only 1V or so?

Once we have the boards, we can easily make a temperature stability measurement to confirm that the performance matches our calculations. Use one channel to perform an open-loop measurement of the "temperature" of a precision 10k resistor, and use the other channel to temperature control the Thermostat board. Look at the reported "temperature" of the resistor as we change the actual temperature of Thermostat.

[gkasprow]

This is what I expect and probably leakage current won't be an issue here.

[gkasprow]

@hartytp please have a look at newest release. I also created dedicated repo for Thorlabs version. https://github.com/sinara-hw/thermostat_thorlabs

[hartytp]

@hartytp please have a look at newest release.

Great, thanks!

@jordens FWIW I'm planning to order a few of these next week, so any feedback you have before then will be gratefully received.

I also created dedicated repo for Thorlabs version. https://github.com/sinara-hw/thermostat_thorlabs

FWIW, a Git branch is probably a better way of doing that.