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
04/17/2024 9:27 AM
morning, branchu

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

allenb
04/11/2024 6:33 PM
Zemona Welcome

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

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

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

Members Online: 0

Total Members: 8,208
Newest Member: branchu

View Thread

Who is here? 1 guest(s)
 Print Thread
TC4 - Coding and tech issues
JimG
Welcome to a new thread for discussing the nitty-gritty coding and technical issues associated with the TC4. My intention in starting this thread is that it be dedicated to techie issues that apply across the entire spectrum of TC4 applications.

First item of business is to announce that Jasen Grice has written a new library that supports Type T thermocouples. I haven't used the new library yet, but I can see that it is compatible with the TypeK library that has been in use for several months now. It looks like the two libraries would be interchangeable as far as existing applications are concerned.

Here is the TRY-branch where you can find the new library:
https://tc4-shiel...asen-TypeT

Reports of any testing done using this new library will be greatly appreciated!

Jim
 
greencardigan
Hi Jim,

I'm still trying to get my head around the filtering side of things in aBourbon so i can replicate this in my picaxe code.

Is this how it goes?

1. Heavy filtering on ambient temps. Does this occur before or after cold junction compensation?
2. Light filtering of temps for display and logging
3. Heavy filtering of temps for ror calcs
4. Heavy filtering of ROR values for display and logging


Currently I'm not filtering the ambient or display temps and my temp traces seem smooth enough.

I've had a few late nights trying to get the (1-beta)*xi + beta*y-1 filter method working on the picaxe! I have to work with temps x 100 to preserve the temp resolution (integer math only) and that means I have to work around the 16bit math limitation to do 31bit math in the filter calcs.

I ended up using a filtering level ranging from 0 to 255 rather than your 0-99 as it is easier to divide by 256.

Also, are you eventually intending to make aBourbon compatible with both pBourbon and Artisan?

Brad
 
JimG

Quote

greencardigan wrote:
1. Heavy filtering on ambient temps. Does this occur before or after cold junction compensation?
2. Light filtering of temps for display and logging
3. Heavy filtering of temps for ror calcs
4. Heavy filtering of ROR values for display and logging

All filtering is done at the end, i.e., after CJ compensation, TC linearization, etc.

The ambient temps are heavily filtered on the idea that the ambient sensor is located in a stable environment (on the PCB, presumably inside an enclosure) so variations are most likely noise. So we kill the quick jumps and keep the longer term trends.

Heavily filtered streams of BT and ET values are used for computing the derivatives (RoR). These heavily filtered BT and ET streams are used only for the calculation of derivatives.

Optionally, the streams of computed RoR values can also be post-filtered. This works surprisingly well. I did some testing while Bill was writing aGesha and found that a combination of pre- and post-filtering for RoR gives better results with less lag time than pre-filtering BT and ET only.

More lightly filtered streams of BT and ET are computed for logging and displaying the data.

A lot of flexibility is built into the code for filtering. Different combinations of sensors and roasters produce varying amounts of signal noise. A lot of air flow will usually create more noise, for instance.

Quote

greencardigan wrote:
Also, are you eventually intending to make aBourbon compatible with both pBourbon and Artisan?

The current release candidate of aBourbon is up to date with your changes to pBourbon.

I chose to write a standalone sketch to support Artisan instead of trying to build more functionality into aBourbon. I've tested aArtisan on the desk, but not on my roaster. It works very well on the desktop, FWIW:
https://tc4-shiel...hes/RB-100

Jim
 
greencardigan
Hi Jim,
I'm having an issue with this section of code in pBourbon REL-200. And the same issue for the equivalent part in the keyPressed function.


void mouseClicked() {
  if( !started ) { 
    started = true;
    delay( START_DELAY );
    println("\nSynchronising aBourbon Time");
    comport.write( "RESET\n" );
  }
  else {
    makeJPG = true;
  }
}


If my TC4 logger is already running, I get the following displayed.

Quote

comport clear()'ed.
buffering...
134,20.75,20.50,-0.45,20.00,-0.07,0
135,20.87,20.62,-0.42,20.12,-0.06,0

Synchronising aBourbon Time
# RESET
# SEND COLUMN HEADERS AND SETUP DETAILS
1,20.87,20.62,-0.39,20.12,-0.05,0
2,20.87,20.62,-0.36,20.12,-0.04,0
3,21.00,20.75,-0.30,20.25,-0.00,0


This results in the graph beign drawn wrong at the start. I get lines from time 134 back to 1.

I suggest that the started = true line be moved to after the comport.write line??

What do you think??
 
JimG
Yeah, I ran into the same problem when I fired up my new Uno board. The issue is that there is a lag between when the RESET command is issued and when it is heard at the remote.

This is what I did to fix things here:

  if( !started ) { // waiting for user to begin logging
    delay( START_DELAY ); // make sure the Arduino sketch has had time to get started
    println("\nSynchronising aBourbon Time");
    comport.write( "RESET\n" );  // issue command to the TC4 to synchronize clocks
    delay( 200 );
    comport.write( "RESET\n" ); // Uno requires a second reset -- why?
    delay( 1200 ); // make sure reset has occurred before we start logging data
    started = true;
  }


Here is a diff that shows the revisions (I've also since removed the extra line of code in KeyPressed):
http://code.googl...mp;old=514

The good news is that I don't think this is a problem on Duemilanove and older Arduino's. The Uno has so many other problems that I can't recommend it at this point.


Jim
 
bvwelch
About this timesync stuff -- perhaps the Arduino side should respond to a RESET by sending a "RESET" response? Then the PC should wait for the RESET to come back, before setting its 'started' variable?

BTW, I'm a bit confused between RESET and STRT messages. Perhaps they could be consolidated?
Edited by bvwelch on 04/16/2011 8:29 AM
 
JimG
I like that idea. I'll give it a try today.

Thanks!

Jim
 
bvwelch
Hi Jim, I revised my suggestion above, at just about the same time as you replied. I'm not sure if START will work, may need a new RESET message coming back in reply ?
 
JimG
I saw that.

The difference between reset and start is that start indicates that the beans have been loaded.

Thanks.

Jim
 
JimG
I've got something that's working well here with both the Uno (problem child) and the Duemilanove. Had the added benefit of getting rid of the forced delay to give the remote (Arduino, PICAXE) a chance to spin up.

Most of the time, 5 resets are required for the Duemilanove. This is because opening the serial port always resets the board.

On the Uno, most of the time 1 reset is required, sometimes 2. But it does not get reset when the serial port is opened.

Anxious to see how it behaves on your PICAXE, Brad.

The basics:

// ------------------------------- reset the Arduino, etc.
void resetRemote() {
//    delay( START_DELAY ); // make sure the remote has had time to get started
    println("\nSynchronising with remote:");
    int i = 0;
    while( resetAck == 0 && i < 10 ) {
      comport.write( "RESET\n" );  // issue command to the TC4 to synchronize clocks
      delay( 500 );
      i++;
    }
    print( resetAck ); println( " reset(s) required." );
    if( resetAck != 0 )
      started = true;
}

// ------------------------------- save a frame when mouse is clicked
void mouseClicked() {
  if( !started ) {  // waiting for user to begin logging
    resetRemote();
  }
  else {
    makeJPG = true;  // queue a request to save a frame
  }
}

...... similar code for beginning of keyPressed()

// -------------------------------------------------------------
void serialEvent(Serial comport) { // this is executed each time a line of data is received from the TC4

    // grab a line of ascii text from the logger
    String msg = comport.readStringUntil('\n');

    // exit right away if blank line
    if (msg == null) return; // *****************
    msg = trim(msg);
    if (msg.length() == 0) return; // ****************

    // otherwise, check first to see if it is a comment --------------------------------------------
    if (msg.charAt(0) == '#') { // this line is a comment
      logfile.println(msg); // write it to the log no matter what
      println(msg); // write it to the terminal no matter what     
      String[] rec = split(msg, ",");  // comma separated input list
      if( rec[0].equals( "# Reset" ) ) { // acknowledge, and count, RESET's echoed back from remote
        ++resetAck;    // count them for possible debugging use
      }
        else if( started ) { // skip these roast markers if logging hasn't been started by the user
        if (rec[0].equals("# STRT")) {
          ba_x = T0[0][idx-1];
          ba_y = MAX_TEMP - T0[1][idx-1];
        } else if (rec[0].equals("# FC")) {
... snipped


Changes committed to the repository here:
https://tc4-shiel...c/pBourbon

Jim
 
greencardigan
Jim,
I gave this a quick test just now and it seems to be working fine with my PICAXE. I get the message '1 reset required'.
 
JimG

Quote

greencardigan wrote:
Jim,
I gave this a quick test just now and it seems to be working fine with my PICAXE. I get the message '1 reset required'.

Sounds good!

BTW, I finally determined that the problem with my Uno was a bad via between the top and bottom layers along the RESET signal. Now, that's bad luck :@

Jim
 
greencardigan
I just solved one of the issues I was having too. My picaxe was locking up at random times while I was testing it with pBourbon and Artisan.

After a few grumpy days and way too many hours looking for bugs in the code I realised the batteries powering the picaxe were very low. :(
 
bvwelch

Quote

JimG wrote:
The Uno has so many other problems that I can't recommend it at this point.
Jim


Now that the reset signal problem on the PCB is repaired, how do you find the Uno's operation?
 
JimG
Now that I've soldered the jumper wire to fix the bad PCB trace, the Uno is working well. Not really any different from the Duemilanove, though, AFAIK.

I've tested the Uno on XP, Ubuntu, and Mac OS X. Still having some issues with Mac, but it may be related to the USB hub I'm using. That is a documented issue with Uno and Mac. I need to do more testing to see if I can get it going on the Mac.

So as of now, Uno = goodo.

Jim
 
bvwelch
Here's a small but fun project for someone -- implement Dan's 'percentage timer' idea for OT1 and/or OT2. Instead of using PWM, use the system time to implement 0 to 100 percent duty cycle with a 10 second period. Put the 'knob' (pot) on ANLG1 or 2.

EDIT: Nevermind, Jim's already done this. Duh.
Edited by bvwelch on 04/19/2011 11:34 PM
 
mhoy
Is there a way to detect that a thermocouple is either unplugged or not used?

Thanks,
Mark
 
JimG
I've done this (prototype level only) for another project by forcing a small current through the thermocouple, on the order of 0.5 uA.

If there is an intact thermocouple connected, the differential voltage created by this small current passing through the TC loop is too small to affect the readings. The common mode voltage is around 500mV, but the ADC seems to be able to reject it OK.

If the TC is broken, or not present, a differential voltage of around 500mV (I use a signal diode) shows up across the input terminals of the ADC channel. This is a low enough value that it does no damage, but high enough to put the input signal out of normal range. So the code just has to check for input values that are waaaay high.

Jim
 
mhoy
Finally made something with my TC4 and LCD board. This is a controller for my Bradley Original Smoker. There is power in/out with one thermocouple input. The buttons (which I have to figure out how to program) will allow on the fly setup of the SSR controlled heater element.

lh4.googleusercontent.com/_0-aEomHvbkE/TbDycAizcOI/AAAAAAAAAm0/pDCFuhmF99g/s800/P1020830.JPG

Mark
Edited by mhoy on 04/21/2011 10:35 PM
 
mhoy
Took another look at the SVN repository and voila, cButton/cButton.[ch]. Somehow I had missed it when I last looked... Oddly the buttons seem to 'bounce' but it works well enough for now. On to trying some smoked salmon. Don't know which grind selection for it. :-) An on/off controller has overshoot but looks like it will work well enough for smoking where the time frame is hours.

Sous Vide would also now be possible, wonder if the wife would notice the rice cooker if it went missing. :)

Mark
 
JimG
Mark -

Nice implementation!

I'm concerned about the button bounce. Not a high priority, but send me some details when/if you have a chance.

Implementing proportional control is nearly as straightforward as on/off. So if you can't live with the overshoot, give simple P control a shot.

Jim
 
mhoy
Unfortunately my test subject (my smoker) burned out the heater element 90% into my smoked salmon. Doesn't appear to be any fault of the digital controller. Seems like they have had a bad run of elements lately (but the company has a 1 year warranty) so come Monday I expect I'll get some parts sent out.

In the mean time, I'll open it backup and work out the bugs with the buttons.

I may just pull in the entire Arduino PID Library and give it a go once the heater element arrives.

Obligatory Coffee Item:
I happen to have placed a K thermocouple in my Elektra T1 group head and used the TC4 to see the shot temp. Pretty cool, might have to wire up another controller soon just as a display.

Mark
 
Bhante
I have done a roast generating raw data without any filtering whatsoever, and have now done some experimenting in Excel. What I found was that I could get quite good cancellation of the jittering in the RoR signal simply by averaging successive values. I got quite reasonable results with a sample period of 4 seconds, averaging all the values of RoR in the sample and then moving on to the next sample period (i.e. this is not a running sample, which would be much less effective at cancelling the jitter due to rounding errors). I still got significant up and down movement of RoR, but I think that is not noise, but I think it is actual rising and falling of RoR in response to the heater going on and off (and possibly also bean temperature variation). It seems to have a certain periodicity to it. By increasing the sample size to 10 seconds the RoR curve is further smoothed out, but like the 4 second sample size there is still no distortion, because it is a simple average.

Thinking about this, I think this approach of averaging samples of RoR is a more direct and effective method of eliminating the jittering than the filtering technique, as it goes directly to the core of the problem - the rounding errors in the digitised samples of temperature. What we are trying to measure is the temperature at this moment, and the rate of change at this moment - this is not a function of past changes, and the most ideal measurement would be over a time period as short as possible. I don't see the filter model as being suitable in this case. When the total change in the period is relatively similar in size to the sampling error/rounding error, the calculated rate of change will fluctuate wildly around the actual momentary rate of change of temperature. What we want to see ideally is the actual rate of change at this moment, as independently of time before and after this moment as we can achieve.

We can take this argument further. Ever since Brad was asking about ADC sampling settings and Jim's answer I have been harbouring reservations about this (indeed before, for that matter). I agree that we need to sample temperature at an accuracy as high as possible in order to minimise sampling errors and get a meaningful value for RoR, but we also need to balance that with the number of samples, and here the inverse relation is true. The quantisation noise at 16 bits is 4 times the quantisation noise at 18 bits, but at 16 bits we can get 4 times as many samples per second. Which gives better results - more samples averaged before differentiating or less samples with lower noise? Right at this moment I cannot quite get my head around this question, whether the two are equivalent or whether one or the other is better, but my gut feeling is as follows: given sufficient number of samples in the sampling period the error due to quantisation will tend to zero, therefore [but is this exactly cancelled out by the increase in noise level???] slightly reducing the bit resolution and correspondingly increasing sample size ought to be an improvement.

In addition to the previous questionable gain we have two definite improvements from a lower resolution: (1) the signal noise is lower at 16 bits than at 18 bits, and (2) if we want to insist on a fixed number of samples per second, the sample size per second for two thermocouples at 16 bits is far more than 4 times the sample size at 18 bits.

What is more, if we give priority to T0 over other thermocouples and optimise the software for a total of two probes, then the sample size for T0 is almost doubled - that is, if we sample at 16 bits, then reserve one sample per second shared between all the thermocouples from T1 to T3 and use all the other 14 samples for T0 which is our highest priority, and then we average all 14 samples to give one reading of T0, and by comparison with the previous averaged T0 reading one reading of RoR, then we would certainly get a much cleaner reading of RoR with zero distortion and almost immediate response. If 14 samples is not enough we could average over 2 seconds and I am sure 28 samples will be more than adequate. A slight variation on this approach, significantly more complicated to program, might be to assume that all the 14 samples within the period approximate to a gaussian distribution on a straight line whose slope corresponds to the average rate of change DURING that one second period, with or without supplementing input from the geometric average of the samples in the preceding and subsequent one second periods. The latter would offer a sort of nearest neighbour filtration on the average rate of change of the samples within a one second period - draw a straight line between all the samples in the one second period, calculate its gradient, then average that with the difference between the geometric average of the immediately previous second and the geometric average of the immediately subsequent second.

Note that each individual sample can only be used once - if we calculate a running average of the most recent 10 samples every time we fetch a new sample from the ADC, then we are optimising the accuracy of the momentary temperature but this has a devastating effect on RoR, because the difference between successive averaged samples is determined exclusively by the first and last samples averaged, i.e. a sample size of only 2, so the RoR will fluctuate wildly.

I also think it is worth testing the validity of each individual sample, and throwing out any samples that are out of range before averaging. Any samples thrown out should be logged on the serial port, so that we get some feedback on any error states that may be arising, from grounded thermocouples for example. I have already mentioned the GreenBean logging project in the UK a few times - GreenBean reads 4 samples per second using a Max6675 chip for each probe, tests each sample for validity, then throws out invalid samples and averages the rest of the samples for one second (he is not using RoR however).

Finally, I have tried using the sample averaging feature in pBourbon, but without success - setting all filtration in aBourbon to 0, I set sample size in the configuration file for pBourbon to 10. The RoR is fluctuating just as wildly as with a sample size of 1, or at least close to that, unlike the results of my excel experiments. I think this is using a running average isn't it?

By the way, I personally don't see any need for filtering on anything at all other than RoR - I am not getting any noise problem at all, except with RoR. Firstly on ambient temperature: my experiments with breathing on it show that it is extraordinarily sensitive to change, but I see this as valid data not noise, and should be used in the correction of the raw thermocouple readings because the ambient temperature does actually change and the cold junction error changes with it. Insulating the TC4 from temperature changes is obviously worthwhile. Secondly on thermocouple temperature readings: again I have no problem of noise, and get extremely smooth temperature curves with zero filtering, both on my HotPot and on my HottoP. Obviously with some types of roaster the position will be different.

Here are some of my results. First the raw data from a roast on the HottoP (with one BT thermocouple), as displayed by the TC4 in Processing. The black trace is BT, green is RoR with zero filtration. (The red line shows the displayed T1 but the T1 contacts are open-circuit; I subsequently tried shorting the T1 contacts, and the proportional relation between T1 and T0 is thereby removed). To optimise accuracy I sent all the data to the serial port with three decimal places instead of one.

up.picr.de/7027479itz.jpg

Next just for comparison a second roast under similar conditions using the recommended filter values (BT, ET, Rise, RoR, Amb 10, 10, 85, 80, 70 respectively).

up.picr.de/7027502mpq.jpg

Now to my excel experiments, the first of which are conducted on the raw data in the first roast above. The first graph shows a comparison of the raw RoR data (light green), raw RoR averaged over a 4 second sample period (red trace), and over a 10 second period (blue trace). This is on my analog HottoP with its rather crude built-in heater control, so I suspect the major oscillations in RoR correspond in large measure to the heater switching on and off; once I can get PWM control of the heater installed this oscillation should be reduced. If however the samples are averaged over a one second period any oscillations should correspond only to actual changes in RoR.

up.picr.de/7027550muf.jpg

The next graph shows a comparison between filtered RoR using Jim's low pass filter (red trace), and averaged RoR as above (orange and blue traces).

up.picr.de/7027551ymc.jpg

The next two graphs give the results of another roast in which all filters in aBourbon are set to 0, but the sample size in pBourbon is set to 10. Both graphs are drawn from the data in excel, and show first the pBourbon averaging an a sample size of 10 seconds (green trace), then the samples averaged within excel as above (red and blue traces) - note that these traces are necessarily based on the output of the pBourbon averaging, averaged a second time in excel. It looks like the pBourbon averaging is not carried out for some reason, or if it is, it is not as effective as it could be.

up.picr.de/7027574qwt.jpg

Finally the filtered RoR, 4 second average and 10 second average comparison for the same data, exactly as above (red, orange, blue respectively).

up.picr.de/7027590ibl.jpg

This posting is already a marathon, so lets go the full 5 miles with one last point which I forgot to mention earlier: we can also make good use of the statistical variability of the BT temperatures between samples, because this should give an indication of temperature distribution of the beans. If we were to calculate the standard deviation of the individual samples returned by the ADC within each one second sampling period (or longer - one second might well be too short) we can display that live on the graph in Processing, and that will show up any problems with irregular bean temperature as they arise. For example if the green beans have too much moisture and have not yet fully dried out, or if the beans were picked with too uneven ripeness, or if we are heating the beans up much too fast, or if we are using a bean like Old Brown, all these things will show up in the standard deviation, and we can then modify the roast profile accordingly.

Bhante
(sorry about the long post!)
Edited by Bhante on 05/06/2011 8:06 AM
 
greencardigan
:up-late: My coffee went cold while I read your post.

I'm still using the 16 bit temp conversions and don't have any problems with it yet.

Brad (the sprinter)
 
Bhante

Quote

greencardigan wrote:I'm still using the 16 bit temp conversions and don't have any problems with it yet.


Are you using the ADC in continuous mode or shot mode? How many readings are you getting per second?

Regards
Bhante
 
Jump to Forum:

Similar Threads

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