Help identifying IC/ADC on a sous-vide cooker

[Lorenzo_1]

Hoping to get some help identifying an ADC in a failed Sous-Vide Supreme cooker (labelled MCU on PCB).  All identifying marks have been erased by the manufacturer. After identifying pin functions tried unsuccessfully to find a match online.

Cooker is a fairly expensive item (~USD500 online currently) that was lent to me and failed after single use. Well out of warranty, no service manual or schematics online. Distributors/agents here supply no parts and don’t repair – no longer sold in Oz. Is on sale Europe but suppliers no help at all – absolutely no response to emails seeking parts/new boards.
 
System has one PCB behind the control panel allowing On/Off, temperature/time setting and heating start. Second PCB holds on RHS an SMPS supplying single +5V rail and on LHS an 8-pin DIP ADC that converts voltage mediated by thermistor on the side of the waterbath to a digital signal fed to control panel. Heating element control is via a 3-pin SCR (under a large heatsink) that is switched on-off by signals from the control panel. After eliminating +5V rail, thermistor and passive components as possible points of failure, began to suspect the 8-pin DIP ADC on the SMPS board.

Found a working unit second-hand but still hoping to resurrect and return borrowed unit. Switching boards confirmed control panel PCB is fully functional and comparative tests confirmed ADC has failed and is bleeding digital signal from output pin 6 onto the adjacent analog input pin (7) from the thermistor.  Control panel reads 140C with bad ADC and correct 29C with good ADC board. 
 
ADC Pins identified as follows:
1:  GND
2:   Input from ceramic resonator Pin 3 (GND connected to resonator Pin 2)
3:   Input from ceramic resonator Pin 1
4:   Vref(?) - connected to Pin 8 via 10k resistor and diode in parallel. 4.99V on bad and good boards.
5:   NC
6:  Digital output to control panel
7:  Analog input from thermistor
8:  Vdd - +5V

Ceramic resonator good – running at 8MHz.  Attached are photos of the analog input signal and the digital output on the good and bad boards.  Long collection photo shows analog T voltage on good ADC reducing, with dips periodically when ice added to bath.   Expanded traces shows analog in (Ch2) and digital out (Ch1) signals on good and bad ADCs (pins 6&7).

As best I can tell, the bad IC is a single channel ADC with limited functionality.  I haven’t managed to dissect the communications protocol yet, but that might be feasible with more work.  Hoping someone might be able to identify this IC from these details and photos.

[fcb]

Pin out is the same as a Microchip PIC12F675 (and others in the family).

#4 also doubles up as the _MCLR pin on the PIC and can be used during programming.  Also they might be using it as general purpose I/O.

The data shown on the 'scope looks like a fairly standard serial.

[TheMG]

Definitely a microcontroller, as the "MCU" labelling would suggest.

Unfortunately this means any replacement IC is going to require programming. You can try to read the program from the good unit, but chances are if the manufacturer went through the trouble to scrub the part number off the IC, they probably also set the code protection flag when programming it (making it impossible to extract read the program out of the IC).

Other option would be a complete reverse engineering of the good units full functionality and write your own code.

[Alti]

I think the only viable option is to replace whole module with some general purpose controller.
Or you could go old-style with mechanical switch with capilary tube for remote sensing.

[mikerj]

Are you certain it's the micro that's faulty and not some other fault on this PCB?  Might be worth lifting one or both pins and checking if this crosstalk still occurs.

[Teledog]

