The Development Log


 
There's a new AVR firmware snapshot available in the online repository 20160910B.

Ever since the switch to the free-running ADC, the buttons have been less responsive. Sometimes they miss a press, and so you hold it down to get it to work and then it works TOO well and you get too many button presses. It was a pain with the 4-way switch, but nowhere is it more obvious than with the 4 individual buttons of the HeaterMeter v4.3, which have a great tactile SNAP when you press them... but HeaterMeter didn't recognize the press. I spent the last day analyzing the button press waveforms in the oscilloscope and concluded it was not a hardware problem, both the 4-way and individual buttons work amazingly well and always have sharp press transitions and almost always have sharp falloffs. It was clearly a software issue, which is what we knew all along right?

The ADC loop in grillpid samples 255 data points and 3 or 48 discard samples for each 6 ADC inputs. Each sample is 0.105ms so 27.09ms per ADC or 162.54ms per loop. This high latency between button means a press can be missed, especially if it was being pressed during the 27ms poll of the button input (which would be discarded as a transition) so the button would have to be held at least 320ms to be detected.

The new code polls the buttons for just 4 samples in between each of the other full-oversampling ADC readings. This creates a 27ms max latency between button polls and because the sampling period is only 0.42ms there is 50x less of a chance of catching an edge (which is on the order of 100ns). Reducing this to 1 or 2 samples may be beneficial if that is found to be a problem.

As a side effect of the high button latency, the user would hold down the button for longer to get it to respond, which also would create key repeats because they would need to hold it for 160-320ms but then release it in under 250ms. The new code enforces a 250ms lockout of all activity after any button event, although the responsiveness of the buttons now mitigate this issue.

So give it a try and let me know if it feels better. Also please pay careful attention to servo chattering. I tried to make the code as small as possible, but there is more code in the interrupt handler which might mess with our servos again.
 
I've noticed the button issue, it's something I just learned to live with... I will give this new firmware a try and let you know how things work.
 
I flashed the snapshot firmware and am happy to report that the buttons work wonderfully now! Response is quick and accurate, seems to be 100% at this speed. I'm not doing a cook right now and didn't check my servo for chatter, I will report back on that later when I have cook going.
 
And the rest of today I spent recalibrating the coefficients for the Thermoworks Pro-Series probes. First I calibrated my thermocouple by binding two thermocouples together and wrapping them in aluminum foil and putting them in the oven and letting it stabilize at 400F, and adjusted my mv/C to get a match in HeaterMeter to what was reported by the Thermoworks Pro Handheld thermocouple reader (5.07mV/C) and let the oven cool back to room temperature to verify the values tracked all the way down.

Next I replaced one of the thermocouples with the thermistor and did the same thing, except this time I turned on the Linkmeter Unknown Probe plugin (lmclient LMUP,start). I got myself a set of coefficients once I was down to 20C (lmclient LMUP,fit && lmclient LMUP,stop) and put them into HeaterMeter. The room temperature value didn't match (off by 0.5C). Then heated up both in boiling water, the values didn't match (off by 0.5-0.75C, hard to tell). Then I spent the rest of the afternoon trying to find a bug in the curve fitting.

-- Went over every line of code in the algorithms checking for math / logic errors.
-- Tried replacing the fit function with single precision floats vs double (AVR is single, RPi is double). Ran another test, extremely small difference (~0.001C) but very difficult to converge the sum of squares for fitting.
-- Tried comparing the values of the log() function from AVR libc to gnuc libc, within 0.0000003 difference. That makes the difference of 0.0000123C at 100C. Nope, not that either.
-- Ran another full test with some "ballast" in the foil with the probes (a teaspoon of salt). Same results.

I'm done with trying because I can't think of why they don't match up better. I guess it has something to do with trying to best fit the steinhart coefficients and there being some variance in the readings from HeaterMeter. In any case, the new coefficients will be in the next linkmeter release, you can see the difference between the old and the new ADC Therm Graphs (new is the Blue). It equates to a 0.9C degree increase at boiling (99.1C previously will now read 100.0C), 1.1C at 150C, and 0.4C at 25C.

The new coefficients are 7.0553684e-4,2.1914861e-4,9.7649335e-8
 
