Introduction
The Troverlo tag system is designed to appear as a wifi access point for the purpose of asset tracking. Its asset tracking abilities are supplemented by several types of sensor support which enable data collection about assets such as ambient temperature, pressure, humidity, volatile organic compounds, CO2, range, activity/double-tap/freefall detection, voltage, and current. The design was initially intended to be a prototyping platform upon which more specialized designs could evolve, as a result, three fundamental use cases were implemented: battery powered with solar charging, host powered with battery backup, and host powered with battery backup and sensor support. The most full-featured use case is on a host-powered tag with battery backup and sensor support while the other use cases subtract functionality for the sake of battery longevity.
Hardware Overview
The Troverlo tag has a shared design for both a solar-powered system and a host-powered system. Required programming pins for the ESP8266 module are brought out as test points near the edge of the board as well as test points for battery, solar panel, and host power inputs. The solar charger IC used is an Analog Devices ADP5091 low power energy harvester and the battery charging IC for host power is the Maxim Integrated MAX8903GETI+. The regulated voltage supply for the processor is provided by a Texas Instruments TPS630242YFFR buck-boost controller.
Refer to the Rev C schematic for a detailed view of the selected resistor, capacitor, and inductor components required to configure all signals on the board for correct operation.
Design Considerations
When selecting a processor, initial considerations were the ESP8266, ESP32, or using a non-Wifi enabled SoC with an external wifi radio component. The added cost was the major reason for avoiding the last option, however, device support was also lacking on many external wifi modules when compared to the Espressif SoCs.
Since initial requirements for the design placed high importance on the ability to transmit barebones 802.11 wifi beacon frames, some initial tests were done with the ESP32 and ESP8266 but there were issues using the esp_wifi_80211_tx() function with the ESP32 so the ESP8266 was chosen.
Note from the firmware engineer: Unfortunately, the issue we faced at that time was not very telling. Basically when invoking the esp_wifi_80211_tx() function on the ESP32 it would behave as though it transmitted the packet successfully, but the 802.11 packet wasn't seen by any device we could test with so we tried it on the ESP8266 and it worked. Since there was no need at the time for anything that was only available on an ESP32, we just went with what worked in the interest of time.
I am confident that the function should work on an esp32, we just didn't have a reason to debug it at the time. I think the most likely reason for the problem was using an unstable version of the ESP-IDF. If they simply use the latest actual release version of the ESP-IDF, I don't imagine they'll have any serious issues with that function (Right now the latest stable version is v4.4).
For the Troverlo Tag PCB (printed circuit board) design, it was required to have the same board (Universal) design be capable of both a solar-powered configuration and a host-powered configuration. To that end, resistors R11, R12, and R13 from the rev C schematic could be placed in alternate positions depending on the desired configuration. The corresponding solar charger or vehicle charger ICs can optionally not be populated during manufacturing.
Software Tools
Firmware development for this project was done using Espressif’s ESP 8266 RTOS SDK v3.4 (the latest release version at the time of writing) which provides a FreeRTOS implementation and a comprehensive set of tools for using the ESP8266 processor. For quick setup on Windows machines, Espressif provides a pre-configured MSYS2 environment containing the required toolchain and software to clone the ESP8266 RTOS SDK so that projects can be built quickly. A full programming guide (including a getting started guide) provided by Espressif can be found here: https://docs.espressif.com/projects/esp8266-rtos-sdk/en/latest/get-started/index.html
Since the ESP8266 RTOS SDK uses an implementation of FreeRTOS, it is also helpful to have the FreeRTOS Kernel Development Docs as a reference. These can be found here: https://www.freertos.org/features.html
For the Troverlo tag, the key components within the SDK used are GPIO for contact closures and host power supply detection, wifi radio components for 802.11 beacon frame transmissions and softAP configuration, an I2C bus for sensor communications when applicable, timers, and a file system. The features of FreeRTOS used in the Troverlo application code are tasks, task notifications, and mutex semaphores.
System Architecture
For a host-powered Troverlo tag with battery backup and sensor support, the firmware architecture is illustrated by the diagram below. (Note that the Solar version of the tag only has the Initialization, App Main task, hardware timer callback, and Beacon Transmit task blocks).
Initialization
Upon initialization, device timing parameters and persistent data are read from flash along with a GPIO signal to indicate whether the device is on host or battery backup power. For both host and battery power, a Sensor Timer task, Sensor Manager task, and SSID Manager task will be created, and a hardware timer will be configured. If host power is detected, the hardware timer will be configured with host power timing parameters, a softAP will be configured, and the softAP Manager task will be created. If battery backup power is detected, the hardware timer will be configured with battery backup timing parameters, the beacon frame buffer will be set up, and the Beacon Transmit task will be created.
App Main task
Once initialization completes, the main task will begin monitoring the power supply detection pin and – if the device is on battery power - the time elapsed since the hardware timer began. If the power supply changes, the processor will reset and switch behavior as appropriate for the supply. If the active time on battery backup power has elapsed, the processor will go into deep sleep mode for the programmed amount of time.
Hardware Timer callback
The hardware timer callback runs every time the programmed hardware timer interval elapses. It adds this amount of time to counter variables and sends task notifications to the App Main task, Beacon Transmit task and Soft AP manager task.
Soft AP Manager task
The softAP manager task only runs when the device is on host power. When it is notified to run by the hardware timer callback, it checks to see if the SSID string has been updated with new information by the SSID manager task. If it has, then the Soft AP manager task stops the softAP temporarily, reconfigures it with the new SSID string, then restarts the softAP. Since it takes a relatively long time to stop and restart the soft AP, the frequency of these changes is limited to 10 seconds to avoid situations where the softAP is constantly stopping to accommodate changing SSIDs.
Beacon Transmit task
The beacon transmit task only runs when the device is on battery power. When it is notified by the hardware timer callback, it checks if the SSID string has been updated. If it has, then the new SSID string is formatted into the beacon frame buffer and will be transmitted once every time the task receives a notification until the SSID string changes again or until the device’s active time has elapsed.
Sensor Timing task
The sensor timing task notifies at a rate of 1Hz the Sensor Manager task, SSID manager task and any sensor tasks that have been created. Additionally, it updates the internal hourly max sensor values when on host power.
Sensor Manager task
The Sensor Manager task is notified by the sensor timing task and checks whether any supported sensors have been connected or disconnected. It creates or destroys sensor handling tasks accordingly and updates a shared data array so that other tasks know which sensors are present.
SSID Manager task
This task manages the SSID string being transmitted. Whenever relevant data changes (time on host power, contact closure status, which sensor is attached and the sensor’s corresponding data) this task will format this data and update the SSID string which is used by either the Soft AP manager task or the Beacon Transmit task depending on whether host power is supplied or not.
The SSID is formatted into one of several sensor data schemas (Z0 through Z8) depending on which sensor is attached. The basic SSID format for each sensor is given by:
| Data Schema indicator | Cumulative hours on host power | Contact closure | Power indicator | Current sensor data | 24 hours max sensor data (field does not present if power indicator field is 0) |
Usage
The battery-powered tag with solar charging is the simplest use case from an implementation perspective. It does nothing more than take pre-programmed amounts of time to sleep, wake up, and transmit wifi beacon frames at a specific beacon interval and then repeat this cycle indefinitely.
The host powered tag with battery backup has two operating modes depending on whether a host power supply is present, or it is running on battery backup power. When on battery backup power, it functions identically to the solar charging tag mentioned above to conserve energy. When a host power supply is provided, the battery will charge and the wifi module will initialize a softAP with WPA2 that will refuse any connection attempts even if a correct password is given.
The host powered tag with battery backup and sensor support functions the same as the one without sensor support except that it will periodically check if any supported sensors are attached to its I2C bus. If there are sensors attached, it will periodically sample that sensor’s readings and update its SSID based on the sensor and data coming in. It will do this whether it is on host or battery backup power, but when on host power the SSID will indicate this and include the maximum reading over the past 24 hours. When on battery backup, the SSID will again indicate this and this time it will have current readings, but not the maximum.
For troubleshooting, it is useful to attach a programmer to the Troverlo tag through the programming pins and open a serial port to receive diagnostic info from the processor.
Overview of Tag Operation
Tags that are host powered, are using SoftAP, they use a standard beacon that is sent out every 100 timeslots (102ms) and we respond to Probe Requests w a Probe Response.
We randomly select channels 1-11 at bootup, we only use the 2.4gHz band.
For other Tags, we have some that run off battery and some that have battery backup.
For tags with battery backup, when they have host power, they use SoftAP.
When the Tags run on battery power, they go into an “active/deep sleep” cycle. In the Active cycle, we send “bursts” of Beacons in a very short period of time, we do not respond to Probe Requests. Each Active cycle, we pick a random channel to send the beacons out on. Active times are small and deep sleep times depend on desired detection rate and duration of the battery life.
We are “mimicking” an AP (access point), so we do NOT connect with anyone, we just need to be “detected.” In our probe response or within the beacon, we provide the SSID (we call it Tag Data) and the BSSID (we call this the Tag ID) in a standard fashion.
Troverlo's OUI
48:06:2B