topbanner.gif
Login
Username

Password




Not a member yet?
Click here to register.

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

10/17/2021 12:40 PM
Ploni and nader fouad, Welcome!

10/15/2021 2:19 AM
merlot85, maycondelpiero and hoeltz, Welcome !

10/14/2021 10:06 AM
Thanks for the addition to the group. Seriously considering building a drum roaster along the lines of oldgrumpus's. Love the design and craftsmanship.

10/14/2021 4:00 AM
Morning, ar3mia ! and... coffee drink

10/12/2021 11:55 AM
Evan Slack and CupOfJoe, Welcome !

In Memory Of Ginny
Donations

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

Members Online: 0

Total Members: 7,362
Newest Member: nader fouad

View Thread

Who is here? 1 guest(s)
 Print Thread
TC4 - Coding and tech issues
Bhante

Quote

greencardigan wrote:

I think I have fixed my freezing/reseting problem. I did the following.
- Powered the arduino from a 7.5V DC power supply rather than USB
- Putting ferrite beads on most of the inputs to the Arduino/TC4
- Adding an X2 suppression capacitor across the 240V AC fan supply.

When I had my TC4 on my Espresso machine a year ago or so I also found differences involving the power supply - with one USB power adaptor it would crash all the time, while with another only occasionally. I think the difference was that the voltage and/or current from the first was not adequate.

Since my move last year I've been having vastly more of the crashes, and I've traced the source of most of the to the fridge and/or freezer. Now I have to unplug the fridge and freezer before roasting, and hope I remember to switch it back on again! Some other things also cause crashes, such as the energy saving lamp I was until recently using for seing inside the hottop. Now I have fixed up a little LED lamp which illuminates the coffee much better anyway (I was hoping to use 12V from the hottop mainboard, but it seems the 12V supply is already not fully sufficient for the fan, and so the fan setting heavily affects the lamp).

Now I am planning to try some of Dan's chokes on the signal lines (thanks Dan!), and will report back whether I get any success or not.

Bhante
greencardigan
I'm having a little issue with my thermocouple readings. When i touch the roast chamber or braided thermocouple shielding, I sometimes get a sudden negative drop in the temp reading. See the graph below just after the 8 minute mark.

Does this suggest I need to ground the thermocouple inputs? Maybe using the spaces left for resistors on the TC4 board?

www.greencardigan.com/misc/arduino_roaster_controller/2013_03_17.png
Bhante

Quote

greencardigan wrote:
When i touch the roast chamber or braided thermocouple shielding, I sometimes get a sudden negative drop in the temp reading.

I've had blips exactly like that from time to time, I think from slightly moving thermocouple cable or USB cable, or conceivably from touching the cable or roaster; touching the metal parts of the roaster is unlikely though because it is hot, and the cable is not with a metal sheath. I had always assumed it was a contact issue, but it could also be capacitative on the thermocouple. What kind of thermcouples are you using?
greencardigan
I'm using cheap probes from eBay like these.

http://www.ebay.c...1244420165
JimG

Quote

greencardigan wrote:Does this suggest I need to ground the thermocouple inputs? Maybe using the spaces left for resistors on the TC4 board?


This could be a ground loop effect caused by the difference in potential between the TC4's GND plane and the roaster shell. If so, then one option is to force the GND plane and the roaster shell to be the same by connecting them with a wire (optionally through a 1K to 10K resistor). Use the 2-pin GNDPT header on the TC4 for this.

Lately I have been experimenting with a different solution, however, that is showing some promise. Instead of using resistors on those empty pads I have been using 0.1uF ceramic capacitors. In the limited testing I've done this has eliminated the ground loop temperature offset without having to tie the roaster and GND planes together.

The other possibility is that touching the probe leads is causing an internal short between the shielding on the probe and the thermocouple wires? This might cause a similar result.

Jim
greencardigan
Thanks for the tips. I'll try grounding the roaster shell and thermocouple shielding first to see if that helps.
Bhante
@ Jim:

In case you plan to make any new versions of the TC4 shield, here are a few suggestions:

