LinkMeter v2 Homebrew BBQ Controller - Part 1


 
Status
Not open for further replies.
Originally posted by Kyle Christensen:
This may be a dumb question, but has anyone developed a How-to / Step by step guide to building the HeaterMeter hardware?

I'm a relative novice when it comes to electronics, having built Icetube clocks and that sort of thing before. However, that stuff is basically paint by numbers and seems far more foolproof than fabricating a HeaterMeter.

I can solder, but I'm wondering if there are pitfalls / best practices regarding getting boards printed (from Dorkbot, BatchPCB, etc), and actually putting everything together.

Also, is it safe to assume that the Heatermeter parts list and schematics in GitHub are "functional" at any point in time, or is there some type of stable branch I'm missing?

I have a spare WRT54GS laying around and have tinkered with Arduino, PID controllers and OpenWRT before so I figure going the DIY route is more interesting than just buying some Auber controller.

I'd appreciate any guidance you guys might have.

Thanks!
Click to expand...

Kyle,

From what you say about your background you are good to go. The HM board is really quite easy to do. I would add to the mouser parts, sockets for the ICs because I find them easier to work with and provide great flexibility.

The most difficult part of the board is generating the CAD files for manufacturing. You may post and ask, as someone here may already have an extra board that they would sell you.

Building the board is easy, connect the dots like you said. I had an issue with the LCD on one of my HM builds, but the other two went off without a hitch.

I too use the WRT54GS and it does not have a cut out inside the router, so I can't put the HM board inside the router. I put it in a project box from Radio Shack instead. I can supply you the faceplate template I used to cut the box if you'd like.

I attached the LCD and 4-way switch board using 2-56 machine screws. The temp probe sockets, and blower connector hook up just fine through the faceplate as well. I ended up connecting the project box to the router (for serial communication) using a cat5e cable and matching keystone sockets.

The one other item you need is the board for the 4-way button. I used the layout from the wiki and etched my own, but it would be easy to do it the way Bryan did in one of his posts on an earlier thread.

Ask more questions if I confused you
icon_smile.gif
I'm pretty good at confusing people.

dave
 
Success!!!

I got all three of my HM up and running now. One is running with the default ET-73 probes, the other two with the ET-732 probes.

The final Steinhart-Hart coefficients I used are:
<STRIKE>{5.3612e-4,1.91532e-4,6.557e-8,1.0e+4}</STRIKE>, // Maverick Probe ET-732 http://content.honeywell.com/s...resistanceTable2.asp

EDIT: updated coefficients, but don't see any difference. Just doing for completeness. New coefficients are: {5.36924e-4,1.91396e-4,6.60399e-8,1.0e4}

In the process of getting the correct coefficients I discovered that my BBQ Guru is off by 8 degrees at boiling, so it reads 220 instead of 211. I guess this means I've been cooking really low-n-slow.

After many hours spent on the ET-732 probes here is my conclusion.
Pro:
- The are rated up to 300C (572F) which I prefer over the ET-73 probes. For food I don't see any benefit, but for the pit I can have higher pit temperatures without fear of damaging the probe.

Con:
- The shaft of the probes is about 0.075" longer that the ET-73 probes. This meant I had to place a collar on the probes to keep them from inserting too far into the sockets.
- These are 1M ohm probes, meaning at 25C they read 1M ohm. I would prefer 12 bits of ADC instead of the 10 bits we get with the ATmega 328 because at temperatures < 90 degrees doesn't have the accuracy I like. 11 bits would be better and 12bit perfect.

Maybe this can help someone else,
dave
 
Bryan,

Do you have a little lcd print function that you use to help print out values for debug? I'm adding in so oversampling and decimation per this app note:
http://www.atmel.com/dyn/resou...ocuments/doc8003.pdf

To the readTemp function to get a couple more bits accuracy, but am having issues with debuging what is going wrong.

Essentially I've changed TempProbe::readTemp to be:

unsigned int over_sampled_temp = 0;
for (int i=0; i<4^INCREASED_ADC_BITS; i++)
over_sampled_temp += analogRead(_pin);
over_sampled_temp = over_sampled_temp >> INCREASED_ADC_BITS;
addAdcValue(analogRead(_pin));

I then also changed the calcTemp fuction to adjust for the proper number of bits. What happens is I get - no pit probe - and it just hangs. I have to pull the controller and flash with the Uno board.

Any suggestions on how to print values to the LCD so I can see them would be great
icon_smile.gif


