Homeroasters - Home Roasting Coffee Community » DATALOGGERS - CONTROLLERS - RATE OF RISE METERS » Dataloggers/Controllers/Rate of Rise Meters
Who is here? 1 guest(s)
Page 30 of 31: 1...2728293031
 Print Thread
4-channel TC meter and datalogger project
JimG
Top  #726 Print Post
Posted on 04/04/2011 8:16 PM

Quote

greencardigan wrote:
2. So we want single key strokes for markers? Just 'F' rather than 'F' then 'Enter'?

I don't feel strongly about it. If completely my decision, I would use the single keystroke. But I can easily live with either method.

Quote

greencardigan wrote:
3. Does aBourbon send this data yet? I cant see it in any of the versions. What format will it be? Something like "# First Crack" ?

Not yet. Suggested formats (for start of roast, first crack, second crack, eject):
# STRT timestamp
# FC timestamp
# SC timestamp
# EJCT timestamp

I implemented something very similar in Catuai (a derivative application that I currently use mostly as a standalone). Except in Catuai, I also force a roast elapsed time reset each time a button is pushed (which completely wrecks the pBourbon plot Shock). I don't know if that's a good feature, though, for Bourbon?



Quote

JimG wrote:
I suggest keeping this line of pBourbon code in the "Brad" branch:

Quote

greencardigan wrote:
Am I able to edit my code there?

If you are familiar with SVN (I use TortoiseSVN), I can set you up as a committer for the repository. Otherwise, you would only have read access, and you would have to rely on me to commit your changes upon request. I'm happy to do this, but it may not be as convenient for you.

Quote

randytsuch wrote:
At some point, I made a change to pKona (based on pBourbon) because it would lock up when you reached the end time limit of the graph, I think it was around 16 mins.


Quote

greencardigan wrote:
Do you guys see that problem?

Yeah, I have run out of time. The program is supposed to just start a new graph, but this feature has never worked right. In the version of pBourbon that I use for roasting, I set the max time to 1120 seconds, FWIW.

Jim
 
Web
bvwelch
Top  #727 Print Post
Posted on 04/04/2011 9:32 PM
Jim, while you're revising aBourbon, you might consider adding in your enhancements for the RoR (from Gesha) -- they help with my roaster, and don't seem to cause Ed any trouble:

http://bvwelch.co...27-706.jpg

http://www.home-b...17232.html
 
greencardigan
Top  #728 Print Post
Posted on 04/04/2011 10:01 PM
Hi Guys, Is the google code site just for arduino code? I'm wondering if my PICAXE code for TC4 could eventually be made available.

At this stage it's compatible with pBourbon, and I hope to add support for Artisan soon.

BTW, PICAXE have developed a 'shield base' which should be compatible with most arduino shields.
 
JimG
Top  #729 Print Post
Posted on 04/04/2011 10:12 PM
Yes, absolutely!

Jim
 
Web
bvwelch
Top  #730 Print Post
Posted on 04/04/2011 11:01 PM
Just be sure you're OK with the licensing -- Note that by mutual agreement, software on the TC4 googlecode site is licensed with the new BSD license and/or MIT license which was intentionally chosen for their rather permissive open-source license.
Edited by bvwelch on 04/04/2011 11:03 PM
 
Bhante
Top  #731 Print Post
Posted on 04/05/2011 8:06 AM

Quote

bvwelch wrote:
enhancements for the RoR (from Gesha):
http://bvwelch.co...27-706.jpg

I noticed something a little bit funny with the RoR curve. Firstly the highest value of RoR is from about 1:50 to 2:30, where it goes right off scale. However the equivalent portion of the BT curve is significantly more shallow than the previous period from 1:25 to 1:50. Is this just due to the averaging process, or is something else at work? On the top line it says 5s average, which I assume is from the Processing section. Is there some additional averaging in the Arduino section?

@Jim:

Whilst on the theme of RoR, I have always been puzzled by the line in aBourbon where v = round( C_TO_F( tempC ) / D_MULT ) - why do you round this to an integer, and then use the rounded value as input to the filter - isn't this going to add random noise from the rounding errors?

If you are updating aBourbon, I'd like to make a suggestion to consider: the main variable we are interested in is T1, and we want to have it updated as quickly and as accurately as possible, but the ADC requires a fixed amount of time for each conversion. The other temperatures (ambient and T2, for 2 channels) could afford to be sampled less frequently. I think the ADC can complete each conversion in just under 1/4 second, is that right? What about converting ambient and T2 (to T4 where used) only once every 5 seconds, and the rest of the time just do T1 4 times per second, recording an average of the 4 values? This would give a much faster response time for T1, and that would also be the basis for a more accurate RoR averaged over a very short period.

Also a little hint: I find it rather hard to understand what is going on in the the filtering, a bit more commenting here would be really nice.

Bhante
 
greencardigan
Top  #732 Print Post
Posted on 04/05/2011 8:19 AM
I'm currently using 16 bit conversions with the MCP3424. This only requires a 70 ms conversion time while retaining acceptable resolution I believe.

I don't think I'm using the highest resolution on the MCP9800 ambient sensor either.
 
farmroast
Top  #733 Print Post
Posted on 04/05/2011 9:04 AM

Quote

Bhante wrote:

Quote

bvwelch wrote:
enhancements for the RoR (from Gesha):
http://bvwelch.co...27-706.jpg

I noticed something a little bit funny with the RoR curve. Firstly the highest value of RoR is from about 1:50 to 2:30, where it goes right off scale. However the equivalent portion of the BT curve is significantly more shallow than the previous period from 1:25 to 1:50. Is this just due to the averaging process, or is something else at work? On the top line it says 5s average, which I assume is from the Processing section. Is there some additional averaging in the Arduino section?


Bhante

I can't comment on the technical stuff but I asked Bill to set up the onscreen csv at 5sec rate while the stored and lcd display is every 1sec. This gives a wider review of recent data onscreen than if it was faster. A BT and RoR at the start will show the TC turnaround artifact of the TC being cooled down by the cool beans from the high preheat temp and then rising when balanced. I use the BT TC turnaround point to judge the charge temp. and batch size. Then I start to look at RoR and look for the rate of diminishing speed as the beans build heat.
I've never tried inserting the BT/RoR TC already equal to the drop in temp of the beans to see what the RoR really is from the start. I just use the TC turnaround artifact as it works well for me to gauge the start.
Edited by farmroast on 04/05/2011 9:09 AM
Ed B.
DreamRoast 1kg roaster, Levers, Hand Mills http://coffee-roa...gspot.com/
 
farmroast
Top  #734 Print Post
Posted on 04/05/2011 3:07 PM
Can I get some impressions of having live RoR either lcd display and especially live graph.

I used JimG DMM RoR for a year. It became the main means of seeing live details in the roast progression. I now have target speeds for points in the roast all other measures considered.
Now The TC4 is running and find the RoR graph profile fascinating. On graphs with too much noise I had trouble seeing the average but on my unit it's running smoothly. It creates such a different and interesting picture! Since my roaster is variac driven I think I can now follow the RoR to make fine adjustments and do them smoothly. It also seems like following a RoR graph for repeatability could really be useful.
Link to a screenshot http://www.home-b...17232.html
Edited by farmroast on 04/05/2011 3:24 PM
Ed B.
DreamRoast 1kg roaster, Levers, Hand Mills http://coffee-roa...gspot.com/
 
JimG
Top  #735 Print Post
Posted on 04/05/2011 9:03 PM

Quote

Bhante wrote:

Quote

bvwelch wrote:
enhancements for the RoR (from Gesha):
http://bvwelch.co...27-706.jpg

I noticed something a little bit funny with the RoR curve. Firstly the highest value of RoR is from about 1:50 to 2:30, where it goes right off scale. However the equivalent portion of the BT curve is significantly more shallow than the previous period from 1:25 to 1:50. Is this just due to the averaging process, or is something else at work? On the top line it says 5s average, which I assume is from the Processing section. Is there some additional averaging in the Arduino section?

Probably what you are seeing is the lag that gets introduced by the filtering (which is performed on the Arduino side). Depending on the amount of filtering selected, this lag time can be 20 seconds or more.

A very noisy signal, such as that from a small mass TC in a roaster with a lot of air movement, will require much more filtering to produce a usable RoR trace than will a higher mass probe in, say, a Hottop.

Quote

Bhante wrote:
Whilst on the theme of RoR, I have always been puzzled by the line in aBourbon where v = round( C_TO_F( tempC ) / D_MULT ) - why do you round this to an integer, and then use the rounded value as input to the filter - isn't this going to add random noise from the rounding errors?

I don't recall now my thinking around storing the temperatures as integers. It seemed like the right thing to do at the time, and it may yet prove to be the best way (although it does look odd). At the moment, there are other more pressing needs, so I plan to put off reopening this issue for a while. What I am fairly confident of, though, is that it does not introduce any significant error or additional noise.

Quote

Bhante wrote:
Also a little hint: I find it rather hard to understand what is going on in the the filtering, a bit more commenting here would be really nice.

It is a very simple low pass RC filter. I tested a number of different options (averaging N samples, Butterworth first order, Butterworth second order, etc.). The RC filter was at least as effective as any of them, and is very simple to implement and adjust. Here is a link:
http://en.wikiped...ass_filter

The difference between that reference and my code is that I defined the filtering level slightly differently. My filtering level = 100% * (1- alpha).

Choosing a filtering level of 0% passes all data through unchanged, while a filtering level of 100% ignores all data points past the first one, i.e., filters out all changes. Those are the extreme values.

Values between 70% and 95% for RoR seem to be the most useful. This is selectable at compile time if you would like to experiment. The best way to test the effectiveness of a filter is to capture some real data and simulate the filter in Excel. I did this many times before settling on the RC filter that is implemented in the library.

Jim
 
Web
JimG
Top  #736 Print Post
Posted on 04/05/2011 9:31 PM

Quote

greencardigan wrote:
I'm currently using 16 bit conversions with the MCP3424. This only requires a 70 ms conversion time while retaining acceptable resolution I believe.


The 16-bit setting will give you a resolution of +/-62.5uV on the MCP3424. If you also use the 8X gain setting, this resolution effectively becomes +/-8uV.

The response of a type K TC is somewhere around 40uV per degree C, give or take.

So using 16 bits should provide a resolution of around +/-0.2C. For monitoring roasting temperatures, this is plenty of resolution, so I don't disagree with your approach.

But, when you consider the calculation of RoR, things get muddied up a little. Say you have an actual constant temperature of 100C at the tip of the probe, and that all other errors are ignored. Your ADC might report a sequence of results like this: 99.8, 100.0, 100.2, etc.

If the sampling rate is 1 Hz, then you might compute an RoR that bounces around between +12C per minute and -12C per minute for a situation where the true value is 0C per minute.

In F units, that would be more like +22F per minute and -22F per minute.

Using 18 bits of resolution reduces the minimum uncertainty in RoR to something closer to +/-5F per minute, which is tolerable after some filtering has been done.

So to get decent data to start with for RoR, I think you really want to use the highest resolution possible from the ADC. This was my thinking at the time the cADC library was written, anyway.

Jim
 
Web
JimG
Top  #737 Print Post
Posted on 04/05/2011 9:45 PM

Quote

farmroast wrote:
Now The TC4 is running and find the RoR graph profile fascinating. On graphs with too much noise I had trouble seeing the average but on my unit it's running smoothly. It creates such a different and interesting picture! Since my roaster is variac driven I think I can now follow the RoR to make fine adjustments and do them smoothly. It also seems like following a RoR graph for repeatability could really be useful


Ed -

Things have come a long way since that original analog board!

After doing a dozen or so roasts with the realtime graph, I've been able to make the transition to using only the LCD display on a routine basis. After watching all three traces (BT, ET, RoR) on several roasts, I developed a very good feel for the effects of different power settings on the RoR.

For instance, I learned that if I want to extend the early drying phase, then I need to keep the power level at 70% until the RoR peaks (normally at around 30). Then I crank the power to 100% for a 20-25 RoR ramp to FC.

