When the Ultrasonic Ranger is first used with the TI-Innovator (or used for the first time in awhile) its first few data measurements might be erroneous. (Toni discussed how to setup and code the Ranger to collect data measurements in this post.)
TI has created a document that outlines a short code segment that can be included in Ranger programs to allow the Ranger to “warm-up” and move through any possible erroneous data measurements. Here is some sample code for this “warm-up”:
Send “CONNECT RANGER 1 TO IN 1 ”
© Use While loop to “warm up” Ranger
Send “READ RANGER 1”
As Toni explained in this post, the Send “CONNECT RANGER 1 TO IN 1” line of code digitally connects the Ranger to the Innovator–naming the Ranger (in this case, RANGER 1) and telling the Innovator what port the Ranger is connected to (in this case, IN 1).
The While loop (with an initial value of d:=-1 so that the loop will be entered and will run at least once) acts as a “warm-up loop” of sorts that continues to collect and recollect distance measurements (READ from the Ranger and then stored to d) until the distance measurements coming back from the Ranger are positive distances.
Question: Should the code for this “warm-up loop” be explicitly included in all Ranger programs?
This is something Toni and I were thinking about recently when we were planning a 1 hour conference session that explored using the Ranger. We knew that the warm-up loop was an important segment of code to include — otherwise participants might see and be confused by “measured distances” of -1. However, we didn’t want participants–many of whom were completely new to Computer Science–to have to parse out this section of code as well as the rest of the program they would write. The “warm-up loop” was not the focus of our session, but seemed to be a necessary precursor–necessary to run in order to get accurate data; not necessary for participants to have to decipher (at this point).
Toni and I made the decision to write the warm-up block of code in as another program in the file and then call that program within the real program that we were building in the conference session. Here are two screenshots to illustrate the point:
Notice how the backup_sensor program (the program we were building and learning about in the conference session) was sent to participants pre-loaded with three “lines” of code — a line CONNECTing the Ranger, a method call for the warm-up program, and (later) a line DISCONNECTing the Ranger. The blank lines were for inserting the lines of code we developed as a group to code/model a back-up sensor (more on that in a later post).
One of the advantages of this approach? We didn’t lose time analyzing and reasoning through the While “warm-up loop”, but we still gained the benefit of having this warm-up loop running inside our program. This allowed us (as a group) to focus on the coding segments that were particularly relevant to our instructional goal.
One of the disadvantages of this approach? There was less transparency regarding what role the warm-up program was playing–how it worked, why it worked, why it was necessary, etc.. Also, since participants were not coding on their individual calculators, they didn’t leave with a copy of the warm-up program/code in case they wanted to use it later. One solution to this might be to distribute a copy of the document created by TI at the end of the session.
What do you think? What are the pros and cons of making the warm-up program explicit and/or “hiding” it instead? When might you make this code segment explicit? When might you “hide” it?