Thermostat: request for comment

[hartytp]

I've sketched out a proposal for a temperature control EEM that I'm provisionally calling Termostat.

I'm interested in any comments that people have. Does that sound like something you'd use? Does the proposal match your needs? Any suggested improvements? etc...

[ghost]

A couple of suggestions:

• Ethernet connectivity would be nice for standalone operation. A transparent Ethernet->UART convertor like this would only add about $10 to the board cost and could easily be DNPed. The only reason I can think not to add this is if it's a buggy piece of junk - anyone used one?

• Add a power rail to the D9 so that a heatsink with a fan can be used? I simple I2C fan controller could also be added but it sounds like you want to avoid this kind of feature creep.

I also have a concern that unlike a traditional IC manufacturer Thorlabs might rapidly discontinue these parts. I guess the board is simple enough that you can just cut your losses and start again with another module.

[hartytp]

Ethernet connectivity would be nice for standalone operation. A transparent Ethernet->UART convertor like this would only add about $10 to the board cost and could easily be DNPed. The only reason I can think not to add this is if it's a buggy piece of junk - anyone used one?

I did think about that, the reason I decided against it was just the usual feature creep etc., extra bugs etc.

My feeling is that it's better just to make an Arduino/Beaglebone/whatever EEM shield and put the ethernet on that.

Add a power rail to the D9 so that a heatsink with a fan can be used? I simple I2C fan controller could also be added but it sounds like you want to avoid this kind of feature creep.

I'm fine to add 5V power to this if you think it would help. Connecting the PWM is a bit of a pain (with the front panel Rj45 there are no spare pins to use for I2C fan control). I'd prefer to avoid this kind of feature creep.

I also have a concern that unlike a traditional IC manufacturer Thorlabs might rapidly discontinue these parts. I guess the board is simple enough that you can just cut your losses and start again with another module.

I did worry a bit about that. But, worst case, we just add one of those Maxim peltier driver ICs and a microprocessor and do this ourselves. In that case, the current design still serves as a very useful template for the new board. Plus, I don't see Thorlabs discontinuing this any time soon, as it's quite widely used.

---

Do you guys think you would use this EEM if we made it?

[dtcallcock]

My feeling is that it's better just to make an Arduino/Beaglebone/whatever EEM shield and put the ethernet on that.

I think the board will be much less likely to be used standalone if you need to faff around with a second EEM (that will also need firmware and debugging). Another issue with things like Beaglebones is that as they run an OS, which means we can't easily put them on the NIST network.

I can also imagine a few other EEM boards in a similar vein to this one that would benefit from cheap, simple and robust ethernet connectivity, so if we can find a good solution it could be reused.

[gkasprow]

Let's use Ethernet solution we use in uTCA chassis based on Texas Instruments CPU compatible with RUST. @sbourdeauducq will like it. It's a single chip solution.

[gkasprow]

The module is similar cost to ADI and Maxim chips that do similar job, but require analog compensation which is painful. In case of troubles with availability we can always develop replacement - the HW part of this module is trivial - just CPU and DC/DC converter, but the FW is considerable effort to develop.

[jbqubit]

@hartytp Your specification is lacking performance goals. In the case of the Thorlabs chip this is

• output current: 1 mA resolution, +/- 50 mA accuracy
• temperature sensing: 10 kOhm thermister, 278 K to 318 K range, 1 mK resolution
• typical closed loop stability over 8 hour: 20 mK (assuming what temperature stability for controller?)

If this is to be an ARTIQ EEM module it's natural that it support the internal EEM connector. Note however that adding a UART PHY to EEM gateware would be a new protocol AFACT. @sbourdeauducq

https://github.com/m-labs/sinara/wiki/EEM#eem-connector-protocol

[dtcallcock]

If this is to be an ARTIQ EEM module it's natural that it support the internal EEM connector. Note however that adding a UART PHY to EEM gateware would be a new protocol AFACT.

Given we don't need fast control and it's unlikely that any physics experiment will ever need to talk to this module, aren't we just using Kasli/Metlino as an expensive and inconvenient Ethernet->UART convertor.

[gkasprow]

We can use EEM and Ethernet CPU at same time. Ethernet plug will have higher priority, EEM will just use double/quad UART protocol. We can make it 4 -channel to lower the cost. Such module can be used stand-alone in single 3U cassette with Ethernet control, part of 3U rack controlled and supplied by Kasli/Metlino or part of 3U rack controlled by Ethernet and supplied by 12V jack.

[hartytp]

Re the ethernet thing:

• Generally, I like the UART interface because it's pretty standard, simple and well supported. One can easily covert it to USB or ethernet using readily available adapters and one can use it directly with most micro controllers. We will probably use one of those USB adapters for initial debugging and operation.
• UART is what the Thorlabs chip provides, so it's the least work. If we use UART then the PCB is pretty trivial. Ethernet would be a major increase in complication, which I don't think is justified in this case.
• My assumption is that any lab using this EEM will already have a few Kasli floating around. The reason we put a large FPGA on Kasli was to have plenty of spare IO. So, it's basically no extra cost to run a RJ45 from the DIO_RJ45 board to the Thermostat EEM. This single RJ45 can control both channels independently.
• Another nice use case for the EEM connector UART interface is things like temperature stabilising a Zotino. Here the same Kasli can supply all power and IO needed with a few ribbon cables. That's much nicer than having to have an external ethernet connection IMHO.
• We could provide ethernet as well as UART-via-RJ45 on the front panel, but then it starts to get to be a bit of a mess (plus too much room for users to plug the cable into the wrong connector). Plus, we'd probably need one ethernet adapter per temperature control channel (I don't want to get into the extra overhead involved with multiplexing multiple temperature controllers onto the same ethernet connection).
• The ethernet connection is generally quite complex and could be a large time sink to debug and get working robustly
• I don't want anything on here that needs firmware if at all possible (that's one of the big advantages of the thorlabs IC IMHO). The cost of programming boards at production then debugging and maintaining firmware is just too great for a project this simple in my opinion. That rules out anything based on a rust microprocessor or as far as I'm concerned. We could go for the lantronix or something like that, but it would be a significant increase to the complexity of the project and I just don't see the justification for it.

[hartytp]

Does that make sense? Or, do you still feel strongly that you'd want ethernet?

[hartytp]

We can make it 4 -channel to lower the cost.

Two channels might be better:

• Is there room for 4 D-types, an ethernet plug and a power jack on the front panel?
• With two channels, the power for this unit can be supplied via Kasli, which is nice. With 4 channels, one exceeds the maximum current rating of the IDCs and could cause damage.

[sbourdeauducq]

There is firmware inside the proprietary Thorlabs device; you are just hiding it. In general I am in favor of the TM4C chip with Ethernet (bringing Ethernet up has been mostly unproblematic on ionpak, unlike Sayma) and not using the proprietary Thorlabs device at all (this TM4C has all that is needed to run the control algorithm, and many relevant I/O peripherals).

[gkasprow]

I placed a comment but it disappeared. I like simplicity, but want to make sure that the board we build is really useful, also in stand-alone applications. The Thorlabs device has a firmware which means we don't have to write it :) Just buy a module and keep it as an ASIC. Of course we can do it using TM4C, but I'd leave it just for Ethernet to UART bridges because it is the simplest way to make it working with almost no work. Good temperature controller firmware is not that trivial and this Thorlabs chip has advantages - it works, has sufficient performance . Development and debugging of similar performance firmware will not come for free

[gkasprow]

@hartytp we won't fit 4 channels. 2 xDSUB hardly fit

with micro-DSUB9 we can fit 3 we can also use double DSUB-9

[dtcallcock]

I think I'm missing something here. Right now, using the core device to intermittently talk to misc non-real time hardware, do logging, and other general housekeeping is very undesirable and unscalable as it directly interferes with running experiments. Having a direct connection from the hardware to a PC running an Artiq slave seems like the right way of doing this and the one that was envisioned from the outset. However it seems that @hartytp is envisioning extra Kaslis being dotted around the lab to handle this kind of thing instead of PCs. Is one picture correct or is it really just a matter of personal preference?