Was going to build a SV unit with a PID, heaters & pump.
Amazon'ed a $150 Anova & a (clear) Cambro - avec floating balls..working well for years!
(don't bother with the "WIFI feature" of the Anova..the WIFI is utterly useless & hack-able)
G'luck!

edit:
PS..most restaurants are now using the "portable" SV units ....cheap, and versatile from anything from a sink to a stand-up wine chiller ..plus Anova has fantastic customer service!

[Lorenzo_1]

Thanks for all the quick and really helpful advice.  I had hoped the IC might be a fairly simple device but looks like I grossly underestimated it.  I'll try socketing the MCU and lifting pins as suggested as a check on the rest of the board. If that doesn't throw something up I think it'll have to be assigned to the spare parts locker - unless I can get a new board from the manufacturer/distributor. I have little or no experience with microcontrollers and their programming and all the coding I do is in high level languages.  I've never found things like assembler code or C++ very digestible.   Not possible to delve into all that for the foreseeable - interesting as it would be.

Seems to me that a lot of these expensive 'user-friendly' devices are basically designed for short lifespans, limited or no repairability after warranty, and a quick trip to the waste dump. Guess it keeps the consumer goods economy churning over - at the expense of the environment.  It would be nice to see some good 'right-to-repair' legislation in place. 

[geggi1]

If you are capable of doing some programming you can look into making a new controller.
There are several exsamples of PID regulators using an arduino on the internet.
You got the controlboard and the only faulty part is the MCU just unsolder it and transplant in a Arduino connected to the pins where the MCU where seated.
You probably have to reverse engineer the whole controll board to ensure correct modification.

[Lorenzo_1]

Have spent a bit more time looking at this system - it has two microprocessors.  The Control Panel has a Samsung 3F9488XZZ-QZ88 that drives the LCD and inputs/outputs to the SMPS board with the MCU that was subject of first post.  Seemed sensible to try and work out what the MCU is doing.  It does look to be a pretty good fit for Microchip PIC12F675 family as fcb suggested.  However, one thing I can't figure at present is why Vpp on Pin 4 appears to be held at ca 4.5V (IIRC) when programming manually indicates low is 0.2V and high 12V (to enable programming).  Control panel also has Atmel 112 EEPROM. Apart from that it's mostly push button switches and passives.

I've run up a somewhat amateurish schematic of the MCU side of the board in Tina-TI (attached). For readability I've used earth symbol for 0V side of 5V SMPS supply. Main thermistor attaches to connector labelled Bot (see earlier photos). Con2 connector goes to Control Panel. MCU only has pins 6 & 7 for input/output as others are dedicated to 8MHz oscillator, Vdd, Vss and what should be Vpp. Pin 6 carries no digital signals as far as I can see - simply taking analog signals from the thermistor. Pin 7 must be carrying the digital output for temperature from the ADC - whether it's carrying other input/output from the Control Panel remains unclear at present. From the PIC datasheet that suggests Pin 6 configured as A/D input and Pin 7 as bidirectional I/O.

Switching control for the SCR is carried on Pin 5 of Con2 - this goes low to turn heater element on. Rate and duration of switching pulses are a function of how close bath is to set temperature. The EL817 optocoupler appears to be monitoring temperature/overtemperature of the SCR, which has an NTC device physically attached.  So it looks to me that all the fancy control and SCR switching control is being done on the control panel PCB by the Samsung and the MCU may be simply feeding a serial stream corresponding to analog temperature to the control panel.  In which case, a PIC12 microcontroller might look like overkill for a fairly simple job?

I've tried looking at the data stream on MCU Pin 7 with my 1630D which is good for selecting triggers, but it only has 1K memory so hard to see slowly repeating patterns. As far as I can see from manuals etc, running it via GPIB (which I've never done) will only give me a series of 1K windows into the data stream rather than the continuous stream.  Perhaps time to get something more capable...  Meantime, I'll try lifting pin/s on the MCU and see how we go.  Thanks for the advice. 

PS.  Link to the item in question.   https://sousvidesupreme.com/products/sousvide-supreme-water-oven-11l-stainless-steel

[Ian.M]

Why did the manufacturer do this crazy thing?  Well IMHO, they either bought in the main controller's code or commissioned it in-house to work with a digital sensor,  then either the digital sensor was discontinued, or they found it was too expensive or it had some other problem (e.g. transients killing it or the main MCU) and they had to patch up the design without the help of the programmer who coded the main MCU's firmware.  Using a slave MCU as an ADC is a valid strategy, but is usually only seen when you need multiple ADC channels electrically *ISOLATED* from the main MCU dirt cheap, as you only need a single optocoupler for a one-way serial link.   

Maybe its time to buy a Salae 'Logic 8' clone, which are dirt cheap and readily available on Ebay, Amazon and the usual far east marketplaces, to use with the FOSS Sigrok software.  Here's Sparkfun's tutorial.  If you post dumps in Sigrok format there are plenty of users here who can help you decode them.

If you are very lucky, we may be able to identify the protocol and match it to a digital temperature sensor IC that's still available N.O.S., in which case you may be able to replace the thermistor with a sensor IC, possibly with an extra Vcc wire to it, rip out the PIC and jumper pins 6 & 7 of its footprint.

Once you've got enough good data to make a fair guess at the protocol, you could set up an Arduino and code a sketch to decode and log the data and also the temperature from an independent probe on the water bath,  and fill the bath with boiling water then log as it cools to ambient.   That will give you the temperature vs output data relationship, which you'll need to create code for a replacement PIC.

Nearly *ALL* Microchip's 8 pin PICs have the same pinout.  If coding up a replacement, it would make sense to use one with lots of memory and a 4x PLL to boost its clock speed, so you can get away with using the XC8 C compiler in FREE mode (which disables many optimizations so generates slow and bloated code) rather than having to wrangle with PIC assembly language.

To answer your pin 4 query: on 8 pin PICs, its dual function, used to enter programming mode and also as an active low Reset pin.  It may also be an input only GPIO pin so you may well see it called out in datasheets as \$\overline{MCLR}/V_{PP}/GP3\$ (i.e.  /MCLR/V_PP/GP3  if you are having Mathjax rendering problems).  On older PICs, taking this pin up to Vpp, (>>Vdd) entered programming mode, taking it down to logic '0' reset the PIC and you needed to keep it at logic '1' (<=Vdd) for the PIC to run.  Newer enhanced midrange PICs got rid of the high voltage Vpp, as they use a different protocol for entering programming mode, but unless external /MCLR is disabled in their CONFIG bits so the pin can be used as an input, still need it at logic '1' to run code.

TLDR: Its a *LOT* of work, not commercially viable to repair, but would be a great learning project if you want to get into sensors, comms protocols and small MCUs.

[Lorenzo_1]

Thanks Ian - that's really helpful advice on a range of fronts.  Been wanting to look more at micro-controllers and the like for a while, so this looks like a good opportunity to pursue it.  I'll take another look at the USB logic analysers and look to collect the outgoing digital data across the temperature range and make sense of it. Coding a replacement Microchip PIC had crossed my mind as a potential solution given it might be doing little more than simple AD conversion without fancy arithmetic to adjust non-linearities and the like. Can't see why the makers would do that in the MCU rather than the Samsung controller.   That said, your other ideas look easier to implement - especially the sensor IC if one can be identified.

 

[Lorenzo_1]

Collected digital datastream in Sigrok readable form  at 1MB/s from the soujs-vide MCU as suggested.  Did this over period of ~500s while water heated from ~28C to 70C between 100 & 500s.  I’ve extracted 100s of that data stream in a bin file but find I can't attach that file type to a post. Grateful suggestions as to what format is best to export and post it here. Meantime attached an image of a packet with green and red markers at start and end.

Also dissected some of the data to try and identify repeating patterns in the stream.  The stream consists of a string of ‘packets’ at intervals of 1.0055s and minimum bit length of 10.052ms. That suggests each packet contains 100 bits.

Each packet appears to start with a long LO signal ~115ms long. After that there’s a string of bits, that recur in patterns of 2 or 4 bits. I’ve labelled those bits from 1 on in the Excel spreadsheet attached that shows the structure of a single packet at intervals between 100s and 450s (LHS column).  Then there’s a unique single bit (an end-of-packet marker?) preceding a long HI of variable length that appears to fill the empty bits in the packet.  So the variable part of the packet (carrying the temperature signal) appears to be between bits 19/20 and the presumed end-of-packet bit, which falls at positions 53-57 in my small subsample. 

Hoping one of the experts here may recognise this protocol or be able steer me in the right direction.  I can now collect whatever data may be helpful, but have held off trying to correlate the bit pattern with temperature at this stage. 

[fcb]

My guess is that it's just standard UART (RS232). No idea what the bit rate is, but probably low.

Looks like 6 bytes, the first byte always being 0x00.  If you scope the data a bit closer you'll probably be able to work out the bit rate, perhaps (if its safe) be able to pipe it into a PC.

[Ian.M]

Zip the SIGROK files and either attach them here, or if too big, post them on a file sharing site that does *NOT* require registration to download or use of a download manager, and link them here.

[Lorenzo_1]

After some trial and error learning managed to export a binary file from Saleae Logic2 that imports fine into Sigrok Pulseview using "Import Salae Logic export files" with file format (auto-detect), Channel count (1), Sample rate (25,000,000) and Word size (. I've captured just 50s of data from the digital temperature output pin (7) at this stage with water bath powered up and heating.  However, no change of temperature over this short duration.  Data packets follow same format I posted in xls file earlier.  If more or different is needed to identify protocol please let me know - data easily collected but will need to gather ca500s of data to get from 28C to 70C.

A read through the Microchip PIC12F675 manual (if that's what MCU is) indicates it converts an analog input to a 10-bit binary. The GPIO pins are 6-bit wide bidirectional ports.  Not sure if this helps with teasing out the signal protocol - microcontrollers are new territory for me.

[fcb]

Are you familiar with RS232?

[Lorenzo_1]

Yes - used it quite a bit over the years and had to use breakout boxes to diagnose comms failures from from time to time.  But never encountered it running over a single line.

[fcb]

So alot of microcontrollers have UART's on them - these UARTs default configuartion is normally 8N1 (8 bits, no parity, 1 stop bit).
RS232 idle condition is -ve, and TTL>RS232 drivers are often inverters, so the TTL idle level is typically +ve (logic 1). Again typically, you'll see a startbit (logic 0), 8 data bits and then a stop bit (logic 1).
You can (again typically) see a stop bit (logic 1) every 9 bits.

Not sure how good your scope trigger options are, but if you can trigger on a falling edge AFTER a long high (the start bit of the first byte), then you have nice stable triggering to examine the data on a scope.

[Lorenzo_1]

No trouble doing that - I'll have another look and do some background reading.  Thks for the guidance.

[fcb]

If it's something like RS232/UART you should find that the smallest logic1 and logic0 have the same length.

[Ian.M]

Its definitely not RS232 framing.

It appears to be 16 bit data words using a variable bit rate encoding.
The signal idles high.  All pulses are low-going.   The data word starts with an extended pulse, then it uses long and short pulses for 1 and 0, (or visa-versa, don't know which is which yet), then it terminates with a very short pulse, the same length as the high gap between bits.  It then returns to idling high till its time for the next data word.

There's one word per second, so I suspect a considerable amount of averaging is going on to get such a stable result from a 10 bit ADC that typically has some noise in the LSB(s).

I suggest as the next step, disconnect power and  checking the thermistor resistance, initially at a known room temperature, then with with enough near boiling water in the tank to get a good reading (if you think it can withstand boiling water, otherwise reduce the water temperature) + measure the water temperature with a thermometer, then again with ice water + crushed ice. 

That will give enough data to let you replace the thermistor with a variable resistor, and run it with the heater disconnected to figure out the ADC input voltage to output code, and finally to displayed temperature, mapping, and also if the code is little-endian or big-endian.

[Lorenzo_1]

Thanks Ian.  IIRC the thermistor has a resistance of ca 90-135 kOhms at operating temperatures - I used a 1.5k potentiometer earlier to pin down faults.  I'll set this up as you suggest and collect data. May take me a couple of days to get to it.

[Lorenzo_1]

Managed to get to this task.  Thermistor out of circuit reads 232kOhm at 5C and 11.9kOhm at 85.9C, using thermocouple attached to multimeter. Substituted a single-turn 1MOhm potentiometer and took series of measurements of in-circuit resistance across potentiometer terminals and temperature as displayed on the control panel LCD (shown in cells A1-B10 of attached spreadsheet) These data are plotted in the graph with a fitted parabolic curve, which is not a perfect fit). At A13 - B14 in the same sheet I've added a reading for resistance turned down to 234kOhm (this point may be anomalous as the pot showed a sudden collapse from 496k to 224k (I may need to repeat tests with a better 10-turn pot).

For each set resistance/temperature I've done a 10s LA collection - attached as zipped .bin files with the filename set out as SVttCt_rrrK.bin, where ttCt is the temperature and rrr is resistance in kOhm.  I've not yet tried to dissect the LA output and relate bit patterns to displayed temperature. Perhaps this will be helpful as is.

Note that the resistance across the thermistor in-circuit is very different to the out-of-circuit measurements taken in iced and boiled water (at cells A18-B27).  The resistance/temperature measurements in iced and boiled water line up with the measurements using the 1MOhm pot when the thermistor is attached to the PCB and the control panel is turned on (cells A25-B27).

Hope all this makes sense.

[Lorenzo_1]

Spent some time decoding the binary data in the captures I posted.  It's consistent with the 16-bit words suggested by Ian M, After breaking each into 4 x 4-bit elements, turns out the 1st and last 4 bit elements (bits 1-4 and 13-16) are identical in every word at all temperatures and look to mirror the near parabolic relationship between resistance and the Control Panel display temperature that I posted previously.  I suspect their decimal values represent something close to the integer part of the temperature divided by 10 - e.g. decimal 12 corresponds to 128C, decimal 8 to 89C. The 3rd 4-bit element (bits 9-12) looks as though it carries something akin to the decimal part of the display temperature as its decimal-converted values consistently vary over just 3-4 adjacent values.  Element 2 (bits 5-8) I need to spend more time on. 

Thinking about the similar parabolic curves for decimal data and resistance versus temperature, I wonder whether the MCU is simply passing the digitised thermistor resistance through to the control panel and leaving it to the Samsung MCU to convert it to temperature. Will explore that further.

Not planning to post any attachments till I make more progress in working out these protocols. 

[Lorenzo_1]

Took another look at the Microchip PIC12F625 datasheet that fcb suggested might be the MCU.  Seems it generates a 10-bit digital output. So took the 1st 10 bits of captures posted earlier, converted them to decimal for easier plotting, and plotted against temperature (C) and thermistor resistance in kOhm (attached as docx).  Turns out the digital output is linearly related to resistance and non-linear with respect to temperature.  So it seems the MCU is simply translating thermistor resistance ( to a 10-bit serial signal and passing it through to the control board for conversion to displayed temperature and for feedback to control temperature. For the analysis I converted LO bits 2-cycles long to digital 0 and LO bits 1-cycle long to digital 1 - following Ian.M's suggestions. That translation scheme appears to make sense of the data stream. 

Presumably the calibration/conversion factors are held in the EEProm on the control board. So the task looks to be reducing down to replacing the MCU with either another PIC12F625 or some other device that will generate a 10-bit digital version of the analog resistance with the correct digital output pattern.   Grateful any comments if I'm perhaps on the wrong track here.