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.

 

Advertisements

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

 

 

Using oddball ESP boards with TASMOTA – Part III (MQTT)

Continuing with our series of articles on utilizing Theo Arends’ TASMOTA firmware on non-Sonoff boards and devices, in this article we’ll look at using MQTT to interact with the target.

Feel free to skip over the next four paragraphs (between the horizontal delimiters) if you’re already familiar with the way in which MQTT works.


Just in case you’re not familiar with MQTT, I’d like to emphasize here that it is not an interactive mode of communicating with your device in the way that using a serial adapter, console or telnet/ssh connection is.  In concept it is more like using radios for verbal communication; you have both a transmitter and a receiver, but they are two separate pieces of equipment.  If you transmitted a message, you wouldn’t hear any reply if your receiver wasn’t turned on and tuned to the appropriate frequency.  Likewise, without a transmitter (again, tuned to the correct frequency) you would simply be a passive listener to whatever was received.  MQTT is similar; you need to know the “frequency” (the topic) which you want to communicate on and you need a transmitter (a publisher), as well as a receiver (a subscriber).

To complicate matters a little further, you are running your radio equipment in a deep valley, surrounded by mountains.  In order to use your radio you need to use a repeater station, situated on a nearby summit.  The operators of the repeater are very generous and will freely rebroadcast anything they receive on to you , just as long as you tell them which frequencies you want to receive.  All of your radio traffic, both outgoing and incoming, needs to go via this repeater.  In MQTT terms, the repeater is a “broker” which will listen for messages and rebroadcast them.  You can receive and transmit messages at will, as long as you specify a topic.

The most common MQTT broker for home use is Mosquitto, which comes with a couple of command-line utilities, “mosquitto_sub”, a subscriber (or receiver) and “mosquitto_pub”, a publisher (or transmitter).  You would run Mosquitto on one of the machines on your home LAN (say, perhaps a Raspberry-Pi or a dedicated NAS or back-up system which is running 24/7).  The Mosquitto daemon provides a fully functional MQTT “broker”, but you can also install the mosquitto-clients package on your desktop or laptop to make the mosquitto_sub/pub utilities available, without the overhead of the full daemon.

Anyway, enough of the radio analogy.  The important things to remember with MQTT are that:-

  • You won’t automatically get any response from a “pub” message sent to your ESP, unless you are also listening to the correct topic with a “sub”.
  • MQTT is a distributed protocol, in the sense that your subscribers will usually be on a different physical machine than the publishers and probably neither of them will be on the same machine as the broker.

On the ESP8266 side, there are a few libraries available which give moderately pain-free access to MQTT from your program.  Currently I’ve been favouring Nick O’Leary’s PubSubClient library and, luckily, Theo includes it by default in TASMOTA, so you don’t need to do anything extra; MQTT capability is built-in.

So, lets get started with MQTT.  As suggested in the previous article, I’d recommend opening up the wiki page describing TASMOTA commands and using it as a handy reference while you’re playing with this.

Example of "screen" with top and bottom window splitHowever, before we jump into the commands themselves, I’d recommend that you bring up two separate windows on your display to allow you input “transmissions” in one window while simultaneously being able to see received messages in the other (if you’re using a full-screen terminal window on some modern version of Un*x, you can also use the “screen” utility to split your single window into top and bottom halves, using “CONTROL-A S”, followed by “CONTROL-A TAB” to swap between the new, top and bottom windows and then “CONTROL-A c” to create a new shell in the bottom window [¹]).

In your top window, start a “receiver” process to monitor the output on TASMOTA’s “stat” (status) topic.  This is where you’ll see the messages which TASMOTA is sending back to the MQTT broker.  Your command will look something like this:-

mosquitto_sub -h mybroker.mylan.com -t “stat/sonoff/#”

…where “mybroker.mylan.com” is the machine where the main mosquitto daemon is running (your “broker”) and “sonoff” is the “friendly name” you’ve given your module in TASMOTA.  The “#” character at the end of the topic string (“stat/sonoff/#”) is the MQTT wildcard character and, in this case, tells the mosquitto_sub command that we want to see all messages that match the “stat/sonoff/” string, whether they be the result of command execution or specific subsystem (ie:- memory) informational messages.

If your broker process is running on a separate machine, the commands which you type in can get quite long, so I’d also recommend building up a couple of aliases for the mosquitto_sub and mosquitto_pub commands (I covered this in an earlier MQTT how-to article).

[ NOTE:- From this point onwards I will use the aliases “mqp” for mosquitto_pub and “mqs” for mosquitto_sub to try and limit the example commands to a single line. ]

As when using the console commands earlier, we’ll start with some simple commands to manipulate the green LED.   Here’s where a simple rule will help out — IF YOU’RE SENDING A REQUEST OF ANY SORT, YOU NEED TO USE THE “cmnd/*” TOPIC.  In this particular instance, it may seem intuitive to use the “stat/*” topic, because we want to see some status, but you need to remember that we’re not using an interactive terminal session; we’re using the transmit and receive functionality of MQTT, so we must send any request as a command.  This takes a little bit of getting used to, but will become second nature very quickly.  So in this case, the command you send to your module will look something like this:-

mqp -t cmnd/sonoff/LedPower -n

The “-n” tells mosquitto_pub that there is no message part to this particular command.

Once sent, you won’t see any  other output in your “transmit” window (unless you’ve made a typo), but over in the window where you left the mosquitto_sub command running in background, you should see the response:-

{"LedPower":"OFF"}

…or possibly “ON”, of course.

Controlling the LED is more intuitive than just getting the status:-

mqp -t cmnd/sonoff/LedPower -m "on"

We’re using the same basic command, with exactly the same topic (“cmnd/sonoff/LedPower”), but a different message (the ‘-m “on”‘ part) and, as you’d expect, this turns on the LED on your remote module and, in addition, TASMOTA automatically sends a status update message, so your mosquitto_sub (receiver) window will display:-

{"LedPower":"ON"}

Then use:-

mqp -t cmnd/sonoff/LedPower -m "off"

…to turn it back off again (hopefully your ESP8266 module is somewhere within sight, so that you can visually check that these commands are indeed working).

The next step is to simply replace “LedPower” with just “Power” and verify that the relay on your ESP8266 is also responding to on/off commands.  The output in the mosquitto_sub window will change to:-

{"POWER":"ON"}  and  {"POWER":"OFF"}

Our next command will return the status (the current pwm count between 0 and 1023) for each of our previously assigned PWM drive pins (the red and blue LED segments of the RGB LED on the Yellow Dev board).

mqp -t cmnd/sonoff/pwm -n

Note that we’re again using the “-n” to tell mosquitto_pub that there’s no message part to this topic.  The output on the mosquitto_sub screen will probably look something like this:-

{"PWM":{"PWM1":0,"PWM2":0}}

The output is just a little more complex, as there are now two separate GPIOs in the overall PWM status report.  I’m sure that by now you don’t need me to tell you that using those PWM1 and PWM2 ids, you can now control your red and blue LEDs in the same way as we did from the console, but using the message part of the MQTT command to vary the PWM drive output:-

mqp -t cmnd/sonoff/pwm1 -m "750"

…returns:-   {"PWM":{"PWM1":750,"PWM2":0}}

mqp -t cmnd/sonoff/pwm2 -m "350"

…returns:-   {"PWM":{"PWM1":750,"PWM2":350}}

Note that the response status from the command still includes all of the defined PWM pins, even though our command lines only change one GPIO pin at a time.

Following along from the examples we went through previously in the “Console” tutorial, we’ll now request TASMOTA to send us the status (including the data) from our on-board temperature sensors.  If you remember, we needed to send the command “status 10” from the console, which translates into another command string for mosquitto_pub.

mqp -t cmnd/sonoff/status -m "10"

…and the response this time (in the mosquitto_sub window) is much longer (this would all be on one line on your screen):-

{"StatusSNS":{"Time":"2018-02-14T09:46:58","DS18B20-1":{"Id":"011590E534FF","Temperature":1.50},"DS18B20-2":{"Id":"031590A618FF","Temperature":35.25},"TempUnit":"C"}}

Anyone who has played around with IOT data in the past few years will recognize this (and the previous examples) as JSON formatted data.   Here we can see that the overall encapsulation is “StatusSNS” and within that we have several different types of data returned.  The first is a timestamp which needs no explanation, but the following two blobs of data:-

"DS18B20-1":{"Id":"011590E534FF","Temperature":1.50},

and

"DS18B20-2":{"Id":"031590A618FF","Temperature":35.25},

…are more interesting.  The strings “DS18B20-1” and “DS18B20-2” are arbitrary identifiers used by TASMOTA to identify individual one-wire temperature sensors.  The “Id” numbers are the actual serial numbers of the DS18B20s themselves (each sensor has a unique serial number burned into its ROM when manufactured).  “Temperature” is again obvious, but just in case of ambiguity, the last part of the StatusSNS data (above) is a specifier for the temperature unit being used (in this case, Celsius).

We can change the temperture reporting units to Fahrenheit using the “SetOption8 1” command:-

mqp -t cmnd/sonoff/setoption8 -m "1"

…and the next time we get a temperature status report, the figures are quite different:-

{"SetOption8":"ON"}

{"StatusSNS":{"Time":"2018-02-14T09:47:38","DS18B20-1":{"Id":"011590E534FF","Temperature":35.04},"DS18B20-2":{"Id":"031590A618FF","Temperature":83.97},"TempUnit":"F"}}

Okay, we’ve covered the same commands as we did in the “Console” article and reached the point where TASMOTA and MQTT are delivering a bunch of useful data back to us from our project board.  In the next part I’ll look at creating a shell script to automatically generate and handle that (JSON) data, so that you can actually control the relay based on temperatures.


[¹] – Commands for manipulating virtual windows from within “screen” all start with a CONTROL-A character, so to create a new virtual window you would input the sequence “CONTROL-A c”, to change the current view to the next window would be “CONTROL-A n” and to change back to the previous window would be “CONTROL-A p”, and so on.  Use man screen for more details.

Adding an Ethernet Port to your ESP (revisited)

Update @ Sat 17th Feb — The source code for this project is now available from my GitHub repository.

Update @ 8th Mar 2018 —  Currently the DHCP option doesn’t work (timeouts/WDT-resets).  The IP address of the W5500 will need to be set manually in the code (thanks to “1rabbit” for the heads-up on this issue).

A few months back I pointed readers to an article by Frank Sautter on adding an Ethernet port to the ESP32 which I found quite interesting.  It reminded me that I’d been playing around with a Wiznet wiz820io board a while back on an older PIC-based project, so I pulled it out of the parts drawer and started fiddling with trying to get it working with an ESP8266 module.  There were some signs of life, but it was so flaky that I really didn’t quite know whether I had dodgy hardware or whether my graft of the ESP8266 code from the W5100 library to the W5200 library was just crap (the latter being a very strong possibility).  It had whetted my appetite though, as I was looking for a means to interface an ESP module to my LAN as an ESP-Now gateway.  Top view of W5500 boardSo I ended up getting one of the (cheap) newer W5500 modules (the one with the yellow pin header and the “PWOER” LED label) which are popping up all over the place at the moment (click on the picture on the right to see the full-size image of the board).  The W5500 handles more sockets than the older versions of the chip and is generally recommended for newer designs (it’s a little cheaper, too).

Although the W5500 needed a little tweaking to get going, there weren’t any serious issues with either the hardware or the software and it didn’t take too long to get it working.  One issue (which is actually an ESP problem, not a W5500 one) is that the chip-select for the external SPI is actually routed via GPIO15 and, as we pretty much all know from experience by now, that’s one of the “magic” pins at boot-up/reset which changes the way that the ESP8266 behaves.  In fact there’s a pull-up resistor on the W5500 (and, as far as I know, all of the other Wiznet modules) CS line which will cause the ESP to drop into programming mode if the W5500 CS line is simply connected directly to GPIO15.  The solution to that is quite easy — put a PNP transistor buffer (configured as an emitter follower) between the two.  Emitter-Follower-PNPBecause of the pull-up on the W5500 board, you don’t need an emitter resistor, but you do need to add a base resistor of somewhere in the region of 3k3 between GPIO15 and the transistor’s base (and the collector of the transistor goes directly to ground).  Any small-signal PNP transistor, such as the BC560 or 2N3906 should work in this situation; it’s not that critical.  This fix should work for pretty much any SPI connected peripheral board …but you might have to add the emitter resistor if the target board doesn’t already have a pull-up.

The second hardware requirement is that we need to dedicate another, non-SPI GPIO as a reset driver for the W5500.  On my test board I used GPIO5.  This allows us to hold the W5500 in reset until the ESP has completed it’s own housekeeping and is ready to bring up the network connection.  So, with that addition, the pin connects between an ESP8266 and the  W5500 are:-Pin interconnects between ESP8266 and W5500

The pin numbering for the NodeMCU boards is given on the left, with the standard ESP8266 GPIO numbers in the centre column.  In addition to the data pins shown above, you need to connect ground and either +5v -or- +3v3.  The W5500 board has its own, on-board voltage regulator, so a +5v supply is okay, but sharing a 3v3 supply with the ESP8266 is a more likely scenario in our case (the data pins on the W5500 are 5v tolerant, by the way).

On the software side, I ended up using the Wiznet Ethernet Library for the Arduino 1.5.x IDE.  It hasn’t been updated in a while …but the last updates were to add the ESP8266 hooks into the code.  There are good instructions in the README.md file on how to install and use it, but –don’t– uncomment the “#define WIZ550io_WITH_MACADDRESS” line referred to in those instructions.  The normal, cheap W5500 boards do -not- have a built-in MAC address and you must set one manually in software before you can use them.

All in all, it really was quite easy to get the W5500 ethernet board not just connected to my LAN, but also talking to my MQTT broker to both publish and subscribe. Sometime in the next couple of days I’ll try to get around to sanitizing my code to the point where I can throw it up on GitHub as a simple example, but even before then, I’d say this is a safe enough purchase[¹] for anyone who wants to muck around with a wired connection to their ESP8266; you’re not going to break the bank if it doesn’t work as expected.

 


[¹] – Careful though!  If you’re reading this in mid February, it’s Chinese new year, so everything will be closed down for the next week or so …even longer delays.  😦

e-Ink/e-Paper Displays

As you may have read in a recent post, I’ve become enamoured of the newer versions of the e-Ink or e-Paper displays to hit the hobby market.  They look great and (apparently) aren’t too difficult to drive, plus their inherent ability to maintain the display when “off” looks to be a major plus for any battery-powered projects.  Waveshare 1.54" Display (courtesy of Waveshare)Unfortunately, there isn’t a whole lot of good, solid information out there yet on using these screens.  That is changing though, as the prices start to drop enough so that people can afford to buy one or two to play with, even if they’re not entirely sure that they’ll work in a given project.  One of those brave early adopters is David Watts and he’s put together a very informative video on how to interface a Waveshare 1.54″ display to an ESP8266, along with details on connections, graphics libraries to use and even a design for a 3D printed desktop stand for the completed project.  It’s well worth a look.

On the subject of the screens themselves, it’s also worth noting that versions with an attached driver/interface card (which is much easier to use) are popping up on all of Waveshare SPI I/F (courtesy of Waveshare)the usual on-line bazaars, so it’s worth taking a few minutes to check whether you’re about to buy a bare screen (with a tiny, 24-pin, flex cable connector) or the former, driver/interface card equipped version.  Confusingly, both are advertised as being “SPI” interfaces and only a check of the photos of the unit for sale will confirm whether you have a usable 8-pin socket, or just a flapping flex-cable.   One of the cheaper options is one of the Raspberry Pi “HAT” displays,  They all seem to come with a standard RPi header connector, as well as the 8-pin connector (or at least the solder pads for it) and, presumably because they’re quite popular, seem to be quite cheap, too.