1) It would be useful to be able to separate the I2C lines from A4 and A5, as there are many new versions of the Arduino these days, many of which use different pins for I2C, and it would seem a pity to lock users in to old technology. I suggest a simple solder jumper connection on the circuit board, which uses very little extra space. As long as the chips on board remain connected to the I2C header on the shield, the SDA and SCL lines can then be disconnected from A4 and A5 and connected by jumper leads to wherever the appropriate I2C pins are. If real estate permits, you could put an extra 2-pin header hole for SDA and SCL adjacent to the I2C header to facilitate connecting the jumpers, or if space does not permit the wires will just have to be forked.

2) Some boards use 3.3V instead of 5V. It would be worth giving a little thought to the implications of this, however it may not be serious - the Olimexino for example has both the Arduino 3.3V and "5V" pins powered with 3.3V, so with existing wiring the I2C header on the shield remain powered by 3.3V as required. Vin on the Olimexino can be anything up to 30V (the 24V battery on a heavy goods vehicle, for example), so in the case of the Olimexino we certainly don't want I2C connected to the Vin pin. As for other boards I don't know. With 3.3V boards the I2C chips on the shield can remain at 3.3V, while a little step-up board can be put in between the I2C header and the LCD to give the 5V the LCD probably requires.

3) What about putting holes on the shield for an optional jumper to short the thermocouple contacts together, where particular channels are not used? Here it makes more sense to use a pin header type jumper rather than a solder jumper, so that it can readily be inserted or removed as required, instead of having to use a special external plug. What I have found implies that for example leaving channels 3 and 4 unconnected while using channels 1 and 2 will introduce errors on channels 1 and 2, even if only 2 channels are selected in the software (and likewise for channel 2 if using only channel 1). However I have only briefly tested the effect of setting the number of channels in the software so it is possible I could be wrong on this.

4) You may remember I once suggested putting a couple of small holes (circa 0.5mm) on the edge of the board where the thermocouple wires come out from the screw connectors so that the thermocouple wires can be secured in place with a piece of nylon filament (fishing line etc). If the Arduino is mounted in a box with the USB socket accessible to the outside, and thermocouple sockets are also mounted in the box, then the wires from the TC4 to the thermocouple sockets necessarily have to bend very very sharply indeed coming out of the screw sockets. This puts an awful lot of strain on them especially when using braided thermocouple wire, and I find they come loose very easily. I find these tiny little screw clamps have great difficulty clamping the wires firmly, although it will probably depend on the type of wire and the number of filaments in the wire, size of wire etc. So I think it would be very helpful to be able to bind them in place with a little nylon filament.

5) I would much prefer to have the thermocouples moved to any one of the other 3 sides of the board, but the conclusion last time we discussed this was that there is simply not the space available to achieve this; nevertheless I'll leave this suggestion here in case you think it makes sense to turn the bourd around. Putting the OT1, OT2, I/O3 connectors on the USB side obviously makes some sense for easy connections to the roaster and the thermocouples can then be on the opposite side, but that is only possible by changing the whole layout which you probably don't want to do.

6) Just a wild idea - have you ever thought about a move away from the shield concept altogether? After all, since we are no longer using the parallel LCD pins, most of the Arduino connections are now through the I2C port, apart from the PWM pins and optionally the analog pins. Therefore instead of mounting the board on the Arduino as a shield you have it adjacent with a handful of pins coming out for I2C, PWM and analog, which can then be connected to whatever pins you like on the microprocessor. I am thinking of this from three perspectives: firstly this leaves more or even all the arduino shield pins free for any other shields you might want to connect (on some of the Arduino compatibles for example you can connect all the I2C, PWM and Analog pins you need to non-shield pins); secondly some Arduino boards and likewise some compatibles have certain incompatible pins such as I2C etc, and also boards like the Nano have their pins in completely different places; and thirdly the TC4 can potentially be used in many different ways with many different microprocessors, most of which do not have the Arduino form factor. There is no reason not to connect it to an STM32 Discovery board for example, if someone wants to modify the software and libraries or use completely different software.

As you might gather from the above I am looking closely at the Olimexino (Maple compatible) at the moment, which has many attractive features such as a STM32F103RB ARM Cortex M3 32 bit processor running at 72MHz, 128kB flash, 20kB RAM, noise immune design (according to the manufacturer), industrial operating temperature range, 3.3V to 30VDC input, automobile/industrial environment compatible, built-in LiIon charger and automatic power switching between USB, DC and LiIon (unlike the Maple where you have to set jumpers), ultra low power design, 37 digital IO pins, 16 PWM pins all at 16 bit, 15 Analog pins at 12 bit, 2 I2C ports, 2 SPI ports, 3 serial ports plus independent USB port, 4 timers all much more advanced and flexible than the Arduino timers, built-in real time clock, built-in microSD socket, CAN port, etc etc ... all at less than the price of an Arduino (at official prices) and only half the cost of the far inferior Maple. The board manufacture quality looks excellent.

With the Olimexino or something similar you could probably put all the Processing software onto the board itself, mount a 5 inch TFT/touchscreen for realtime onboard plotting, and log results to the microSD card and store profiles there. Probably you could also use a (replacement) iPhone display and touchscreen, which you can buy as spare part from China for about 10 to 15 Euros (or other smartphone displays - some of them probably have easier interfaces than others). That seems to me to be the way for the future.

Bhante

(Sorry it's a long post, hope your coffee is not cold!)
bvwelch
I did some early prototyping for the TC4, at 3.3 volts with a JeeNode. So the essential chips will run fine at 3.3 volts. I have a 3.3 volt LCD but no time to play with it.

Another project waiting in the wings is the marrying the TC4 to the Raspberry Pi. -- so many projects, so little time.
Bhante
... Jump ahead to 2020 ... wait, maybe 2015 ...

Hmm, would be nice to have one of these onboard the TC4:

the chip:
http://www.ti.com...uct/cc2541

application example:
http://www.ti.com...1dk-sensor
http://processors..._SensorTag
http://processors...User_Guide

Bhante
JimG

Quote

Bhante wrote:

1) It would be useful to be able to separate the I2C lines from A4 and A5, as there are many new versions of the Arduino these days, many of which use different pins for I2C, and it would seem a pity to lock users in to old technology. I suggest a simple solder jumper connection on the circuit board, which uses very little extra space. As long as the chips on board remain connected to the I2C header on the shield, the SDA and SCL lines can then be disconnected from A4 and A5 and connected by jumper leads to wherever the appropriate I2C pins are. If real estate permits, you could put an extra 2-pin header hole for SDA and SCL adjacent to the I2C header to facilitate connecting the jumpers, or if space does not permit the wires will just have to be forked.

This is actually already in the works.

Quote

Bhante wrote:
2) Some boards use 3.3V instead of 5V. It would be worth giving a little thought to the implications of this, however it may not be serious - the Olimexino for example has both the Arduino 3.3V and "5V" pins powered with 3.3V, so with existing wiring the I2C header on the shield remain powered by 3.3V as required. Vin on the Olimexino can be anything up to 30V (the 24V battery on a heavy goods vehicle, for example), so in the case of the Olimexino we certainly don't want I2C connected to the Vin pin. As for other boards I don't know. With 3.3V boards the I2C chips on the shield can remain at 3.3V, while a little step-up board can be put in between the I2C header and the LCD to give the 5V the LCD probably requires.

The output stages of the TC4 currently use BJT's in an open collector arrangement. I doubt this will work well at 3.3V. Future versions of the TC4 will probably use NMOS instead. LCD panels which operate at 3.3V are available. VIN is not used for anything on the TC4 these days.

Quote

Bhante wrote:

3) What about putting holes on the shield for an optional jumper to short the thermocouple contacts together, where particular channels are not used? Here it makes more sense to use a pin header type jumper rather than a solder jumper, so that it can readily be inserted or removed as required, instead of having to use a special external plug. What I have found implies that for example leaving channels 3 and 4 unconnected while using channels 1 and 2 will introduce errors on channels 1 and 2, even if only 2 channels are selected in the software (and likewise for channel 2 if using only channel 1). However I have only briefly tested the effect of setting the number of channels in the software so it is possible I could be wrong on this.

Good idea. Real estate is difficult in that area, but I will try and implement. Probably will require a larger shield footprint, though.

Quote

Bhante wrote:

4) You may remember I once suggested putting a couple of small holes (circa 0.5mm) on the edge of the board where the thermocouple wires come out from the screw connectors so that the thermocouple wires can be secured in place with a piece of nylon filament (fishing line etc). If the Arduino is mounted in a box with the USB socket accessible to the outside, and thermocouple sockets are also mounted in the box, then the wires from the TC4 to the thermocouple sockets necessarily have to bend very very sharply indeed coming out of the screw sockets. This puts an awful lot of strain on them especially when using braided thermocouple wire, and I find they come loose very easily. I find these tiny little screw clamps have great difficulty clamping the wires firmly, although it will probably depend on the type of wire and the number of filaments in the wire, size of wire etc. So I think it would be very helpful to be able to bind them in place with a little nylon filament.

Again, this is simply a matter of real estate. I liked the idea then, and still like it. But the shield would have to become bigger to accommodate.

Quote

Bhante wrote:

5) I would much prefer to have the thermocouples moved to any one of the other 3 sides of the board, but the conclusion last time we discussed this was that there is simply not the space available to achieve this; nevertheless I'll leave this suggestion here in case you think it makes sense to turn the bourd around. Putting the OT1, OT2, I/O3 connectors on the USB side obviously makes some sense for easy connections to the roaster and the thermocouples can then be on the opposite side, but that is only possible by changing the whole layout which you probably don't want to do.

I'll have a look at this in association with developing the changes needed for the new locations of the I2C pins. It is a pretty major rearrangement of the board!

Quote

Bhante wrote:
6) Just a wild idea - have you ever thought about a move away from the shield concept altogether? After all, since we are no longer using the parallel LCD pins, most of the Arduino connections are now through the I2C port, apart from the PWM pins and optionally the analog pins. Therefore instead of mounting the board on the Arduino as a shield you have it adjacent with a handful of pins coming out for I2C, PWM and analog, which can then be connected to whatever pins you like on the microprocessor. I am thinking of this from three perspectives: firstly this leaves more or even all the arduino shield pins free for any other shields you might want to connect (on some of the Arduino compatibles for example you can connect all the I2C, PWM and Analog pins you need to non-shield pins); secondly some Arduino boards and likewise some compatibles have certain incompatible pins such as I2C etc, and also boards like the Nano have their pins in completely different places; and thirdly the TC4 can potentially be used in many different ways with many different microprocessors, most of which do not have the Arduino form factor. There is no reason not to connect it to an STM32 Discovery board for example, if someone wants to modify the software and libraries or use completely different software.

In its present state the shield can be separated from the Arduino by using a 4-wire cable connected to the I2C header on the TC4. Use of the shield's input/output pins is lost, but the temperature logging capability is preserved since all of the IC's on the shield are I2C anyway.

Jim
Bhante

Quote

JimG wrote:

Quote

Bhante wrote:

4) You may remember I once suggested putting a couple of small holes (circa 0.5mm) ...

Again, this is simply a matter of real estate. I liked the idea then, and still like it. But the shield would have to become bigger to accommodate.

Quote

Bhante wrote:
6) Just a wild idea - have you ever thought about a move away from the shield concept altogether? ...

In its present state the shield can be separated from the Arduino by using a 4-wire cable connected to the I2C header on the TC4. Use of the shield's input/output pins is lost, but the temperature logging capability is preserved since all of the IC's on the shield are I2C anyway.

4) I've just drilled some tiny holes on my 4.0 shield - location is not so good but it is do-able. If the track on the top layer going from under the reset button to pin 1 of the Jee connector could be moved about 2mm closer to the edge of the board, and likewise the track immediately below it on the bottom layer, this would allow an optimal position for the holes just where the + and - are screen printed. The + and - print could then be moved out 1.5 mm and the TCn print 0.5mm in the opposite direction.