thanks,
dave
 
OK I got it mostly working and do see an improvement.

Still having one issue. When adding any additional bits, I think there is a memory over-run because when I only have a single probe plugged in, I actually get that temperature (pit) and a "normal" probe reading as well. I'm wondering if that means that the value is over-running into the next probe in memory?

If this is the case, how do I increase the size of the variable that I'm storing the read value? From looking at the code and _accumulator in TempProbe is is an unsigned int and that is plenty big enough for 11 bits. Of course I could just be reading it all wrong.

thanks
dave

Originally posted by D Peart:
Bryan,

Do you have a little lcd print function that you use to help print out values for debug? I'm adding in so oversampling and decimation per this app note:
http://www.atmel.com/dyn/resou...ocuments/doc8003.pdf

To the readTemp function to get a couple more bits accuracy, but am having issues with debuging what is going wrong.

Essentially I've changed TempProbe::readTemp to be:

unsigned int over_sampled_temp = 0;
for (int i=0; i<4^INCREASED_ADC_BITS; i++)
over_sampled_temp += analogRead(_pin);
over_sampled_temp = over_sampled_temp >> INCREASED_ADC_BITS;
addAdcValue(analogRead(_pin));

I then also changed the calcTemp fuction to adjust for the proper number of bits. What happens is I get - no pit probe - and it just hangs. I have to pull the controller and flash with the Uno board.

Any suggestions on how to print values to the LCD so I can see them would be great
icon_smile.gif


thanks,
dave
Click to expand...
 
Originally posted by D Peart:
Success!!!

I got all three of my HM up and running now. One is running with the default ET-73 probes, the other two with the ET-732 probes.

The final Steinhart-Hart coefficients I used are:
{5.3612e-4,1.91532e-4,6.557e-8,1.0e+4}, // Maverick Probe ET-732 http://content.honeywell.com/s...resistanceTable2.asp

In the process of getting the correct coefficients I discovered that my BBQ Guru is off by 8 degrees at boiling, so it reads 220 instead of 211. I guess this means I've been cooking really low-n-slow.

After many hours spent on the ET-732 probes here is my conclusion.
Pro:
- The are rated up to 300C (572F) which I prefer over the ET-73 probes. For food I don't see any benefit, but for the pit I can have higher pit temperatures without fear of damaging the probe.

Con:
- The shaft of the probes is about 0.075" longer that the ET-73 probes. This meant I had to place a collar on the probes to keep them from inserting too far into the sockets.
- These are 1M ohm probes, meaning at 25C they read 1M ohm. I would prefer 12 bits of ADC instead of the 10 bits we get with the ATmega 328 because at temperatures < 90 degrees doesn't have the accuracy I like. 11 bits would be better and 12bit perfect.

Maybe this can help someone else,
dave
Click to expand...

This is where I am stuck. I am trying to figure out to get the coefficients. This is the biggest thing I am missing when creating my own network connected thermo. Can anyone point me in the direction of step by step howto on how to set this up and calculate?

Thanks.

-Mike
 
Originally posted by D Peart:
Still having one issue. When adding any additional bits, I think there is a memory over-run because when I only have a single probe plugged in, I actually get that temperature (pit) and a "normal" probe reading as well. I'm wondering if that means that the value is over-running into the next probe in memory?

If this is the case, how do I increase the size of the variable that I'm storing the read value? From looking at the code and _accumulator in TempProbe is is an unsigned int and that is plenty big enough for 11 bits. Of course I could just be reading it all wrong.
Click to expand...
It doesn't overflow memory like that. In C if you add to an integer the size remains the same regardless of how much you put in it. It just rolls over on itself. The code already kinda does what you're trying to do though, it takes 8 samples then averages them. It does this to remove outliers though more than to provide enhanced resolution.

You should have enough space in an unsigned int to store 64 ADC samples, but your code looks to be sampling 4^bits times where if bits is larger than 2 you're overflowing. If you want an accurate value out, you need to keep the number of samples below 64.

I advise you to try writing a program that reads the ADC then reads it 1000 times after that and calculates the variance and standard deviation. I did that back when I was in the design phase of this and found that no matter how many times you read the ADC it doesn't increase the resolution by a significant amount. If the temperature is 73.3 or 73.4 or 73.5 or 73.6... 74.2 you always will get the exact same ADC reading unless there is noise on the line so sampling it a jillion times doesn't matter because you always get the same result. I was hoping it would bounce between two numbers and you could estimate the temperature based on how many times it was one value vs the other. If you notice the temperature HeaterMeter outputs comes out the same 99 times out of a 100 despite the fact that it is taking 8 samples.

