Who is here? 1 guest(s)
 Print Thread
4-channel TC meter and datalogger project
SteveN

Quote

stoneguard wrote:
Just in looking over everything with the TC4, I am very interested in purchasing one myself, but have to admit a little fearful that I will get it and just stare at it. At this point in my roasting, I would love to have a data logger with real time display. Is that primarily what the TC4 is? I admit to not having read this whole thread - lots to sort though - so I am a bit confused by the different programs (Kona/Bourbon). And I am wondering how easy it would be for me - a programmer, but not a circuit board developer - to use this?


Phil: As someone who is neither a programmer nor a circuit board developer, I think I can say that the information provided by all those involved is extensive and clear. I have never soldered a circuit board before this and mine seems to be working ok.

I now have the bourbon (only thermocouple datalogging) program working. I will likely soon try Catuai (combination of bourbon and SSR output with manual control) to get started and seen how my new roaster works. Once I get a bit more familiar I want to move to a more automated system: Kona (PID with selectable profiles with both heater and fan control + datalogging). I'm hoping to be able to modify Kona or take pieces of the code already put together but this will likely be a long process for me (see above... not a programmer)

Based on my understanding, the board can do more... a programmer might be well positioned to take advantage of that. I'm certainly not smile
 
JimG

Quote

stoneguard wrote:
At this point in my roasting, I would love to have a data logger with real time display. Is that primarily what the TC4 is?

Probably best to think of the TC4 as programmable interface hardware for multiple thermocouple sensors.

Currently available applications that use the interface:

1. Bourbon
2. Catuai (pre-release, but I am using it and satisfied it works)
3. Kona

Each of these programs support both standalone operation using an LCD display and/or data logger operation if the TC4 is attached via USB cable to a PC.

Bourbon is a straightforward monitoring and logging application. When used as part of a standalone system it displays elapsed time, BT, ET, and BT-RoR on a 2-line LCD. Since Bourbon creates and sends a continuous data stream over the USB serial interface, realtime graphic display of roast history as well as CSV format data logging can be done if you connect the TC4 to your computer.

Catuai is very similar to Bourbon. In addition to the above, by connecting 1 or 2 potentiometers to the analog input 3-pin headers provided on the TC4 board, you can manually control one or two PWM SSR outputs. I'm using this feature for manual heater control on my Hottop. Catuai also supports an optional 4-button interface (1=reset timer at start of roast, 2=mark first crack, 3=mark second crack, 4=mark end of roast).
http://code.googl...es/aCatuai

Both of the above offer a couple of different ways to connect an LCD display, if you choose to use a standalone display. Or you can use the PC interface only. In the hardware section of the SVN archive there is some documentation for an LCD adapter board that works with both of these programs. But that adapter board is strictly optional.
http://code.googl...rdware/LCD

Kona is a much more powerful program that offers PID control. I'll refer you to Randy's posts here, and the online documentation, for a summary of features.

Jim
 
stoneguard
Jim, Thanks for the clean summary! This should go on the page where the board is, so it doesn't get lost smile http://www.mlgp-l...o-pcb.html. I am in the process of actually reading back through the thread now and starting to glean some of this information. I will likely be purchasing one of the boards today or tomorrow.
 
rama
Following up on the over-sensitive reported RoR, I installed the latest Arduino bits, and ran the latest Bourbon logger. The sensitivity may have been exacerbated. (Disclaimer: this was a 6oz roast and I typically do 7oz roasts. Given the TC placement, its possible the beans weren't fully covering the TC probe all the time. Couldn't tell as the TCs are installed in the drum's back wall.)

In either case, for my setup, the RoR average- here shown as a 20 second average post eject, thus the wacky numbers- was very helpful. I may even try forgoing the plotting of RoR, and instead rely on 1s, 5s, 10s, and 20s RoR averages to try to steer things.

If anyone else is interested in the RoR averaging, its now committed: https://code.goog...tail?r=225
rama attached the following image:
13oct2010-roast.jpg

Edited by rama on 10/13/2010 7:17 PM
 
JimG
Hi, Rama -

I just happened to be browsing the googlecode site and saw your pBourbon revisions. Thanks! I think the idea of a user-selectable averaging on the PC side is a nice approach.

Would you be willing to do some testing of RoR by varying the filtering on the Arduino side? The current source for aBourbon.pde provides a means of really dialing up the filtering for RoR. I assumed (but only confirmed on one roaster) that varying the filtering level within aBourbon could be successful on its own, without having to perform additional averaging calculations on the PC side.

Anyway, this line

#define RISE_FILTER 70


in the aBourbon.pde code can be changed to smooth out RoR. If you are so inclined, I would love to know the effects (on your roaster) of changing this value to 80, 85, 90, or even 95. The RoR trace should smooth out significantly with higher levels of filtering, and should theoretically flatline with a filter level of 100.

With either the digital filtering approach, or the N-sample averaging approach, the penalty for smoothing out RoR is delay. With a 20-sample average, you are going to see values as they were 10 seconds ago, for instance. Higher levels of digital filtering have a similar effect.

Thanks for any testing you're willing to do on this!

Jim
 
rama
Hi Jim-

I recall you mentioning the rise filter, but thought you also said its default value should be plenty stable, so expected this jumpy RoR to be unique to my roasting setup. I'd be curious what others are seeing.

I'll absolutely try out the rise filter tweaks and report back. (Obviously I can't do this with an empty roaster, and I typically roast every 3 days, so it'll take a bit of time for results.) The delay in reported values when averaging or more heavily filtering is acceptable to me-- the Hottop I use certainly can't turn on a dime anyway. ;)

--Rama
 
rama
I'm also curious what the end state looks like for those who've already built and use the TC4. Here's mine- the "enclosure" is just a recycled SparkFun box with a battery pack taped to the outside should I wish to run it without the USB connection. Eventually I'll relocate it to something more durable, attached with screws to the lower back wall of the Hottop, so the only exposed cable will be the USB one.

BTW, that potted plant behind the upper left corner of the laptop is a coffee plant.
rama attached the following image:
roaster-setup.jpg

Edited by rama on 10/13/2010 10:27 PM
 
farmroast
Observation from peanut gallery,
Still using Jim's first RoR unit,
I've been using the meter reading #s during roast I don't even notice the noise anymore.
I haven't been datalogging. One roast I wrote the readings every 15secs and put them in 3 columns start-300F, 300-400f, 400-finish.
I really liked this format as a way to review the roast and use to compare.
Ed B.
DreamRoast 1kg roaster, Levers, Hand Mills http://coffee-roa...gspot.com/
 
rama
And lastly while I'm here, http://www.allied... emailed me a 10% coupon, 20% if you spend > $100, good through October 20. The code is SAVEMORE in case anyone's interested.

I was pleased with my experience when ordering TC4 parts from them a few months ago, when Digikey and Mouser were out of stock on various components.

No affiliation, YMMV, etc...
 
JimG

Quote

rama wrote:I recall you mentioning the rise filter, but thought you also said its default value should be plenty stable, so expected this jumpy RoR to be unique to my roasting setup.

A filtering value of 70 percent worked pretty well with some captured data, and also gave me reasonable results on my Hottop. But looking at your traces and some others, I guess maybe I jumped the gun.

Will be interesting to see whether manipulating the filtering value can completely control the smoothness of the RoR trace on the Arduino side. The nice thing about doing all of the filtering on the Arduino side is that you get identical results on a standalone LCD display or on your PC screen that way.

Jim
 
patf11

Quote

randytsuch wrote:


I'm pretty sure there are still a few bugs in there, but it is also can be hard to test your own code, you know what to expect, and what the code is supposed to do.

I am getting tired of testing, and I think I am hitting the point of diminishing returns, so I think its time to enlist whoever is willing to try Kona.

Randy



Certainly true about code testing, I have been associated with hardware/software for 25+ years, testing can be the most frustrating and misleading phase.
I am planning to try kona soon; my only remaining hurdle is getting 5 stable buttons. Appears the buttons I have are too noisy for a resistor ladder, digital is fine. I also have a 5 function joy stick that should work for the upcoming kona release. Currently thinking about either moving the LCD to serial or implementing a port expander on serial bus so joystick can be implemented on individual ports. Serial expander circuitry is simple enough but JeeLabs has a inexpensive port expander for not much more than parts would cost.

Port expander http://www.modern...ander-plug as well as LCD serial expander http://www.modern...bs-lcdplug.

[Hint]
Unless Jim is willing to sell a couple of his LCD expander boards, I think I will order the port expander since end result is more available ports.
[/hint]
Comments welcome on this approach for buttons.

Patrick
 
JimG

Quote

patf11 wrote:
[Hint]
Unless Jim is willing to sell a couple of his LCD expander boards, I think I will order the port expander since end result is more available ports.
[/hint]
Comments welcome on this approach for buttons.

Of course willing -- if I had any. I'm waiting on a new prototype from BatchPCB right now but do not have anything else ordered. If there is enough demand, I'd be happy to place a larger order and offer them here at cost.

My LCDapter only supports a max of 4 buttons, though (along with 3 LED's). In hindsight, Randy and I probably should have conspired to create a standardized interface for the TC4 family of applications :|

Jim
 
randytsuch

Quote

patf11 wrote:
I am planning to try kona soon; my only remaining hurdle is getting 5 stable buttons. Appears the buttons I have are too noisy for a resistor ladder, digital is fine. I also have a 5 function joy stick that should work for the upcoming kona release.

Patrick


Patrick
The upcoming version of Kona has all of the buttons on the Analog inputs, but only two are on a resistor ladder circuit, I had problems with noise too.

So, I have one each on three inputs, and 2 and one other input. Details are in the user manual I uploaded the other day.

One problem with my current implementation is that it conflicts with Jims program, which wants to use a couple of analog inputs for pots.

I am trying to decide how to implement buttons in the next version, whether to use a port expander for the buttons, or move the buttons back to IO pins, and move something else to the port expander.

Randy
 
patf11
Randy,

Ports are definitely in short supply. I do think Jim is on the right track with his LCD module, moving the LCD and 4 buttons to expander will certainly free up a lot of ports on the main board. The only possible issue is delays in reading buttons over the serial interface while the LCD is updating, however this does not seem likely.

I did download the svn version of kona. The concept of breaking out the code into modules is a great idea. Seems even if you end up take a different route for buttons all I would have to do is maintain a small module for the buttons in my hardware implementation.

Think I will order the JeeLabs expansion board, it is inexpensive and should be easy to implement into the latest kona.

Patrick
 
bvwelch
Hey Patrick,

I think you'll like the JeeLabs stuff - I came very close to going with the JeeNode approach for this project but I figured that the more typical Arduino and 'shield' would have a wider appeal. I have several of the JeeLabs widgets including the LCDplug so have fun.

By all means, please join us in working on the code - arduino or pc or both - send me or Jim a PM and we'll add you to the list over at google code.

Thanks! -bill
 
bvwelch

Quote

JimG wrote:
Probably best to think of the TC4 as programmable interface hardware for multiple thermocouple sensors.

Currently available applications that use the interface:

1. Bourbon
2. Catuai (pre-release, but I am using it and satisfied it works)
3. Kona

Each of these programs support both standalone operation using an LCD display and/or data logger operation if the TC4 is attached via USB cable to a PC.

Bourbon is a straightforward monitoring and logging application. When used as part of a standalone system it displays elapsed time, BT, ET, and BT-RoR on a 2-line LCD. Since Bourbon creates and sends a continuous data stream over the USB serial interface, realtime graphic display of roast history as well as CSV format data logging can be done if you connect the TC4 to your computer.

Catuai is very similar to Bourbon. In addition to the above, by connecting 1 or 2 potentiometers to the analog input 3-pin headers provided on the TC4 board, you can manually control one or two PWM SSR outputs. I'm using this feature for manual heater control on my Hottop. Catuai also supports an optional 4-button interface (1=reset timer at start of roast, 2=mark first crack, 3=mark second crack, 4=mark end of roast).
http://code.googl...es/aCatuai

Both of the above offer a couple of different ways to connect an LCD display, if you choose to use a standalone display. Or you can use the PC interface only. In the hardware section of the SVN archive there is some documentation for an LCD adapter board that works with both of these programs. But that adapter board is strictly optional.
http://code.googl...rdware/LCD

Kona is a much more powerful program that offers PID control. I'll refer you to Randy's posts here, and the online documentation, for a summary of features.
Jim


Hey Jim, nice description, I took the liberty of pasted it over on the google code site as well. Feel free to improve, delete, as you see fit.

http://code.googl...c4-shield/

thanks! -bill
Edited by bvwelch on 10/14/2010 6:48 PM
 
JimG

Quote

bvwelch wrote:
...I took the liberty of pasted it over on the google code site as well.


Thank you. Much appreciated.

Jim
 
bvwelch

Quote

rama wrote:
If anyone else is interested in the RoR averaging, its now committed: https://code.goog...tail?r=225


Glad you're working on noise -- I have similar noisy RoR here.

I was thinking that it will be better to let the Arduino do the filtering -- Jim has implemented a nice 1st-order low-pass filter routine - we just need to learn how to tune it.

But, if you do want to add filtering to the PC side, perhaps it should be disabled by default, to avoid confusion? thanks! -bill
 
JimG

Quote

patf11 wrote:
Think I will order the JeeLabs expansion board, it is inexpensive and should be easy to implement into the latest kona.

On Bill's suggestion I put a 6-pin Jee-compatible header on the version 3.00 TC4 board (the one you have). I didn't have any way to test it, so I'm anxious to hear from you how it works.

The Jee LCD plug uses the 8-bit version of the MCP23017 port expander that I'm using on my LCD adapter. FWIW, the only reason I didn't just use the Jee LCD plug design was because I wanted the buttons, and there were no available ports on the 8-bit expander.

Jim
 
bvwelch
About the RoR graph/plot - I may try plotting it X1, instead of X10, and adding a bias of 100, perhaps that would make it easier to use? Or I may just keep increasing the filtering on the Arduino side. I hope to do some roasting today. I'm getting tired of this 8-o-clock Columbian... :-)
 
JimG

Quote

bvwelch wrote:
...Or I may just keep increasing the filtering on the Arduino side.

Not tryin' to tell ya what to do, but it would sure be helpful to have some more data on performance with different levels of filtering B)

Jim
 
rama
I roasted a "mother-in-law" coffee for the sake of experimentation. ;) This is 8oz (an ounce *more* than typical for me, just to help smooth things out as much as possible), with the Arduino rise filter set to 85%.

For my application, its much better in regards to the overly sensitive default value of 70%, however I believe it will need to be filtered a bit more. You can see the wild RoR peaks and valleys, even though the only change I made on the Hottop was to cut heat to 50% at minute 12.
rama attached the following image:
19oct2010-roast-log.jpg
 
bvwelch
Thanks for the update Rama. That sure looks better to me. Did the change in the Arduino filter have any adverse effect to your 'average RoR' ?
 
patf11
Received the JeeLabs expander and does indeed work as advertised. Tried JeeLabs idea of bit/banging digital ports as well as more "normal" A4 & A5 analog ports for I2C, both work fine. No surprises as plug is about as simple as one can expect. The JeeLabs connector on TC4v3 works fine (thanks Jim) as well as I2C connector. Currently have implemented on TC4v3 I2C connector at address 0x20 with a joystick that gives five buttons, this seems to save the most ports. Means there are 3 left for whatever? Any ideas as to using LEDs for some purpose or more buttons?

I did use aCatuai modified to use my new 23008 library for tonight?s roast. Did not see any issue with another device on the I2C bus.

I currently have new library files for MCP23008 chip, could easily merge with existing cButtons.h and MCP23017.h with new class of something like cButtonPE08 for the MCP23008 chip or I could create new library. JeeLabs libraries also work but have large overhead for their multiple plug devices. Anyone have any preference?

Next step is to use joystick with Randy?s Kona program.
 
bvwelch
Hi Patrick,

Sounds like great fun! It is entirely up to you of course, but I'd suggest keeping your library separate, and small -- at some point we'll bump our heads on code space. After some months go by, we can re-visit the libraries then.

I'm a big fan of JeeLabs but he tweaks his libraries fairly often so I quit using them except for experiments.

If you plan to make your software available under BSD or MIT license, feel free to put on our tc4 google code site -- I'd love to try it some time. thanks! -bill
 
Jump to Forum: