This is the third article in a series about Glanceable Displays and my efforts to create one for my household. For other articles in the series, click on the title of the article under the heading “Glanceable Displays” on the right side of the webpage.


In the previous article, I detailed the steps required to get the Raspbian (Linux) operating system installed on a Raspberry Pi with remote access through SSH enabled.

This article attempts to move the needle forward by tackling a number of the issues that I had in getting necessary foundation services up and running on my Raspberry Pi. The two services that I had issues with were: ensuring that Wi-Fi was working properly and that the Raspberry Pi clock was being set properly. Until I was confident that these two issues were resolved, I was not confident that I would be able to use my glanceable display in it’s intended location, as that location does not have any wired network access.


As the steps in the previous article concluded with providing SSH access to the Raspberry Pi, I performed all of the following configuration using an SSH client. While you are welcome to enter them through a keyboard directly connected to the Raspberry Pi, I did not test any of the steps in that manner.


From the experience of reviewing and retrying these steps, sudo reboot is a good friend. If it looks like something didn’t work and you think it should, consider using sudo reboot to reboot the machine and carry on from there. This is very handy when changing configuration.

Step 1: Wi-Fi Access

Unless you have the fortune of having a wired network outlet available near your display AND enjoy the aesthetic of having a network cable going into your display, you most likely want to enable Wi-Fi access to your display. Here are the steps I went though to get wireless access enabled.

Step 1a: Searching for Existing Wireless Access

The first command that I used to check for wireless network access was the ifconfig command. This is a general command used to determine what network connections are available. I had a network cable running into the machine, but nothing else, so the following response1 was expected:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

While it looks like gibberish to some, it was what I expected. Linux systems often use the tag eth0 for the first wired connection and the tag lo for the loopback connection. The important thing I noticed was that I didn’t see a wlan0 tag, typically used for the first wireless connection. The clear observation I had was that the system did not currently have a capability to have a wireless connection.

This observation on a normal computer running Linux might be farfetched, but from information gained researching the Raspberry Pi on various forums, it is relatively normal for a Raspberry Pi to not have any wireless capability built-in. As wireless components have recently become cheaper, it seems like it is only the latest versions of the Raspberry Pi 3 have wireless access built in.


I have not repeated these steps on a newer Raspberry Pi, but I would expect that doing so would allow me to skip the next section on installing the adapter. I will update the article once I have tested that scenario.

Step 1b: Installing a Wireless Adapter

In my instance, the machine I was configuring did not have any wireless capabilities built in. That was resolved in short order by noting down the connection requirements for the household router (WPA2-PSK (AES)) and purchasing an inexpensive USB Wi-Fi adapter from a nearby store.


If possible, use that store’s online presence to inspect the possible adapters, verifying 1-3 choices for adapters that meet the router’s specifications. While not necessary, it can avoid round trips to the store to try and find the right adapter. Doing this, I found that my local store had a TP-Link TL WN823N USB Adapter that was right for the job for $15.

Returning home from the store with an inexpensive TP-Link TL WN823N adapter, I powered off the Raspberry Pi, installed the Wi-Fi adapter in one of the open USB slots, and powered up the Raspberry Pi. Once Raspbian had booted up, I reconnected to the machine using SSH and entered the lsusb command. This command is similar to the ls command to list files, but is used to list various USB components that the machine has recognized. The response I received from that command was:

Bus 001 Device 006: ID 2357:0109 TP-Link TL WN823N RTL8192EU
Bus 001 Device 005: ID 0461:4e26 Primax Electronics, Ltd
Bus 001 Device 004: ID 0461:4d64 Primax Electronics, Ltd
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Seeing as the adapter I bought was a TP-Link TL WN823N, I was relieved to see it listed as device 06. At this point it was clear to me that the Raspberry Pi recognized the adapter, and it was time to install the required drivers.

Step 1c: Installing the Wi-Fi Drivers

From a research point of view, this was the most frustrating part of getting wireless access working. In most of the articles I researched, the authors seemed to assume that the drivers for a given adapter would already be installed in the Raspbian distribution. The few articles I found that handled missing drivers were very specific, and not very helpful. They often used the Raspbian apt-get family of commands to look for an adapter, and each adapter I found seemed to have a slightly different way of making sure it worked properly. As I was writing down notes for this article to help other people, that experience was frustrating and was far from helpful.

