Distance and Display

Everything you have measured so far has been reported to a serial monitor. That means the board has to be attached to a computer, and somebody has to be looking at the right window.

A device with its own screen is a different thing. Unplug it, carry it to the tank, and it still tells you what it knows. That is the whole difference between an experiment and something a person can use.

So this band does two jobs at once:

• A new sense. Distance, measured with a click you cannot hear, and the arithmetic that turns a time into a length.
• A new output. Sixteen characters by two rows, which sounds like plenty and turns out to be a design problem all of its own.

By the end you will be able to

• Measure a distance and say where every number in the calculation comes from
• Tell the difference between “zero centimetres” and “I heard nothing”
• Wire an LCD screen, of either kind, and get letters onto it
• Explain why a screen flickers, and write to it in a way that does not
• Fit a useful message into sixteen characters
• Install a library you did not already have

What you need

• Your board, USB cable and breadboard
• An HC-SR04 ultrasonic sensor, the one with two silver eyes and four pins
• An LCD1602 screen, either kind. Part 5 tells you which you have.
• A passive buzzer, the one where you can see a small green circuit board underneath
• A 10k potentiometer, only if your screen has sixteen bare pins
• A tape measure or a ruler, and a wall
• About twenty jumper wires
• A full-size breadboard, the long kind with numbers running past 60. This band runs out to column 42.
• Optional: a servo from Band 6, for a lid that opens

No board for this part. You need a wall, a large open space, and a friend if you have one.

If you have somewhere with an echo

A long corridor, a big empty room, a wall across a field, the side of a building.

If there is nowhere with an echo

Do it with a ball instead, which is the same experiment slowed down so you can see it.

That last question is the one that will save you an hour later. No echo does not mean nothing is there. It means nothing came back.

Soft things swallow the click. Angled things send it off sideways. Very close things get their echo back before the sensor has finished listening. Your sensor reports the same thing for all three as it does for an empty room.

Keep the paper. In Part 3 your sensor will read 0, and you will already know what that means.

Take out the HC-SR04. It is a small board with two silver cylinders on the front, which look like eyes and are not. One is a tiny loudspeaker. The other is a tiny microphone.

Look at the four pins along the bottom edge. Their names are printed on the board itself: VCC, Trig, Echo, GND. Read them off your own board now rather than trusting any picture, including the one below.

The two numbers, and where they come from

Here is the line that turns the sensor's answer into centimetres. Every part of it means something.

long cm = microseconds / 29 / 2;

29

Sound travels about one centimetre every 29 millionths of a second in ordinary air. That is the speed of sound written upside down, in a form that is convenient here. Dividing by it turns a time into a length.

2

Your click went to the wall and came back. So the length you just calculated covers the distance twice. Halving it gives you the distance to the wall.

Neither number is magic and neither should be copied without understanding. If you were measuring underwater the 29 would be completely different, because sound travels four times faster in water. The 2 would stay the same, because there and back is there and back wherever you are.

Read the sketch first. You have seen every instruction in it except two.

digitalWrite(trigPin, LOW);
delayMicroseconds(2);
digitalWrite(trigPin, HIGH);
delayMicroseconds(10);
digitalWrite(trigPin, LOW);

unsigned long microseconds = pulseIn(echoPin, HIGH, 25000);

long cm = microseconds / 29 / 2;

Now wire it

Now check it against a real ruler

A number on a screen is a claim. Claims get checked.

Look at the five lines that start the measurement.

digitalWrite(trigPin, LOW);
delayMicroseconds(2);
digitalWrite(trigPin, HIGH);
delayMicroseconds(10);
digitalWrite(trigPin, LOW);

That is a pulse: off, on for exactly ten microseconds, off again.

The sensor's own instructions say it needs at least ten. The two microseconds of LOW at the start are there to make sure the pin has settled before the pulse begins.

You are not choosing these numbers. They come from the sheet the sensor's maker published, and reading such a sheet is a skill worth having. Search for “HC-SR04 datasheet” and look for the timing diagram. It will look hard to read, and you only need two lines of it.

Why unsigned long and not int

unsigned long microseconds = pulseIn(echoPin, HIGH, 25000);

You met this in Band 5 with millis, and the reason is the same. An ordinary int on this chip holds numbers up to 32767. The limit here is 25000, which fits, but only just, and a longer limit would not.

The habit is worth keeping even when a number happens to fit today: anything holding a duration in microseconds or milliseconds is unsigned long. You will not remember which ones were tight.

The function with a name

In b7_04 and b7_05, all of that lives in one place:

long readDistance() {
  ...
  return microseconds / 29 / 2;
}

This is exactly what you learned to do in Band 5. Nine lines with one job, given a name, so that everywhere else in the sketch you can write readDistance() and be done.

Notice what else it buys you. Suppose you decide that a reading of 0 should mean “far away” rather than “touching”. You change that in one place.

That decision is a rule about your device. Rules about your device belong in one place each.

Take out the LCD and turn it over. What you see on the back decides everything about the next hour, so do this before reading further.

The trap, before you build either one

This is the single most common wasted evening in all of hobby electronics, and you can avoid it by reading one paragraph.

Every one of these screens has a contrast adjustment. On the I²C kind it is a tiny blue screw on the back. On the bare kind it is the potentiometer you are about to wire to pin 3.

Set wrongly, a perfectly working screen shows absolutely nothing. No hint. No faint text. Nothing at all, exactly as though it were dead.

Turn it too far the other way and you get a row of solid blocks. That is also not broken. Somewhere between blank and blocks is readable text, and the range is narrow.

Do one of the two builds below, whichever matches the back of your screen. Then rejoin at Part 7.

6a. The I²C kind, four wires

6b. The bare kind, twelve wires and a knob

This is the longest single build in the course. Do it in one sitting, slowly, and test in the middle rather than at the end.

screen.setCursor(0, 0);     // column 0, top row
screen.print("Hello");
screen.setCursor(0, 1);     // column 0, bottom row
screen.print(42);

Join the sensor and the screen together in the obvious way and something unpleasant happens.

Upload b7_04_buggy_flicker.ino with the sensor still on pins 10 and 11, as you wired it in Part 3. That is the I²C screen's arrangement; if you have the bare screen your Echo wire moved to pin 9 in Part 6b, so read the box above rather than uploading this.

The fix, and the trap inside the fix

The obvious repair is to stop calling clear(). Do it: comment that line out and upload again.

Move the sensor so the reading goes from 100 down to 99.

Send a fixed width every time, padded with spaces. Here is the version from b7_05:

if (cm < 100) screen.print(" ");
if (cm < 10)  screen.print(" ");
screen.print(cm);
screen.print(" cm          ");

The spaces are not decoration. They are an eraser, and they cost nothing, because those character positions were going to be written anyway.

The two if lines at the top are the part worth understanding. They make the number itself always three characters wide: 7 becomes   7, 42 becomes  42, and 742 is already 3. Without them a three-digit reading would send one character more than a two-digit one, and the row would stop adding up.

Put that together with only writing when the value actually changed, and you have a screen that is steady, correct, and never blank.

if (cm == lastShown) {
  return;
}
lastShown = cm;

Now a whole device. It measures how far away you are and tells you three ways at once.

• The number, on the bottom row.
• A word saying what to do, on the top row.
• A beep that gets faster as you close in, and becomes one solid tone under 10 cm.

Three ways at once is the point. A driver is not looking at a screen, and a person across the room cannot hear a small buzzer. A device that reports one way only works for one person in one position.

The pin plan

Fit it into sixteen characters

Look at the top row. Nearly there is 12 characters and fits. Now try writing your own words for the four ranges, and find out how quickly sixteen runs out.

a. Read loop first

void loop() {
  long cm = readDistance();
  showDistance(cm);
  updateBeep(cm);
  delay(50);
}

Four lines: measure, show, beep, pause. Anyone can read that and say what the device does. Everything complicated is behind a name.

That delay(50) at the bottom is a blocking wait, and Band 5 taught you to be suspicious of those. Be suspicious of it. It means the beep timing can only be checked twenty times a second, so a beep can be up to 50 thousandths of a second late. On a beep that lasts 350, that is small enough to accept. That is a judgement, not an exemption. If your device needed millisecond timing, this delay would have to go.

b. Follow the beeping by hand

Assume gapFor returns 350 and lastBeep is currently 4000. Fill this in.

c. Break it on purpose