I also learned that I need to cut the power back to 30% at the start of FC, and leave it at 30% until the RoR has dropped below 10. Once that happens, I increase the power in steps, with the goal of keeping RoR above 5, but below 15. This gives me a nice finish for my FC espresso roasts.

So for me, the realtime graph was a huge help in learning more about my roaster. But now, for most roasts I can rely only on RoR value on the LCD display.

Jim
 
Web
JimG
Top  #738 Print Post
Posted on 04/05/2011 11:08 PM

Quote

greencardigan wrote:
3. Does aBourbon send this data yet? I cant see it in any of the versions. What format will it be? Something like "# First Crack" ?


https://tc4-shiel...hes/RB-200

This version of aBourbon now writes markers to the serial port for four events:

1. Button 1 --> start roast --> # STRT,xxx.x (where xxx.x = timestamp)
2. Button 2 --> first crack --> # FC,xxx.x
3. Button 3 --> second crack --> # SC,xxx.x
4. Button 4 --> eject --> # EJCT,xxx.x

In addition, the LED's on the LCDapter are illuminated as follows:
start roast --> LED 1 turns on, stays on
first crack --> LED 2 turns on, stays on
second crack --> LED 3 turns on, stays on
eject --> all LED's turned off

To implement these new features, the current code requires the use of the LCDapter.

Default configuration is Fahrenheit scale with LCDapter. Use the user.h file to configure for your setup and preferences. aBourbon still works fine without an LCD or an LCDapter, once the user.h file is correctly configured.

Testing and comments are requested before release. Thanks.

Jim
Edited by JimG on 04/05/2011 11:42 PM
 
Web
greencardigan
Top  #739 Print Post
Posted on 04/06/2011 7:04 AM
I have updated my version or pBourbon to be compatible with Jim's latest aBourbon V2.00.

pBourbon_Brad_2.zip

Below is a summary of my changes to the trunk version of pBourbon.

- Receives marker commands from aBourbon V2.00 button presses and plots markers on graph and adds text to log file.

- Celsius or Fahrenheit mode (set in the config file)

- Roast Markers now using a single key press. B = Begin or Beans in, F = First Crack, S = 'Second Crack', E = End or Eject. This now requires the user to press 'Space' before entering other text to be written to the log file.

- Temperature axis automatically scales if maximum temp variable (MAX_TEMP or c_MAX_TEMP) is changed

- Time axis automatically scales if maximum roast time variable (MAX_TIME) is changed

Also requires testing. I don't have an arduino to test with but my PICAXE tests work.


Brad
Edited by greencardigan on 04/06/2011 7:08 AM
 
JimG
Top  #740 Print Post
Posted on 04/06/2011 7:35 AM
Excellent! Thanks, Brad.

I've committed the new version of pBourbon to the repository, here:
https://tc4-shiel...nches/Brad

Here is a link to a diff between current and previous versions of Brad's pBourbon:
http://code.googl...mp;old=385

Also, Bill has reminded me to incorporate into aBourbon the RoR filtering improvement that was introduced in aGesha. I will do this shortly and post it to the repository for testing.

Jim
 
Web
JimG
Top  #741 Print Post
Posted on 04/06/2011 8:03 AM

Quote

greencardigan wrote:
- Time axis automatically scales if maximum roast time variable (MAX_TIME) is changed

Maybe a good idea to use a larger default value than 5 minutes? Suggest that the default value be revised to, say, 19 minutes.

Jim
 
Web
greencardigan
Top  #742 Print Post
Posted on 04/06/2011 8:06 AM
Whoops, I forgot to change that back. I had it set on 5 so the graphs moved across the screen quicker when I was testing the markers.
 
Bhante
Top  #743 Print Post
Posted on 04/06/2011 11:03 AM

Quote

greencardigan wrote:
Whoops, I forgot to change that back. I had it set on 5 so the graphs moved across the screen quicker when I was testing the markers.

I am experimenting with it just now, and when it got to 5 minutes the graphs all went blank and the axes were not extended. Did you disable that feature during your marker tests?
 
