A non-trivial ESP8266 project

If the name Aidan Ruff rings bells with you, it’s probably because of the frequent mentions he receives on Pete Scargill’s blog and for his designs of their “Hackitt & Bodgitt” series of ESP-based hardware (Aidan’s board designs, such as "Hackitt & Bodgitt" Nextion Display Boardthis ESP12 board aimed at supporting a Nextion display, are especially useful for general purpose ESP8266 development and he makes the files freely available on-line).

Aidan is in the process of having an old farmhouse (in an olive grove in Spain) rebuilt and, because there are no mains services (electricity or water) available, has embarked on what, to most of us, would be the non-trivial project of providing enough solar (and possibly wind) power and enough battery capacity to provide summer cooling and winter heating without having to resort to the use of a generator during prolonged, adverse weather conditions.  His outline plan on how he intends achieve this (along with some impressive floor-plans) are available on his “Off Grid in Spain” blog.

Of more specific interest to ESP aficionados though, is the solar-tracking sub-project he’s put together to ensure that the (MPPT) output from his panels is maximized by adjusting elevation and direction.  The tracker controller is an ESP8266-ESP12 of course, but with a novel twist.  Instead of using the tried-and-tested optical tracking method (with its inherent problem of “hunting” on overcast days), Aidan has hooked up a GPS receiver to the ESP and uses a combination of the precise time and positional data to compute where the sun should be in the sky at his particular location (whether it’s hidden by clouds, or not).  The ESP communicates via MQTT (but also has an embedded web server and an attached OLED display panel), which means that, with additional data from a connected weather station, Aidan can add features such as having the solar panels rotate down to lie flat when the wind speed exceeds a pre-set limit.

The initial prototyping and testing of the two-axis, linear actuator based tracker is already completed and Aidan has put up his board and mechanical design files and a couple of videos on a Hackaday I/O project page.  Unfortunately, at the time of writing, the ESP code doesn’t seem to be available either on that page or from Aidan’s GitHub repository, but despite that, it’s definitely a project worth watching (tracking?).


Free SBCs

Linux Gizmos is currently running its yearly round-up of SBCs, along with the customary questionnaire/competition, giving you the chance to win an SBC or a shield/add-on board for free.  So, if you’re interested in getting hold of an SBC as a gateway for your network of ESPs, head on over there and answer a few questions.  I make it roughly a 1:120 chance of winning (based on their stats from last year), which is a lot better than the lottery.



Battery not lasting as long as it used to?

Back in July of last year, Jeff King (@wb8wka) noticed that there was a problem with  ESP.deepSleep() calls using the ESP8266 Arduino Core.  Versions greater than 2.0.0 appear to ignore the WAKE_NO_RFCAL flag and the WiFi calibration routine is run every time the ESP wakes, adding around another 200ms to the total start-up time, as well as a corresponding current spike.

Jeff notes that using the Espressif “system_” calls, rather than the Arduino wrapped calls, results in the expected behaviour (that is, no calibration being run), so the problem does seem to be with the Arduino Core and, as of 2.4.0, it is still an issue.  Ivan (@igrr) has acknowledged the problem, but so far there is no fix.

So, if you’re using ESP.deepSleep() and your batteries don’t seem to be lasting as long as they used to, you might want to go back to Arduino Core 2.0.0 for building your battery-powered projects.

Ref: esp8266/Arduino issue #3408

u-blox produced ESP32 has FCC approvals

Update 15th May 2018 — Between writing the first draft of this article and pushing the big red “Publish” button, the prices for all of the items mentioned here have already changed (downwards), so please refer to the u-blox AG online site for the latest, up-to-date pricing for your area.

u-blox AG, the Swiss company famous in hobby circles mainly for their excellent (and cheap) little GPS modules, have started selling two new standalone WiFi modules, the NINA-W101 (external antenna connector) and the NINA-W102 (module mounted antenna).  u-blox AG's NINA-102 moduleThe W101 is priced at $US 8.75 and the W102 is $US 9.48, direct from u-blox in bulk (250, or more).  While that price is fairly competitive for an ESP32 module (assuming that the one-off price isn’t too far out of that particular ballpark), the cost of the development board is a bit excessive, at US$ 99 (again, available directly from u-blox AG’s on-line shop).

The antenna on the W102 model (shown above) is neither the older SMD-chip type nor the PCB trace type.  It seems to be a custom made planar inverted-F antenna (PIFA), distinct from the existing ESP modules in that it stands over 1mm higher than the RF shield on the module.  u-blox AG provide suggested sizing for orientation and ground-plane sizing in their datasheet.

The NINA-W10 series data-sheet makes interesting reading and, although the u-blox document doesn’t come right out and say “this is an ESP32”, it doesn’t keep it a secret, either (on a couple of the pages there’s a footnote reference saying “See the Espressif ESP32 Datasheet for…).

Although neither of these modules is particularly hobbyist friendly (ref the solder-side of the W102 module in the photo, above), many IOT designers will be excited to see that they are FCC approved for the U.S. (and RED/FCC-equivalent for many other countries, too) and that u-blox AG offer support for integrating the modules into an end product as a “grantee” (if you understand the FCC process that last part will hopefully make sense to you).

In the same “Short Range, WiFi” product category are the closely related NINA-W131 and W132 products which appear to be almost identical, except that Bluetooth isn’t available.  Details on these two modules are a little sparser than the W101/102 variants.



Over the past weekend, Theo pushed out another fairly big update to TASMOTA with some interesting new additions.

  • Language file support for:-
    • Portuguese
    • Czech
    • Bulgarian
    • Russian
    • Hungarian
    • Greek
  • Addition of  “rules”, to enable local, logical control of devices based on various inputs (so, for instance, a self-contained thermostat application can now be implemented internally on the Sonoff module, without requiring support via MQTT or other external methods).
  • Addition of KNX UDP protocol support to enable integration of Sonoffs into building automation projects.
  • The re-addition of variable support for MQTT client/topic values, using the ESP chip-ID.
  • Addition of a new, optional OTA upgrade method to allow for a PlatformIO-type “push” of large binaries (up to ~700kB) without requiring the use of a local web server.
  • Addition of support for hardware and software serial bridging (text only).
  • Addition of support for the Zengge ZJ-WF017-A PWM LED strip controller (ESP12S based).
  • Addition of support for the SGP30 air quality sensor.
  • Addition of sunrise/sunset option for scheduling (by geographical location).

As well as all of these new additions, there are a whole host of fixes and updates to existing features.  Definitely worth checking this one out!


Driving WS2812 LED strips with the ESP8266

There’s a really captivating article on Tweaking4All illustrating the various effects (firelight, bouncing-balls, chasers, etc) that can be easily reproduced with the common WS2812, addressable, RGB, LED strips, available from just about every vendor out of the Middle Kingdom.  Although the article is a couple of years old and is aimed at Arduino hardware using the FastLED or NeoPixel libraries, the routines are, for the most part, directly transferable to the ESP8266 (both libraries are available for the ESP when using the Arduino framework).  When used with the ESP8266 though, there are a couple of pitfalls which you need to be aware of:-

  • 3v3 vs 5v voltage levels
  • The ESP8266 wireless housekeeping requirements

The first is something you need to pay a little bit of attention to, in order to prevent damage to the ESP GPIO pin.  It’s very easy to isolate your ESP8266 from the WS2812 5v supply voltage and provide a low impedance drive for the WS2812 bus at the same time, using a cheap, PNP transistor in emitter-follower configuration.  An emitter-follower is a non-inverting buffer, which provides a medium to high impedance on it’s input (so it doesn’t place any significant load on the GPIO pin) and presents a low impedance output (meaning it can drive more current than the ESP GPIO pin can alone).PNP Emitter Follower  Unlike the more traditional common-emitter transistor circuit, the emitter follower doesn’t amplify the input signal at all; in this circuit it is acting as a switch, but while the output from the GPIO is switching between 0v and 3v3, the output of the emitter-follower is switching between 0v and 5v.  Thus this simple circuit not only protects your ESP from damage, but also provides the correct voltage swing for the WS2812 data bus, too.  Almost any common, small-signal PNP transistor (2N3906, BC560) will work in this configuration; specific type is not too critical.

The second issue is the common watchdog-timeout issue which plagues applications which spend too much time in tight, time-critical loops without allowing the ESP8266 time to attend to its WiFi housekeeping.  The answer in this case is fairly simple …just put a couple of calls to yield() into the code in strategic places (one in the top of the loop function and another following the call to showStrip() , in whichever example code is being used, worked well for me).  Unless you’re doing something insanely complicated and insanely fast, you shouldn’t notice any visible difference to the display.  If you are running something i-comp and i-fast, you should bump the ESP8266 speed up to 160Mhz to handle it, anyway (“board_f_cpu = 160000000L” in your platformio.ini file); you don’t need to make any changes to the code to handle the faster CPU clock.

With these two issues addressed, you should be able to run any of the examples from the Tweaking4All site.  You have the choice of using either the FastLED or NeoPixel libraries and the Tweaking4All collection comes with all of the examples duplicated across two directories, one for each library.

Other Options

There’s also a second version of the FastLED library available from Cory R. King which adds DMA output for the ESP8266 for a smoother, flicker-free output.  Note that DMA hardware in the ESP8266 uses pin-3 (which is the UART RX pin) as the output …so no matter which pin you define in the display code, it will always use pin-3.

In addition to those already mentioned above, Makuna (Michael C. Miller) has also done a lot of work on optimizing WS2812 driver code specifically for the ESP8266 and ESP32 processors with his NeoPixelBus library.  It has multiple interfacing options (DMA, UART and bit-bang) available.  DMA is the default (and recommended) operating mode.  Users have reported that, for the ESP8266, the NeoPixelBus library is the most robust and reliable method for driving addressable LEDs when the WiFi must also be in use.  Although Michael’s examples are quite comprehensive, you may find yourself with some coding to do if you want to convert all of the Tweaking4All demos to run using this library.

ESP8266 GPS NTP Server in the making

Chris Liebman is my kind of maker.  His projects are interesting, practical and almost always have the words “work in progress” somewhere in the (usually brief) description.  I was led to the NTP-server project when following up on his (ESP8266-based) AnalogClock creation (a method of keeping el-cheapo analog clocks in perfect time, even across power outages and daylight-savings time changes, using an ESP8266 and NTP).

The NTP-server is another “work in progress” project, with very little information, Breadboard prototype NTP serverother than the code, available.  It does hit a couple of sweet spots for me, though:-  NTP from a GPS PPS (pulse-per-second) signal and being ESP based (although the breadboard picture shows an ESP32, rather than ESP8266).

Chris is using an Adafruit “Ultimate GPS Breakout” board to provide the PPS signal, as well as serial time and date information to the ESP (the GPS communicates with the ESP via the standard serial pins, while debug-terminal output goes to Serial1).

I have to admit that I haven’t managed to get Chris’ code to compile successfully, yet (you’ll need to download some of Chris’ modified versions of several required libraries to get even close), but this certainly looks like one to keep an eye on (and I’m wondering if a lead soldered to the ‘status’ LED on one of those cheap, USB, GPS dongles would work reliably as a PPS signal source in this case).