• Home
• Video Materials
  YouTube Channel LBRY Feed
• Reading Materials
  ESP8266: Getting Started ESP8266: HTTP(S) Client ESP8266: TCP Client-Server ESP8266: Highway Jams Monitor
• Downloads
  ESP-12-E(F) Breadboard Adapter PCB ESP-12-E(F) LED Bar PCB
• About

Sigma Projection

ESP8266 WiFi Module - Highway Jams Monitor

Overview

Nowadays traffic congestion on specific routes can become an ordinary issue. Constant monitoring of specific road jams can help you to make a decision whether to drive a car or to use a public transport (like a train) to reach the destination point. Existing mobile applications and portable maps allow you to get these details, but each time when you would like to understand what is the current traffic jams level - it will require you to wait until the corresponding application will be loaded. This section represents overall details on how to build sample highway jams monitor device that can represent a constant indication of current traffic jams condition on a selected route. This is an open-hardware project distributed under Creative Commons License: Attribution 4.0 International (CC BY 4.0) https://creativecommons.org/licenses/by/4.0/. So, this device can be assembled and used on a constand basis - like a classic alarm clock.

The following topics can be explored under this page and under videos provided:

Youtube Videos

Details on traffic jams monitor application are presented in two parts. The first one explains overall details on how to design and build LED bar PCB which is used for road congestion level indication. The second part contains overall details on how ESP module integration with Google Directions API is implemented and how to build and execute the application:

Highway Jams Monitor. Application Details.

This project is designed to constantly display current traffic jam conditions on a specific route. The application is integrated with Google Directions API which allows retrieval of the current traffic congestion information using REST API. This application is targeted to be built under ESP8266_NONOS_SDK platform (version 3.0.0 or 3.0.5). Target ESP8266 NON OS SDK is available for download at ESP NON OS SDK 3.0.5.

Highway Jams Monitor application itself is available on GitHub. Using the following command it can be cloned into a local folder (repository project files can be placed to any subfolder under SDK root folder):

git clone https://github.com/sigma-prj/esp-highway-traffic-monitor.git

Application is designed to run on ESP-12-E or ESP-12-F modules. As a hardware part - LED Bar PCB is used. This part is built in KiCad 5.1.9, and original PCB design files with gerbers are available on GitHub as well:

git clone https://github.com/sigma-prj/esp-12-e-led-bar-pcb.git

Initial Configuration

In order to pre-define a specific route, which will be a subject of constant monitoring, there is a need to update the following file below. Constants START_POSITION, END_POSITION and WAYPOINTS should be used to specify GPS coordinates of route start point, route destination point and intermediate waypoints respectively:

// route start GPS position
static const struct gps_coords START_POSITION = { 51.564418, -0.062658 };
// route end GPS position
static const struct gps_coords END_POSITION = { 51.519986, -0.082895 };
// intermediate waypoint GPS positions
static const struct gps_coords WAYPOINTS[] =
{
    { 51.556724, -0.074518 },
    { 51.531606, -0.077044 }
};

Google Directions API always tends to provide a few alternative routes when checking traffic jams between two target points. This can introduce ambiguity while trying to display congestion information using the LED bar. As the target user will not be aware of which exact route is pre-selected for displaying. This way, the inclusion of extra waypoints into the route will help to pre-define which exact route needs to be selected for displaying. These waypoints can be defined using WAYPOINTS constant array (by specifying corresponding GPS coordinates).

The next part of configuration relates to sensitivity level adjustments, which is used for traffic congestion indication. This will allow to establish what is the best possible time to drive this route without any traffic jams. This way, any period of time predicted by Directions API, which is less than this value - will result in switching off all LEDs (which means the road is free - no traffic jams). And, as the opposite, value of the worst time in traffic can be specified. This will trigger the ignition of all 8 LEDs, in case of Directions API will predict time in traffic more than this value (which means - the road is blocked). Corresponding values can be set using these constants:

// defines the worst time on the route (in seconds) - all warning LEDs will be ignited - means traffic jam
static const sint32 WORST_ROUTE_TIME = 1600;
// defines the best time on the route (in seconds) - all warning LEDs will be off - which means the road is free
static const sint32 BEST_ROUTE_TIME = 960;

All other intermediate results will ignite only a subset of LEDs. The amount of ignited LEDs will be calculated on a pro-rata basis:

static uint16 calculate_level(sint32 value)
{
    uint16 result;
    if (value > WORST_ROUTE_TIME)
    {
        result = LED_COUNT;
    }
    else if (value < BEST_ROUTE_TIME)
    {
        result = 0;
    }
    else
    {
        result = ((value - BEST_ROUTE_TIME) * LED_COUNT) / (WORST_ROUTE_TIME - BEST_ROUTE_TIME);
    }
    return result;
}

Wi-Fi Connectivity Details

The following application parameters need to be set, in order to establish a WiFi connection and have the ability to query Directions REST API. The way how to retrieve the Direction API key is explained under the "Project Links" section below, in a separate video.

// Update according to WiFi session ID
#define WIFI_SSID       "[WIFI-SESSION-ID]"
// Update according to WiFi session password
#define WIFI_PASSPHRASE "[WIFI-PASSPHRASE]"
// Directions API Key
#define HTTP_QUERY_KEY  "[GOOGLE-DIRECTIONS-API-KEY]"

MBEDTLS Library and Directions API with TLS 1.3 handshake

Directions REST API which is used in this application is secured by the most recent TLS 1.3. And the certificate size used for TLS handshake is a bit bigger than expected for standard ESP8266 SDK SSL libraries. This way, a standard library like libssl.a might not work correctly while trying to establish the connection using espconn_secure_connect. In such case, the application might cause an out-of-memory error on ESP8266 and might trigger ESP chip reboot.

Due to these reasons - MBEDTLS library is used in this application. MBEDTL is an open-source library and allows to override the required memory allocation for TLS handshakes. To allow TLS handshakes to be executed without errors, there is a need to increase MBEDTLS allocated memory size from 8192 to 9800. This can be achieved by the following steps:

[esp-sdk]/third_party/Makefile needs to be modified - build mode should be set from debug to release:

TARGET = eagle
#FLAVOR = debug
FLAVOR = release

[esp-sdk]/third_party/make_lib.sh script also needs to be modified to re-target output folder from .output/eagle/debug to .output/eagle/release :

#cp .output/eagle/debug/lib/lib$1.a ../../lib/lib$1.a
cp .output/eagle/release/lib/lib$1.a ../../lib/lib$1.a
xtensa-lx106-elf-strip --strip-unneeded ../../lib/lib$1.a
cd ..

[esp-sdk]/third_party/include/mbedtls/sys/espconn_mbedtls.h should have the amount of TLS handshake buffer memory size to be increased from 8192 to 9800:

//#define ESPCONN_SECURE_MAX_SIZE 8192
#define ESPCONN_SECURE_MAX_SIZE 9800
#define ESPCONN_SECURE_DEFAULT_HEAP 0x3800
#define ESPCONN_SECURE_DEFAULT_SIZE 0x0800
#define ESPCONN_HANDSHAKE_TIMEOUT 0x3C

And as the last step, there is a need to outline the build target for MBEDTLS as ESP8266. Just need to uncomment the following section at [esp-sdk]/third_party/include/mbedtls/config_esp.h :

/**
 * \def ESP8266_PLATFORM
 *
 * Enable the ESP8266 PLATFORM.
 *
 * Module: library/ssl_tls.c
 * Caller:
 */
#define ESP8266_PLATFORM

Once pre-configuring is done - MBEDTLS library build can be triggered by the following instruction:

cd [esp-sdk]/third_party
./make_lib.sh mbedtls

Once the compilation is done - the newly built library can be found at [esp-sdk]/lib/libmbedtls.a. No need to copy this library anywhere, as it will be picked up automatically by the ESP application build Makefile.

Build and UART Logs Configuration

In order to build this project, the standard ESP SDK procedure can be followed. The build process can be triggered by the execution of the default target on a project's root Makefile with a specific set of arguments. Typical Makefile target execution sample and arguments set can be found in ESP SDK example:

[esp-sdk]/examples/peripheral_test/gen_misc.sh

Particular shell command and arguments may depend on a specific ESP board configuration. Below is a typical example to trigger a build on a certain ESP configuration:

make COMPILE=gcc BOOT=none APP=0 SPI_SPEED=20 SPI_MODE=DIO SPI_SIZE_MAP=4 FLAVOR=release

This application also can be built with output debug UART logs enabled. For these purposes, the special symbol UART_DEBUG_LOGS can be defined in build configuration:

make COMPILE=gcc BOOT=none APP=0 SPI_SPEED=20 SPI_MODE=DIO SPI_SIZE_MAP=4 FLAVOR=release UNIVERSAL_TARGET_DEFINES=-DUART_DEBUG_LOGS

More details on how to enable and monitor debug logs, while the application is running, can be found under this section, which explains a sample TCP client-server application.

Flashing Compiled Binaries to ESP Chip

The following scripts can be found under project's root folder:

./erase_mem_non_ota.sh
./flash_mem_non_ota.sh

These scripts can be used to flash compiled binaries into ESP chip memory. Erase script also will allow to clean up ESP memory before flashing the actual application. Once binaries are compiled, the shell script can be triggered directly either through corresponding Makefile targets:

# To erase ESP memory
make esp_erase
# To flash actual application into ESP memory
make esp_flash
# To remove binary eagle files from build output folder
make clean_image

Within shell script there is a need to update the following input parameters:

For more information about how ESP NON-OS SDK can be setup and can be used for app compilation and flashing - please refer the following link: http://www.sigmaprj.com/esp8266.html

Project Links

Below you can find a set of useful links which cover the main aspects of this project and downloadable design files: