Creating a wifi signal strength detector with Arduino Uno

Arduino Wifi Strength Tester

Why:

I recently moved to a new house and have been struggling to set up our wireless to provide an even amount of wifi coverage to each area with the three devices I have (2 Airport Extremes, 1 Airport Express). I also recently started to dig back into the Arduino stuff now that I’m in the new house and finally have a dedicated space to lay out everything. This seemed to be fate – I had a problem to solve and needed a project at the same time. Below I’ll walk through the learning process and include the final project details.

Equipment used:

Arduino Uno R3

Adafruit ATWINC1500 Wifi Breakout Board

10k Ohm Breadboard Potentiometer

220 Ohm Resistor

16×2 LCD

Common Cathode RGB LED Breakout Board

Breadboard

Solderless Breadboard Wires

8AA Battery Pack

The Hardware Setup:

I first started out getting the wifi chip up and running using Adafruit’s excellent tutorial linked from their product page. Once everything was wired up, I installed the Wifi101 library found on GitHub in this Zip file of their master branch.

My Wifi Wiring:
  • ATWIN1500 ==> Arduino Uno R3
  • VIN ==> 5v
  • GND ==> Ground
  • SCK ==> D13
  • MISO ==> D12
  • MOSI ==> D11
  • CS ==> D10
  • EN ==> 5v
  • IRQ ==> D9
  • RST ==> D8
  • WAKE ==> Not Used
  • CFG ==> Not Used
  • RXTD ==> Not Used
  • TXD ==> Not Used

Next was opening up the Arduino IDE and loading up the CheckWiFi101FirmwareVersion sketch as instructed by Adafruit, making sure to set:

WiFi.setPins(8,7,4);

in void setup().

My firmware was 19.4.4 so I needed to update, which I did following these handy instructions. Great! I was now ready to go.

Having wired, installed and updated everything, I was able to start scanning for wifi, which could not be easier with the built-in examples in the WIFI101 library. I first ran the ScanNetworks sketch and then the ConnectWithWPA sketch. Both worked flawlessly and allowed me to see available networks and even connect to a website and download the page into the serial monitor. Web scraper anyone?

Next, start to customize the code to remove the need for the serial monitor so I don’t have to carry my laptop around with my setup. That means adding a LCD. Luckily I have a few of these on hand.

My 16×20 LCD Wiring:
  • SunFounder LCD1602 ==> Arduino Uno R3
  • VSS ==> Ground
  • CDD ==> 5v
  • V0 ==> 10k Potentiometer Wiper (center)
  • RS ==> D2
  • R/W ==> Ground
  • E ==> D3
  • D4 ==> Arduino D4
  • D5 ==> Arduino D5
  • D6 ==> Arduino D6
  • D7 ==> Arduino D7
  • A (LED Anode) ==> 220Ω ==> 5v (22.73mA)
  • K (LED GND) ==> Ground

LCD added, let’s add some code to make it work!

First, include the library at the top of the sketch:

#include <LiquidCrystal.h>

Then declare the pins you’re using for the LCD in the top of our sketch. In our case, we just need to declare the RS, E and Com pins like this:

LiquidCrystal lcd(2, 3, 4, 5, 6, 7);

The LCD setup is done and ready for instructions. But first lets also add a RGB LED so that we can also have an obvious visual indicator for when we’re making adjustments to the wifi from across the room, etc.

My Common Cathode LED Wiring:
  • LED Breakout ==> Arduino Uno R3
  • –  ==> Ground
  • R ==> A5
  • G ==> A4
  • B ==> A3

wifi_strength_tester_fritzing

The Code:

That’s it for hardware, let’s move on to the code, which is a mashup of lot’s of other tutorials, but really quite simple!

#include <LiquidCrystal.h> // needed to power the lcd screen
#include <SPI.h> // needed to communicate will everything
#include <WiFi101.h> // need to run the wifi chip


char ssid[] = "YOUR-WIFI-SSID-HERE"; // your network SSID (name)
char pass[] = "YOUR-WIFI-PASSWORD-HERE"; // your network password

int status = WL_IDLE_STATUS; 
WiFiServer server(80); 

LiquidCrystal lcd(2, 3, 4, 5, 6, 7); // set the pins used for the LCD(RS, E, Coms)