Last edited:
What a PITA...
For what it's worth, even though the original TW's coefficients result in a slight inaccuracy at the boiling point, I've always found meat to be cooked exactly the way I want it when using TW probes. Perhaps they are more accurate in the 125-155F range for rare to medium-well cooks where a couple degrees makes a difference. My well done low and slow cooks always turn out great too, so I can't argue with the results....
 
I found this site that has a Steinhart-Hart coefficient calculator. How closely are your values to those produced by the calculator?

Did you adjust the boiling temp for altitude? I'm at 735'msl and that is enough to lower the boiling point by ~0.8C.
Another source of error could be in the accuracy of your resistance meter.

I hope I'm not insulting you, just brainstorming possible error sources. Even NASA gets it wrong sometimes....

Regardless, thank you both for all your time and effort on this project!!

Mike
 
Bryan Mayland said:
And the rest of today I spent recalibrating the coefficients for the Thermoworks Pro-Series probes.
Click to expand...

I'd just like to give you a huge thank you for all the incredible work (along with others). I love my heater meter, and I especially love that I built mine using open source designs and software for the most part.
 
MHutchins said:
How closely are your values to those produced by the calculator?

Did you adjust the boiling temp for altitude? I'm at 735'msl and that is enough to lower the boiling point by ~0.8C.
Another source of error could be in the accuracy of your resistance meter.
Click to expand...
Thanks for the ideas, Mike. There's no insulting, sometimes the answers are easily overlooked! It is hard to say if that calculator makes close values. I take about 1000 data points then try to curve fit it to the steinhart equation so I'm not sure if 3 points would give the same solution. Even using the tools I have built into linkmeter, adding like 5 new points changes the 3 coefficients by a few percent, and given that the equation is T=1/(A + B * ln(R) + C * ln(R)^3) - 273.15, it is reallllly hard for me to say if A B or C should be slightly higher or lower.

As far as the boiling point, I lucked out in that I am in Tampa, FL at an altitude of 7m above sea level so the boiling point should be just about right at 100C. Also, popping the Thermoworks probe into the Chef Alarm read 100C as well. I did another run but this time shifting up the thermocouple by 0.25C on every reading. Now. I think they're good enough, but they read 0.25-0.50C low at room temps, right on between 50C-100C, maybe up to 1C high at 200C. I think that covers our target area best. You can see here they track pretty well, although they respond a little more slowly than the bare wire thermocouple, even if wrapped in a layer of tin foil.

Shuxi7g.png


I've also added coefficients for the new Maverick ET-735 probes after a correlation run. These probes seem to be a little better than ET-732s, but they have the longer 2.5mm mono plugs so they can be inserted too far into the HeaterMeter jacks. I wouldn't recommend them for new builds, but they can be used if anyone has them.

@Paul Kierstead: Thanks! I do appreciate that sentiment. Sometimes these things can be a bit of a pain in the butt, but I use HeaterMeter for something almost every week (even oven cooking!) and I still enjoy working on it over 7 years now. I think the fact that people build their devices adds to the enjoyment of using it-- there's a certain amount of pride in showing it off and if someone thinks it is cool, telling them how than can make one too.
 
Last edited:
After posting in this thread, I had an idea that the PID I-term accumulated sum should be limited to the fan startup max during startup to prevent it from getting too large during startup when the setpoint is being slowly reached and causing a large overshoot. I initially had the idea of tying the max sum to the max fan speed, but then that would also limit the damper in normal operation. Instead of adding another confusing knob to the settings page, I tied the max I sum to the max fan speed but only during startup and lid recovery.

However, I am wondering if this will create an issue for people who have their startup max set so low and their fan active floor so high that the setpoint can never be reached. I've posted AVR firmware 20161018B to the online repository with this change for testing and feedback.
 
Thinking about the 8MHz challenges, I thought about how the Voltage mode output would be affected by the reduced frequency. This lead me down the dark path of trying to google up better fan drive solutions. This is the sort of thing I do every 6 months or so where I think "There HAS to be a better way" and spend the day sifting through the 3.2 million posts from people who simply direct drive a fan with PWM through an N-channel MOSFET and call it a day. Other poorly-thought-out solutions include LM317 regulators with potentiometers on the feedback pin (cuts off the top 1V-2V from the 12V supply) or putting a high wattage potentiometer on the 12V line and just dialing in the loss (impossible to do digitally without a large switchable resistor matrix).