One can easily covert it to USB or ethernet using readily available adapters and one can use it directly with most micro controllers.

If my picture above is correct then I think any piece of hardware where direct connection to a PC is the preferred mode of operation should have the necessary hardware (eg. ethernet) built in. One of the big wins of Sinara for me will be not having to add my own adaptors or micro controllers to things.

I don't want anything on here that needs firmware if at all possible (that's one of the big advantages of the thorlabs IC IMHO). The cost of programming boards at production then debugging and maintaining firmware is just too great for a project this simple in my opinion.

The ethernet to UART convertor I suggested obviously has firmware but, just like the Thorlabs controller it is pre-loaded and hidden from the user (as @sbourdeauducq points out).

The ethernet connection is generally quite complex and could be a large time sink to debug and get working robustly

These convertors are supposedly transparent (like the Ethernet to GPIB convertors we use). I mean if they don't actually work, that's one thing, but if they do then it doesn't seem like any extra work. Does anyone have experience with these? If they are junky then having something equivalent would be a great addition to Sinara in my opinion. In that case I think it should be considered a separate project (albeit one that Thermostat can take advantage of) and we should move it to another thread.

[jordens]

• I would consider moving the driver towards the peltier. The long, fat, rigid cables needed for low resistance are an issue IMHO. I would even do that when using that Thorlabs module despite the fact that the same cable thickness would be needed. Then just run uart and power over the cable. And now then I'd also probably just plug a Ethernet-to-UART converter in front of it. And then we are left with very much reduced requirements for the backhaul (power supply and UART-to-ethernet) in the rack.
• Pretty sure that module is not good enough (not enough temperature stability, too large temperature coefficient, too large temperature setpoint steps, too much temperature noise, ripple) when controlling DBRs or DFBs in several applications. 10mK (or even 2mK) is high for many applications. You might want to temperature-stabilize that module itself.
• If you really use 4 channels, then please go to 8HP.

[jbqubit]

I created a new Issue for #473 Ethernet-related comments. Let's keep present focus on @hartytp 's suggested hardware. If the new Issue reflects everybody's views, consider pruning this Issue @hartytp.

[jbqubit]

Comment from @restelli by email. Topic: JQI's temperature controller.

---

Our temperature thermostat project, developed by Benjamin Reschovsky (in CC) is based on commercial linear temperature controllers (Wavelength's WTC3243) it features 4 channels, it is compatible with both peltier and heaters and it can work both stand-alone and computer controlled.

https://github.com/JQIamo/Linear-Temperature-Controller

Tom's system would be much simpler because it leverages the Thorlabs MTD415T digital interface. In that case maybe an out-of-the-box TCP-IP to serial converter could even be used. It costs just $20 Our temperature thermostat project, developed by Benjamin Reschovsky (in CC) is based on commercial linear temperature controllers (Wavelength's WTC3243) it features 4 channels, it is compatible with both peltier and heaters and it can work both stand-alone and computer controlled.

https://github.com/JQIamo/Linear-Temperature-Controller

Tom's system would be much simpler because it leverages the Thorlabs MTD415T digital interface. In that case maybe an out-of-the-box TCP-IP to serial converter could even be used. It costs just $20

http://www.shopwiznet.com/wiz750sr-ttl

http://www.shopwiznet.com/wiz750sr-ttl

---

@hartytp

Re relative performance of the two models: the WTC3243 is a really nice chip in terms of stability etc. But, it's all analog. The big plus of the thorlabs chip is that it provides digital gain control and logging etc. The performance of the Thorlabs chip is still good enough to get from +- a few K lab fluctuations to comfortably better than 100mK, which is good enough for all the applications we have in mind. But, as always, the best solution depends on the application!

[gkasprow]

I use since many years Lantronix embedded servers and I'm happy with them. But they support only one serial port. They have 3 IOs which can be used to select desired channel. They support virtual COM port.

TM4C is another single-chip low cost option to consider. There is reference design based on FREE RTOS, so addition of more UART channels would be trivial. It already supports 2 channels.

[sbourdeauducq]