In your copy, delete the line lastBeep = now; from inside the if. Predict, then upload.

d. The number that decides everything

Change delay(50) at the bottom of loop to delay(500). Upload and walk your hand in.

Work on a copy of the worked sketch that matches your screen.

Bronze

Make the bottom row show a bar instead of a number: one block character for every 10 cm, up to sixteen. You will need a for loop and screen.print((char)255), which prints a solid block. Then say in one sentence which is easier to read from three metres away, and why.

Silver

Add a smallest ever reading that is remembered and shown on the top row, with a button to reset it. This is genuinely useful for a parking guard: it tells you how close you actually got. Watch out for the reading of 0.

Gold

Take the average of the last five readings instead of using each one raw, and show that instead. The screen will become noticeably calmer. This is hard for an interesting reason: you need somewhere to keep five numbers and a way to throw the oldest away each time. An array from Band 3 and a position that wraps round will do it.

The test that matters most in this band

Put it where it belongs, hand nobody any instructions, and watch one person walk up to it.

Write down what they read first, how long before they acted, and whether they did the right thing. If they read the number before the word, your layout is telling them to. If they hesitated, count the characters in the message they hesitated over.

Show your work

Post four things: a video of somebody using it, a close photo of the screen with a real reading on it, your ruler-accuracy table, and your build log. Then look at one other person's screen layout and tell them one thing you had to read twice.

Code you have not seen. Answer from reading only. Do not upload it.

#include <Wire.h>
#include <LiquidCrystal_I2C.h>

LiquidCrystal_I2C screen(0x27, 16, 2);

int trigPin = 10;
int echoPin = 11;
int lastCm = -1;

void setup() {
  pinMode(trigPin, OUTPUT);
  pinMode(echoPin, INPUT);
  screen.init();
  screen.backlight();
}

void loop() {
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);

  unsigned long us = pulseIn(echoPin, HIGH);
  int cm = us / 29 / 2;

  if (cm != lastCm) {
    lastCm = cm;
    screen.setCursor(0, 0);
    screen.print(cm);
    screen.print(" cm");
  }

  delay(100);
}

1. The sensor is pointed at a wall 100 cm away, then slowly at one 99 cm away. What does the top row of the screen say?
2. The sensor is now pointed out of a window at open sky, so no echo ever comes back. What does the device do? Answer carefully: this is not a question about the screen.
3. Compare the pulseIn line with the one in b7_01_ping_given.ino. One value is missing here. Which, and what does leaving it out change?
4. The wall is 60 cm away and nothing is moving. Roughly how many times a second is the screen written to?
5. int cm and unsigned long us. The wall is 3 metres away. Is int big enough to hold the answer? Show the arithmetic.
6. Somebody wants this to also sound a buzzer that beeps faster as things get nearer, and adds a tone and a delay inside the if. Name two separate things that will go wrong.

Part 11 was the real test. This is a warm-up for it, and a list to come back to. Say each of these out loud, to somebody or to yourself, without looking anything up.

• Say where the 29 and the 2 come from in the distance calculation
• Say what a reading of 0 means, and name two things that cause it
• Name three surfaces this sensor is bad at, and say why
• Explain why a screen flickers, and give the two-part fix
• Say why printing 99 over 100 shows 990
• Say what to try first when a screen shows nothing at all
• Install a library you do not already have, without help

Your board can measure a distance now, and it can tell somebody about it without a computer in the room. Those two together are what a device is.

The more useful thing you learned is smaller and harder to see. You took a number your sensor gave you and you did not believe it until you had checked it against a ruler. Then you found the places it could be trusted and the places it could not, and wrote those down.

Most people never do that, and it is the difference between a project that works in a video and one that works in a room.

Before you move on, make sure you have

• A video of somebody using your device, and a close photo of the screen with a real reading on it
• Your completed ruler-accuracy table from Part 3, all five rows
• Your notes on the three awkward surfaces, and the two distances you decided you would trust
• Your completed beep timing table from Part 9b
• Your four sixteen-character messages, counted
• Your build log for this band
• Five or six correct answers in Part 11, including question 2

Next is Band 8: Build for Nzemaland. The last band, and the only one with no new parts in it. You find a problem somebody actually has, decide beforehand what would count as solving it, and then find out honestly whether you did.