6) In addition to the I2C and power, just adding 4 extra digital lines for OT1-2 and I/O3-4 (and optionally 2 for the analog headers) - maximum 10 connections including I2C - would preserve full capability of the TC4. The Jee port (where desired) is actually more an Arduino connection than a TC4 connection, likewise the reset button - that means you could save 24 pin connections on the TC4 plus the reset button, which nearly doubles the available space on the TC4!! Furthermore the layout - which as shield is heavily constrained by the needs of the Arduino pinout - could be optimised saving further space, and also optimised from the point of view of signals (not sure how much EM noise those transistors produce, but moving them away from the thermocouples and the MCP3424 closer to the thermocouples couldn't be a bad thing). That would leave enough space on the (say!) TC4B for pads for optional optoisolators for the I/O pins as well as jumpers for the thermocouples and space for a few other things. Then the TC4 and Arduino (any, including Nano etc) could be mounted side-by-side in a box instead of vertically.

I must say, Arduino is small, but as soon as you put it in a box it is big! Firstly because the 55mm x 70mm does not fit well with most boxes, and secondly because with the shield it is then too fat for almost all small boxes. So this would be a big bonus for the side-by-side arrangement in addition to pin flexibility for different Arduino versions and also non-Arduinos.

Of course diverging into another board option has its disadvantages too, since you already have an impressive range of different boards to maintain and it also increases the cost per board layout, but that depends primarily on how many people are using TC4; and the TC4 has many uses outside coffee roasting!

PS - if you put solder pads on the two holes for the locating pins of the thermocouple terminals, the terminals could optionally be turned around so that they point inwards! Not sure it is an ideal solution though, and might not work for the new 8-in-a-row terminals - how many locating pins do they have?
Edited by Bhante on 04/01/2013 12:03 PM
JimG

Quote

Bhante wrote:
PS - if you put solder pads on the two holes for the locating pins of the thermocouple terminals, the terminals could optionally be turned around so that they point inwards! Not sure it is an ideal solution though, and might not work for the new 8-in-a-row terminals - how many locating pins do they have?


The 8-position terminals do not have locating pins.

Jim
Bhante

Quote

JimG wrote:
The 8-position terminals do not have locating pins.

Can the whole block be turned backwards, or is there any reason why it would not fit? Perhaps it is not ideal having the thermocouple wires directly over the board, but there are no inductive components so I suppose it shouldn't be serious.
JimG
Turning backwards should work fine.

Jim
atsamattau
I know this is probably redundant or not the right place to ask, but I am overwhelmed by all of the information and have a simple question.

I want to get started with a TC4C and would like to know which Arduino is the most capable version the TC4C will work with. Is it the Mega 2560? Has anyone used it with the ADK? Is there any reason to stick with the regular UNO? Will it work with the DUE?

Any help is appreciated. Thank you.
atsa lot a pizza pie, mozzerella too
peperroni, provalone
atsa matta u?

Astra Mega 2C Auto, Nuova Simonelli Beach, La Pavoni Europiccola, Brassilia Club, Gaggia Classic, Enrico of Italy Lever, Cunhill Full Metal & Bosch Burr Mills, etc,....

Got crema?
happycat

Quote

atsamattau wrote:

I know this is probably redundant or not the right place to ask, but I am overwhelmed by all of the information and have a simple question.

I want to get started with a TC4C and would like to know which Arduino is the most capable version the TC4C will work with. Is it the Mega 2560? Has anyone used it with the ADK? Is there any reason to stick with the regular UNO? Will it work with the DUE?

Any help is appreciated. Thank you.


TC4C doesn't need an Arduino... It incorporates an Arduino and TC4 board together in one board.
atsamattau
Yes I know, How about if I rewrite the question without the C on the end...


....I want to get started with a TC4 shield and would like to know which Arduino is the most capable version the TC4 will work with. Is it the Mega 2560? Has anyone used it with the ADK? Is there any reason to stick with the regular UNO? Will it work with the DUE?

Is that better?
atsa lot a pizza pie, mozzerella too
peperroni, provalone
atsa matta u?

Astra Mega 2C Auto, Nuova Simonelli Beach, La Pavoni Europiccola, Brassilia Club, Gaggia Classic, Enrico of Italy Lever, Cunhill Full Metal & Bosch Burr Mills, etc,....

Got crema?
JimG

Quote

atsamattau wrote:
....I want to get started with a TC4 shield and would like to know which Arduino is the most capable version the TC4 will work with. Is it the Mega 2560? Has anyone used it with the ADK? Is there any reason to stick with the regular UNO? Will it work with the DUE?


A regular Uno is the best.

It can be made to work with Mega, but the locations of the I2C connections are different on these boards, so bending of pins and fly wires would be needed. The TC4 makes extensive use of the I2C bus.

On the Uno and older boards, pins A4 and A5 carry the SDA and SCL signals needed for I2C. On the Mega, the SDA and SCL pins are separate from A4 and A5.

The Due is a 3.3V board, so using it with the TC4 (designed for 5V operation) would probably create issues with the on-board LED's and the transistors used on OT1 and OT2. The "important" chips on the TC4 would probably work OK, but I am not aware of anyone having verified this. The SDC and SCL signal issue described for the Mega is also an issue with the Due.

I don't have any experience with ADK, so I can't answer that one. Best guess is that the I2C interface issue described above applies.

Jim
atsamattau

Quote

JimG wrote:

Quote

atsamattau wrote:
....I want to get started with a TC4 shield and would like to know which Arduino is the most capable version the TC4 will work with. Is it the Mega 2560? Has anyone used it with the ADK? Is there any reason to stick with the regular UNO? Will it work with the DUE?


A regular Uno is the best.

It can be made to work with Mega, but the locations of the I2C connections are different on these boards, so bending of pins and fly wires would be needed. The TC4 makes extensive use of the I2C bus.

On the Uno and older boards, pins A4 and A5 carry the SDA and SCL signals needed for I2C. On the Mega, the SDA and SCL pins are separate from A4 and A5.

The Due is a 3.3V board, so using it with the TC4 (designed for 5V operation) would probably create issues with the on-board LED's and the transistors used on OT1 and OT2. The "important" chips on the TC4 would probably work OK, but I am not aware of anyone having verified this. The SDC and SCL signal issue described for the Mega is also an issue with the Due.

I don't have any experience with ADK, so I can't answer that one. Best guess is that the I2C interface issue described above applies.

Jim


Thanks Jim, I'll start with a regular Uno and go from there, it looks like it would be fairly easy to get it to work with any of them and even the clones and look a likes with some work, but thanks for the direction, I just need a place to start and was wondering the quickest way to get one going.

I was mainly interested in the voltage levels, sticking with 5 volts makes it easier to work with other hardware, and pulling them down to 3.3V would be easy enough (I would think anyway) for using it with the Due, but I will probably start with a Uno or one of the clones.

I've been trying to read as much as I can, wow, there is a lot of information, I had no idea people were doing this. I went through a DIY CNC craze and have a couple of routers and a lathe and mill to work with so building roasters should be a lot of fun.

Thanks again.
JimG
Another option might be to not stack the TC4 on to the Arduino.

The I2C header (4 pins, labeled I2C) on the TC4 will provide access to the temperature sensing system and the EEPROM on the shield. You would lose the functions of OT1, OT2, I/O2 and I/O3 since those ports rely on the connections made through the stacking header. But if you are only using the TC4 as a temperature reading device that should not be a problem.

So you might want to try making a 4-wire cable that carries Vcc, GND, SDA, and SCL and connect it to the TC4. Be sure and consult the TC4 schematic to get the signals in the correct positions on the 4-pin header.

Jim
Jump to Forum:

Similar Threads

Thread Forum Replies Last Post
Heating Issues with Nesco Pro Other Roasters 5 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
Lack of airflow or stale beans (or other issues)? Kaldi roaster troubleshooting. Roasting Coffee 21 03/20/2017 9:04 AM
Fluid-o-Tech Vibrator Pumps Equipment re-builds, reviews, fix it's and more 2 05/28/2016 8:18 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 © 2021 PHP-Fusion Inc
Released as free software without warranties under GNU Affero GPL v3
Designed with by NetriX