Mechanical Components

Brinkmann Trailmaster Charcoal/Wood Smoker

Chimney Door

Above: Chimney door closed

:

Above: Chimney door partially open

Chimney Door Control

The temperature will be moderated by adjusting the openness of the above door.

Several approaches have been thought out.

Considerations include:

• Ease of reverting to manual smoker operation

• Available force vs. force required to open/adjust chimney door

The selected servo (Hitec HS-322HD) is a standard size servo. This servo offers 51 oz-in of force, which will likely be more than enough to easily adjust the chimney, even if it sticks. A force gauge (trigger pull gauge) was used to determine that even under sticky conditions, the door should require less than 8 oz. of force at the outer diameter to open.

Two designs stick out, each with their own set of advantages and disadvantages.

(Following are doodles drafted during conversation about potential means of door control)

Solid/bar linkage -

• Easily disconnected for standard/manual smoker operation

• Potential for accidental disengagement or low precision if implemented incorrectly

Gear/Chain Drive -

• Increase in mechanical advantage and precision if gear reduction used (ideally 2:1)

• Harder to disconnect (or must be left in place) for standard/manual smoker operation

After initial considerations, the selected method will be using a sprocket and chain drive. A 10 tooth aluminum sprocket will be attached to the servo, and we will test a 16 and 24 tooth aluminum sprocket on the door. Judging by previous operations, an angle of 90 degrees (open) may be desired, so it is likely that the 16 tooth gear will be selected unless additional output torque is required.

The 16 tooth gear will provide 112.5 degrees of movement for the door, and 81.6 oz-in of torque on the hinge point of the chimney door.

The 24 tooth gear will provide 75 degrees of movement, and 122.4 oz-in of torque.

Above: Servo in removable bracket attached to chimney clamp (4” automotive exhaust clamp welded to “L” bracket). Chain tension/slack will be adjusted by rotating the clamp assembly.

Above: Milling the washer stack that will be the mount for removable door sprocket (so that sprocket can be changed if needed).

Above: Washers with nuts and bolts mocked up to be welded.

Above: Mount for sprocket attached to hinge point on chimney door. [Yes, it is FAR from my best or prettiest welding. It will hold way beyond its intended load, and is properly aligned, however.]

Above: Sprocket on mount.

Above: Initial test fit (6/29/14). Note angle of servo is tilting towards chimney, and chain is slack.

Above: nuts welded to motor mount bracket to allow for motor angle adjustment.

Above: Motor mount studs fastened with wingnuts (for easy removal of motor when not in use). Motor angle adjustment screw is middle screw with wingnut at head.

Above: Another angle of previous image.

Above and below: Components painted and installed. Note motor angle (as corrected by angle adjustment screw).

Circuit Design and Testing

A solderless breadboard was fitted with Pi Cobbler breakout assembly and cable, 3 switches, 3 LED’s, an external power supply and a servo motor (plus all wiring and resistors for above components).

• The 1st switch will set the smoker to manual mode, and illuminate the 1st LED when manual mode is active

• The 2nd switch (enabled only in manual mode) will adjust the door towards its open position. [Function replaced with potentiometer]

• The 3rd switch (enabled only in manual mode) will adjust the door towards its closed position. [Function replaced with potentiometer]

• The 2nd LED will illuminate while the servo is positioned at its open limit the temperatures and servo angle are being output to file, the 3rd at closed limit.

The 2nd and 3rd switches have been replaced by a potentiometer, as it is much more intuitive. The 2nd switch has been assigned to start recording to file, the 3rd is to stop it. This was for debugging purposes, and it is likely that they will repurposed again at a later date.

Above: Breadboard fitted with Pi cobbler, servo, 3 LED’s, 3 switches (in middle, under green wire), MCP3008, 10K potentiometer. [Not shown: battery pack to power servo, Raspberry Pi with Yocto Thermocouple and attached thermocouples]

Above: Enclosure with mounted potentiometer, switches, and LED’s (2 are shown on)

Above: Manual mode button replaced with toggle switch

Above: Top and under side of circuit board

Above: wiring diagram (drawn with digikey scheme-it). All GPIO pins shown as circles (labels in color, other than GND’s).  The Yocto device is attached to the Pi via USB port, and the thermocouples are connected directly to the Yocto, so they were left out of this diagram for the sake of simplicity.

When migrating to a permanent board from the breadboard, a single power supply was desired. The Pi’s 5v GPIO line is not rated to supply the servo motor (at least when loaded) when the Pi is powered through the USB port, and a second independent supply or battery pack for the servo seemed excessive. Instead, a USB cable was hacked apart and wired to the 5v and GND GPIO pins, and the servo was attached to the same lines. The USB cable is powered by a 120 VAC to 5.25 VDC (1000mA) adapter.

Above: Yocto-Thermocouple with probe and clip thermocouples. Different thermocouple connectors have been installed on each so that they are not interchangeable (as code is setup to specify one as meat thermometer, the other as smoker thermometer).

Software

Software Design

Current version will be regularly updated on Github: https://github.com/mattstarr/autosmoker. As of 6/23/14, current version was limited to manual operation. Upon arrival of final components and assembly of all hardware, we started data logging for 1-3 manual smokes, gathering enough data to begin attempting (closely monitored) automated cooks.

Files

• Current settings file - settings (reload in case of power failure)

• start time

• projected finish time

• current door angle

• desired temps (possibly related to a specific, later)

• Log table - keep track of filenames/paths of current and old log files

• Log file - 1 per smoke session, data taken in 5 sec increments (stored as csv)

• time

• meat temp

• smoker temp

• door position

There will be a single main class to handle servo and file input/output, timing, and temperature input. It is likely that this will output to (and accept user input from) a web interface via webpy.

Sensor Testing

Before even developing the web interface, it seemed like a good idea to collect data in order to test the accuracy and responsiveness of the temperature probes and Yocto-Thermocouple.

Above: CSV output (select fields) plotted in Excel. Series 2 is the clip-style sensor (attached to center rack). Series 3 the meat thermometer, Series 4 is the servo angle.

For the above output, I used one sensor in the kitchen oven. I started heating before the Pi was on (thus starting at 100 deg. F). I turned off the oven after it was at temperature for a short period, and the decline in temperature can also be seen. For the meat thermometer, I left it outside the oven. I placed my hands on it (in the circled portion) to check response time and accuracy. For this test, my only interest was checking the accuracy and response time of the thermocouples to be used with the smoker, so I did not adjust the servo angle at all (as it had no impact on this particular experiment). The temperature output was compared against a commercially bought remote dual probe grill thermometer, and was proven to be very close to the same temperature.

Above: Marked up, graphed CSV output from a test using a grill and some steak. Servo angle was left off of this plot.

For the above data, I cooked a steak on the grill using the temperature probes in order to verify accuracy and responsiveness. The grill was preheated, and the recording was started before the probes were placed in the grill and meat. The grill probe temperature is in blue, the meat probe temperature in red.

Points of interest:

• Black circle: probes inserted into grill and meat. note that meat thermometer temperature plummets upon insertion into meat (still cold from being in refrigerator).

• 1st magenta line: 1st grill opening, opened to add more sauce to meat.

• 1st yellow line:  grill closed.

• 2nd magenta line: grill opened for visual inspection of meat, for flipping and adding sauce. Meat probe was removed and reinserted when meat was flipped.

• 2nd yellow line: grill closed. Note duration required for grill temperature to reach previous temperature!

• 3rd magenta line: grill opened, meat flipped again. Meat probe temperature spike likely caused by brief contact with grill surface while removed in order to flip meat.

• 3rd yellow line: you guessed it -- the grill was closed yet again…

• 4th magenta line: grill opened for retrieval of meat.

• Green circle: upon removal of meat probe, it was rested on grill surface for several seconds (thus the rapid temperature spike).

Live Testing

On 07/06/14, our first live test was performed. It was not without issues, but we were able to collect enough useful data to begin discussing automation. Smoking a pork tenderloin with the smoker in “manual mode,” many noteworthy observations were made.

Above: graph of collected data from pork tenderloin smoke. Smoker temperature shown in red, meat in green. Servo angle shown in purple.

Points of interest:

• Orange arrow: fuel depleted, more charcoal added

• Blue arrow: smoker opened to rotate meat

• Note steady increase of meat temperature. Discarding outliers and approximating 1st derivative of meat temperature should allow fairly accurate prediction of time that meat will reach desired temperature

• Seemingly erratic servo angle adjustments were made to allow for recording of correlation and response time of smoker temperature to door position

The main point of the experiment (and ultimately the project) is to find the correlation between door position, internal temperature and meat temperature, all in order to attempt to automate the cooking process by measuring and adjusting these values. While many other factors must be taken into account (including fuel temperature and amount left), the impact on the meat temperature seems very minimal. This dictates that most likely, door position will mainly be used to respond to sharp drops and rises in internal temperature (indicating smothering of fire or overly rapid consumption of fuel). Depending on type of fuel used (compressed charcoal, uncompressed, wood, etc.), attempting to maintain a specific smoker temperature may not be as achievable (or important) as initially assumed. However, more testing will required to allow this to be further explored.

Above and below: the result of our first live run -- a delicious success in the name of science!

A second test was performed on 07/13/14. The data is graphed below:

Each sharp drop in smoker temperature was from the smoker being opened to add, move, or remove items other than that which was the “subject” for this experiment.

Servo positions were manually adjusted in response to observed temperatures.

On 07/19/14, our first automation test was run. The graph follows:

The above graph is notably horizontally condensed, as it was from a 6+ hour smoke (whereas most of our previous runs were 3 hours or less). The servo angle responded well to the internal temperature, and was able to quickly react and prevent internal temperatures from normally breaching 340 F, even when coals or wood flamed up.

Several times, we were required to replenish fuel, and an “add fuel” alert will likely be added when the internal temperature is below a specified threshold for an extended period of time.

The changes in target temperatures were made based on decisions made after starting the smoke. The meat target was changed to allow the meat to cook longer, and the smoker target was changed at times to lower the acceptable high temperature range. Tightening the adjustment temperature threshold (which will later be achievable on the fly) would have been preferable at the time, and the desired threshold change has, for now, been hard-coded in.

All in all, this test was a success, and displayed that (at least according to previous tests and anecdotal evidence) the automation was able to achieve a tighter level of control than operating in manual mode or without the assistance of this electronic system at all.  

08/02/14: A single, thin cut brisket was our test subject. With the exceptions of a spike when the wood caught fire, a drop when the fuel was depleted, and another spike from too much fuel added, the machine was able to maintain temperature very close to our target (and was able to return to temperature as quickly as could be expected of a human operator). Cook time was approximately 5 hours.

The notable drop in meat temperature, we assume, was the result of the temperature spike “squeezing” the juice out of the meat, and its evaporation, resulting in the cooling of the meat. The drop of temperature was a cause for alarm (and likely a potential alert notification to be added later) that prompted us to foil wrap the meat and let it rest.  

Above: Our test subject (beef brisket) from 08/02/14.

08/03/14: A test that ran over 6 hours and 20 minutes, cooking ribs, a pork shoulder, whole chicken and several thighs was performed. This test further validated the tightening of our adjustment threshold (we had reduced the temperature window for each servo position from 25 degrees to 20 before the test on 08/02/14), and the idea that below a certain point, the smoker vent should be shut to reduce heat loss (currently, when temperature is too low, the vent is opened entirely to facilitate an increase in temperature of the coals by providing more oxygen -- however, when the door is opened to work with the food or the coals have been depleted, opening the vent simply serves to reduce internal temperature, which is not desirable).  

Above: Graph of the multi-meat run. The smoker was opened several times to adjust, crutch, and remove some meats before the shoulder (containing the meat probe) was fully cooked.

Above: The assortment of meats from the 08/03/14 test.

Web Interface

Deciding on a plan of attack for the web interface requires balancing and taking into account many items:

• Ease of implementation

• Ease of use

• Reliability

One of the first available options was to adapt the sample Yocto-Thermocouple project to our needs. Initially, it failed to reliably run more than 20 minutes. In addition, it did not appear easily adapted, so it was abandoned (though their hardware is excellent).

Flask appeared to be a suitable option, but upon discovering it, I had already started experimenting with web.py, which appears to be more than capable of doing the job. Until further notice, web.py will be our selected tool for the job.

If I am to re-write this, and upon continuation of the electric version, I shall more than likely use Flask, as I have happily used it in other projects, and I find myself much more comfortable with it, at this point. Still, having not used Python at all before this project, I am happy with the results.

Above: screenshot of early web-based user interface (with default settings and noted features). This is setup for ease of testing and data collection -- it is far from finished or pretty, but works well enough.

Parts

• Auber Instruments K Type Thermocouple 4” Probe with Clip for Oven/Smoker: http://www.auberins.com/index.php?main_page=product_info&cPath=20_3&products_id=327

• Auber Instruments K Type Thermocouple 6” Pointed Probe: http://www.auberins.com/index.php?main_page=product_info&cPath=20_3&products_id=56

• Yocto-Thermocouple: http://www.yoctopuce.com/EN/products/usb-sensors/yocto-thermocouple

• HS-322HD: http://www.servocity.com/html/hs-322hd_standard_deluxe.html#.U5-zZIXiiE4

Notes/links

• source/how-to for using SPI with MCP3008: http://www.raspberrypi-spy.co.uk/2013/10/analogue-sensors-on-the-raspberry-pi-using-an-mcp3008/

Personal working code notes/task list:

Turn current meat temp display yellow when at temp but not for specified time, turn red when at temp for required duration.

Add config file to store (to run on resume if shutdown before done):

current file, targets, position, whether or not it is done, sprocket being used, email settings

Add events (using event code?) to csv log file and/or debug log file.

Increase verbosity of debug log file, pipe email and other output (console bound output) to log file

Automation notes:

Estimated door/servo position depending on used sprocket (note max angle on 24-tooth is 75 degrees)

will need to infer trend and condition from 1st derivative of smoker temp data. Will need to assume grill is open (and light/blink LED to alert user it knows current condition-- perhaps have condition codes to blink) based on sharp negative slopes, and to hold position until smoker is closed for at least a couple of minutes.

Basic algorithm for testing will be as simple as this:

for the first 5 minutes, hold at position 2. after that:

set threshold = thr

current smoker temp = ct

target smoker temp = tt

if (ct > tt + (3*thr)), set position 1

if (ct > tt + thr) and (ct <= (3*thr)), set position 2

if (ct >= tt - thr) and (ct <= tt + thr), set position 3

if (ct >= tt - (3*thr)) and (ct < tt - thr), set position 4

if (ct < tt - (3*thr)), set position 5

A “fuel depleted/low temp” alert will be sent for an added position 6 (which will close the vent until remedied, in order to retain heat).

Prediction (for meat done time):

use Newton’s law of cooling and/or (why not show predictions with each and log which is more accurate?) 5 point rolling average rate over past 5, 10, or 15 minutes. Test all methods on previous .csv’s to see which is most accurate.

--currently using matlab to run predictions on previous collected .csv’s to test prediction accuracy and develop a decent algorithm.

Using linear regression (available in many existing python libraries) will be explored, as well. Code-wise, this may be the simplest and most accurate method.