LinkMeter v2 Homebrew BBQ Controller - Part 1

[D Peart]

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:
I just checked and at 72.0 F I get 1.170 mega ohms. I looked at the ET-73 sheet and it reports:

rmax 43.40k
rnom 40.82k
rmin 38.35k

That is a substantial difference.

Yeah it sure is. From my calculations based on that, 72F is 1015 (out of 1023) on the ADC. I'm wondering if there's enough error in the single-precision floats, the fixed resistor, and the probe itself to cause a reading of -22F.

Now that I look at it, it doesn't look like a tremendous difference. I'm guessing the problem is that that 1015 is 4.96V, which may be too close to the 5V reference voltage to get an accurate reading? </div></BLOCKQUOTE>

EDIT: I was looking at the table, if I change the 10k to 20k, that seems to put the non-linear spot between 200-250F. That gives us the most separation in the prime cooking area.

Does that make sense or am I way off?

dave

 

[D Peart]

Got my DVM out and took some measurements.

coeffecients:
pc0=4.31592e-4,2.08437e-4,4.71797e-9,0,1.0e4

Temp .... Reported Temp Voltage
72.5 .... -14 ......... 4.91
92.8 .... 2 ......... 4.88
121 .... 32 ........ 4.79
142.8.... 55 ........ 4.68

Voltage without the probe inserted is 4.95
dave

 

[Bryan Mayland]

Dave I'll run your numbers through to see if what you're seeing jives with the math tomorrow. It doesn't seem to match what I'd expect to get but you've given me some good data so I can trace through the code and see if there's a bug in it.

I did come to post that I pushed a new firmware / lm package that expands on the archive page and allows you to delete stashed files, activate them (if they are within the past 24 hours), and shows free space available on the stash path. It also works around some mixing problems if you try to attach your HeaterMeter to ttyS0, which I have now that I blew out my ttyS1.

If you're trying to run off ttyS0, make sure you disable the getty on it by commenting out the ttyS0 line in /etc/inittab. If the getty is running on it too you'll have intermittent failure.

Finally, I'll say that I haven't upgraded to Arduino-1.0 yet. This isn't because I am lazy, it is because I'm not quite happy with the changes they've made to 1.0. Notably, the Print class, the serial overhead, and the way they seem to just ignore glaring problems and carry on their merry way. HeaterMeter does not compile under 1.0. Stick with 0022 for now.

 

[D Peart]

Bryan,

I modified the code to print Vout instead of the temperature.

When I look at Vout I see that it tracks correctly. I get the correct Vout value for the temperature I see on my digital thermometer. For example, at 95 I get 1008 and for 75 I'm getting 1014 - 1013 which is pretty close as well.

If I use the coefficients that I get from a datasheet for a 1 mega ohm, glass thermistor (which is what I think the ET-732 uses) I get even better numbers. When I put the probe in my arm pit it reads 1006 which is 98 degrees per the table.

Now I just need to figure out why the temperature conversion isn't happening correctly. Ideas on where to look?

dave

 

[D Peart]

OK I coded up your temperature conversion code in TCL to see if it worked for me there and it does. Maybe we have a precision issue? Here is what I get from TCL

set Steinhart_0 3.61446e-4
set Steinhart_1 2.04672e-4
set Steinhart_2 6.27945e-8
set Steinhart_3 1.0e4
set Vin 1023.0
set Vout 1006.0

# If you put the fixed resistor on the Vcc side of the thermistor, use the following
set R [expr log($Steinhart_3 / (($Vin / $Vout) - 1.0))]

# Compute degrees K
set T [expr 1.0 / (($Steinhart_2 * $R * $R + $Steinhart_1) * $R + $Steinhart_0)]

set Temperature [expr (($T - 273.15) * (9.0 / 5.0)) + 32.0]
puts $Temperature

3.61446e-4
% 2.04672e-4
% 6.27945e-8
% 1.0e4
% 1023.0
% 1006.0
% % % 13.2908643786
% % % 309.67976194
% % 97.753571492
% 97.753571492

Which came out at 97.7 which is what the table predicted and is close to body temp.

dave

 

[Bryan Mayland]

Originally posted by D Peart:
Now I just need to figure out why the temperature conversion isn't happening correctly. Ideas on where to look?

With your information I've modified my HeaterMeter to emulate yours and guess what? I get -15F too! If I compile the code for Win32 I get 77.3F. Now I can track this bug down, stand by!

 

[D Peart]

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:
Now I just need to figure out why the temperature conversion isn't happening correctly. Ideas on where to look?

With your information I've modified my HeaterMeter to emulate yours and guess what? I get -15F too! If I compile the code for Win32 I get 77.3F. Now I can track this bug down, stand by! </div></BLOCKQUOTE>

Good I wasn't imagining things. I was going to look at the R value that gets calculated to see if that was failing.

My only way to debug is to print the values as the pit temp on the LCD

It works, but isn't too fast.

dave

 

[Bryan Mayland]

Originally posted by D Peart:
Good I wasn't imagining things. I was going to look at the R value that gets calculated to see if that was failing.

I've got it figured out. It is actually a bug in the web setting routine causing the coefficients to get screwed up when being passed to HeaterMeter. I'll have a fixed linkmeter package out later today.

EDIT: Fixed! You can just
opkg install http://capnbry.net/linkmeter/s...meter_2_brcm47xx.ipk

Or optionally install the whole new firmware. With your original coefficients from the previous page, I now get 77.3 at 1013 ADC. The bug was actually in the linkmeterd setter code but I found a lot of little bugs that caused some values to be corrupted on send for various reasons.

 

[D Peart]

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:
Good I wasn't imagining things. I was going to look at the R value that gets calculated to see if that was failing.

I've got it figured out. It is actually a bug in the web setting routine causing the coefficients to get screwed up when being passed to HeaterMeter. I'll have a fixed linkmeter package out later today.

EDIT: Fixed! You can just
opkg install http://capnbry.net/linkmeter/s...meter_2_brcm47xx.ipk

Or optionally install the whole new firmware. With your original coefficients from the previous page, I now get 77.3 at 1013 ADC. The bug was actually in the linkmeterd setter code but I found a lot of little bugs that caused some values to be corrupted on send for various reasons. </div></BLOCKQUOTE>

I installed the new package, but something is still not right.

If I set the coefficients in hmcore.cpp, then it appears to work, but if I then try to set the exact same coefficients via the webpage, it goes to -no pit probe -. So something is still not working.

I did reboot my router, but it didn't make any difference.

dave

 

[Bryan Mayland]

Originally posted by D Peart:
If I set the coefficients in hmcore.cpp, then it appears to work, but if I then try to set the exact same coefficients via the webpage, it goes to -no pit probe -. So something is still not working.

Ah crap. I'll have to dig into it and see what I've forgotten to include. It is really fun working on it because I make all the changes to get it working, scp back all the files I've changed to the build system and make the package. I must have forgotten one of the changed files, but I can't fix it now because my system is all torn apart trying to fix a bug in LuCI's nixio.

Can you try setting the parameters via a standard "set"? Not a rawset. Log in and go back to the LM home screen then append the url with /set?pc0=xxxxxx. This can tell me if the bug is in the form on the config page, which is something I had to fix today.

Also try going right to serial from an ssh/telnet prompt `echo /set?pc0=xxxxx > /dev/ttyS1`

 

[D Peart]

If I run:

echo /set?pc0=3.16446e-4,2.04672e-4,6.27945e-8,0,1.0e4 > /dev/ttyS1

I get the - no pit probe - message. I have to reset the HM to the original configuration to get it working again.

I get the same result from the webpage.

The coefficients do seem to work if I set them as the defaults in hmcore.cpp.

dave

dave

 

[Bryan Mayland]

Originally posted by D Peart:
echo /set?pc0=3.16446e-4,2.04672e-4,6.27945e-8,0,1.0e4 > /dev/ttyS1

Ah! You have an extra coefficient in there so... the resistance is 0 so "do not change" and then 1.0e4 is being interpreted as probe type, so probe type 1 is "disabled".

 

[Bryan Mayland]

I've done it! I've tracked down another set of bugs in the LuCI nixio UNIX domain sockets implementation which was limiting linkmeterd to only being able to handle 1 client at a time (the other's just wouldn't get any data back). What's that mean? LIVE STREAMING. Yup, the web browser* now gets updates as they happen rather than polling every 10 seconds.

* Only on browsers that support "Server-Sent Events". Firefox, Chrome, Opera. IE and Android Browser still use polling.

Now the problem is that the graph fills up with garbage if you keep adding points every 2 seconds. Every time it hits 500 points it reloads from the rrd database which looks fine at the 1 hour mark, but really terrible when the graph scale is 6-24 hours. :/

 

[D Peart]

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:
echo /set?pc0=3.16446e-4,2.04672e-4,6.27945e-8,0,1.0e4 > /dev/ttyS1

Ah! You have an extra coefficient in there so... the resistance is 0 so "do not change" and then 1.0e4 is being interpreted as probe type, so probe type 1 is "disabled". </div></BLOCKQUOTE>

OK so this works

echo /set?pc0=3.16446e-4,2.04672e-4,6.27945e-8 > /dev/ttyS1

just the coefficients.

dave

 

[D Peart]

echo /set?pc0=3.16446e-4,2.04672e-4,6.27945e-8,

Just for my edification.

When I update my coefficients in hmcore.cpp, compile and flash new hex file. I need to do a reset configuration to see the changes. Correct?

thanks
dave

 

[Bryan Mayland]

Originally posted by D Peart:
When I update my coefficients in hmcore.cpp, compile and flash new hex file. I need to do a reset configuration to see the changes. Correct?

Yeah the compiled-in values are the defaults if there's no configuration found in EEPROM or you force reset them. I assume setting them from the web interface works now too, if you remove that 0?

Here's what the graph looks like if you store all the points (only the last 15 minutes is 'live' data). I'm thinking about maybe doing something like if the point is different than the previous point, looking at the spread of the graph, and then if the new point would appear within 2 pixels of the previous point, averaging the two prior points before adding the new point. Got any better ideas?

EDIT: Forgot to link the image durrrr

 

[D Peart]

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:
When I update my coefficients in hmcore.cpp, compile and flash new hex file. I need to do a reset configuration to see the changes. Correct?

Yeah the compiled-in values are the defaults if there's no configuration found in EEPROM or you force reset them. I assume setting them from the web interface works now too, if you remove that 0?

Here's what the graph looks like if you store all the points (only the last 15 minutes is 'live' data). I'm thinking about maybe doing something like if the point is different than the previous point, looking at the spread of the graph, and then if the new point would appear within 2 pixels of the previous point, averaging the two prior points before adding the new point. Got any better ideas?

EDIT: Forgot to link the image durrrr </div></BLOCKQUOTE>

So the upper window is the latest 15 minutes, and the bottom window will be the entire cook?

 

[Bryan Mayland]

Originally posted by D Peart:
So the upper window is the latest 15 minutes, and the bottom window will be the entire cook?

No it is still the same way it works now, which is bad enough with 10s updates, but the new code pushes every update to the web browser rather than the browser requesting it every 10 seconds so the graph gets all jammed up on itself like on the right side.

 

[D Peart]

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:
So the upper window is the latest 15 minutes, and the bottom window will be the entire cook?

No it is still the same way it works now, which is bad enough with 10s updates, but the new code pushes every update to the web browser rather than the browser requesting it every 10 seconds so the graph gets all jammed up on itself like on the right side. </div></BLOCKQUOTE>

The only thing that I like to see updated more "real time" are the temperatures. For me the graph just updating every 10 seconds, or even a rolling average is fine with me.

I don't like the smashing on the right side as it blocks the real data with noise.

dave

 

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