const int redPin = A5; // pin used for red pin of LED
const int greenPin = A4; // pin used for green pin of LED
const int bluePin = A3; // pin used for blue pin of LED

void setup() {
 // set up the LCD's number of columns and rows:
 lcd.begin(16, 2);
 
 pinMode(redPin, OUTPUT); // set A5 to output
 pinMode(greenPin, OUTPUT); // set A4 to output
 pinMode(bluePin, OUTPUT); // set A3 to output

 // set pins used for Wifi chip
 WiFi.setPins(10,9,8); 

 // initialize serial and wait for port to open:
 Serial.begin(9600); 

 // wait for serial port to connect. Needed for native USB port only
 while (!Serial) {
 ;
 }

 // check for the presence of the shield:
 if (WiFi.status() == WL_NO_SHIELD) {
 Serial.println("No wifi shield not present");
 // don't continue:
 while (true);
 }

 // attempt to connect to WiFi network:
 while (status != WL_CONNECTED) {
 lcd.setCursor(0,0); // set cursor to top/left most spot on the lcd
 lcd.print("Connecting to:"); // write message to lcd
 lcd.setCursor(0,1); // set cursor to bottom/left most spot on the lcd
 lcd.print(ssid); // write the name of your wifi network to lcd
 
 // Connect to WPA/WPA2 network. Change this line if using open or WEP network:
 status = WiFi.begin(ssid, pass);

 // wait 10 seconds for connection:
 delay(10000);
 }
 server.begin();
}

void loop() {

 long rssi = WiFi.RSSI(); // sets signal strenth to variable rssi

 lcd.setCursor(4,0); // Set cursor to 5th spot on the top row
 lcd.print("Signal:"); // print message to lcd

 // in a loop, check the stregth of the signal and print it to the lcd
 // turn make the LED a corrosponding color
 
 // if strength is more than -50 it's excellent
 if (rssi > -50) {
 lcd.clear();
 lcd.setCursor(1,0);
 lcd.print("SGL: Excellent");
 color(0,255, 0); // green
 
 // or if strength is between -50 and -59 it's good
 } else if (rssi <= -50 && rssi >= -59) {
 lcd.clear();
 lcd.setCursor(4,0);
 lcd.print("SGL: Good");
 color(0, 0, 255); // blue

 // or if strength is between -60 and -69 it's fair
 } else if (rssi <= -60 && rssi >= -69) {
 lcd.clear();
 lcd.setCursor(4,0);
 lcd.print("SGL: Fair");
 color(237,109,0); // yellow-ish

 // or if strength is or less than -70 it's fair
 } else if (rssi <= -70) {
 lcd.clear();
 lcd.setCursor(4,0);
 lcd.print("SGL: Poor");
 color(255, 0, 0); // red
 }

 // print the acronym for decibel-milliwatts (dBm) 
 lcd.setCursor(4, 1);
 lcd.print(rssi);
 lcd.setCursor(8, 1);
 lcd.print("dBm");
 delay(1000);

}

// color function which tells the pins how to behave
void color (unsigned char red, unsigned char green, unsigned char blue) { 
 digitalWrite(redPin, red); 
 digitalWrite(bluePin, blue); 
 digitalWrite(greenPin, green); 
}

That’s it! Add your wifi ssid and password to:

char ssid[] = "YOUR-WIFI-SSID-HERE"; // your network SSID (name)
char pass[] = "YOUR-WIFI-PASSWORD-HERE"; // your network password

 (This is not secure, so don’t upload that to github without removing or obfuscating it)

Now go scan your house, garage, backyard, office, whatever! 

Early prototype testing:

Testing the WIFI!

Make webdriver wait for an element to become visible with Selenium Python

It’s a problem I’ve encountered many times: building out a test and getting to an element I need to click on or test its attributes or text only to find out that it’s being dynamically loaded by Javascript. When this happens I always get the same error in the console.

ElementNotVisibleException: Message: element not visible

It’s frustrating since virtually all help threads Ive found on Stack Overflow and on other blogs are close but never offered help that actually works. Maybe because my issue is not quite the same or because I write my tests differently, but truly I’ve never gotten any of those solutions to work. The following is a list of things that are either really bad ideas or just never worked for me:

  • Sleep the browser
  • Programmatically move the cursor 1px in order to find a button hit state
  • Injecting click actions into the browser developer console (ewww)
  • Use XPATH instead of CSS Locator
  • Get the size of the element first then click
  • etc

