Computing stuff tied to the physical world

Putting it all together

by Thorsten von Eicken

One of the issues that comes up many times while putting all the pieces together is debugging. With the esp8266 this means ‘printf’ to a serial port, which is a tricky proposition since the serial port is already needed for other purposes. In total there are 4 functions vying for the UART:

  • flashing the esp8266, needed to initially bootstrap the firmware and whenever a bug causes the OTA upgrade to malfunction
  • printing the debug log so one can see what the firmware is doing
  • programming the attached microcontroller
  • logging the output and providing input to the attached microcontroller

There is a second UART in the esp8266, but it can only transmit on the GPIO2 and GPIO7 pins. The latter pin is actually used to drive the external flash chip, leaving only GPIO2 as a viable option. In the esp-bridge board that signal is brought out to a special “debug” header to make it easy to access, but for fans of minimal design (or lowest production cost) that’s an excessive luxury.

As an alternative, the esp-link software uses one UART for all functions and offers different modes. The normal mode is to print debug information on the UART until the esp8266 manages to associate with the configured access point and obtain an IP address. At that point it ceases to log to the UART. If it looses the association it re-enables the logging. This way most of the phases during which things go wrong are covered by the logging. When the logging causes issues with the attached microcontroller, esp-link can be put into a mode where it does not log at all to the UART.

What if something happens mid-course? For that purpose, all the log text is stored in a small circular in-memory buffer of 1024 bytes and a web page displays that buffer. The way it works is that the web page reads the buffer and displays it but keeps track of where is was. When the user hits the refresh button an AJAX request asks for characters starting at the end position of what is already displayed making for a seamless log as long as refresh is pressed often enough. An auto-refresh mode might be desirable, but the requests for fetching the log are also logged themselves and pollute the log…

Screen 2015 06 27 662

Wifi power consumption

One of the debates at JeeLabs during the development of the esp-bridge was about power consumption: would it be at all practical to operate an esp-bridge on battery power? As mentioned in the first episode, the esp8266 consumes close to 200mA peak when transmitting, which is a lot of power. The key to reducing the power of Wifi systems is to turn the radio off, and then to also turn the processor off in addition.

The 802.11 standard has had a power save mode for a long time that is built on the periodic beacons sent out by access points (APs). Each AP sends out a beacon announcing itself typically every 100ms. In addition to announcing the presence of the AP the beacon can carry “TIM” flags that tell associated clients whether the AP has queued a packet for them.

In order to go into low-power mode, the esp8266 sends the AP a short packet notifying it that it is going into power save mode and then turns off its receiver until the next beacon. Meanwhile the AP queues any packet for the esp8266 and flags the presence of packets in the beacon.

Just before the next beacon, the esp8266 wakes up, turns on the receiver, receives the beacon and examines it for queued packets flags. If packets are queued, it asks the AP to send them and then goes back into power save until the next beacon.

To be precise, the waking-up does not happen for every beacon at the standard 100ms interval. Instead APs have a “DTIM” setting that determines for how many beacon intervals the AP queues packets. A popular setting is 3, which means that packets are queued for 3 intervals, i.e. 300ms, allowing clients in power save mode to wake up only every 300ms to examine the beacon.

The oscilloscope screen shot below shows all this in action in the esp-bridge. The purple trace shows power consumption of the whole circuit. Ignore the yellow trace, it was used to trigger the scope. The little “3” marker at the lower-left edge is the zero reference for the trace and one can clearly see two power states: the idle state where the esp-bridge consumes approximately 16mA and the receive state where it consumes approx 70mA. The time base of this trace is 500ms per grid (6 seconds from the left edge to the right edge) and the vertical cursors show a 300ms DTIM interval.

Screen 2015 06 27 663

The trace shows that the esp8266 often is in low power idle mode and wakes up very briefly at least every 300ms to check the beacon for waiting packets. Sometimes there must be a packet and it turns the receiver on for approximately 100-200ms before it goes back into power save mode. The average power consumption depends on how often the AP has a packet for the esp-bridge.

The esp8266 and Espressif SDK implement an even lower power state called “light sleep” where the CPU is switched off and the chip consumes 0.6mA. In this mode it wakes up either from a timer or an external pin change. The documentation is not very clear but it appears that waking up on an incoming character on the UART is not possible in this mode, making it difficult to use with the esp-bridge.

Getting the software

There are many more facets to the esp8266, the esp-bridge circuit and the esp-link software than can be covered here and it may be time for you to dive in yourself! The software is open source and can be found conveniently on GitHub. There are periodic binary releases made evailable on GitHub that do not require the esp8266 development environment to be installed in order to flash an esp8266 and the esp-link software can be used with the most common esp-01 module. Bugs and feature enhancements are tracked using the GitHub issue tracker and discussions can be either conducted on the esp8266.com forum or in the Gitter chat room for esp-link.

[Back to article index]