Not a member yet?
Click here to register.

Forgotten your password?
Request a new one here.
You must login to post a message.

04/14/2024 5:56 AM
TheOtherJim and papajim, welcome to forum !

04/11/2024 6:33 PM
Zemona Welcome

04/11/2024 9:19 AM
Mrbones and sgupta, coffee drink ?

04/10/2024 1:09 AM
welcome cup, Ed K

04/09/2024 5:34 PM
TheJak99 Welcome

In Memory Of Ginny

Latest Donations
dmccallum - 10.00
JackH - 25.00
snwcmpr - 10.00
Anonymous - 2.00
Anonymous - 5.00
Users Online
Guests Online: 1

Members Online: 0

Total Members: 8,205
Newest Member: TheOtherJim

View Thread

Who is here? 1 guest(s)
 Print Thread
TC4 - Coding and tech issues
The Arduino folks just released "Arduino 1.0", the latest version of the downloadable Arduino development package. Unfortunately (inexplicably?), 1.0 is not backward compatible with previous Arduino releases. Changes will be required to most TC4 applications to run on 1.0. :@

So I suggest that TC4 users stick with Arduino 0022 or 0023 releases until I have a chance to update TC4 libraries.

Edited by JimG on 12/03/2011 12:08 PM


JimG wrote: I made a simple change to the code to trap this error.

Many thanks for your support and the links. Having the diff files to my own customised version is quite a luxury!

I've just installed the mods (couldn't access the Google site a couple of days ago, not sure why), and will wait and see what Arduino's reply is. By the way, subsequent to my last crash-observation-report the Arduino remained on and faultless for almost 48 hours before the subsequent crash; next one in less time than it took to complete the boot-up; then more than a day free from crashes - i.e. highly variable.

What is the variable that overflows - "timestamp"? Instead of simply fixing the overflow time on 59:59 it would probably make sense just to run resetTimer() wouldn't it?


Bhante wrote:What is the variable that overflows - "timestamp"? Instead of simply fixing the overflow time on 59:59 it would probably make sense just to run resetTimer() wouldn't it?

The integer variable that was overflowing was just an intermediate step in converting seconds to mm:ss format. The master timestamp probably can continue incrementing for a few centuries before overflowing.

I don't see much value in wrapping the elapsed time clock back to 00:00 after it has run past 59:59, but you are free to make whatever changes suit your needs. A couple of lines of code, max, should handle it.

Hopefully, at some point you will discover a pattern to your Arduino locking up.

I received the TC4C in record time. Thanks for getting it out so quick. Quite happy to see it fired up and reporting to pBourbon, splendid.
Is the anything I need to know about using a 20 X 4 LCD? I've searched and found about moving the buttons but little else.

Hi, Mark -

Glad to know USPS came through again :)

You don't have to do anything special to make the 20 x 4 work with the LCDapter. Just solder the pins just like you would a 16 x 2.

In the software, change this line:
lcd.begin( 16, 2 );

to this:
lcd.begin( 20, 4 );

That should take care of it.


Just what I needed to know!



JimG wrote:In the software, change this line:
lcd.begin( 16, 2 );

to this:
lcd.begin( 20, 4 );

I find the 20x4 LCD is REALLY worthwhile. Of course, to take advantage of the extra space available you have to change a few extra lines of the code! If you look at my aCatuai code in the TRY BHANTE branch of the software site you'll see one example of the benefits. I've added a decimal point to the temperatures, spaced it out a bit, and on the bottom line it displays the software version loaded (useful when you sometimes load different software/versions).
Thanks for the heads-up. I know it's not real C but even though my not real c is rusty I did manage to find and incorporate the changes. Everything up and running!

I'm new here, and only been roasting for a month manually with better results than many have reported who are roasting with a cheap air popper-- I am an Electrical Engineer. Since I'm a EE, I get the software and hardware aspects of the TC-4. I'm a bit lost (for an engineer, anyway) when it comes to Mechanical Engineering topics like heat transfer and thermodynamics. What I could use a quick answer on is the following:

I'm going to (initially at least) use an popcorn popper for the device to PID control.

Where is a good place to put an environmental temp thermocouple? I have one with pretty high thermal mass that I'd use for that measurement. For bean temperature I assume the little "bead type" small thermal mass in the air bed is the way to go?

I assume on fluid bed (air popper) I'd want to monitor the coil (nichrome wire) temperature for the "environment", correct? Is the "big thermal mass" type-K okay for that? Is using a small thermal mass type-k correct for the bean temp?

What's the consensus on this?


Fred, good to have you on board! Having the electrical side down is a big plus.

In regards to environment sensing location it totally depends on which popper. Some have enough space between the nichrome and hot air discharge to allow afixing the TC in that cavity just before the air discharges out to the bean mass. This is a good place to put it. (lock it down so it can't contact the nichrome) As far as bean temp, I've had my best read by placing the TC well above the beans off to the side. Many times you'll get a false read with too much hot air versus bean temp if placed within the bean mass.

I've never used anything but bare TC's for ET and BT as even a thin stainless sheath can cause quite a bit of lag which can cause problems with PID controllers. Some folks don't like the wear and tear of a bare TC if placed in the bean mass but with a fluidbed it's minimal and mine go for years.

1/2 lb and 1 lb drum, Siemens Sirocco fluidbed, presspot, chemex, cajun biggin brewer from the backwoods of Louisiana
First, let me say thanks to all involved in creating and producing this wonderful shield. It's a gem.

I'm running custom code with a TC4 sitting on an UNO R3. At the moment, it reads the ambient and TC1 and graphs the data out to a small TFT display. It will eventually become a Silvia PID controller.

It's all working roughly correctly, the ambient reading looks perfect and the thermocouple reading goes up when I hold it and down when I release it. However the value holding it calculates to be about 40C which triggered some suspicion on my part. So I dunked the thermocouple in an ice bath and got -20C. A second thermocouple also recorded a similar -18C.

I can't quite work out where I've gone wrong. Both thermocouples are cheapie type K's off fleabay, but even so...

Here's the snippet of the code I am using for the readings:
#define TC_TYPE typeK
ambSensor ambient( AAMB ); // MCP9800
cADC adc( A_ADC ); // adc for thermocouples
float fAmbient;
float fTempThermocouple1;
int iUptime;

void setup()
ambient.init( AMB_FILTER ); // initialize ambient temp filtering

void loop()
if(iUptime != millis()/1000) // do stuff on the second
iUptime = millis()/1000;
iVoltage = adc.readuV(); // retrieve microvolt sample from MCP3424
fTempThermocouple1 = tc.Temp_C( 0.001 * iVoltage, fAmbient);
// readings complete, code to use data goes here ...

Any ideas where I have gone wrong, or what to try next?
Hi Philip,

If you want to double-check your hardware and TCs, why not load aBourbon in the board? It wont matter if you don't have the LCD -- just connect to the COM port and monitor the ascii print statements. If they look good, it points to your custom software, but if aBourbon doesn't work, that implies a hardware problem. -bill
Great idea! I loaded aBurbon and that showed correct measurement. So I traced back through both sets of code and discovered that my voltage was being scaled incorrectly, which in turn was caused by not initialising the gain and offset. It seems the random values just happened to be close to 1 and 0 so it wasn't super obvious.

So, I added a call to:
adc.setCal(1.0, 0.0);
and it's all now working as expected.

One other question if I may. OT2 uses digital pin 10, which is also the SPI SS pin. I want to use hardware SPI for my TFT display (for performance), so for me this pin becomes unusable (even if I use a different SS, the ATmega still throws logic at this pin). Was there a specific reason to chose this pin?
Pin 10 was chosen because it can be tied to the 16-bit timer to provide PWM at the (low) frequencies useful to drive an SSR. Same goes for pin 9.

Pin 10 may still be usable for SS without making any hardware changes (it is tied to a 2k resistor for driving an open collector transistor) -- I'm not sure. In any event, if you don't need OT2 then you could unsolder/remove the NPN's base resistor.

Let me know if I can help.

Thanks again. Are pins 9/10 different from 3/5/6/(11)? I'm very curious about the low frequency ssr driving. Is there a particular library I should look at first? Perhaps better to have a look at some code or read a resource page before I launch into 101 noob questions.

As for pin 10, I've just left it as is for now. While the transistor is being triggered (along with the handy led) it's not connected to anything. I'm guessing it's not sucking too many mA or doing any harm like this. Is there any downside other than a few wasted mA?
Have a look in the PWM16 library on the googlecode site. With a tiny bit of tweaking that code, you can probably still use pin 9 for PWM on OT1, but reserve pin 10 for SS. Or you can just not use the PWM16 library and handle OT1 with your own code. Just don't connect OCR1B to pin 10 and you'll have no interference from the PWM on pin 9.

Pins 9/10 were used because they connect with timer1 for PWM. Timer1 is the only 16-bit timer/counter on the 328p.

Timer0 and timer2, which provide PWM on 5/6 and 3/11 respectively, are both 8-bit. At the Arduino's clock speed of 16MHz, the 8-bit timers are just too dang fast for switching zero cross SSR's.

The LED and the 2N3904 connected to 10 shouldn't cause any problems. For the SPI master, I think you'll need to configure 10 as an output, and then set it high. This will waste around 7mA, but should be OK otherwise.

Or you can always remove the 1K and 2K resistors.

Thanks Jim. I've had a play with the code, so think I have my head around it. Very neat to be able to set the registers to control the timer behaviour.

The bit that I am not quite there on yet is the frequency I'd use to control the a zero cross SSR. Since we're using 0-100% for the duty cycle, do I simply set the frequency to 100x slower than the mains frequency so that a cycle of 1% gives a single cycle of on time? So for 50Hz, I'd use 0.5Hz?

This feels somewhat slow to me (though I am new to this). Would it be advantageous to calculate the on/off ratio based on one cycle intervals. So a 1% duty would be 1xON, 99xOFF, with a 25% duty being 1xON, 3xOFF, and a 50% cycle being 1xON, 1xOFF etc. Or does a typical heater have a heating or efficiency delay that counters the accuracy of this approach?

The other question I have is on the sampling rate to feed the PID algorithm with. I was planning to use 1Hz by default. Anything to consider with the ratio between PID and Output frequencies? I can't decide if it's futile to update more rapidly than you can control (or if this adds accuracy to the next duty cycle). Or maybe I should just time the PID calculation to collect inputs, complete and set the duty cycle as close as possible to the next PWM cycle start?
Edited by philipm on 02/15/2012 8:24 AM
I've fallen into the trap of trying to over engineer this I think! I've rigged up a test bed using a kettle and it works nicely with sample and PWM frequencies of 1Hz (since 50Hz zero crosses twice per cycle). All working very nicely. Thanks again for the help in getting this project up and running.
Has anyone tried one of these?


It is a 32bit version of the Arduino.
There are many arduino clones and compatible boards. The benefits are things like more RAM, speed or IO pins. The downside is that not all functions and libraries may be supported and hardware functions may differ.

Have a look at their wiki:

You're also likely to get better support (if you need it) from the Arduino support groups.

As a simple example, the PWM library used by the TC4 uses timer 1 on the processor. With a different processor, this isn't going to work. So you'd have to write your own library to control an SSR (or anything else using PWM on pins 9/10).
I am having what is probably a simple problem. My TC4 is returning identical temperatures from both chan 1 and chan 2 to to artisan
Check your TC wire connections to the TC4 board. If the connections are bad it will return approximately ambient air temp readings on the channels.
Honey badger 1k, Bunn LPG-2E, Technivorm, Cimbali Max Hybrid, Vibiemme Double Domo V3
If you're comfortable (temporarily) replacing aArtisan firmware with aBourbon, you can view the continuous stream of ASCII data coming from the board, with the Arduino IDE 'monitor', Putty, Hyperterm, etc. Then you can watch the data while you track down any wiring problem. I'd remove everything and then make sure a single TC was working, and maybe move it to different inputs, and then add the 2nd TC, etc.
I've been looking at the design of the TC4. The design around the SSR output perplexed me initially. Though I think I now understand that it's a circuit allowing the higher of 5V and VIN to be used to drive the SSR Outputs without frying the Arduino.

Prior to discovering this excellent board I was planning to switch my SSR straight from an Arduino digital pin (5V and 40mA max). I didn't find it hard to find an SSR that could be switched this way. Was there a specific application or reason for this more complex output circuit? (Or just "because we can!" )
Edited by philipm on 03/05/2012 9:04 AM
"Because we can" is pretty close ;)

The thinking is/was that there might be an application requiring more than the 20-30mA that an Arduino pin can safely source. There was also consideration of avoiding overloading the Arduino's on-board 5V regulator. That was the reason for providing the VIN option.

An open collector arrangement is in fairly common use in industrial temperature controllers. The TC4 copied the arrangement used on many Watlow controllers.

Jump to Forum:

Similar Threads

Thread Forum Replies Last Post
New TC4+ Popcorn Pumper issues Building a Coffee Roaster 19 04/24/2023 9:30 AM
Arduino - TC4+ - SSR issues Dataloggers/Controllers/Rate of Rise Meters 16 11/21/2022 2:11 AM
Heating Issues with Nesco Pro Other Roasters 4 04/22/2021 1:51 PM
Repeatability Issues Due to Chaff Combustion During Roasting?? HotTop Roaster 5 01/01/2019 2:14 AM
TC4/Artisan Temp Read Issues Dataloggers/Controllers/Rate of Rise Meters 16 01/04/2018 12:03 AM
Homeroasters Association Logo, and all Content, Images, and Icons © 2005-2016 Homeroasters Association - Logos are the property of their respective owners.
Powered by PHP-Fusion Copyright © 2024 PHP-Fusion Inc
Released as free software without warranties under GNU Affero GPL v3
Designed with by NetriX
Hosted by skpacman