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]

These are two modules that don't have many common things. There won't be common firmware, chipset is different.

[hartytp]

Look beautiful @gkasprow! Many thanks for doing that, another great design!

While I'd be happy to send it off to manufacture as it is now, I had a few final thoughts:

• One thing that did occur to me is that it would be nice to have a grounded "screening" connection on the screw terminals. EMI sensitivity can be a major source of error in these designs. Hopefully the digital ADC will reject most of that, but for long cables it's highly advisable to use screened twisted pair to connect the thermistor. So, it's nice to give users a convenient point to ground the screening. If there isn't room to add an extra connection to the screw terminals then don't worry. If it helps, the screening pin could be shared between the two screw terminals.
• While we don't need a detailed power budget, we do need to give the user at least a rough indication of the max power the module can draw so that they can ensure they connect it to a suitable PoE supply
• ~with the new ADC the error analysis needs tweaking. I'll do that next week once the design is finalised (I'll open a new issue)~ Edit: let's just delete the error analysis from the schematic. Once we've got the board, I'll post measured data to the Wiki. That's more useful than calculations anyway.
• obvious point, but just to sanity check: is the TEC CMC rated to the right current (won't saturate etc) and has a low enough DC resistance to avoid excessive power dissipation
• not that it really matters, but it feels like we should ground AIN4 on the ADC

[gkasprow]

CMC wont saturate up to 5A Changed connectors to 5pin ones with GND Grounded ADC AIN4

[gkasprow]

added power budget. We will fit within 20W. Continous PoE converter Pmax is 24W, 30 peak.

[hartytp]

Splendid :)

No further feedback from me then. Let's give others until end of Weds to give any further comments and then produce a batch (email Greg/Me/Wojciech if you want some).

[hartytp]

@gkasprow well, the only other comment I have is about the layout. The 24-bit ADC is packed in tightly between the microprocessor and the TEC driver, so there is quite a bit of potential for EMI issues.

I don't think there is much we can do to improve this without making the board quite a bit bigger, so let's build one and have a go. We can easily test this by using a precision 10k resistor instead of a thermistor and looking at the rms noise in the ADC measurements. We can also look at the change in measured temperature as a function of the TEC current with the device running open loop.

Anyway, hopefully this won't cause any issues, but it's worth being aware of it.

[gkasprow]

I designed it in such way to make sure the return currents don't pass via the ADC circuit. I don't thin we would get any EMI issues.

[hartytp]

Okay, good! :)

[jordens]

• It's weird to use a PWM to control a PWM. If the MAX is just there to provide V/IP/IN limiting, some PWM-to-current loop, and an H bridge, then it seems misplaced. If there was no filter and just an H bridge driver from two suitably modulated pins of the µC and I/V sensing, that would be more straight forward. And you could do really nice sigma-delta modulation to get efficient spectral shaping of the output noise compared to that MAX. It might need about the same space. If the PID loop is digital, I would really want to stay digital all the way up to the H bridge. I am not doubting that you can get good performance with this. This is just to point out that this is an irritating design mismatch. Isn't there anything from the H bridge world that does this better?
• Anti windup wont be straight forward (for the reason above). There is either wasted headroom between the actual limit and what's reported as limit or there is a dead zone where the reported limit (in the digital PID) is reached after the driver is already railed.
• Should be possible to also connect I2C on the second TEC to the CPU. I2C2 or I2C3 (when moving STAT) seem doable on quick glance.
• Please expose the UART not on individual pads but on a pin header.

[hartytp]

It's weird to use a PWM to control a PWM. If the MAX is just there to provide V/IP/IN limiting, some PWM-to-current loop, and an H bridge, then it seems misplaced. If there was no filter and just an H bridge driver from two suitably modulated pins of the µC and I/V sensing, that would be more straight forward. And you could do really nice sigma-delta modulation to get efficient spectral shaping of the output noise compared to that MAX. It might need about the same space. If the PID loop is digital, I would really want to stay digital all the way up to the H bridge. I am not doubting that you can get good performance with this. This is just to point out that this is an irritating design mismatch. Isn't there anything from the H bridge world that does this better?

For me, using the MAX chip mainly comes down to convenience. Its performance is pretty good, it packs a lot into a small board area with fairly low EMI, it's relatively cheap, and, most importantly, it reduces the amount of design + software development work we need to do to get a high-quality board up and running.

If we're going to switch to a roll-your own solution that requires more work (and probably costs more, requires more board space etc) then there should be a strong performance reason to do so. Do you think the MAX IC's noise etc performance won't be good enough for us?

This is just to point out that this is an irritating design mismatch

I agree that it's conceptually less neat than rolling our own, but that doesn't mean it's not the best means of achieving the result we want.

If you're keen on an H bridge approach, can you suggest a topology + some components you'd like to use?

[jordens]

I'm not suggesting to roll your own H bridge. There are small fully integrated H bridges with gate drivers and power-MOS, some even with current sensing, and multiple channels in one package. And I am not doubting the specifications of the MAX. I'd just try to get a bridge driver that doesn't come with its own PWM modulator and current loop. Instead I would look at those integrated bridges/drivers and add the missing features (current/voltage sensing/limiting). That all looks well within the scope of the on-chip ADCs (I/V sensing and limiting is not a precision or high resolution job). Instead of one modulated control signal going to the driver you'd now have two. You'd save on the filtering components and you'd get voltage monitoring as well. What else is missing that you need the MAX for? Does it have better performance than a typical bridge driver? From the datasheet it is meant to be used in an analog loop, not in a digital one. Bringing the digital signal all the way to the bridge instead of reconstructing it with a filter and steering a PWM to a current sensor would at least allow you to do noise shaping and get voltage sensing for free. It looks likely that it is also better suited for low thermal mass applications where the switching pattern needs to change. Performance is probably going to be fine for most applications. And if it hinges on me finding a better bridge chip doing the design, then I'll pass ;) And this is probably fine as a first iteration. In any case, don't you want to wait and debug the parts of the design shared with the Thorlabs version first before signing this one off? We'd be interested in testing this one for ultra-low thermal mass control at some point as well.

[hartytp]

Performance is probably going to be fine for most applications. And if it hinges on me finding a better bridge chip doing the design, then I'll pass ;) And this is probably fine as a first iteration.

Well, it hinges on someone doing the design. I'm short on time right now and the MAX IC will be absolutely fine for all the applications I have in mind, so it won't be me who does all the legwork for this. If you can convince someone else to do the design work required for this then it's fine by me.

What do you think @gkasprow

In any case, don't you want to wait and debug the parts of the design shared with the Thorlabs version first before signing this one off?

By this point, there isn't much common between the two boards, and I have some temperature control needs coming up for which the Thorlabs chip is a bit marginal. So, unless someone is planning to test the Thorlabs version of Thermostat reasonably soon then I'd prefer to press on to manufacture.

[gkasprow]

@jordens The MAX works at 1MHz. Even with 10 bit PWM you would need 1GHz clock in CPU. One can do some tricks with 8 bit PWM and noise shaping but IMHO it is not worth the effort.

[jordens]

The PWM from the CPU to the MAX will also need dithering to get the needed resolution. There is no change from that.

[jordens]

Even if you were to stay at plain PWM from the CPU, you get even more resolution by adjusting the frequency. The continued fraction algorithm to do that will fit just fine into the ~10ms sample rate. I assume that's what @cjbe was already doing.

[hartytp]

Even if you were to stay at plain PWM from the CPU, you get even more resolution by adjusting the frequency. The continued fraction algorithm to do that will fit just fine into the ~10ms sample rate. I assume that's what @cjbe was already doing.

@cjbe

[gkasprow]

I"d like to treat the version with MAX chip as a first iteration. Doing own HW bridge with cycle per cycle current sensing needs quite sophisticated mechanisms inside of the CPU. Once I did laboratory grade BLDC motor driver using brand new special AVR chip dedicated for that tasks with special high resolution PWMs with HW dithering, synchronous ADCs, HW protections, etc but it took enormous amount of time due to bugs in the silicon. Finally I had to build required functions writing critical parts in assembly. And I burned a lot of MOSFETs during testing because HW protection functions (programmed using fuses) did not work as expected causing spectacular failures by switching top and bottom switch at the time :) Every design can be made better, but if MAX chip does the job and simplifies R&D, let's use it. If we discover that it does not meet our expectations, we will switch to something else.

[hartytp]

@gkasprow It sounds like the plan is to keep the MAX IC for Thermostat v2.0. If we decide it's not good enough, we can replace it in v3.0. Thermostat v2.0 will give us a high-performance board that we can develop most of the required firmware on.

Please could you update following @jordens comments (copied below) and then upload a release and close this issue?

• [x] also connect I2C on the second TEC to the CPU. I2C2 or I2C3 (when moving STAT) seem doable on quick glance.
• [x] Please expose the UART not on individual pads but on a pin header.

[gkasprow]

done for both designs.

[hartytp]

Thanks!

Okay, let's close this. We'll keep the new TEC driver design in mind for v3.0