Bhante
Top  #744 Print Post
Posted on 04/06/2011 11:33 AM
I have tried setting all filtering (at every level) to 0 to see what happens, which is very interesting. The ambient sensor is unbelievably fast and sensitive, as the attached graph shows. At each of the four markers, B, FC, SC, and E, I breathed out relatively short and sharply in the direction of the ambient sensor, at a distance of about 10cm. At the same time as the breath I pressed the relevant button. The first and second "cracks" were so close to instantaneous that the rise curve virtually through the centre of the timing marker. (I aimed to press the button as accurately as possible at the start of the outbreath, which lasted probably about 1/4 second or so). The first peak * on the graph occurred unexpectedly as I moved while preparing to start (probably a gust of warm air caused by my movement). I am not sure why there is no response from the first breath; all the breaths were biologically controlled, therefore not exactly identical, and the distance likewise. Maybe the first breath was a little too light and too far away, but virtually every breath has a similarly dramatic response.

Sorry, I can't get the attached file to attach!

I've just tried the same thing with the BT TCs, and to my surprise the results are even more dramatic. The TCs are at the bottom of a copper pot 10cm wide and 25cm deep. Breathing sharply into the mouth of the pot I could get RoR to go from off-screen negative (probably marginally off-screen) to off the top of the screen within a fraction of a second of the start of the breath (probably around 1/2 second). The TCs are 1.5mm mantel elements.

* Ahemm. The graph of course shows T0 and RoR of T0, while what changes is ambient, which affects the calculation of T0 in the opposite direction. Therefore it seems the breathing on the ambient sensor was a cooling effect while the breathing in the mouth of the pot had a warming effect. Nevertheless the results are just as astounding. Well done Jim and Bill for developing such good hardware!

OK, here are the graphs. First the ambient:
up.picr.de/6761814hca.jpg

Then the T0:
up.picr.de/6761816amp.jpg
Edited by Bhante on 04/06/2011 12:10 PM
 
JimG
Top  #745 Print Post
Posted on 04/06/2011 12:13 PM
I have started a new thread that is specific to Bourbon discussions:
http://forum.home...ad_id=2173

Please, let's move our Bourbon discussions over there.

I have also changed the name of Brad's branch in the repository to be consistent with naming conventions I described in the new thread. Brad's current pBourbon code can now be found here:
https://tc4-shiel...s/TRY-Brad

Jim
 
Web
Bhante
Top  #746 Print Post
Posted on 04/06/2011 1:35 PM

Quote

JimG wrote:
I have started a new thread that is specific to Bourbon discussions ...
Please, let's move our Bourbon discussions over there.


@Jim:
I agree it is necessary to start a new thread, but wait, I have an alternative suggestion:

1) The main TC4 thread is HUGE. It contains masses of very important information, but finding required information is a nightmare. On the other hand I think this TC4 thread is a good place to centralise current discussions, especially ones which might be of interest to all TC4 users, not just Bourbon users. There is an overwhelming need for a new thread which ONLY contains authoritative information on the hardware and software, building, obtaining, using, problems, solutions etc, without millions of discussions about issues that are not relevant to all users, especially to new users. Therefore I suggest you use the new thread ONLY for authoritative statements: what is, how to, how it works (excluding discussions and questions), how to build, how to install/calibrate, updates/new issues/new branches etc. It would be nice if we could get full documentation for everything but I know that is a difficult target to reach and may never happen for lack of time, since the most productive people are always short of time - but the best alternative I think is to have a repository of key authoritative information without any discussion. (Otherwise the new thread will also in no time be a mamouth thread, and it will be difficult to find essential information there too). Therefore my proposal is that you discourage discussion on the new thread as far as possible, rather than simply moving the discussion from one place to another, and keep the new thread for authoritative statements, which hopefully over time will build up step by step to something approximating to reasonably full documentation.

2) Note that Bourbon is both aBourbon and pBourbon, and some other programs depend on aBourbon although not using pBourbon (pCatuai for example). Additionally, many discussions of Bourbon will be entirely relevant to all or several of the other programs used on TC4, and vice versa, so I think it would be valuable to keep such discussions together so that anyone interested in developments of TC4 in general knows where to look, and doesn't have to split his attention between split discussions for split audiences and/or duplicate his discussions.

