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.

renatoa
11/24/2022 8:17 AM
Trick or... crack... er... Grin

allenb
11/24/2022 8:12 AM
Happy Thanksgiving to all

renatoa
11/23/2022 3:28 AM
Birdman and dpineau coffee drink

allenb
11/21/2022 5:46 PM
lig76ct Welcome

Rich Saurman
11/21/2022 5:22 PM
Hi! New member starting with SR540. I am brand new and slowly getting better results with this roaster. I am interested in any roasting pointers.

In Memory Of Ginny
Donations

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

Members Online: 0

Total Members: 7,717
Newest Member: dpineau

View Thread

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

Quote

greencardigan wrote:
I could make it place the crack markers without having to press enter. But then I'm not sure how to handle longer text notes starting with 'f', or 's' etc. I'll have a think about this. Any ideas?

I had the impression that any longer texts are already eliminated by the software anyway, on the grounds that they are longer than one character - am I mistaken in this belief? Is it necessary to have longer texts? If so, then they could perhaps be marked by one specific first character (itself not a part of the text) to indicate that what follows is a text string terminated by return.

Quote

greencardigan wrote:
But leaving it at x10 should give you the same graph as using Fahrenheit mode. I think??

What I can say is that the first time I tried using it on a Hottop I simply converted the upper scale limit to Centigrade without changing RoR, and the RoR graph went violently off the top. Whilst this might have been for purely obscure reasons, I interpreted it as being because the RoR was expressed in Fahrenheit numbers multiplied by 10, while the temperature scale had been converted (by me, conceivably not entirely correctly) to centigrade, therefore with smaller numbers. I have to say though that my understanding of this program is somewhat hazy, partly because I cannot find enough time to properly get to grips with it and have to work somewhat in fits and starts; also more substantially because of inexpertise in programming. I am planning for my next roast to try 4x RoR + 50.

Quote

greencardigan wrote:
I'm also thinking that the temp axis on the right side could be used for ROR. So the left side could range from 0 to 280C while the right side could range from -? to +? degrees per minute.

Sounds like a good idea to me.

Quote

greencardigan wrote:
Some updated code ...

Looks nice - I'll give it a try on my next roast. Just a thought (not sure if this is a good idea or not) - what about the user putting a list of key codes in the config file, which are then taken as a list of valid marker commands. Different people have different ideas and/or constraints of what to record.

Bhante
 
JimG

Quote

greencardigan wrote:
Thanks Jim,

I'm keen to continue helping with the coding if it can eventually be merged into the trunk. ie. I only want to code somerthing that others want included and is compatible with the trunk.

Also, I dont want to go too far before any merges with the trunk happen.

My suggestion would be to work towards a stable release of pBourbon with a limited number of new features:

1. Selectable Celsius or Fahrenheit graphs according to runtime config file.
2. Single keystroke markers for specific roast events.
3. Recognize LCDapter button press roast markers coming from aBourbon (see below).
4. There is a timing issue related to the lag in opening serial communications with the Arduino. It would be nice to fix this, too.

I suggest keeping this line of pBourbon code in the "Brad" branch:
https://tc4-shiel...nches/Brad

I would also like to propose that aBourbon be revised for compatibility:

1. Selectable (at compile time) C or F units through the user.h file.
2. Add support to read LCDapter button presses that do the same thing as pBourbon's single character keystroke inputs. The LCDapter supports 4 buttons, so that would be aBourbon's limit.

I will take care of the aBourbon side of things, and have already started a branch for release 2.00 in the repository.
https://tc4-shiel...hes/RB-200

Jim
 
randytsuch
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.

Do you guys see that problem?

I think it just takes a few changes to fix it.

Randy
 
Bhante

Quote

JimG wrote:
I would also like to propose that aBourbon be revised for compatibility

Very nice!
 
greencardigan

Quote

JimG wrote:
2. Single keystroke markers for specific roast events.
3. Recognize LCDapter button press roast markers coming from aBourbon (see below).

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

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" ?


Quote

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

Am I able to edit my code there?


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.

Do you guys see that problem?

I think it just takes a few changes to fix it.

Randy

I've never tried running it that long. But my code allows you to change the end time limit. I think it would be good if it automatically extended the graph if you were approaching the end time limit.
 
JimG

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
 
bvwelch
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
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
Yes, absolutely!

Jim
 
bvwelch
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

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
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

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
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

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
 
JimG

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
 
JimG

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
 
JimG

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
 
greencardigan
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
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
 
JimG

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
 
greencardigan
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

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
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
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
 
Jump to Forum:

Similar Threads

Thread Forum Replies Last Post
Finally Completed Roaster Project Fluidbed Roaster 10 05/25/2022 9:43 AM
Fluidbed Roaster project Fluidbed Roaster 145 03/01/2022 11:27 PM
aArtisanQ_PID thermocouple jumps when active PID channel Dataloggers/Controllers/Rate of Rise Meters 16 06/10/2021 9:57 AM
Hottop Project outside the box Dataloggers/Controllers/Rate of Rise Meters 31 05/08/2021 7:13 AM
Flow Meter/Needle Valve Combo Electric and Gas Heat Sources 5 08/19/2020 4:27 PM
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 © 2022 PHP-Fusion Inc
Released as free software without warranties under GNU Affero GPL v3
Designed with by NetriX
Hosted by skpacman