Everything changed when my research led me to a reference to the Fars Robotics driver install script. This breaks down the process into the following three commands:

sudo wget -O /usr/bin/install-wifi
sudo chmod +x /usr/bin/install-wifi
sudo /usr/bin/install-wifi

Instead of playing around with apt-get commands and looking for a specific driver, this script automated the process, finding the correct driver and installing it. The commands first downloaded the script into the /usr/bin directory, set it to be executable, and then executed the downloaded script. Within 60 seconds, it had completed, and it’s output suggested that the driver for my TP-Link TL WN823N had installed successfully.

To double check that it worked properly, I resubmitted the ifconfig command and got the following:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet  netmask
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500

Great! Progress! The new Wi-Fi adapter was installed, the driver was connected, and Raspbian was reporting that it could talk with it! From experience, I now had to configure the machine to connect to the wireless network. From the output, this was somewhat obvious. For the eth0 and lo adapters, there was a line beginning with inet that described the current IPv4 setup for that adapter. As the wlan0 adapter was missing the inet line (and also the inet6 line), Raspbian could talk to the adapter, but the adapter was not connected to the local Wi-Fi network.

Next stop, configuring Wi-Fi access.

Step 1d: Configuring Wi-Fi Access

Similar to the previous section on Installing the Wi-Fi Drivers, I found many articles on how to do this by hand, each with its own little twist on how to set things up better. In my case, I wanted to go for repeatable and easy, and the sudo raspi-config command used to set up SSH access in a prvious article proved to be the best solution.

From the main menu, I selected 2 network options and then N2 WiFi. As it was my first time setting up the network on this machine, I was prompted for my country, which I entered. Next I was prompted with Please enter SSID, and I responded with my router’s SSID. This was followed with the inevitable Please enter passphrase. Leave it empty if none., to which I responded with my router’s password. Hoping everything would work out, I pressed the Next button.

After waiting for approximately 30 seconds, the focus was returned to the main configuration screen. Exiting out of that screen and back to the main screen, executing the ifconfig now had the following response:

eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet  netmask  broadcast
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet  netmask
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast

This was what I was waiting for! At the moment, the eth0 wired connection had an address of and the wlan0 wireless connection had an address of The address is the one I had been SSHing into while fixing up the Wi-Fi, so that lined up. Based on my router’s configuration, was a likely address for a new machine, so that lined up.


If you have your network secured, make sure you follow the normal steps for adding a new machine to your network. This may include asking your local network person to add your machine to the network. In my case, forgetting that step cost me over an hour trying to figure out why the Raspberry Pi would not connect to the network!

To verify things were working, I repeated the relevant portions of Step 5: Setting Up SSH Access from the previous article, using the new address, instead of the old one Once this succeeded, the final test was to disconnect the physical connection and see if the wireless connection worked.

It did take a lengthy bit of time, and one trip to a local store for hardware, but it was very gratifying being able to talk to the glanceable display over a wireless connection!

Step 2: System Clock Synchronization

While the Raspberry Pi is a useful little machine, it’s small form causes it to not have a component that many machine take for granted: a system clock. Not having this set up for your glanceable display can cause any display of time to be extremely out of sync. In addition, if the Raspberry Pi’s time is not decently close to the actual time, the downloading of extra components through mechanisms such as the apt-get commands may fail. To avoid these issues, setting up proper system clock synchronization is a must.


The list of servers and download locations for the apt family of commands has most likely changed since the Raspbian image was constructed. If this is the case, any apt commands that require any kind of package updates will most likely fail. To solve this before it becomes an issue, I issued the following command to update those tables.

sudo apt-get update

Step 2a: Installing the NTP Service

The quickest and most efficient solution to solve the synchronization issue was to install the NTP time service. In the distribution of Raspbian that I was using, the NTP service was not installed. When I entered the command sudo systemctl status ntp, I saw the following output:

Unit ntp.service could not be found.

Based on various articles, the clear solution was to install the NTP service using apt-get with the following command: sudo apt-get install ntp. Once that finished, when I repeated the sudo systemctl status ntp command, I then received the following output:

● ntp.service - Network Time Service
   Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
   Active: active (running) since ...

At this point, I was satisfied that the NTP service was up and running, but not that it was working correctly.

Step 2b: Diagnosing the NTP Service Configuration

Once the service was loaded, I needed to confirm that the NTP service was working properly. The easy way to do this was to reboot the machine using sudo reboot and then use the date command to check the date. When I followed that pattern, the date was over 2 weeks off from the actual time. Time to go into debug mode.

The documentation on the NTP service mentions a useful command: ntpq -p. This command lists information about what the current NTP service is doing. Presented as a series of columns, the important column was the number of seconds since the service successfully contacted a specific NTP server.

When I checked the output of the command, I was greeted with the following table:

     remote           refid      st t when poll reach   delay   offset  jitter
 0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.004
 1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.004
 2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.004
 3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.004

Looking at the when column, the issue seemed to be that it was not able to connect to those servers and get information about them. Doing a bit of research, it turned out that other people have had problems with the default servers for the NTP server, and there were ways to address that.

Step 2c: Changing the NTP Service Configuration

Now that I had the NTP service installed and had issues with the default configuration, it was time to look at it. The configuration for the service is located in the file /etc/ntp.conf. As I had found issues with the default configuration, I needed to learn more about this configuration file to fix the problem.

Looking at the file using a command like more /etc/ntp.conf was daunting. There were a number of 1-2 line sections with multiple lines of comments before them. When I saw that, I was concerned. In my experience, a large comment to useful line ratio means they are commenting the heck out of it, because people have done stupid things in the past.

Learning more about the configuration, it turned out that I only needed to look at one particular section. The most important part of the configuration is a section that started with the follow text:

# maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <>

Right after this text, there was a group of servers specified where the first part of the server name was a number between 0 and 3, and the rest of the server name was the same. Many of the articles I found didn’t touch the rest of the file, but focused on that small set of lines.

A very useful page I found during my research was the NTP Pool Time Servers page. Near the bottom of that page is a table that lists the various geographic areas, from which I selected the North America selection. At the top of the next page was a clearly marked section of text, with clear instruction to add that text to the ntp.conf file.

Given that information, I went back to the Raspbian machine, entered sudo nano /etc/ntp.conf to edit the /etc/ntp.conf file, and replaced the default debian servers in that section with the information from the clearly marked section of the NTP Pool Time Servers page. Followed up with Ctrl-X to save, y to save the file, enter to use the provided file name, and it was changed. Just to make sure, I did another sudo reboot after verifying my changes, and the date command now returned the right date.

Step 2d: Verify that the NTP Service is Working


As a number of Denial-Of-Service attacks have used the NTP port to return bad information, a number of routers come pre-configured with their firewalls set to block port 119 and 123, the NTP ports. If you follow these instructions and are still having issues, check the firewall settings for your computer and your router.

Previously, when I had checked the status of the NTP service using the ntpq -p command, I did not seeing anything other than - in the when column of the output. If things were working properly, I would expect that column to change.

Submitting the ntpq -p command once the system rebooted, I got the following output:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================    2 u   21   64    1   59.302    9.614   6.053
+  3 u   17   64    1   26.382    5.225   3.611
+time1-inapsales  2 u   17   64    1   41.043   -2.463   4.417
*  2 u   18   64    1   36.759   -5.673   2.870

Submitting the command multiple times, I observed that the when column values increased to a certain point before they started over with a low single digit number. From the documentation, this was a good indication that each of those servers was being queried successfully, then registering itself for the next time to check against that server.

Seeing the successful connections with the NTP servers, the time synchronization issues were cleared up! Just to be sure, I did a couple of cycles of sudo reboot and checking the time, with no errors.

What Was Accomplished

This article detailed the steps taken to fix two of the major issues I had after installing Raspbian on my Raspberry Pi: the Wi-Fi access and the system clock being out of sync. I worked through the various steps taken to ensure that the wireless access was up and running, including the various checks I did throughout the process. I then walked through the steps I took to ensure that the time on the Raspberry Pi was reflecting actual time, despite not having an onboard system clock.

With this accomplished, I had confidence in having firm foundations on which to start building the display part of my glanceable display.

What’s Next?

In the next article in this series, Glanceable Displays: Setting Up Our Display I walk through the steps I took to setup the Raspberry Pi to start the display upon boot for the glanceable display.

  1. In any of these examples, a set of ellipses (“…”) are used to denote that content was removed that was either sensitive or not relevant to the example being presented. 

Like this post? Share on: TwitterFacebookEmail


So what do you think? Did I miss something? Is any part unclear? Leave your comments below.

Reading Time

~13 min read


Glanceable Displays


Integrating Technology


Stay in Touch