3) To help keep the new "repository" thread slim and information easy to find, I propose that all questions about points in the new thread, and about information people cannot find, or requests for explanations, should go here in the main discussion thread, where the emphasis would be more on current discussion.

4) Of course, my proposed authoritative information could equally well go somewhere else such as in the wiki of the google code site, but what matters is that somehow and wherever the key information gets collected in a place where it is easy to reach.

That is my proposal.
Bhante
 
JimG
Top  #747 Print Post
Posted on 04/06/2011 2:22 PM

Quote

Bhante wrote:
That is my proposal.
Bhante


Thanks for your thoughts.

Quote

JimG wrote:
As a relative newcomer to HRO, I have to first ask "Does the HRO community wish for HRO to continue to be the primary forum for the TC4 system?"

If yes, then my thoughts would be to initiate a few new threads, generally along these lines:

1. TC4 - Overview and announcements
2. TC4 - Hardware discussions
3. TC4 - Bourbon application software
4. TC4 - Catuai application software
5. TC4 - Artisan application software
6. TC4 - Gesha application software

Randy has already started a thread for the Kona application, so I think that application is covered already.

If the consensus here is that those new threads would be appropriate, and welcome, then I will volunteer to get them started.

Jim

The direction posted previously in this thread (quoted above) is where I currently plan to take things. Will that satisfy your concerns?

Jim
 
Web
greencardigan
Top  #748 Print Post
Posted on 04/06/2011 4:54 PM

Quote

Bhante wrote:

Quote

greencardigan wrote:
Whoops, I forgot to change that back. I had it set on 5 so the graphs moved across the screen quicker when I was testing the markers.

I am experimenting with it just now, and when it got to 5 minutes the graphs all went blank and the axes were not extended. Did you disable that feature during your marker tests?

No, I haven't coded that feature yet.

The max time currently needs to be set before running. The axis will then scale to fit to the max time value.
 
tony359
Top  #749 Print Post
Posted on 05/08/2011 10:09 AM
Hi all

First post here, my name is Antonio and I write from the UK. Not exactly a British name, I am actually Italian!
I could be sligtly off topic here, but was not sure if I should have opened another thread.

I was searching the Internet for a 2 (or more) thermocouples USB logger for reflowing XboX. I would like to do it properly and I would like to find a correct reflow profile using my equipment. See the graph on video would be the best thing to do.

Now, let me say that your project is AWESOME! It's good to see that open source can gather so many people in great projects! Well done.

Said that, I knew the Arduino platform and I would like to buy one for experimenting. The TC4 board seems to be the icing sugar on top.

Do you think the TC4 could be suitable for my task? I think it's approximately the same of roasting coffee (ok, don't take it wrong!), I need to reach a temperature keeping an eye on the rising rate of it, to avoid damaging the chips.

The ultimate software would be to have a superimposed graph I could follow using the heaters (well, the ultimate one would be Arduino to control the tools, but that's another task!).

I read many pages of the forum but as some says there is a lot of content and it's not easy to keep track of all of it (not a complaint, definitely not easy to keep everything tidy).

If I correctly understand to run the TC4 I need... the TC4, which can be ordered bare, partly populated or fully populated; then I need an Arduino board. Which model? UNO?

Thanks for your time and for helping me!

Cheers
Tony
 
bvwelch
Top  #750 Print Post
Posted on 05/08/2011 3:12 PM
Welcome Tony! It seems to me that the TC4 should be fine for your project. The 4-channel adc that we use is a bit slow-- something like 250mS to sample but most of us run 2 channels with an overall update rate of 1 second. We have software both for the Arduino and also for the PC. You might be able to use the software as-is, or you might want to tweak it, or just study it and roll your own. I'd suggest the 'Bourbon' sotware application as a good starting point.

Yes, the Uno will work, or the Duem, or similar that have the original shield format. We use I2C heavily in the tc4, by the way.

Feel free to start a new about your project - reflowing is of interest, as is datalogging.
Edited by bvwelch on 05/08/2011 3:13 PM
 
Page 30 of 31: 1...2728293031
Jump to Forum: