Results of the design
Speed of execution
We have very minor speed issues in the final product of our project. One is the button speed. The buttons have been heavily debounced (125ms) relative to the pushbuttons on the STK-500 (30 ms). In addition, there is slight flicker whenever the LCD is refreshed will a large amount of text on the screen. Finally, we could not implement the timer countdown during speech. We tried to separate out the speech and timer countdown functions in different interrupts, but since this caused many errors we decided to be safe and live with this design flaw.
Our only issue of accuracy is the numeric accuracy of the conversion of our thermometer probe’s measurement into temperature. This accuracy is ±1 °F. This is due to the limitations of fixed point math, and the quantization that results when our floating point result is converted to an integer.
How you enforced safety in the design
Obviously our device is not ready for commercial manufacture yet, as many electrical components are still exposed. However, all of the elements in the design are grounded properly and would be safe to carry during operation.
The user’s safety with respect to meat consumption is enforced with the inclusion of USDA guidelines in the recommended cooking temperatures. While the user can adjust the desired temperature while pressing buttons 1 and 2 on the grilling screen, the recommended cooking temperature serves as a strict warning to the user.
Interference with other people's designs
Our design interferes with others only if they are transmitting on the 433Mhz band. While this is unfortunate, it is unavoidable if one wishes to wirelessly transmit data from a low powered non licensed device.
We believe we achieved a reasonable level of usability from a student project, as discussed below.
Success of Design and Meeting Expectations
The final objective of our project was to have a portable grill monitor and we feel that we succeeded in that respect. Both the transmitter and the receiver are able to operate with out being plugged into a wall socket, the transmission range is sufficient to allow for some freedom from the grill. In addition, the receiver is light enough to carry around in one hand. The only issue that makes our device less portable is the lack of an appropriate case for the receiver. Although light, the Rx is much too cumbersome and delicate to be useful in most barbeque settings at this stage. Some reinforcing physical connections between the LCD, receiver protoboard and audio amplifier protoboard as well as a plastic or aluminum case would be a simple fix to this drawback. We didn’t implement this aspect in our design because of budget and time constraints.
In making the Grillzilla usable we feel that we succeeded. The interface of buttons with speech and the LCD gives the user enough information to make good decisions about safely cooking meat on a grill. The receiver’s ability to consistently receive information from the transmitter and the reliability of the menu displaying the correct information reduces frustration when using our device. The menu displays what number buttons perform what functions (except on the grilling screen due to space limitations) so that the user does not have to guess.
Our first major achievement with this project was to get the transmitter and receiver not only working separately, but as a system. This was initially done on the breadboards and then, after debugged, moved to the protoboards. The transmitter has been the most reliable component of our device, being that it never required any debugging and it never failed to work. The Rx was a different story, when concerned with reliability, but in the end it displayed only the correct packets with the proper ID and it received them very consistently.
Quality of Feedback
Speech and sound was something of a reach goal for us. It is a part of the device that is that enhanced functionality, but was not needed for proper operation. We succeeded in getting sound of an appropriate volume and understandability out of the signal sent from the PWM of the ATMega32 after amplifying it using an LM386. We could have stopped with a beep or series of beeps to signal different points in cooking progression, but decided to implement speech as well. Speech was an area that could see improvement in the quality of the words spoken from the speaker, but since high quality speech synthesis was not an objective of our project, we used the compression algorithm supplied by the course website.
We have not tested the range of our transmitter extensively, although we have estimated reliable transmission up to 100 feet. With further field testing we expect that we could receive packets from up to 300 feet as indicated by the specifications of the 433 Mhz band.
Ideas for Improvement
Ideas for improvements for future or final models of the Grillzilla include many more guidelines for different meats as well as the use of multiple thermometer probes simultaneously. In addition, there is the possibility of using external memory for more speech functionality. Also, we originally hoped to provide the user with an estimate of the cooking time remaining for their meat. However, after researching we found that this estimate would require a multitude of parameters about the meat being cooked as well as the cooking source, so we scrapped this idea. With proper knowledge and more time we don’t think that this is a farfetched idea.
Other Lessons Learned
Of course, we were disappointed with the fact that we couldn’t incorporate our graphical LCD into our display. However, trying to get the graphical display to work taught us a several valuable lessons. The first is to check and double check the availability, clarity, and feasibility of all schematics with any parts that you order through Bruce Land. The second is to ensure that there are solid application examples for the component that you order depending on your skill and comfort level in the course.
Conforming to Applicable Standards
See introduction above for discussion of our consideration of FCC section 15 standards as well as the inclusion of USDA recommendations
Intellectual Property Considerations
See introduction section for discussion of code reuse and patent considerations. None of the code we used is in the public domain, so no licenses need be cited. We did reverse engineer Brookstone’s design to a certain extent, but there are no patents covering their design. In fact, a generic version of the Grill Alert system is available through various internet sites. We did not have to sign non-disclosure to get sample parts. There are probably not any patent opportunities for our project due to the amalgamation of design sources (Meghan Desai, Bruce Land, etc), but it has the potential to be enjoyed by microcontroller hobbyists.
- to accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment;
We made sure to do research on our meat cooking temperatures by getting information from a variety of sources, including the USDA. We also ensured that we would be following FCC regulations so that our transmissions would not interfere with any non-private high powered transmissions.
- to avoid real or perceived conflicts of interest whenever possible, and to disclose them to affected parties when they do exist;
We credited the sources for this project including Brookstone, which sells a product similar to our design, as well as Meghan Desai for his wireless communication software. In addition, many of the techniques used in our code came from Bruce Land, as discussed earlier.
- to be honest and realistic in stating claims or estimates based on available data;
We made the set the most realistic goals and honestly documented our experiences.
- to improve the understanding of technology, its appropriate application, and potential consequences;
By participating in this project we had the objective of improving our understanding of technology. Specifically, we gained an appreciation for producing a commercially viable product.
- to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others;
We properly credited our sources, always asked for help and for ways to implement certain aspects of our device in more effective ways.
- to assist colleagues and co-workers in their professional development and to support them in following this code of ethics.
We would often assist our fellow classmates in a variety of ways, mostly by offering advice and sometimes by showing them how to do something.
See Intellectual Property considerations section above. The Radiotronix devices we used were not tampered with or modified in any way, so we legally adhered to Section 15 of the FCC standards.
|Custom PCBoard for Mega32
|Solderboard for Audio Amplifier
| Radiotronix RCT-433-AS RF Transmitter
| Radiotronix RCT-433-RP RF Receiver
| Graphical LCD (Hundai #HG25604)
| Character LCD (4x20)
| 8 Ohm 0.2W Speaker (26SP08WR)
| 9V Battery
| 4-button Pushbutton Pack
* = Sampled
References you used
See hyperlinks throughout the web page for Radiotronix components, software references, and other goodies. The LM386 datasheet is here.
Division of Labor
For the most part, Jeff “master of soldering” Guido did the hardware layout, breadboarding, and testing of all hardware components. For the most part, Matt “code monkey” Bertenthal wrote and tested all of the software for the transmitter and the receiver. This division of labor carried into the writing of this report as well.