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).



Extinguish as necessary

Not ESP8266 related, but important enough (and techie enough) to bear further dissemination through the IoT/Maker/DIY communities.

Hackaday published a short feature on this today and it looks as though two basic flaws with the Anet A8 3D printer can work together to cause a serious fire.  The summary is that there is no check for thermal runaway of the print-head in the printer’s default firmware and the heating element is prone to coming loose from the body of the print head itself.  This is what can result from that combination:-

Burned Anet A8 Printer
Anet A8 printer remains (picture courtesy of http://www.thissmarthouse.net)

John, the owner of this ex-printer, freely admits that some of his self-printed add-ons undoubtedly contributed to the conflagration, however the two defects noted above appear to have been the combined root cause.

By all accounts, the A8 is a decent enough printer which sells at a very competitive price, so there are probably a lot of them out there.  Apparently there is third-party replacement firmware (“Marlin”) available for this unit which does include thermal runaway protection for the print-head, so if you own an A8 an upgrade sounds worthwhile.

John mentions that had he not had an extinguisher to hand, the outcome of this incident could have been a good deal worse.  The takeaways from this are:-

  • Don’t ever leave a running 3D printer unattended
  • Regularly check that the heating element and temperature sensor are both firmly attached to the print-head
  • Upgrade to “Marlin” firmware if you’re using an A8
  • Keep an extinguisher and/or fire-blanket close at hand when using equipment which produces temperatures capable of causing ignition
  • Install a smoke alarm over your 3D printer



Rust on the ESP8266

Here’s something which seems as though it might be of interest to a few people …Rust on the ESP8266. Rust logo “emosenkis” (Eitan Mosenkis) has put together a script to install the toolchain on a Linux machine, enabling the user to use PlatformIO and the Arduino environment to build Rust projects.  I haven’t tried this myself, yet (I don’t know the first thing about Rust), but it is something I’ve seen mentioned on other people’s “wish lists” now and then.

So, Rust enthusiasts, give it a try and report back and let us know how you get on (and why we should all convert …or not).