Finally just breaking down and looking at the Docs for Waits in Selenium/Python there, of course seems to be some promise. The example they give is as follows:

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Firefox()
driver.get("http://somedomain/url_that_delays_loading")
try:
    element = WebDriverWait(driver, 10).until(
        EC.presence_of_element_located((By.ID, "myDynamicElement"))
    )
finally:
    driver.quit()

Scanning the code quickly, I figured this was right up my alley. I copied the code, changed the placeholder element to the one I’m looking for, saved the file, rebuilt Docker, and ran the test. Same failure. Literally this code changed nothing. It didn’t wait, the element was still not visible and the test still failed. Ugg.

I read back through the code more thoroughly and noticed the Expected Condition line of

presence_of_element_located

which caught my eye. Presence. Ahh, right ok. My issue was not that the element was not present, which can also happen. My issue this time as you recall above was that the element was not Visible. Ok, dig deeper into the docs and look at the full list of Expected Conditions which are:

title_is
title_contains
presence_of_element_located
visibility_of_element_located
visibility_of
presence_of_all_elements_located
text_to_be_present_in_element
text_to_be_present_in_element_value
frame_to_be_available_and_switch_to_it
invisibility_of_element_located
element_to_be_clickable - it is Displayed and Enabled.
staleness_of
element_to_be_selected
element_located_to_be_selected
element_selection_state_to_be
element_located_selection_state_to_be
alert_is_present

Ahh, look at this. Visibility conditions. This is looking promising! Let’s make a quick change to something like:

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Firefox()
driver.get("http://somedomain/url_that_delays_loading")
try:
    element = WebDriverWait(driver, 10).until(
        EC.visibility_of_element_located((By.ID, "myDynamicElement"))
    )
finally:
    driver.quit()

Save the file, rebuild Docker, run the test. While testing in our dev environment I have Docker run the test with a headed browser, usually Chrome or FF so I’m able to watch it run. This time around something is different. The test properly pauses while the page content is loading in dynamically then once loaded the test proceeded. Success! That was it.

Chrome inspector’s 0 variable

Ever noticed a little commented-out expression hanging off your code in Chrome’s inspector that looks something like ==$0?

Chrome Inspector 0 variable

Google Chrome’s inspector assigning the above line a variable of 0.

I have, but never gave it much mind. I finally thought I’d look into it today and wish I had a long time ago. Turns out what the expression means is that if you click on a line of code in the inspector or right click inspect an element the variable 0 gets assigned to that node and its children.

Calling this variable by typing $0 into the console of Chrome will then display just that node and its children. Super helpful if you’re like me and prefer to focus on certain lines or nodes without the clutter of everything else in the DOM.

Google Chrome console

By typing $0 into the console of the browser just the selected line of code in the inspector will display along with its children.

Pretty handy trick, right? Well, you can also use $1 $2 $3 $4 to go back and look at previous nodes that you inspected before the most current $0 inspection. Stack Overflow user deadlock, has the winning explanation here.

Tell Protractor where your Angular app lives, avoid sync issues

A handy trick (read: best practice) I ran into today was about how to properly inform Protractor where to look for your Angular application when it pols the DOM.

In my early Protractor tests I always started out with something like:

// ignore Angular and sync
beforeEach(function() {
    browser.ignoreSynchronization = true;
});

I have a few tests that need to run back and fourth between Angular and non-Angular pages and this worked in a pinch but I never really looked into the details of it.

Today while working on a new test that’s being extremely finicky, I needed to debug that line a bit and came across a great post by Vincent Tunru. In essence, adding a browser.ignoreSynchronization = true;  line to each test works, but in reality it’s better to simply tell protractor in your config file where your Angular app will exist and let it sort out whether or not there’s Angular on the page.

You can accomplish this by adding to your cons.js file the following:

exports.config = {
  
  rootElement: '*[ng-app]', 

  ...

Which will tell Protractor that your Angular app should be found on an element with the attribute of ng-app whether your Angular app is in the default body tag or most likely not.

Neat and much cleaner. Thanks, Vincent!