Improving the T-962 Reflow Oven – Part 1

I came across a post in a while ago about improving the T-962 reflow oven by Werner Johansson at Unified Engineering in Sweden. I happened to have one too, before seeing this post, I was in the progress of building a replacement controller based on design using Arduino. I got to the stage to have the PCBs made because I already have all the parts except the thermocouple amplifiers. Another reason why I want to have the PCB made instead of buying from ESTechnnical is because my T-962, a smaller version of the T962A, it doesn’t have enough space to mount two external solid state relays (SSR) like the one shown on the left.FOTEK-SSR-25DA

Another reason is that I don’t want to cut out the SSR part of the board from the original controller, as described in the ESTechnical installation guide . At the end, I designed a new SSR board using 2 Sharp S202S02 SSRs.

I added isolation cutouts on my own PCB to improve the safety, where high mains voltage are separated from the low-voltage input circuit, as you can see from the image below. However, I made the mistake in not using the same Molex SPOX socket like the original, so that I don’t need to modify the original cabling.


While I was busy getting the board to work, Werner’s article came about. It’s a really good hack, and I wish it came out a few months eariler, so that I needn’t have to waste my time and money on the clone design. Nonetheless, I made the detour and try out Werner’s replacement firmware, and needless to say, It works! However, the biggest pit fall is that I still need to rely on the thermocouple amplifier of the original controller which uses simple op-amp design and the CPU’s internal analog-to-digital converter (ADC). I am a bit sceptical with the accuracy of the design. Since I already purchased the MAX31855 thermocouple amplifier for the clone design, I really want to see if this amplifier will make any improvement to the crude op-amp/ADC design of the original.

Werner suggested to use the One-Wire version of the Maxim’s thermocouple amplifier, the MAX31850, which I think was a logical choice, since there isn’t that many free pins available on the original controller. Werner has thoughtfully mapped out all the processor pins usage and place it in the t962.h file in the source code that he provided.

However, there is one problem. I can’t get the MAX31850 from my usual supplier, Farnell UK. Also, it comes only in TDFN-10TDFN-10 package which I have no confident in hand soldering it probably. I only have one reflow oven and it’s in the state of being upgraded.

Since I already got the MAX31855. It’s in SO-8 package and I can hand solder them without any problem. The LPC2134 has 2 SPI ports available,  but looking at the pin mappings, the needed SCK0 pin for the first SPI port is being used as input by the F4 button. Part of the second SPI port(MOSI1, MISO1) are also being used by the LCD R/W and EN pin. Damn it!

Another bus on the processor that is of interested is the I2C bus. This bus requires only two wires and it’s brought out to a very convenience place next to the EEPROM. A quick search on Google brought me to this I2C to SPI bridge chip, SI18IS602B, by NXP. To my delight, It’s in hand solderable TSSOP package and Farnell UK stocked them, it only £1.72 each.

With the ESTechnical clone PCB I made earlier, I reuse the thermocouple front-end portion and added the SC18IS602B chip on TSSOP proto-board.


I wire-wrapped the SPI connections from the MAX31855 chips to the SC18IS602B I2C-to-SPI bridge and soldered the SDA and SCL pins to the two 4K7 pull-up resistors next to the on board EEPROM. Each I2C-to-SPI bridge can address 4 SPI devices, two of which (SS0, SS1) are connected to the MAX31855. I did not take the power from the original controller. Instead, I tapped the raw DC from the bridge rectifier on the original controller and fed it to the 5V and 3.3V voltage regulators on my clone board. This should minimize any noise from the original controller, my clone board also had separate analog ground plane for the MAX31855.(click on the picture to zoom in)

With all the hardware done, it is time to get the software to work with Werner’s modified firmware. Two libraries are needed, the first is the driver for SC18IS602B I2C-to-SPI bridge. According to the datasheet, the chip communicates with the processor through function IDs and data buffers. The chip can hold 200 bytes of data. Once the I2C communication completes, the chip will pass on the data onto the SPI bus to the selected device automatically. At the same time the MISO pin on the SC18IS602B chip will reads in the data and stores them in it’s buffer.


For my purpose, I only need to read from the thermocouple amplifiers. The MAX31855 does not need any command to be written to it, instead, it will output the 32-bit temperature data on it’s DO pin according to the SCK pin. So to get the SC18IS602B to collect the data from the MAX31855, we need to do a dummy write to the chip, which MAX31855 will ignore, at the same time SC18IS602B reads the data via it’s MISO pin and store them in it’s internal buffer. From there onward, the processor can read out the data from the I2C-to-SPI bridge buffer.

To work with this design, you’ll need at least v0.3.0 code or later. Werner has kindly added the support of this design in his latest code release, you can get it here. His latest code will check for the present of One-wire connected MAX31850, if they are not found it will then check for the present of any MAX31855 connected via the SC18IS602B I2C-to-SPI bridge and if non of that are found too, it will fall back to use the internal Op-Amp/ADC.

Next thing I’d like to tackle is the annoying noise level of the internal system fan. Ideally, I’d like PWM control for the system fan based on the board’s temperature. If either the MAX31850 or the MAX31855 are used, there is no need to worry about the cold-junction temperature of the thermocouples, the chips will handle that automatically. I can reuse the DS18B20 temperature sensor as the board temperature monitor and control the speed of the system fan accordingly. In next part of this series, I’ll have the full schematic available and the board design ready to be submitted to the PCB house.

44 thoughts on “Improving the T-962 Reflow Oven – Part 1

  1. Wow, that’s the first time I’ve ever seen one of those i2c to spi bridge chips put to good use, nice work!

    I’m a bit curious though, most of the sc18is602 code seems to be doing a lot of the i2c work that could be done by simply calling I2C_Xfer with various parameters in i2c.c? I haven’t looked into it in greater depth but a quick glance seems to indicate that quite a bit of the code could be simplified. Was there something in particular that wasn’t supported that was needed by the bridge chip? Needless to say my I2C code has never talked to one of these bridge chips before. On various MCUs it has talked to quite a diverse range of peripherals though.

    I would definitely be interested in bringing in support for this setup, and detecting the presence of the bridge makes it a lot easier to determine which thermocouple sources are available (and only if no other sources are found fall back to the built-in ADCs).

    I’ll link this from the Wiki as well!


    1. Initially, I did use your I2C_Xfer to try to communicate with the SC18IS602B bridge. However, I’m not able to get it to work! In a desperate attempt, I pulled out the code that I’ve used before so that I don’t have to waste my time on it. Over the Xmas holidays, I’ll try to figure out why your I2C_Xfer didn’t work for me.

      I agree with you that there are many places where you can simplify the code. Please go ahead and let me know, I’m no expert in coding and I’d very much like to learn more.


      1. Makes sense! After a very quick search it wasn’t obvious that the CC BY-NC-SA 3.0 license chosen for your code was 100% compatible with the GPLv3 license covering the rest of the controller code, so instead of importing I made a quick stab from scratch at supporting this setup very much like my current 1-wire TC-interfaces. It would be great if you could take a look and possibly give the code a spin on your hardware as I can’t test it here. I have checked the code in on a separate branch at the moment which can be found here:

        It’s very likely that I failed to understand some parts of the bridge chip functionality but I’m fairly sure that the MAX31855 parts should be OK (as the core is the exact same one as in the 1-wire version)


  2. Wow, you code are very nice and clean. The CC BY-NC-SA 3.0 license just happened to be there when I copied the comments from the original Arduino code. Just as well you rewrote the whole lot for me. Now I have no worry being accused of nicking other people’s code.

    Unforturnately, the new code didn’t work straight out on my hardware, but I’ve borrowed a logic analyzer from the office to use over the holidays. I’ll hook it up to see what went wrong and hopefully I can get back to you before next weekends.


    1. Thanks for testing it out! It was worth a shot trying at least. 🙂 It will be very interesting to see what didn’t work out, probably some mundane detail! Did it even reach the point where it detected the bridge chip or it failed before that? Did the uart output have anything interesting to say?


      1. Good news, I think I’ve found the problem. The code got to the point “Probing for MAX31855 devices…No devices found!” and then falls back to internal ADC, which in my case I get large temperature reading of 118+ degrees for the left ch and 695+ degrees for the right ch, because I didn’t have any TC probes connected. I’d the logic analyzer hooked up and saw one transaction to the I2C-SPI bridge, that is from the SC18IS602B_Init called within SPI_TC_Init, (an I2c write to address 0x50 with function ID 0xF0 and data 0x00) after that all captured I2C transactions are for the EEPROM.

        After more scrutinizing of the code, I realized that that SPI_TC_Init tries to determine how many SPI devices are attached by scanning all possible devices up to MAX_SPI_DEVICES, 4 in our case. It then creates a task using the very same routine, SPI_TC_Work, that you used to scan the SPI bus for attached devices. I got a bit confused when the variable “numspidevices” which you used in the global context, is also used as the local variable within the SPI_TC_Init routine.

        Anyways, my understanding is that the code tries to do is to start off with MAX_SPI_DEVICES available and after going through the scanning/probing process in SPI_TC_Init, it should determine the actual number of devices found, and set the “numspidevices” with the actual number of devices found in the system. Next time when SPI_TC_Work is called as a task, it will only do the actual number of devices, which should be 2 in our case.

        So in order to get the code running correctly with my hardware, I made the following changes:

        1. I changed line 30, after int16_t spiextrareadout[MAX_SPI_DEVICES]; to

        int numspidevices = MAX_SPI_DEVICES;

        2. For my convenience and readability,(I hope you don’t mind!) in line 52, I replaced :

        uint32_t numspidevices = 0;


        uint32_t numofspidevices = 0;

        and also all subsequence “numspidevices” within SPI_TC_Init routine.

        3. I added the following after Sched_SetState( SPI_TC_WORK.... at line 77

        numspidevices = numofspidevices; // now actual number of devices are found, set it!
        printf("n%d device(s) foundn", numspidevices);

        so that the global variable “numspidevices” is now updated with the actual number of devices found.
        I also added the extra printf statement to show how many devices are found at the terminal.

        With the logic analyzer still attached, I indeed saw the four I2C dummy-writes and read-backs probing process happened once during bootup, subsequence captures after initialization, all I2C transaction to the bridge chip only has 2 dummy-writes and read-backs, and at the terminal, I saw the following output:

        SPI_TC_Init called
        SC18IS602B_Init – Done
        Probing for MAX31855 devices…
        SS0: [SPI Thermocouple interface]
        SS1: [SPI Thermocouple interface]
        2 device(s) found

        TC0= 20.8C TC1= 20.5C CJ= 22.0C Setpoint= 30C Actual= 20.6C Heat=0x00 Fan=0xff Mode=STANDBY
        TC0= 20.8C TC1= 20.5C CJ= 22.0C Setpoint= 30C Actual= 20.6C Heat=0x00 Fan=0x00 Mode=STANDBY
        TC0= 20.8C TC1= 20.8C CJ= 22.1C Setpoint= 30C Actual= 20.8C Heat=0x00 Fan=0x00 Mode=STANDBY
        TC0= 20.8C TC1= 20.8C CJ= 22.1C Setpoint= 30C Actual= 20.8C Heat=0x00 Fan=0x00 Mode=STANDBY
        Other than the above changes, I haven’t touch any other part of the code and they all worked like magic:))

        Let me know when you will commit this changes to the main source tree so that I can pull my patch code and update by blog to reflect the new features you’ve added.

        Oh, BTW, I keep getting the “NO VERSION INFO” on the LCD at startup. How do I get ride of it? I notice in main.c that you’ve mentioned about LPCXpresso should generate that needed version.c file. How do I get LPCXpresso to generate this version.c file? Should I just create the version.c file myself? What should the content be? Just a function Version_GetGitVersion() that returns the version number, in int or chr string?


  3. (initial version of this comment seems to be delayed/lost, trying again):

    Oh crap, of course! Thanks for digging into it! I had this idea to reuse the Work code to scan for sane spi results but I forgot about the fact that it used numspidevices that wasn’t initialized yet, sorry about that. There’s a new commit on the max31855-integration branch that should fix this (and a pull request for master). Good to see that the rest of it seemed to work though. I found a timing bug in the Work code as well that I committed a fix for yesterday evening.

    As versions go – LPCXpresso builds will all show the default version as nobody has figured out how to call “git describe” in a sane way during build. The releases on github that have version info embedded are built using the standard Makefile by the Travis-CI system. It’s like magic! 🙂 But seriously speaking, nobody has found a good way to do this in LPCXpresso yet. If you want to change the default just take a look at the weak function at the top of main.c, that’s the one that will be used if no version file has been generated. You can also create a version.c containing

    const char* Version_GetGitVersion(void) {
    return “whatever version”;


  4. I had to rework your suggestion somewhat as I didn’t want numspidevices to be set to 4 before any initialization had been done, but the main issue has been corrected!


  5. I have tested the resulting code on my hardware without the sc18is602b chip and see no side-effects so as soon as you give the thumbs-up that this latest fix actually works on your hardware I’ll pull the code in and do an official 0.3.0 release (that should hopefully simplify the instructions here a bit!)


    1. Thumbs-up! I’ve tested the new code and it works great on my hardware. I did a few test runs with old populated boards in the oven and see no issues. Yeah, go for an official 0.3.0 release. I’ll update my blog with better schematics and pull my patches, hopefully before Xmas. Things get rather busy this time of the year!

      Liked by 1 person

      1. By the way, with the MAX31850 interfaces in use I have completely disconnected my annoying system fan at the moment. Even after several cycles the board temperature is still < 45C which is nothing to worry about. The LCD will get washed out when the temperature approaches 60C (which I only reach when running bake mode at high temperatures for long periods).

        That said I'm still very interested in a potential PWM fix for the system fan as it would mean that it would solve those bake issues while still being quiet most of the time. I haven't mapped out exactly how it is hooked up to the power supply (I'm surprised that the speed changes as much as it does when the heater kicks in). The only easily available unused GPIO is GPIO0.25 as that is available as a testpoint marked ADO. Unfortunately that pin does not have PWM capabilities, but it does double as the DAC output. It can either be run as a software PWM or analog out depending on how the driver interface will look like. An op-amp can be fed a triangle waveform on one input and the reference output from the DAC on the other and create PWM like that. Several possibilities exists, that's for sure!

        When using the built-in thermocouple interface the system fan has to be connected (or PWM'ed) as it's impossible to measure negative delta there so if the board temperature is higher than the setpoint it simply will never reach the setpoint.


      2. If we go the software PWM way, the driver circuit will be simple, just a power FET and associated passives. Using the on-board DAC with external op-amp will increase the complexity and component counts, which I don’t prefer. I do have 2 spare pins(chip select pins), can act as GPIO on the I2C-to-SPI bridge if more outputs are needed, but that’s not a universal solution! I belive we do have sufficient CPU time available to do software PWM without affecting other core processes, right?


  6. Yep, more than enough CPU time left for a slow PWM for a fan. I guess it doesn’t have to run more than say 100 times per second. The simple FET solution sounds like the better one in this case, the needed resolution and accuracy is so low anyway.

    You might have a hard time PWM:ing through the GPIOs on the I2C to SPI controller, that takes way more CPU time to address than the fast GPIOs onboard the MCU. Also you might want to hook up two additional thermocouple interfaces so you can measure the actual temperatures on two places of the actual board you reflow – that’s my main use for the additional two channels I have on the 850 interface (they will also show up in bake mode UI).

    Have you mapped out how the fan is connected on the board? It seems to have a separate diode hooked into the AC supply? Seems like a strange way to hook it up but I haven’t traced it accurately enough yet. The fewer components and tracks that has to be modified the better.


    1. Without the board in front of me, just from memory, I think the power to the fan is just the raw DC after the bridge diodes with one of the big capacitor connected acrossed it. You see 5 diodes there is because the one nearest to the switching regulator is the schottky diode for the switching circuit. Originally, I want to power my board by taking the power from the fan socket, but I don’t have the right JST type plugs and headers. That’s why I soldered the power cables directly across the bridge diodes as you saw in the picture.

      I have a feeling that the fan is working above 12V depending on the output of the 9V transformer, which is rated for 220VAC. For us here in the UK, with 240VAC input, we’re probably feeding that fan near it’s limit!

      Yeah, PWM through I2C-to-SPI bridge is a crazy idea! But if there are desperate needs for extra I/Os, it’s there to be used. I honestly never thought of using more than 2 thermocouples! I always have this feeling that if we can get that fan at the back spinning at the right speed to help the air circulation, with our oven’s size, the temperature gradient shouldn’t vary too much. The T-962A might be different! I’ll have to wire up a few probes to take some measurement.


      1. Anybody had a look at the SSR circuit of the original controller? It doesn’t seem to provide any type of zero-cross switching for both heater and fan. May be OK for inductive loads like the fan, but they should at least provide ZC switching for the heaters. Will there be any advantages in swapping the MOC3021 with a ZC type MOC3041? Any thoughts?


  7. OK, lots of stuff at the same time here:

    Ah, that makes sense that there would be a Schottky in there! I have the 110V version (but my UPS data logging shows that the mains voltage averages around 118VAC). Wasn’t the UK supposed to lower the voltage to 230VAC just as Sweden had raise from 220VAC to 230VAC to harmonize the EU mains voltage by the way?

    I took another look inside and you’re right, pin 1 (the one closest to the opto-couplers) of the 2.5mm pitch JST XH connector is connected straight to ground and pin 2 is connected to the rectified DC. I measured 10.2VDC there with the heater off and 9.2VDC with the heater on, a significant difference! I also measured the AC to be 9.16VAC with heater off and 8.5VAC with the heater on.. Not really sure what’s going on there except that there seems to be a significant voltage drop on the input of the transformer as the current doesn’t change much (I measured 80mA without heater and 90mA with heater which might very well just be the SMPS compensating for the drop in input voltage, and a small increase due to the fact that the opto-coupler and panel LED will be lit).

    I assumed the voltage drop would be because of the close to 8Amps of current to drive the 800W heater. Surprisingly I’m only reading 4Amps of load when measuring the input current! Tonight I measure 110VAC at the back of the power switch with heater off and 103VAC with heater on (consuming 4Amps). That’s the point where the 9VAC transformer is hooked up. That readout matches the ratio between 9.16VAC and 8.5VAC fairly well, but it means that the oven I have here only has roughly 400W of heating power(!) Long story short: Fan isn’t running close to it’s rated voltage in my oven, so it will be very interesting to see how your voltage levels are!

    Swapping to a different (thicker) IEC power cable than the one supplied increased the power to roughly 575W, so that might be something to watch out for with the 110VAC versions! Still low though.

    To be able to control the system fan either a trace has to be cut on the board or a special cable could be made that plugs in the system fan connector and then hooking into the GPIO, having the FET switch in-line. A standard logic-level gate N-ch FET could easily drive a small fan like that. No permanent modifications to the board or fan in that case. I measured the current consumption to be 80mA at 12V (lower than the specified 110mA). I did not measure locked-rotor current. I’m thinking about trying one of the TO92 2N7002 FETs I have in the junk drawer with gate connected to ADO plus a diode across the fan just to see what happens.

    The reason for having the extra two thermocouple inputs would be so that you can measure the actual board temperature simultaneously with air temperature as the boards will have quite a bit of thermal mass making it lag behind significantly. Not 100% necessary, more for fine-tuning if you have sensitive components and run hot lead-free profiles.

    As far as zero crossing detection goes, my oven has none of it for its TRIACs. I think that it might be beneficial for temperature control _not_ to have it actually as the PWM resolution will be slightly higher (otherwise you only have 100 or 120 times per second where the heater can actually turn on). If we could detect zero-crossings and feed that into the MCU instead phase dimming of the heater would be possible that in theory could produce even better accuracy, but it doesn’t seem necessary. The 32 or so levels you get now seems to be enough, and the PID loop will compensate fot the rest.

    Do you see significant EMI from switching the heater at all kinds of odd phase angels now, or what was the main reason that you wanted to switch only at zero-crossing?


    1. Harmonize with the rest of EU is probably what our politicians get told everytime they go to Brussels! My multimeter reads 238-239VAC across the power socket and I guess we’re not in line with the rest of the Europe yet!

      I get about 10V when I measure across the bridge with the heater off and no lower than 9.80V with the heaters fully on. I don’t seem to get the same voltage variations like you do. I was a bit puzzle when you said your fan’s speed changes when the heater kicks in, but now I understand why. If you run yours at 110VAC, you’ll need higher input current and thicker cables. I suggest you check those inter-connected cabling around the IEC socket and power switch. I suspect those cables are not the best of quality and need replacing. I didn’t use the included power cable when I felt that “flimsiness” when I picked it up in my hand, it will just not able to handle the current. The higher input voltage I have here has the advantage too because the cables are also carrying lesser current.

      BTW, did you take a look at the heater elements inside the oven. My heaters are marked 220V 300W. So the oven is not rated for 800W as advertised, but rather, it’s more like 650W with 240VAC input. With my power meter plugged in, I measured 2.17A with the heater on @ 100% (heat=0xff shown on terminal) and 0.15A with the heater off and the fan fully on. During idle, the oven only takes 0.03A. So that works out my oven is doing around 520W.

      I’ve a gut feeling that you can convert yours into 230VAC working if you replace the transformer and the AC fan at the back if your heaters are also at 220VAC rating. I don’t think they will make the SSR board differently for 110V and 220V versions. My board used the BT139 Triac, which should handle at least 500V.

      Your idea of hooking up a FET to control the system fan is very much like what I’ve in mind. I’ll give your code a spin in the next few days to see what I can make out of it. As for the zero-cross switching, I’m less worry about the EMI but rather, I’m trying to see if I can eliminate the “knocking” noise coming from the now PWM controlled cooling fan at the back. I tried swapping out the MOC3021 with the ZC type MOC3041, the heaters work OK, but the fan doesn’t even spin!


  8. I committed some crude code for system fan temperature control. It works and it keeps the fan silent most of the time. I had to do some serious baking to hit 40C which is when the fan turns on at the lowest speed.

    It turns out that it wasn’t the 2N7002 FETs I had, it was the 2N7000. I also tried the old trusted BC547B (with a 4k7 base resistor), both types worked with no issues. The transistor, catch diode and resistor (if using BC547B) was added to the fan cable and the additional gate/base wire was hooked up to the ADO testpoint.

    Hopefully I won’t have to disassemble the oven for quite some time now that the system fan actually works again! 🙂 (I’ve had it disconnected for a few weeks because of the noise)

    Note that the code will use the cold-junction temperature which will be the average of the TC interface CJ temperatures if found or the temperature sensor for the onboard ADCs otherwise. If no temp sensor is found at all it will run the fan at full speed all the time. I’m thinking that the logic might be expanded at some point to go through all the cold-junction sensors and base the fan speed on the warmest one.


    1. Wow, you’ve done a lot today! I feel really guilty because I spent all day partying! Now that my blood’s alcohol concentration has subsided, I’ll go home to do some measurements and let you know my findings. As for harmonizing with the rest of EU, tell our politicians!


  9. Hehe, my code contains its share of proper single malt Scotch whiskey.. Late night coding FTW! 🙂

    Interesting that the fan fails to spin with the MOC3041. Did you try upping minimum fan speed in setup? The resulting lower resolution might round the lower fan speeds down to effectively zero.

    OK, good to know that the UK is still on the high side in terms of mains voltage, I can’t say I’m super surprised given the other slow conversions (driving on the “wrong” side of the road and the whole imperial units).. 🙂 The lack of SI units problem exists on this side of the pond though. As a Swede in the US I take every opportunity to whine about that.. 😉

    I haven’t spotted any markings on my heaters yet, will have to take another look at them, but it makes sense that I got closer to 600W when using a proper power cable. At first I thought that the heaters would be in series for 220V and in parallel for 110V, but the fact that you have 220V marked on yours tend to indicate that the hookup is the same but they have two different types of heaters instead. I do have the same BT139 TRIACs and the board AC input is marked AC220V so it seems to be the same board and components.

    That 30mA idle current consumption still results in some 7.2W, which is quite a lot. I think it’s something similar for the 110V version. Sure the MCU isn’t even doing WFI when idling, but there’s definitely something else contributing as well. LCD backlight would be one thing.

    There probably won’t be too much hacking on this for a few days for me, but there’s some interrupt stuff going in (still on a separate branch) and then maybe the MCU might get some sleep every now and then.. Happy holidays!!


    1. Got my system fan working with your latest code. Fabulous! The only thing left for me to do is to wait for the boards return from the PCB house so that I can do some tidying up and put the top back for good. I’ll tried to have my blog updated with all the latest before me going into hibernation.

      I don’t know why the fan failed to spin with the MOC3041, I brought the minimum fan speed to max but nothing happened! Must be something to do with the inductive load. I’d need to do some thinking over the holidays to figure out why. Meanwhile, I only have the MOC3041 for the heaters and leave the MOC3021 for the cooling fan.

      So you’re going to spend Christmas on the other side of the pond. I wish you a very Merry Christmas and a Happy New year!


      1. Thanks a lot, I hope you had a nice holiday as well! Yep holidays in the US this year, it’s been that way every other year since me and my family moved here almost 5 years ago. Airfare was too expensive to go back to Sweden during Christmas this year.

        I’ve also been in a bit of hibernation mode during the holidays, but did manage to sort out the interrupt stuff yesterday!

        I’m curious, which PCB house are you utilizing for low volume production that uses red solder mask with what looks like sane silkscreen? (some of the prototype fabs have used ridiculously low-resolution silkscreen printing)


      2. Yeap, I spent the holidays eating, drinking, sleeping, drinking, eating and repeat, now I’ve got 11 months to bring that cholesterol level back down before I repeat this cycle again! It must be nice spending Christmas in the US, I must give that a try someday.

        I go to two places to have my PCB done. and You can have red, yellow, blue, white, black as well as the usual green. You can have it done for as low as US$9.50 for 5 pieces at 5cmx5cm. The only problem is that, although they get your board done pretty quickly, you’ll have to wait for about 2 to 5 weeks for the board to arrive at your desk! Unless you go for the DHL/Fedex route, but that cost almost as much as the boards, if not more! So if you don’t mind waiting for a few weeks, you can give it a try.

        I’ll grab a copy of your latest and try out the new interrupt serial stuff.


      3. Patrick, I wonder. I have bold question. Do you have the 2 up MAX thermocouple interface board available surplus to requirements? I made 40mm dia. 12V recirculating fan and shoehorned it into T-962 oven above IR heaters and in-between thermocouples. It is too early to judge, but so far I am very pleased. Apart from licking my cuts, as the innards of the oven are sharp and cramped. My way of thinking is, that if I recirculate the air inside, than despite the cooling fan opening at the back and perforated bottom the air pressure remains same and there will not be loss of hot air or addition of cold air from outside. And large number of thermocouples will not even out temperature across the whole oven.

        My configuration is T-962 oven running Werner’s V051 with cold junction compensation and Setup Cooling fan speed =0. When I run profiles now, the actual temperature is tightly following the set profile and even the max. temperature is reached faster than previously – due to Fan Speed = 0. I wired the fan motor directly onto the 10.2V diodes, and as the fan is silent, I leave it on all the time the oven is on. I will try smoke test (fill the oven with smoke) and see if any smoke is exiting the oven and run some soldering tests. If it all works OK, I will consider making upgrade kits. Hence the question – would you swap my recirculating fan kit for your 2 up MAX board? Do you know, or can you guess how many of these ovens are in use?


      4. I’ve a populated 2-channel board that I used previously before I switched over to a 4-channel version. You can give it a try if you want, just let me know where you want me to send it to and I’ll pop it in the post for you.

        It’s amazing that you managed to fit a 40mm fan between the heating elements and the thermocouples. I assumed that the fan and blades are made of metal, otherwise it will not withstand the heat inside the oven. Since you have the fan on all the time, may be we can find a way to PWM it like we did with the system fan, Werner may be able to help us on this. As for the number of ovens in used, I’m sure there will be quite a few given that it’s the cheapest available on the market at the moment, unless you go for the toaster oven route which, some people I know did. Your kits will need to be easily fitted with minimum tinkering, I’m sure many of them, like me, are not metal work expert.


  10. Schematics posted on wiki for project of my t962A 119v version.
    i was thinking about redesigning the controller board as a drop in replacement for this
    poor implementation. I never understood why people do not use a cold junction measurment for T/C designs.


  11. I’m also trying to connect some MAX31855s to my T962 ( as the readings I get from one of my TCs is way off).

    I could by some of those I2C to SPI converter ICs, but a cheaper alternative, which I’m going to try is to use an Arduino Pro Mini (3.3V 8Mhz) as an I2C slave to act as the bridge.

    I just need to write some fairly simple code to emulate the few commands that are used in the converter IC.

    However there may be an even easier way to do this, that does not require a converter.

    When I looked at he various Max31855 Arduino libraries, I have noticed that all of them actually use software SPI, In that they bit bang a GPIO pin to generate the SPI clock and just read the data in via another GPIO pin, and then shift and OR the single incoming bit, to get the combined 32 bits from the 31855.

    Admittedly, if you have 4 thermocouples you need 4 SS lines plus Sck plus Data In, but for 2 31855s any 4 GPIO pins would do.

    The difficulty is more likely in being able to solder to the MPU if the pins are close to each other, so perhaps the I2C bridge is actually more practical.

    But I thought I would share the idea 😉

    Liked by 1 person

    1. Yes, accessing the MAX31855s directly in the firmware would have been ideal but it will have to be software SPI, because all pins for the hardware SPIs were used up by other functions. At the time when I experiment with various options in my prototypes, software SPI did came across my mind. However, the advantages of bit-banging the SPI signals using GPIO pins will quickly outweighed by the difficulty of soldering wires to the small and narrow CPU pins. It’s not an easily repeatable process for others.

      While working through my options, I also need a way to minimize the effort for Werner to support my enhancement in his firmware, especially when I knew that he doesn’t have the hardware in his setup (remember he uses the 1-wire version of the MAX31855, the MAX31850). Using the I2C-to-SPI bridge was the best option because the code for the I2C communication was already written for the EEPROM access, it will require the lease effort for Werner to support my hardware. This is why I went down this route. Of course, there are many options you can take to enhance this project. I still have other options that I used during my prototype which I could have elaborated further, but for now, this has served me well and those enhancements has been put aside at low priority in my to-do list for this project.


  12. Thanks for the reply.

    I was going to write the bit banged SPI myself, but I agree that soldering to the processor pins would be an issue.

    I will see if I can write some Arduino code to replicate what the I2C-to-SPI bridge does, as I already have all the components to do this, and as Arduino Pro Mini’s are only a few dollars, it will be a cheaper and quicker solution for me


    1. Guys,
      I love the Arduino Idea for the TC interface, moreover is should be easy to test just TC interface without the oven with Arduino IDE 😉
      by the way may be it’s possible instead to emulate I2C slave just to emulate 1Wire slave, like this no need to grab SCA/SCL from eeprom but direct on DS18B20 DQ (may be we need to pass DS18B20 in non parasitic mode for this ? not sure or better drive also DS18B20 with the Arduino) just an idea.

      Here are example of 1Wire Slave for Arduino


      1. If your objective is to reduce the amount of wiring, the firmware already has support for the 1-Wire version of the TC amplifier, the MAX31850. So there is really no need to implement any protocol translation.


    1. Hi. I tried the Adafruit breakout board attached to T962 reflow oven with 0.5.1 FW Unified Engineering but without success.
      With the original thermocouple disconnected the system tells the Oven is at 560°C and that’s a little bit too much. Pressing F3 shows NO Cold junction compensation.
      I assume the flashing of the firmware is correct and also the solders on the board plus the 4k7 SMD resistor between 3,3V and GPIO is correct.
      The fact is that the system does not recognize the Adafruit board. Should I address some particular value or leave it as is?
      Best regards


      1. I assumed you’re using the 1-Wire version of the thermocouple amplifier boards, MAX31850, because you mentioned you wired some 4k7 resistors to the GPIO pins. Unified Engineering’s firmware supports both the 1-Wire and SPI versions with the SPI version connected through the SC18IS602B I2C-to-SPI bridge. You mentioned you disconnected the original thermocouples, did you reconnect the thermocouples to the MAX31850 boards? If my memory is correct, the cold junction compensation is provided by the MAX31850 chips, therefore the use of DS18B20 as cold junction compensation is only needed if you planed to use the on-chip ADC of the LPC2134 together with the on-board OP-Amps. So if you see No Cold junction compensation when you press F3, may be you should check the connections of the Adafruit boards or check if those boards are working as intended via, say an Arduino board.

        Liked by 1 person

  13. Hi thanks for the reply. Yes you are correct I used Adafruit MAX31850 but without success. the thermocouples attached to the external breakout board were not reading or at least not communicating with the MCU. By the way do you know if is there implemented in the firmware a display mode indicating the use of the external ADC (like “cold-junction compensation” text display) or is it simply blind and only reading the right temp from the external ADC tells you everything is ok?
    So I reverted back to the on-chip ADC and trying to see the performances.
    ls there please a guide to adjust the readouts of temp? I mean I read between the Left and Right TC a gap of approx 8°C difference and there must be an incorrect misalignment if two TC one near the other 2cm away reads different temperatures. should I rotate the two multi turn potentiometers on the PCB or should I play with the F2 settings: L/R TC gain and offset? can someone please indicate the way to calibrate the TC this way? Best regards and Happy Easter!! Thanks


    1. If you have a serial interface attached to the board you should see the boot up messages telling you what kind of devices are found, by default if the MAX31850/MAX31855 are available, they will be used. If none are found, the firmware will use the on-board ADC instead. The software will use the cold junction compensation provided by the chips instead of the DS18B20.


      1. Yes, they are the known problem, my readings for the two original probes differ by 150 degrees at high temperatures, that’s why we use the four probes including the originals (thus 4 digital TC amplifiers) and have the extra 2 probes place close to the board you’re baking. The firmware will use the extra information to compensate for any variances. Also, if your fan is under control by the firmware, you can adjust the fan speed to move the air inside the oven just enough to even out the temperature in the oven.

        Liked by 1 person

    1. Sorry, pal I have a question after reading all the comments by your great work and the hackaday post: What do you mean when you write: “..if your fan is under control by the firmware, you can adjust the fan speed to move the air inside the oven just enough to even out the temperature in the oven.” The mod adding a FET to AD0 aka “System fan control” is related to the small 40×40 FAN that is near the PCB, not the BIGGER AC powered by 230Vac. How can I control this in order to move air inside the oven?
      Is this related to the MENU Setup/Calibration MIN FAN SPEED?
      BEST REGARDS and sorry for the mess


      1. Sorry for the late reply, I’ve been rather busy lately and not able to get back to you as soon as I can. The fan that I was referring to is the large AC fan at the back of the oven which is under control by the firmware. You’re correct that the “MIN FAN SPEED” in the “Setup/Calibration menu” can adjust the amount of air movement within the oven.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s