People and Business

When we talk about a successful product or a company, most of the time our conversation revolves around same set of questions such as, “what is the underlying design & technology ? what does separate it from others?, what is the business model ?” etc. We fail to stress the importance of people and their needs. In the end all products, services and businesses are consumed by the people.The people are the ultimate drivers of a business.s

Why Count People?

As a rule of thumb, in any business more number of customers translate into more profit and success. When we know the number of people nearby our point of interest then it is easier to provide better services and convert them from normal passerby to satisfied customers. Let’s assume, you own a taxi company and you have installed a device to count number of people close to point A where you always find your customers. When on your laptop screen flashes that there are 15 people at point A, you could immediately send more taxis, serve better and earn more. Similarly, this could be a useful metric for trade fair organizers, food truckers, campaign organizers and can also be utilized for passenger metering at train stations and airports.

How to Do That?

We live in a time where everyone uses smartphones and is glued to them most of time because of work, games, news, social media etc. A smart phone is equipped with Bluetooth and WiFi communication technologies. Periodically,  every WiFi station scans each radio frequency (RF) channel to find access points except it is in the Airplane mode.According to IEEE 802.11 standards, the scanning process can be done in the following two ways.

Passive Scanning

In the passive scanning a WiFi station (STA) listens to channels and waits for beacon management frames (beacons) generated from access point (AP) in an infrastructure basic service set (BSS) having service set identifier (SSID) of a network for a specified time. These frames contain information such as timestamp, beacon interval, supported set etc. which are then used by a WiFi client to connect to the AP. When a STA receives the frames from one or more access points then it determines which access point it want to associate to based on vendor specific algorithms.

Active Scanning

In the active scanning a WiFi station sends probe request frames containing MAC address of itself and SSID of known access points or broadcast SSID (FF:FF:FF:FF:FF:FF). A probe request frame with specific SSID is received by the concerned access point and with broadcast SSID the station can direct the frames to all access points in the proximity. An AP must reply to all probes that contain broadcast SSID or an SSID that matches its own with probe response frame. You could find more details of the association process here.The following picture depicts the format of the probe request frame and you get more information of the MAC header in the frame here.

Probe Request frame

There are multiple limitations of passive scanning. Firstly, it generally takes more time and secondly a WiFi station might miss a beacon from AP if it doesn’t wait long enough. That is why, the active scan feature is more common in WiFi devices nowadays. We use a sniffing device to look for the probe request frames from nearby smart phones, laptops, tablets etc and estimate number of active devices. This estimation gives a rough idea about number of people present there at a given time. The device is called Paxcounter, where pax stands for people or an alternation of passenger from 1970s.

Hardware and Software Setup

We used TTGO v2.1 development board and  bought from ebay. It is a very powerful board, packed with ESP32, LoRaWan chip, SSD1306 oled display of 128×64 pixels and IP5306power management IC. We utilized source code from ESP32-Paxcounter, an open source GitHub repository. The repository has libraries required for oled display, LoRa, power management and other tasks all at one place. ESP32 is a single 2.4 GHz WiFi and Bluetooth system on chip (SoC).

The ESP32 WiFI functionality is configured and monitored using the WiFi library provided by Espressif. Using this library the device can be configured to run in different roles with distinct encryption protocol such as WPA, WEP etc. The important roles are Station (STA, WiFi client), Access Point (AP) and both STA-AP combined. It has also very interesting feature which allows it run in promiscuous mode. In the promiscuous mode it could monitor IEEE 802.11 packets. We enable this mode on the device to sniff probe request frames from smart devices. The configuration is done in wifiscan.cpp  as following. The detailed API information can be found here.

Configuration Before Compilation

We have to make some changes in the existing files and create new files to configure the device before compilation.

  1. Select board type ttgov21new in platformio.ini
  2. Configure duty cycle and payload encoder in paxcounter.conf
  3. Select frequency band in lmic_config.h respective to your country, in Europe it is 868 MHz for LoRaWAN
  4. Create loraconf.h file with the template provided in loraconf.sample.h.

    We have to make an account to use The Things Network (TTN) resource. We also need to add an application and register a device. After completing all this we could get EUIs information from the account and copy in the loraconf.h file. For an instance, we created paxcounterasvin application and registered a device named ttgo as shown in the picture below.
  5. Create ota.conf using the template ota.sample.conf, it is used for OTA update and has details of WiFi access point and Bintray user account.

Compilation and Uploading

We used PlatformIO extension in VS Code. It is very efficient and quite easy to use. The PlatformIO toolbar contains quick access buttons for basic commands such as Build, Upload, Test and Serial Monitor.


The Things Network

The Paxcounter displays the number of devices available and also sends real time information to the things network servers based on the settings in loraconf.h . On the things network side, we have to put some code in decoder and converter section respective to the payload format configured in the paxcounter.conf. We used the code from here.

Now we are ready to receive the data on our TTN console. You could check that in the Data section of your application on the things network console.

Downlink Packets

The Things network provides a feature to schedule and send downlink packets, from application side to the Paxcounter. You could access this feature on device section in the TTN console. You could specify payload and port number on the console and send the packet to the device. For an instance, we sent a packet on port 2 with payload 0x81 to check device status as shown below.

The response from the Paxcounter can be checked in the Data section of the registered application. For an example for we got device information such as cputemp, memory etc. as shown below.

There are multiple commands supported. The detailed list can be found here.

Is it Privacy Intrusion?

A WiFi or Bluetooth device can be uniquely identified by MAC address. It is assigned by the manufacturer and is 6 bytes long. Typically, It includes manufacture’s organizationally unique identifiers (OUI). In a MAC address, 3 bytes are for OUI. The Paxcounter is specifically designed to filter probe request frames and uses only the OUI part of a MAC address. A unique identifier is created by combining a OUI with randomly generated variable (salting) and hashing it. It does not persistently store the hashed identifier and generates a new salt in every scan period. It keeps it for a specified scan time (60s default) and only utilizes to count the number of devices. It sends only the number of devices not the MAC addresses to the things network and everything is cleared after a scan period. The source code for the same can be found in the wifiscan.cpp file as depicted below.