What exactly is going on inside those Thorlabs or teamWavelength devices? Do we really need those single-source black-boxes?

[jordens]

There is. uC, a 16 bit dac (more would be better, or multiplying or sigma Delta), a 16 (24 would be better) bit ADC, reference current source, opamp, and most likely the maxim driver module I mentioned in the wiki.

[gkasprow]

@jordens there is just synchronous DC/DC converter that drives Peltier module directly. https://www.eevblog.com/forum/metrology/mtd415-a-low-cost-rs232-controllable-bipolar-1-5a-tec-controller-module/ We can start from such modules and when there is a need to build better version of them.

[sbourdeauducq]

I find it much more interesting to have control over the whole design, especially if we want to push the specifications. And I really don't like the black-box aspect of those modules, I think this part should be open source, plus those modules make it look like we can't figure out how to build a good PID controller and need black magic from some vendor.

[gkasprow]

@sbourdeauducq Yes, I fully agree with you, but development of own firmware is costly. And somebody need to volunteer or be paid for it. Hardware part is simple - just good ADC and high resolution PWM or DAC + Maxim chip. If you know open implementation of good PID controller, let me know. I know that basic PID is just a few lines of code, but this Thorlabs module seem to be much more than that. AFAIK one does not need to tune it and it works with various loads so either it identifies step response and tunes itself or is designed with large phase margin to cover most use cases.

[cjbe]

@sbourdeauducq it is definitely more fun to design ones own, but the firmware development is a pain - the core is just a 10 line PID loop, but all of the surrounding command handler / control interface adds up and is boring to write and support. My guess is that the firmware would be several k$ of time, and will divert effort from more critical software.

I see this board as something very quick to design, and relatively low performance (~10mK) - this is all one needs to temperature stabilise most things around the lab apart from laser diodes. If the need arises, we can design a second revision using our own design rather than the Thorlabs module - I have a temperature controller design using a AD7191 that has a <0.2 mK/K uncompensated tempco (unmeasurably low after temperature compensation).

[gkasprow]

@cjbe did you develop this module yourself ?

[cjbe]

@gkasprow yes. Just a MAX1968 peltier driver, a PIC microcontroller, and a differential sigma-delta ADC with a trivial input stage (input_stage.pdf).

(I never thoroughly characterised the long-term drift or noise immunity of this design, so the annotations on the schematic may be overly optimistic.)

[dtcallcock]

Just going back @jbqubit 's point about supporting UART over EEM (assuming the Thorlabs module is used). Would you do that or stick to the current SPI standard and add a $2 bridge like this?

[gkasprow]

@cjbe did you use straight-forward PID implementation or you implemented something more sophisticated? What about PID tuning? Is if hard-coded ? The ideal temperature controller should work with various loads, i.e. typical laser setup or Zotino DAC chip so the regulator should adapt to the load.

[cjbe]

@dtcallcock IMHO there is no good reason to have an EEM connector on it at all, apart from to leach power to avoid another wall-wart. I don't think that it is that natural to patch in slow control and background diagnostics into the hard realtime part of the control system: one hardly needs a high-bandwidth link to a temperature controller.

My preference is just for a USB-UART of Ethernet-UART link.

[cjbe]

@gkasprow I used a straight-forward PID with anti-windup. The PID coefficients were programmed over the control interface. To choose the gains I had a semi-automated system to measure the step-response around the desired setpoint then calculate the optimum gains.

[gkasprow]

So maybe, if you are willing to publish your design, we could use your approach, at least chipset and source codes. Or build two versions - simple with Thorlabs chip and robust, based on your approach and TM4C chip... But I'm not sure if it is worth to maintain two designs..

[jordens]

@gkasprow good find!

IMHO it would be nice to be able to just use PoE for power and Ethernet for comms for that thorlabs module. Then there would only be distributed modules with a dc/dc converter from 48v to 5v and uart-to-ethernet (either the custom controller or a COTS black box) hanging on RJ45 cables.

[gkasprow]

@jordens I uses PoE regularly in other designs so it is not a problem.

[dhslichter]

Just joining the conversation now, I am inclined to agree with @jordens and say it should be incredibly simple with PoE for power, Ethernet comms (via a COTS solution), and very small form factor. I agree that the cable resistance for TECs is an important consideration, and that engineering this to try to meet 1 mK (or even 10 mK) is going to be a real pain in the neck in a Kasli-type rack, so we shouldn't try -- just accept 100-200 mK and be done with it. If you want a gold-plated solution, roll your own.

Anyway, my two cents. Out of curiosity, what is the value added here relative to just buying things from Wavelength Electronics for example? With all the time and money to be invested in this design, you'll need a real boatload of temperature controllers to make it worth your while, it would seem.

[hartytp]

Picking this up again...starting with the issue of a roll-your-own solution (essentially: ADC, DAC, microprocessor and pelter driver) versus the Thorlabs IC:

• In short, I'm still in favour of using the Thorlabs IC for the V1 of Thermostat. If anyone requires the custom solution and has the resources to do a proper job if, then they're welcome to make a v2.0 of Thermostat. Once that's debugged and working well, we can scrap the v1.0
• The reasons for my preference of the Thorlabs solution are simplicity, cost and time to develop and debug.
• While a custom solution can provide better performance than the Thorlabs IC, the Thorlabs IC provides sufficient performance for all the use cases I have in mind. In particular, it will be fine for improving the ambient temperature stability by an order of magnitude or more (this is exactly what we need for Zotino to get few K fluctuations down to few hundred mK). For cases where better stability is required, one can temperature control Thermostat as well. We could also consider adding the same TEC/mechanics to Thermostat that we've put on Zotino. We have two channels on Thermostat, one of which can be used to control Thermostat itself by adding a short "jumper" ribbon cable from that channel's IO header to the TEC/thermistor header.
• While the custom solution is conceptually simple, these things always take far more time to develop and debug than one expects. e.g. getting the firmware really robust, sorting out the AFE to actually provide mK-level stability in a realistic environment (e.g. worrying about rectification of low-level EMI). None of it's that so hard, but it does take time.
• Right now we have limited resources and I don't want to prioritise reinventing the wheel (no matter how much fun that can be) when a satisfactory COTS solution exists.
• As I said, this doesn't prevent anyone from making a v2.0 that provides better performance.

[hartytp]

Channel count/connector:

• I don't see any need to go beyond 4 channels on Thermostat
• I'm happy with any connector for the front panel that's readily available and easy to hand solder. Some of the locking DIN connectors could also be fine.

[hartytp]

@jordens

I would consider moving the driver towards the peltier. The long, fat, rigid cables needed for low resistance are an issue IMHO. I would even do that when using that Thorlabs module despite the fact that the same cable thickness would be needed.

That's roughly what I'm trying to achieve by having the IDC connector on the inside of the PCB. Plan is:

• Shallow depth Eurocard form-factor with a front panel. A large point of the front panel's purpose is to provide a convenient way of mounting Thermistor when it's used in the same rack as Zotino etc.
• Have an internal IDC, which can be used to connect it to loads like Zotino via a short ribbon cable
• The front panel connectors are only there as a fallback when mounting this near the load isn't possible.

[hartytp]

Interface:

• My reluctance to use ethernet is just cost/time to develop. If @gkasprow thinks he can do the ethernet to UART bridge easily using a COTS IC (no firmware for v1.0 please) then I agree that's probably the best solution.
• I'd like to keep I2C on the IDC though. My use case for this is things like Zotino, where one just wants to program some gains and a set-point at startup and then forget about it. This would be used in cases where one isn't trying to log the temperature etc (that would be best done over ethernet) and just wants the simplest possible solution. In that case, it's convenient not to have to run an ethernet cable as well as the IDC. However, if the I2C causes a lot of extra complexity then I'd probably be okay scrapping it and only having ethernet.

Edit: I have no experience with PoE, but if someone wants to sort out the details then that could be really nice.

[gkasprow]

@hartytp we can make tiny module with Thorlabs chip and I2C->UART bridge IC that is plugged directly to the IDC socket. So no cable would be needed. Just one fixing screw would do the job.

[hartytp]

Finally, @dhslichter:

Anyway, my two cents. Out of curiosity, what is the value added here relative to just buying things from Wavelength Electronics for example? With all the time and money to be invested in this design, you'll need a real boatload of temperature controllers to make it worth your while, it would seem.

At least for the v1 design, I envisage this as being something really simple and cheap to design -- little more than a more convenient version of the eval board that Thorlabs sells for those ICs. As a result, the cost to develop should be low (so long as we avoid feature creep).

The advantages I see of this are:

• Digital control, allows python attuning etc. Tuning loops up with those analog boards is always a pain.
• Allows the option of digital temperature logging and flagging up an error if the temperature goes out of the set range
• Sorting out all the mechanics in a nice way. It's always time consuming mounting those black-box temperature controllers and supplying all the voltages they need etc.

[sbourdeauducq]

My reluctance to use ethernet is just cost/time to develop.

Please test smoltcp Ethernet on TM4C and tell me if that doesn't work well.

[gkasprow]

the simplest way of having Ethernet on board is Tibbo or Lantronix RJ45 module. The only problem is that they have only single UART + a few IOs. So either we add mux that brutally sects one of thermal regulators or use CPU with Ethernet + TI reference design of dual IP to serial bridge. Switching between ports requires control packets while talking with remote IP UART is simple - there are virtual COM drivers that make it transparent.

[gkasprow]

@sbourdeauducq do you have working IP to UART bridge that we can use without SW development?

[hartytp]

@hartytp we can make tiny module with Thorlabs chip and I2C->UART bridge IC that is plugged directly to the IDC socket. So no cable would be needed. Just one fixing screw would do the job.

We could do that, but is it any more convenient than just having a separate eurocard board? That board can be in the rack slot next to Zotino and just connected by a very short ribbon cable.

• It will still need a 12V->5V SMPS, so won't be that tiny.
• As others have pointed out, for temperature logging/checking for the temperature going out of range, it's best to use ethernet and not I2C or whatever via Kasli. So, we'd still want to support an ethernet connector. That's most conveniently done via a front panel connector IMHO.
• Having it as a eurocard board with front panel connectors makes it more useful as a general-purpose piece of lab equipment. Ideally, I want to make it a small enough PCB that it can be mounted in-situ (in that case, DNP the front-panel connectors) if one wants, but can also be attached to a simple front panel.

[gkasprow]

@hartytp ACK

[hartytp]

Please test smoltcp Ethernet on TM4C and tell me if that doesn't work well.

I'm still a bit too scared from the past 18 months of smoltcp bugs to get enthusiastic about that (being told that "this time it will actually work" a few too many times). AFAICT, it hasn't been tested that widely yet, is still missing widely deployed features, still has known bugs and is generally not quite ready for use in production systems.

More importantly, I just don't see any advantages of doing this over using something like the Lantronix other than an aversion to anything not open source. Those Lantxonix ICs are widely used and just work.

• The TM4C solution isn't going to be a lot cheaper (particularly after we've paid someone to flash it)
• It requires development and maintaining of custom firmware

[hartytp]

and, as I said, we can always move to that in a future revision.

Anyway, are you offering to do all that software development for free? Because I have more important things to fund right now than unnecessary firmware development.

[gkasprow]

@hartytp I'd expect from such Ethernet-UART bridge to have some configuration webpage that allows easy setup of at least IP address. Lantronix has it.

[sbourdeauducq]

I'm still a bit too scared from the past 18 months of smoltcp bugs to get enthusiastic about that (being told that "this time it will actually work" a few too many times).

There haven't been 18 months of smoltcp bugs. With the first smoltcp commit on Dec 10 2016 that's simply impossible.

Anyway, are there still lots of smoltcp problems with ARTIQ 3.3? And I don't think that we actually told you "this time it will actually work", instead things were simply delayed. Meanwhile there was still ARTIQ 2.x - did you go complaining about lwIP bugs (of which there are a lot more than in ARTIQ 3.3) to the lwIP developers?

still missing widely deployed features, still has known bugs

Such as?