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.

[hartytp]

Perhaps there should be a wiki page so people know what PoE gear to buy? It takes a bit of research to figure out what all the standards are and how they might relate to Sinara.

Sure, I'll add something to the Wiki once I've had a play around with this and found something that works nicely.

[hartytp]

Those Silvertel Ag9600 PoE modules will only put out 9W at 5V but the MTD415Ts can draw up to 8W each. Is this a problem or do you expect to just limit them to a total of 9W in software?
It looks like 5V modules are available that support the full 13W available with basic PoE (Silvertel Ag9200).

Personally, I'd be happy using a 13W PoE module and limiting the power per TEC in software. If the users exceed the power threshold then no damage will be done. If this turns out to be an issue, we could consider dropping to one temperature controller per Thermostat, but I don't think that's necessary.

There is 30W version available in similar package.

What's the downside of using the 30W ones compared with he 13W ones? Just the extra 10EUR or so per board?

I can make dual footprint so on can insert 13 and 30W modules...

Let's just pick one and stick with it instead of having too many different population options!

[hartytp]

Okay, so trying to summarise this:

• Form-factor: make the PCB as small as we can.
• Mounting: design to mount off a standard 3U front panel, also add some general-purpose mounting holes.
• Power: PoE module. 13W? 30W?
• Interface: ethernet using a Wiznet module (no firmware). Also add a DNP microprocessor that people can play with if they want (sits under the Wiznet module so doesn't take up any additional space)
• Channel count: 2
• Connectors: 4-pin DIN, IDC (no I2C/+12V on the connector), terminal block socket
• Misc: consider adding a CMC + capacitor on the TEC outputs to reduce noise. I assume these outputs are quite robust, so no diodes etc are needed. Add an LED attached to the status pin of each temperature controller module. Also a power LED?

let me know if you disagree with that, or if I've missed anything. Otherwise, I'll close this issue and write this up on the Wiki.

Also, it would be good to know who would be interested in buying one of these...

[jordens]

LGTM I'll buy two.

[hartytp]

Okay, we seem to have reached a consensus on what this design should look like. Closing the issue, but feel free to reopen if you have any more questions/comments about the design.

[hartytp]

@gkasprow one last thing about this: does the Wiznet support configuring over USB/UART?

Our networks have pretty restrictive firewalls, so it's nice to be able to set up the ethernet settings via USB/UART if the Wiznet supports it. If they do, can we add a micro USB on the front panel? No worries if not!

[jordens]

Have a staging network that you control. The switches that you need for poe can do that for you.

[hartytp]

Sure. Isn't having a micro USB nice in general though? e.g. for the future version where we have a microprocessor this is useful for firmware updates, debugging etc

[gkasprow]

The Wiznet modules can be configured via AT commands on the first serial port. I plan to use quad port module so we can connect USB to the first port permanently. I will also route the USB to the TM4C port.

[gkasprow]

I found low profile, low cost 30W PoE modules so we don't have to restrict the power to 13W

[jordens]

Adding USB is a antifeature here IMHO. The uC will have JTAG/SWD already. If its really only the conector, fine. If it needs an interface then I wouldn't do it.

[hartytp]

Okay, I'm not fussed either way. I was thinking of just having a usb micro and nothing else. I agree, it's not worth the UART.

In any case, it seems the use for it is somewhat marginal, so let's drop it.

[gkasprow]

I can place 3 goldpins so one can connect cheap USB-TTL cable to change settings when needed,

[hartytp]

@gkasprow That sounds like a good idea. Let's do that.

[dnadlinger]

Also, If the module can do DHCP (and preferably the MAC address is printed on a sticker somewhere), it should be plug-and-play for us anyway.

[gkasprow]

They have a configuration software that scans network and is looking for valid MAC.

[dnadlinger]

Huh, for a valid MAC?

[gkasprow]

@klickverbot I mean MAC that is within their address pool.

[sbourdeauducq]

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

So the IP address can be set over HTTP, but not the temperature?

[gkasprow]

This webpage is for ethernet converter setup only. For temperature controller it is transparent.
In addition I will implement TM4C specially for @sbourdeauducq :)

[sbourdeauducq]

Nice, thanks Greg.

[restelli]

A quick info that might be useful. Individual MAC addresses can be bought for few dollars in the form of small flash chips from companies such as Microchip/Atmel.
https://www.microchip.com/design-centers/memory/serial-eeprom/getting-started/with-mac-address-chips
The advantage of this solution is that it is not required to individually program each piece of equipment to have a different MAC address and there is no risk that somebody will forget to change each MAC address when updating the firmware on multiple devices. Reading from the flash is trivial and there is even some extra space to write down extra information and configuration flags.

[gkasprow]

@restelli we use these chips on every single module in Sinara family for identification purposes..
It's worth using it in thermostat as well.
Thanks for idea.

[jordens]

That's nice but not critical. A perfectly valid strategy is to choose an LAA OUI and then generate the device part of the EUI-48 from the hash of the unique identifiers of the CPU (if it has one) or from the Thorlabs modules (they do). That's what I am doing with Kasli v1.0. And the CPU also has enough flash space.

[gkasprow]

transferred the issue to the right repo.