This time I decided to instead pull out an older motherboard and reverse engineer the fan circuit used there. They have direct voltage control output, they don't use giant potentiometers, how do they do it? A little something like this (values adjusted for HeaterMeter operation):
aDmkbSZ.png


What's happening is they have a P-MOSFET that they're operating in the linear region and there's a DC voltage input which sets the output voltage. Feed the output back into an NPN transistor to vary the input voltage based on the output voltage, and then use a PNP transistor as the non-inverting input to the whole thing. The current at its base drives the overall output voltage. That we can set using standard 490Hz PWM run through a RC filter to turn it into a DC voltage. The 10k/30k resistors on the output side set the gain of the amplifier section, (10k+30k)/10k = 4 times 3.3V gives us up to 13.2V out. Smartiepantses might note that 27k could be a better match, but for some reason I'd only get 11.8V that way so I am guessing there is some sort of reduction in output from the NPN junction, or perhaps from the emitter current passing through the 10k resistor? Not sure about that.

In practice it works! But you may be wondering, if the output voltage is lower than the input voltage, and the current is the same, where does the extra power disappear to? If you said "heat" you got it right:
TPSGfTL.jpg


This is driving a 400mA / 12V blower at 5V / 120mA. 7 volt drop, 120mA = 840mW of power that has to go somewhere. It was still heating up when I took this picture so 97C is not even maxed out yet. The MOSFET is just floating in air on a breadboard, which is almost the worst case for heat dissipation. I took one of the HeaterMeter 4.3 boards and hooked up its MOSFET (which has that min-spec copper pad to help transfer heat away). I would probably put this in the "acceptable" range, and this could be much better if I had designed the pad larger. In our current Pulse and Voltage mode output the FET is always in saturation so there is very little heat to dissipate at all, even at 1A current it wasn't an issue.
JdrB3Ht.jpg


Disadvantages:
-- Limit blower to probably 400mA max in practice vs ~1000mA currently
-- Adds 4 resistors, one capacitor, and a PNP transistor, swaps the current signal mosfet for a NPN, removes the inductor and diode. More parts!
-- Removes ability to have pure PWM output

Advantages:
-- Removes blower switching noise completely from the 12V line, this is a linear power drive
-- Works independently of CPU clock speed
-- Slightly cheaper parts (~20 cents)

It would remove a little of the versatility of HeaterMeter so it isn't a pure win across the board. Just something to keep in mind as a possibility for future versions.
 
Something new to help get your HeaterMeter running right from the start, I've put some work into a firmware download page
CWmRMDW.png


The work to have to build two separate firmwares for the two Pis architectures, then merge them together was messy. It isn't just the boot kernel that is specific to each platform, there are also the modules, and adding a "v7" kernel localversion like the Pi foundation does was creating some issues with the way that openwrt builds its modules, which would cause problems loading them on whichever platform was built with the extra version info (they segfault on load).

Instead I just decided to make two separate images, one for original Pis and one for Pi 2 and Pi 3. Because I thought it would be confusing for folks to select the right file based on filenames, I put together a little form. While I was at it, I came up with the idea of making custom firmware for everyone which came pre-configured for their wifi network and allows them to skip the whole process and hopefully avoid all that confusion.

The page you see right now is a working prototype and I'll be adding other wifi configuration options as well as the ability to just download the stock firmware with the HeaterMeter AP configuration. There will be a bunch of help text added and some photos to help match things up. Note that you only need custom firmware the first time you install, once you're up and running on the network, the standard build will keep you connected. Once I've got this fully implemented, I'll be removing the old directory browser system full of images and just have this (although you can still get to the directories if you want them).

There will also be information added about the process and how the wifi information is only stored until the image is generated and even if the download is canceled or interrupted, the server will not retain any of the information.

EDIT: I also bought a heatermeter.com SSL certificate, so please use the https:// website to keep your wifi configuration secure.
 
Last edited:
Pushed out new snapshots for both Pi and Pi2/3 which finally enables HTTPS for the web server as well as some other minor fixes.
Custom firmware download
Raw images

Only thing I have left of my list is to include the RT5370 wifi driver. The rtl8192cu driver does not support AP mode any more so this new firmware will be a step backward for those who use Edimax adapters in AP mode. Client mode works just fine, as well as the Pi3 wifi in either mode. The RT5370 should also work in both modes but I haven't tested yet.
 
So is AP mode going away?

After reading your previous post about WiFi config I had been meaning to make a suggestion....

It's nice that you can setup the wifi from the website, however, if I follow you correctly the HM would have to be connected to a wired LAN to gain internet access before you could go to HeaterMeter.com and enter the wifi connection info? IDK if it is possible, but it would be nice if WiFi config could be done like this:

1) At first boot have the HM start up in AP Mode
2) Use a smartphone/tablet etc to scan for and connect to the HM AP, open the HM web interface, go to Config/Network/WiFi and scan for wireless networks

Here is the change...

4) After selecting a WiFi network to connect to, rather than actually connecting right then, add the ability to select "Make this my default network" and include a field to enter the passphrase. Then have the HM write that WiFi info to the Config.txt file, which would take effect after the next boot.

If I recall correctly, when I connect to the HM in AP point mode I am unable to complete a connection to my home wifi network because the wireless nic is being used for AP mode. If we could write the wifi network info to a config file and make it take effect at the next boot that should solve this problem. If it is not possible to scan for wifi networks while connected to the HM in AP mode you could just add a field to manually enter the SSID and Passphrase for the wifi network and write that to the config file.

This seems like it would be a pretty user friendly way to negotiate the wireless network connection for the HM, and if things go wrong you can use the menu on the HM LCD to RESET the config and revert back to AP mode and take another stab at it.

Also, for people that use their HM on the road and also at home it would be nice to have a "Favorite Networks" section where the WiFi configs were stored. This way you could change the HM to AP mode for when you are on the road, camping, at a BBQ competition etc, then when back at home select your home network from the "Favorite Networks" and reboot and you're back on the home WiFi.

What do you think, is this doable?
 
Last edited:
Re-wrote the SD card with the snapshot and still no luck. Put the release v13 back on and it fired right up.
 
RalphTrimble said:
So is AP mode going away?
Click to expand...
No, AP mode is only going away for original Pi Bs with Edimax (8192) wifi adapters. Pi3 and other Pis running with RT5370-based wifi adapters still have AP mode.

As far as the 1-2-3 steps, ideally, you'd just do 1-2 then select the wifi network you want to be on, enter the password and boom-- done. The problem is that OpenWrt gives you way too much flexibility at this point and it might create a second wifi network (which often breaks both), or configure it with an incompatible IP address, or 20 different other things that can go wrong because there are just too many knobs. I created a simplified web page that just scanned and let you type the password and be done but that ended up getting scope creep as I made it more like the "Favorite Networks" thing you described, which is the best way for it to work. It is a largish amount of work both in the UI and a backend service, and I ended up losing all my work when I flashed over it by mistake and I never went back to redo it.

The massive problem with all the ideas described in the previous paragraph are that they have one fatal flaw: you need to be able to be on the same network as the HeaterMeter AND find and log into the device before you can do any of these changes. To get around this, I created the "custom firmware" download. Here you download firmware pre-configured to connect to your wifi network and skip the whole process entirely. You flash the downloaded firmware onto your SD card, plug it in, and a minute later your HeaterMeter will already be on your wifi network, skipping the AP mode and initial login to the device entirely.

Steve: Thanks for testing! I'll need to see if I can replicate, something might have gone wrong in the build process. I've got a full morning of heatermeter assembly, procurement, and fulfillment stuff to do this morning but I will test this afternoon ASAP.
 
Steve_M said:
Re-wrote the SD card with the snapshot and still no luck. Put the release v13 back on and it fired right up.
Click to expand...
Yeah there was a problem with the kernel build on that platform that was causing a kernel oops when launching init. Had to bust out the ole serial cable to be able to see the error as it scrolled off the monitor I had plugged into the Pi.

See if it works now, I've rebuilt both images from scratch and both appear to be working for me.
 
It flashed, but didn't reboot on it's own, I had to power cycle it.

It's also taking quite a bit of time to load the stream URL, anywhere from 3-15 seconds.

2gXdUy2.png
 
You must log in or register to reply here.

 

Back
Top