If you just want more samples, then just change TEMP_AVG_COUNT to something larger. It used to be limited to 8 because it stored the counter inside the value itself and more than 8 would overflow them both, but now it is limited to 64.
 
Yes I see that you already average and even with oversampling/decimation you still want to average.

There is a difference between the two though. For oversampling/decimation you take 4^n samples, sum them up, and divide by 2^n. This is where you get the additional accuracy. This part is working quite well. With 10 bits my temperature fluctuates between 62, 68 and 74 when the temperature is ~71. Averaging doesn't fix this, as you need more accuracy. When I use 12 bits it sticks right at 71 - 72. So I can see the added benefit. I just need to figure out why I get the pit temperature correctly displayed while at the dame time another probe at some odd temperature printed when using more than 11 bits.

Using this method you can add up to 3 bits of accuracy with only 64 over samples. But if I even do 1 bit of accuracy (4 over samples) I get the same thing with the probe temp being displayed when it shouldn't.

I'll keep plugging away at it to see if I can figure it out as I don't want to give up the improvements. All in all I only had to change about 10 lines of code to get it implemented. Just need to figure out what I borked
icon_smile.gif


Here is a quick example:
NADC reading 8 readings at 1015 and 8 readings at 1014 for a total of 16 readings and sum of 16232.

16232/16 = 1014.5
16232/4 = 4058

10bit = average = 1014.5 = 71-74 degrees
12bit = oversampling/decimation = 4058 = 73 degrees

thanks,
dave

Originally posted by Bryan Mayland:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by D Peart:
Still having one issue. When adding any additional bits, I think there is a memory over-run because when I only have a single probe plugged in, I actually get that temperature (pit) and a "normal" probe reading as well. I'm wondering if that means that the value is over-running into the next probe in memory?

If this is the case, how do I increase the size of the variable that I'm storing the read value? From looking at the code and _accumulator in TempProbe is is an unsigned int and that is plenty big enough for 11 bits. Of course I could just be reading it all wrong.
Click to expand...
It doesn't overflow memory like that. In C if you add to an integer the size remains the same regardless of how much you put in it. It just rolls over on itself. The code already kinda does what you're trying to do though, it takes 8 samples then averages them. It does this to remove outliers though more than to provide enhanced resolution.

You should have enough space in an unsigned int to store 64 ADC samples, but your code looks to be sampling 4^bits times where if bits is larger than 2 you're overflowing. If you want an accurate value out, you need to keep the number of samples below 64.

I advise you to try writing a program that reads the ADC then reads it 1000 times after that and calculates the variance and standard deviation. I did that back when I was in the design phase of this and found that no matter how many times you read the ADC it doesn't increase the resolution by a significant amount. If the temperature is 73.3 or 73.4 or 73.5 or 73.6... 74.2 you always will get the exact same ADC reading unless there is noise on the line so sampling it a jillion times doesn't matter because you always get the same result. I was hoping it would bounce between two numbers and you could estimate the temperature based on how many times it was one value vs the other. If you notice the temperature HeaterMeter outputs comes out the same 99 times out of a 100 despite the fact that it is taking 8 samples.

If you just want more samples, then just change TEMP_AVG_COUNT to something larger. It used to be limited to 8 because it stored the counter inside the value itself and more than 8 would overflow them both, but now it is limited to 64. </div></BLOCKQUOTE>
 
Mike,
What I did was use vegetable oil, put it in the freezer to make it really cold, then slowly warmed it up, with the probe to be characterized in it with an instant read digital thermometer. I hooked up my DVM directly to the thermistor and wrote down the resistant and temperatures as the oil was heated. This got me close, but not exact.

What I ended up doing in the end was to get the values at boiling water (212 for me because I'm essentially at sea level), and room temp, but 25C would work best. So get those two pairs of numbers. I then went to mouser searched for thermistor ntc (I have an NTC thermistor, which means that the resistance decreases with increasing temperature). They are ranked by the resistance seen at 25C, and the temperature range. For me it was 1M ohm at 25C with a range of -50 to 300C. I was then able find thermistors that were close to what I had, go to the manufactures website and pull the T vs R curves. I looked at the cures to find the ones that matched most closely to my recorded numbers. This led me to a published result that matched very well.

You will also need the temperature sensor lookup table generation tool that Bryan pointed to in earlier posts and is on the webpage.

What type of probe do you have? If it is the ET-73 one, then Bryan has already done that work and it should work by default.

dave


Originally posted by M Rochford:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by D Peart:
Success!!!

I got all three of my HM up and running now. One is running with the default ET-73 probes, the other two with the ET-732 probes.

The final Steinhart-Hart coefficients I used are:
{5.3612e-4,1.91532e-4,6.557e-8,1.0e+4}, // Maverick Probe ET-732 http://content.honeywell.com/s...resistanceTable2.asp

In the process of getting the correct coefficients I discovered that my BBQ Guru is off by 8 degrees at boiling, so it reads 220 instead of 211. I guess this means I've been cooking really low-n-slow.

After many hours spent on the ET-732 probes here is my conclusion.
Pro:
- The are rated up to 300C (572F) which I prefer over the ET-73 probes. For food I don't see any benefit, but for the pit I can have higher pit temperatures without fear of damaging the probe.

Con:
- The shaft of the probes is about 0.075" longer that the ET-73 probes. This meant I had to place a collar on the probes to keep them from inserting too far into the sockets.
- These are 1M ohm probes, meaning at 25C they read 1M ohm. I would prefer 12 bits of ADC instead of the 10 bits we get with the ATmega 328 because at temperatures < 90 degrees doesn't have the accuracy I like. 11 bits would be better and 12bit perfect.

Maybe this can help someone else,
dave
Click to expand...

This is where I am stuck. I am trying to figure out to get the coefficients. This is the biggest thing I am missing when creating my own network connected thermo. Can anyone point me in the direction of step by step howto on how to set this up and calculate?

Thanks.

-Mike </div></BLOCKQUOTE>
 
OK got it all working. I'm not sure why it was breaking, but my latest change fixed it. I'm now getting very steady values at 71 degrees. Prior to this it would fluctuate between 62 and 74.

When I tried 256 samples it did overflow and I got bogus values (306F). So 64 over samples is the correct value to not overflow. I don't see that I need more than this anyway. Next I'll swap the 10kohm resistor to a 22kohm one to shift the curve to the left and re-center the graph.

This is awesome
icon_biggrin.gif


dave

P.S. - Serial.println is your friend . . .
 
Bryan,

I'm not sure if you're interested in this change, but I figured it was easy enough for me to post a patch file.

grillpid_diff.txt:
18a19,22
> // Oversample and decimation is used to increase ADC accuracy
> #define INCREASED_ADC_BITS 3
> #define MAX_ADC (pow(2,(10 + INCREASED_ADC_BITS)) - pow(2,INCREASED_ADC_BITS))
>
109c113
< // If we get *any* analogReads that are 0 or 1023, the measurement for
---
> // If we get *any* analogReads that are 0 or MAX_ADC, the measurement for
111c115
< if (analog_temp <= 0 || analog_temp >= 1023)
---
> if (analog_temp <= 0 || analog_temp >= MAX_ADC)
122c126,130
< addAdcValue(analogRead(_pin));
---
> unsigned int over_sampled_temp = 0;
> for (int i=0; i<pow(4,INCREASED_ADC_BITS); i++)
> over_sampled_temp += analogRead(_pin);
> over_sampled_temp = over_sampled_temp >> INCREASED_ADC_BITS;
> addAdcValue(over_sampled_temp);
127c135
< const float Vin = 1023.0f;
---
> const float Vin = (float)MAX_ADC;
362c370
<
---
>

The problem I had was with MAX_ADC. I originally set it to
#define MAX_ADC (pow(2,(10 + INCREASED_ADC_BITS)) - 1) because for 10 bits you had it set to 1023. I assumed you just wanted 0-1023 that that was the reason for 1023. However, when I ran at anything about 10 bits I got the issue where all the probes thought they had temperatures and would be updated on the display. I found that if I changed it to what is there now, basically -2^n instead of -1, it works. What I don't understand is why would MAX_ADC make that difference? It just sets Vin and is used to cut off bogus values. Anyway it is working great now so I thought I'd share.

dave
 
Originally posted by D Peart:
There is a difference between the two though. For oversampling/decimation you take 4^n samples, sum them up, and divide by 2^n. This is where you get the additional accuracy. This part is working quite well. With 10 bits my temperature fluctuates between 62, 68 and 74 when the temperature is ~71. Averaging doesn't fix this, as you need more accuracy. When I use 12 bits it sticks right at 71 - 72. So I can see the added benefit. I just need to figure out why I get the pit temperature correctly displayed while at the dame time another probe at some odd temperature printed when using more than 11 bits.
Click to expand...
Oh I see! That's what I get for glossing over that PDF you linked while nursing a hangover. Dang I wish my LinkMeter was plugged in right now, I'd love to try this out. It is really a quick change and it would be pretty beneficial to increasing the resolution of the data. The only addition I'd make is that when doing your oversampling, if any of the ADC values is 0 or 1023, all the data should be thrown out for that cycle, as a probe could be being inserted or removed. I'll take a look at this tonight!
 
What is the vertical yellow bar on the fan speed line? I see it starts at the far right, and as the cook progresses it moves to the left.

dave
 
Originally posted by D Peart:
What is the vertical yellow bar on the fan speed line? I see it starts at the far right, and as the cook progresses it moves to the left.
Click to expand...
It is the "average" fan speed over the 60 samples.

"Current / Average fan speed. The current fan speed percent is indicated by the size of the bar and the label. The exponential moving average of the fan speed is displayed as a translucent rectangle at the correct percentage."

The oversampling change breaks lmremotes so I'm kinda having to retool that a bit, but I definitely want to get this in. This is awesome, Dave!
 
Here is a link to my latest test run. This was an empty smoker so I expect that the oscillations will decrease when I actually get some thermal mass inside. I was testing out my latest changes to the thermistor and testing my newly built SSR with the electrical element. I did learn that I do need a heat sink on the SSR. It didn't get too hot, but hotter than I would like. So next is attaching my heat sink, putting in a pan of water and giving it another shot.

Capture.png
 
I think it would work inside the addAdcValue function the best, but I didn't understand it well enough to get it in there, so I just put it in readTemp. Hopefully you can figure out a cleaner solution
icon_smile.gif


dave

Originally posted by Bryan Mayland:
<BLOCKQUOTE class="ip-ubbcode-quote"><div class="ip-ubbcode-quote-title">quote:</div><div class="ip-ubbcode-quote-content">Originally posted by D Peart:
What is the vertical yellow bar on the fan speed line? I see it starts at the far right, and as the cook progresses it moves to the left.
Click to expand...
It is the "average" fan speed over the 60 samples.

"Current / Average fan speed. The current fan speed percent is indicated by the size of the bar and the label. The exponential moving average of the fan speed is displayed as a translucent rectangle at the correct percentage."

The oversampling change breaks lmremotes so I'm kinda having to retool that a bit, but I definitely want to get this in. This is awesome, Dave! </div></BLOCKQUOTE>
 
Originally posted by D Peart:
Kyle,

From what you say about your background you are good to go. The HM board is really quite easy to do. I would add to the mouser parts, sockets for the ICs because I find them easier to work with and provide great flexibility.

The most difficult part of the board is generating the CAD files for manufacturing. You may post and ask, as someone here may already have an extra board that they would sell you.

Building the board is easy, connect the dots like you said. I had an issue with the LCD on one of my HM builds, but the other two went off without a hitch.

I too use the WRT54GS and it does not have a cut out inside the router, so I can't put the HM board inside the router. I put it in a project box from Radio Shack instead. I can supply you the faceplate template I used to cut the box if you'd like.

I attached the LCD and 4-way switch board using 2-56 machine screws. The temp probe sockets, and blower connector hook up just fine through the faceplate as well. I ended up connecting the project box to the router (for serial communication) using a cat5e cable and matching keystone sockets.

The one other item you need is the board for the 4-way button. I used the layout from the wiki and etched my own, but it would be easy to do it the way Bryan did in one of his posts on an earlier thread.

Ask more questions if I confused you
icon_smile.gif
I'm pretty good at confusing people.

dave
Click to expand...

Thanks for the info! I just ordered up the mouse/digikey/polou parts list on the Wiki and some IC sockets, and have a 3.1 board on the way. Once I've had time to put the board together I'll see about getting a button board printed up or depending on time see about etching my own (I've always wanted to try that.)

I haven't ordered probes yet as I was unsure as to actual probe usage. I haven't stumbled upon mention of how many most people run, or probe placement.

I'm new to smoking meat in general, I recently bought my first house and my gf bought me a 18" as a housewarming gift. In typical geek fashion, I have not even fired it up yet and I'm ready to modify it..
 
Status
Not open for further replies.

 

Back
Top