Arduino: A Quick-Start Guide, Second Edition (2015)

Figure 16. Photo of PING))) basic circuit

To bring the circuit to life, we need some code that communicates with the PING))) sensor:

First we define a constant for the IO pin the PING))) sensor is connected to. If you want to connect your sensor to another digital IO pin, you have to change the program’s first line. In the setup method, we set the serial port’s baud rate to 9600, because we’d like to see some sensor data on the serial monitor.

The real action happens in loop, where we actually implement the PING))) protocol. According to the data sheet,^[57] we can control the sensor using pulses, and it returns results as variable-width pulses, too.

In lines 9 to 11, we set the sensor’s signal pin to LOW for 2 microseconds to bring it to a proper state. This will ensure clean HIGH pulses that are needed in the next steps. (In the world of electronics, you should always be prepared for jitters in the power supply.)

Finally, it’s time to tell the sensor to do some work. In lines 13 to 15, we set the sensor’s signal pin to HIGH for 5 microseconds to start a new measurement. Afterward, we set the pin to LOW again, because the sensor will respond with a HIGH pulse of variable length on the same pin.

With a digital pin, you have only a few options to transmit information. You can set the pin to HIGH or LOW, and you can control how long it remains in a particular state. For many purposes, this is absolutely sufficient, and in our case it is, too. When the PING))) sensor sends out its 40-kHz chirp, it sets the signal pin to HIGH and then sets it back to LOW when it receives the echo. That is, the signal pin remains in a HIGH state for exactly the time it takes the sound to travel to an object and back to the sensor. Loosely speaking, we are using a digital pin for measuring an analog signal. In the following figure, you can see a diagram showing typical activity on a digital pin connected to a PING))) sensor.

We could measure the duration the pin remains in HIGH state manually, but the pulseIn method already does all the dirty work for us. So, we use it in line 18 after we have set the signal pin into input mode again. pulseIn accepts three parameters:

· pin: Number of the pin to read the pulse from.

· type: Type of the pulse that should be read. It can be HIGH or LOW.

· timeout: Timeout measured in microseconds. If no pulse could be detected within the timeout period, pulseIn returns 0. This parameter is optional and defaults to one second.

Note that in the whole process, only one pin is used to communicate with the PING))). Sooner or later, you’ll realize that IO pins are a scarce resource on the Arduino, so it’s really a nice feature that the PING))) uses only one digital pin. When you can choose between different parts performing the same task, try to use as few pins as possible.

We have only one thing left to do: convert the duration we have measured into a length. Sound travels at 343 meters per second, which means it needs 29.155 microseconds per centimeter. So, we have to divide the duration by 29 and then by 2, because the sound has to travel the distance twice. It travels to the object and then back to the PING))) sensor. The microseconds_to_cm method performs the calculation.

According to the specification of the PING))) sensor, you have to wait at least 200 microseconds between two measurements. For high-speed measurements, we could calculate the length of a pause more accurately by actually measuring the time the code takes. But in our case this is pointless, because all the statements that are executed during two measurements in the loop method take far more than 200 microseconds. And outputting data to the serial connection is fairly expensive. Despite this, we have added a small delay of 100 microseconds to slow down the output.

You might wonder why we use the const keyword so often. To program the Arduino you use C/C++, and in these languages it’s considered a good practice to declare constant values as const (see Effective C++: 50 Specific Ways to Improve Your Programs and Designs [Mey97]). Not only will using const make your program more concise and prevent logical errors early, but it will also help the compiler to decrease your program’s size.

Although most Arduino programs are comparatively small, software development for the Arduino is still software development, and it should be done according to all the best practices we know. So, whenever you define a constant value in your program, declare it as such (using const, not using #define). This is true for other programming languages as well, so we will use final in our Java programs, too.

Now it’s time to play around with the sensor and get familiar with its strengths and weaknesses. Compile the program, upload it to your Arduino board, and open the serial monitor (don’t forget to set the baud rate to 9600). You should see something like this:

In addition to the output in the terminal, you will see that the LED on the PING))) sensor is turned on whenever the sensor starts a new measurement.

Test the sensor’s capabilities by trying to detect big things or very small things. Try to detect objects from different angles, and try to detect objects that are below or above the sensor. You should also do some experiments with objects that don’t have a flat surface. Try to detect stuffed animals, and you will see that they are not detected as well as solid objects. (That’s probably why bats don’t hunt bears—they can’t see them.)

With only three wires and a few lines of code, we have built a first version of a digital metering rule. At the moment, it outputs only centimeter distances in whole numbers, but we’ll increase its accuracy tremendously in the next section by changing our software and adding more hardware.

Increasing Precision Using Floating-Point Numbers

According to the specification, the PING))) sensor is accurate for objects that are between 2 centimeters and 3 meters away. (By the way, the reason for this is the length of the pulse that is generated. Its minimum length is 115 microseconds, and the maximum length is 18.5 milliseconds.) With our current approach, we don’t fully benefit from its precision because all calculations are performed using integer values. We can only measure distances with an accuracy of a centimeter. To enter the millimeter range, we have to use floating-point numbers.

Normally it’s a good idea to use integer operations, because compared to regular computers the Arduino’s memory and CPU capacities are severely limited and calculations containing floating-point numbers are often expensive. But sometimes it’s useful to enjoy the luxury of highly accurate floating-point numbers, and the Arduino supports them well. We’ll use them to improve our project now:

This program doesn’t differ much from our first version. First, we use the more accurate value 29.155 for the number of microseconds it takes sound to travel 1 centimeter. In addition, the distance calculation now takes a potential gap between the sensor and the case into account. If you plug the sensor into a breadboard, usually a small gap between the sensor and the breadboard’s edge exists. This gap is defined in line 5, and it will be used in the distance calculation later on. The gap is measured in centimeters, and it gets multiplied by two because the sound travels out and back.

The loop method looks much cleaner now, because the program’s main functionality has been moved to separate functions. The whole sensor control logic lives in the measure_distance method, and output_distance takes care of outputting values to the serial port. The big changes happened in the microseconds_to_cm function. It returns a float value now, and it subtracts the sensor gap from the measured duration. To make sure we don’t get negative values, we use the max function.

Compile and upload the program, and you should see something like the following in your serial monitor window:

This not only looks more accurate than our previous version, it actually is more accurate. If you have worked with floating-point numbers in any programming language before, you might ask yourself why the Arduino rounds them automatically to two decimal digits. The secret lies in theprint method of the Serial class. In recent versions of the Arduino platform, it works for all possible data types, and when it receives a float variable, it rounds it to two decimal digits before it gets output. You can specify the number of decimal digits. For example, Serial.println(3.141592, 4);prints 3.1416.

Only the output is affected by this; internally it is still a float variable. By the way, on most Arduinos, float and double values are the same at the moment. Only on the Arduino Due is double more accurate than float.

So, what does it actually cost to use float variables? Their memory consumption is 4 bytes—that is, they consume as much memory as long variables. On the other hand, floating-point calculations are fairly expensive and should be avoided in time-critical parts of your software. The biggest costs are the additional library functions that have to be linked to your program for float support. Serial.print(3.14) might look harmless, but it increases your program’s size tremendously.

Comment line 37 out and recompile the program to see the effect. It will no longer work properly, but we can see how this statement affects the program size. With my current setup, it needs 3,002 bytes without float support for Serial.print and 5,070 bytes otherwise. That’s a difference of 2,068 bytes!

In some cases, you can still get the best of both worlds: float support without paying the memory tax. You can save a lot of space by converting the float values to integers before sending them over a serial connection. To transfer values with a precision of two digits, multiply them by 100, and don’t forget to divide them by 100 on the receiving side. We’ll use this trick (including rounding) later.

Increasing Precision Using a Temperature Sensor

Support for floating-point numbers is an improvement, but it mainly increases the precision of our program’s output. We could’ve achieved a similar effect using some integer math tricks. But now we’ll add an even better improvement that cannot be imitated using software: a temperature sensor.

When I told you that sound travels through air at 343 m/s, I wasn’t totally accurate, because the speed of sound isn’t constant—among other things, it depends on the air’s temperature. If you don’t take temperature into account, the error can grow up to a quite significant 12 percent. We calculate the actual speed of sound C with a simple formula:

C = 331.5 + (0.6 * t)

To use it, we only have to determine the current temperature t in Celsius. We will use the TMP36 voltage output temperature sensor from Analog Devices.^[58] It’s cheap and easy to use.

To connect the TMP36 to the Arduino, connect the Arduino’s ground and power to the corresponding pins of the TMP36. Then connect the sensor’s signal pin to the pin A0—that is, the analog pin number 0:

As you might’ve guessed from its vendor’s name, the TMP36 is an analog device: it changes the voltage on its signal pin corresponding to the current temperature. The higher the temperature, the higher the voltage. For us, it’s an excellent opportunity to learn how to use the Arduino’s analog IO pins. So, let’s see some code that uses the sensor:

In the first two lines, we define constants for the analog pin the sensor is connected to and for the Arduino’s supply voltage. Then we have a pretty normal setup method followed by a loop method that outputs the current temperature every second. The whole sensor logic has been encapsulated in the get_temperature method. It returns the temperature in degrees Celsius, and we convert it to a Fahrenheit value, too.

For the PING))) sensor, we only needed a digital pin that could be HIGH or LOW. Analog pins are different and represent a voltage ranging from 0V to the current power supply (usually 5V). We can read the Arduino’s analog pins using the analogRead method that returns a value between 0 and 1023, because analog pins have a resolution of 10 bits (1024 = 2¹⁰). We use it in line 20 to read the current voltage supplied by the TMP36.

How to Encode Sensor Data

Encoding sensor data is a problem that has to be solved often in Arduino projects, because all the nice data we collect usually has to be interpreted by applications running on regular computers.

When defining a data format, you have to take several things into account. Among others, the format shouldn’t waste the Arduino’s precious memory. In our case, we could’ve used XML for encoding the sensor data:

Obviously this isn’t a good choice, because now we’re wasting a multiple of the actual data’s memory for creating the file format’s structure. In addition, the receiving application has to use an XML parser to interpret the data.

But you shouldn’t go to the other extreme, either. That is, you should use binary formats only if absolutely necessary or if the receiving application expects binary data anyway.

All in all, the simplest data formats, such as character-separated values (CSV), are often the best choice.

There’s one problem left, though: we have to turn the value returned by analogRead into an actual voltage value, so we must know the Arduino’s current power supply. It usually is 5V, but there are Arduino models (such as the Arduino Pro, for example) that use only 3.3V. You have to adjust the constant SUPPLY_VOLTAGE accordingly.

We can turn the analog pin’s output into a voltage value by dividing it by 1024 and by multiplying it by the supply voltage, which we do in line 21.

We now have to convert the voltage the sensor delivers into degrees Celsius. In the sensor’s data sheet, we find the following formula:

T = ((sensor output in mV) - 500) / 10

We have to subtract 500 millivolts because the sensor always outputs a positive voltage. This way, we can represent negative temperatures, too. The sensor’s resolution is 10 millivolts, so we have to divide by 10. A voltage value of 750 millivolts corresponds to a temperature of (750 - 500) / 10 = 25°C. See it implemented in line 22.

Compile the program, upload it to the Arduino, and you’ll see something like the following in your serial monitor:

As you can see, the sensor needs some time to calibrate, but its results get stable fairly quickly. By the way, you’ll always need to insert a short delay between two calls to analogRead, because the Arduino’s internal analog system needs some time (0.0001 seconds on the Uno) between two readings. We use a delay of a whole second to make the output easier to read and because we don’t expect the temperature to change rapidly. Otherwise, a delay of a single millisecond would be enough.

Now we have two separate circuits: one for measuring distances and one for measuring temperatures. See them combined to a single circuit in Figure 17, The TMP36 and the PING))) sensors working together and Figure 18, Photo of final circuit.