Want a new workshop?

Hackster.io is currently hosting a competition promoting IOT2020 units, with the first prize being several thousand dollars worth of lab equipment for your electronics workshop.

The IOT2020 is an Intel Quark based controller (running Yocto Linux), packaged into an industry standard, DIN-rail mountable case, designed to enable your project to morph directly into a product by providing a unit which is already FCC approved.  The main requirement for the competition is that your entry be based around the IOT2020, but the nice thing is that they are actually giving away ten of the units in the opening round, so all you need to do is submit an idea and you could win an IOT2020 to play with and also have a chance at the grand prize.

Peter Oakes (who is promoting the competition) does specifically mention ESP8266-based projects as being a prime example of where this unit might be used (as, for instance, a gateway between a local network of ESP8266 modules and the internet).

Currently there are only about seventy entries registered, so those are pretty good odds.  If you have an idea for an IOT device that you think would sell as a product, you’re not going to lose anything (other than the element of surprise) by entering.

 

 

How to do a Sonoff memory upgrade

Jonathan Oxer, over at SuperHouseTV, has been running a series of video episodes on the Sonoff product line recently and I really recommend his latest.  The theme of the video is Sonoff-specific hints and hint #1 is how to upgrade the memory chip in a Sonoff.  Jonathan does a great job of demonstrating how to remove the chip with nothing more than “a big, old, clunky soldering iron” and a screwdriver.  A picture is worth a thousand words, so you need to multiply that by whatever the frame rate of a YouTube video is.  Watch it!  It’s worth it.

Olimex ESP32 Development Board

Just in case you haven’t seen it elsewhere already, the good news for ESP aficionados today is that Olimex have announced an ESP32-based (WROOM-32) development board with a couple of novel features.

Olimex ESP32 Dev Board

The most obvious is that prominent ethernet connector.  According to the specs it’s a “fast” ethernet port, so 10/100Mbs.  The two relays are rated at 10A/250V and it’s worth noting that, from the photograph of the bottom of the board, both the N/O (normally open) and N/C (normally closed) contacts are broken out to the screw terminals.

Olimex ESP32 Dev Board (bottom)

What makes that more useful than N/O only?  Well with two relays, you now have complete control over a switched device and the existing wall switch still works as normal if your ESP32 board is powered off:-

  • The N/C relay is in series with the existing wall switch and the N/O relay is in parallel.
  • If the light is switched on at the wall switch, you can switch it off remotely by activating the N/C relay to open the series contacts.
  • If the light is off at the wall switch, you can activate the N/O relay to close the parallel contacts, switching the light on.
  • Fail-safe operation. If the power to the ESP32 board fails, your wall switch still works as normal.
  • If the light isn’t being controlled by the ESP32 board, the relays are both off, so the relays don’t draw current and your wall switch, as above, still works normally.

This isn’t by any means novel, but a lot of the low-cost ESP relay control boards out there only have a single, normally-open relay contact pair available.

Moving on from the relays, there is also a micro-SD card slot available for on-board storage, two buttons, a decently sized barrel connector for an external +5V supply and a connector for a LiPo battery, with an on-board charger and step-up converter to enable battery powered operation.

There’s a 40-pin connector, which apparently gives access to all of the available GPIO pins (the pin map for the connector is silk-screened onto the bottom of the board) and, finally, a “UEXT” connector (the ten pin socket, next to the 40-pin connector).  If you’re not familiar with the UEXT connector (and I certainly wasn’t), it turns out that it’s something which Olimex developed, are already using on many of their boards and have made available to the community as an Open-Source (as in royalty-free) standard.  It consists of 3V3 and GND power pins, TX and RX serial pins, SDA and SCL I2C pins and MISO, MOSI, SCK and SSEL SPI pins.  Now before you get too excited and start pulling all of those 30-year-old floppy disk cables out of your junk box, you should note that there’s no special magic used here; the I2C and SPI busses are still basically short-haul, on-board interconnects and you won’t be connecting remote devices over miles of (ancient) ribbon cable.  On the other hand, it is quite a neat idea to be able to plug (for instance) an LCD display directly onto the board.  You can check Olimex’s UEXT documentation for a (surprisingly long) list of their boards which already have this connector built in.

Unfortunately, although they’ve announced the price, at €22, the board isn’t actually available for sale quite yet.  According to the Olimex blog, the prototypes are in and as soon as they’ve been tested and some example code has been written, it’ll be going into full production.

Thanks to CNXSoft for breaking the news on this one.

A neat toy (but not an ESP)

Here I go with yet another not-quite-ESP-related diversion, but one which the audience of this blog this should find interesting, I hope.

A couple of weeks back I bought a cheap USB GPS dongle from Amazon.

U-Blox USB GPS Dongle

It was amazingly cheap (the Yen equivalent of $8 U.S.) and I wasn’t expecting too much, but I have a yearning to get a local reference clock for NTP set up on my local network and I thought that, if nothing else, this would be a good starting point for fiddling around with GPS before paying for (and possibly breaking) something more expensive.USB GPS dongle, antenna side  I have to say that I’m really, really impressed with this little thing.  I’m sitting in a valley with major mountain ranges to both the east and west of me (~3,000m on each side), so I have a fairly narrow view of the sky, but this little unit acquires and holds nine satellites from inside the house and about 1.5m from the window.

The second thing I did (after verifying that the unit did actually work) was to rip the covers off to verify the make and model of the receiver chip and, as you can see from the photo above, the built-in antenna covers most of the board space on the top side of the PCB (the single, other component, top L/H side, is the green, status LED).

USB GPS dongle, component side

The component side has the U-Blox G7020-KT chip in the bottom,R/H corner.  Note that there’s no FDTI (or equivalent) chip, as the G7020 has a USB interface included.

There’s a back-up battery on the board to maintain memory contents between power cycles (which, it turns out, is critical for reasonable start-up times for GPS receivers).

Unlike another (non-GPS) dongle which I bought recently‡, this unit barely gets warm to the touch and there are no ventilation slots or holes in the plastic cover.

Anyway, for anyone else interested in playing with these beasties, here are some hints to get you started:-

  • The very first time you power on this unit, it will take up to 25-minutes to locate the satellites and lock on. Apart from a very brief flash of the green LED when you first connect it, it will appear to be dead. It’s not! Just leave it connected and it will download the data it needs (the “almanac”) from the satellites it can see and eventually the green LED will start flashing once per second to show that it is now operational.
  • After that initial connection, the unit will come to ready (green LED flashing) in only a few seconds the next time you power on. This is because it saves that initial data to internal memory (with battery back-up).
  • If, on that first power-up, you don’t see a green flashing LED after 30-minutes, it’s because the unit can’t get a decent signal. Move it as close as you can to a window, or if you have a laptop, take it outside. If that doesn’t work, grab a 1m or 2m USB extension cable from your local 100-Yen shop and move your GPS dongle as far away from the computer (and as close to a window) as you can.
  • If you’re using Windows, you can get the genuine Windows driver directly from the chip manufacturer’s web site:-        https://www.u-blox.com/ja/support      -or- https://www.u-blox.com/en/support
  • The chip inside this unit is the U-Blox G7020-KT.
  • If you’re using open-source, you will probably find that your OS correctly identifies the USB device as soon as you plug it in. The application you need (as already noted) is the GPS daemon, “gpsd”. When you install “gpsd” you’ll get some additional helper applications bundled in, such as the invaluable “gpsmon” and “gpspipe”, which allow you to view the GPS data in several formats.
  • The device which you use to connect to the USB dongle will be different between various OSes. OpenBSD and FreeBSD will see it as /dev/cuaU0. Linux will see it as /dev/ttyACM0 or /dev/USB0.
  • To run gpsd you should use the “-n” option (“no-wait” – don’t wait for a client to connect before handling GPS data) and the device. So something like this:- /usr/local/sbin/gpsd -n /dev/cuaU0
  • After starting gpsd you should be able to run gpsmon (just type “gpsmon”) and see data coming from the device.
  • If you want to run your GPS dongle as a local source for the NTP daemon, you still need to start “gpsd” (and it’s important to use that “-n” option in this case). The gpsd process will automatically populate shared memory segments, which the ntpd daemon can then read to get time information (you may have to check your OS for sysctl settings for PPS to get this working). There are notes in both the ntpd and gpsd manual pages on how to do this. So far I have only managed to get ntpd to use the GPS embedded time information, not PPS.

As you can see from the photos above, the board has most of the components (including the battery and the G7020-KT chip) on one side and the antenna on the other. The green LED is on the same side as the antenna, so when you position your USB dongle, you should always have the green LED facing –upwards-. If your USB forces it to be downwards (unusual) or sideways (fairly common), you might want to buy an adapter or extender cable to ensure that you can position it so that the antenna (and LED) are pointing upwards.

 

‡ – A generic, black SDR dongle, bought for the advertised “R820T” tuner chip and specifically for receiving 1090Mhz ADS-B traffic from aircraft flying overhead (see the previous post on “PlaneSpotter”).  Not only does this thing get hot, it -doesn’t- have an R820T tuner chip at all (they use a cheaper and completely useless NC00012 tuner, which has a frequency range which cuts off at 985Mhz, so it doesn’t even cover the ADS-B band).  If you want to play with SDR (and especially ADS-B), save your money and buy a NooElec “Mini 2+” bundle (directly from nooelec.com) instead.  It has an R820T2 tuner chip, plus a temperature controlled, 0.5PPM accuracy oscillator and comes with a “starter” antenna and a remote control unit (??? don’t ask me …I have no idea why!) for $21 U.S. + $5 postage to anywhere in the world.

0.96″ OLED with an SPI interface

There’s a metric ton of those tiny, cheap, 0.96″ displays for sale out there, but one of the drawbacks is that you’re never quite sure which of the interface type you’ll be getting (the photos displayed by the vendors rarely match to the shipped product and the descriptions almost never do).  I ended up with an SPI version on my bench the other week, when what I was really after was the good old I2C version.  Oh well, how hard can this be, anyway?

Well, when you look at the back of the display there are some silk-screened instructions for what combination of resistors are used for which interface, but I have to admit that the idea of moving SMD devices of that size around without losing one on the floor, or pulling off a trace, didn’t seem too attractive to me.  An internet search found a StackExchange thread dealing with the subject and, although the procedure described didn’t look too intimidating after all, it also yielded important clues to the connections needed to have the module just work in its intended mode of SPI.  I was using a Node-MCU module, so I had pins to spare for the extra three wires, so it wasn’t really much extra effort to slap the whole lot onto a breadboard and mess around to try and get it working. OLED breadboarded with NODE_MCU I was also using Squix’s “PlaneSpotter” package as the software to test it with, as Squix’s excellent implementation of the SSD1306 driver library is claimed to be interface agnostic and should work with the SPI as well as the I2C interface (all of his current examples use the I2C interface).

The one thing that did confuse me to begin with were which of the SPI pins to connect on the ESP side; specifically the “DI” and “DO” pins from the display.  It’s SPI, so those should be the MOSI and MISO lines, right?  Err ..no!  With the help of the above mentioned StackExchange thread, I eventually cottoned-on to the fact that the display doesn’t use DO as MISO at all, it uses it as the SPI clock line, so ignore that wonderfully helpful labelling on the display connector.

The next step was working out which pins were which on the Node-MCU.  This is the first time I’ve used one of these beasties and I didn’t find its pin labelling particularly helpful, either (on the other hand, it is undeniably a nice packaging of the ESP module and USB interface components).  Eventually I got it all worked out, loaded up “PlaneSpotter” and had Tokyo to Seoul traffic showing up first try (all due to Squix’s neat programming and packaging).

Well that was the test part and now that I’ve verified that the display works, I need to move on to implementing my own, more modest project.  Before I leave you though, I’d just like to make a note of the hardware connections and minor software changes which were needed, as they might be of help to someone else.

First, here are the connections for both Node-MCU and normal ESP8266 GPIO pins for the display:-

Display NodeMCU ESP8266
CS D8 GPIO15
DC D4 GPIO2
RES D0 GPIO16
DI D7 GPIO13
DO(CLK) D5 GPIO14

 

…and here are the changes to the main.cpp file of the PlaneSpotter code.  As you can see, we just comment-out the I2C defines and add our own pin definitions below (note that the SPI pins, DI, DO and SCL, are hard-coded into the ESP8266 library and can’t be changed):-


// Display Settings
//const int I2C_DISPLAY_ADDRESS = 0x3c;
//const int SDA_PIN = D2;
//const int SDC_PIN = D3;


// 4-pin SPI Version.
const int RES = D0; // GPIO16. \
const int DC = D4; // GPIO2. - Normal ESP pin numbering.
const int CS = D8; // GPIO15. /

Next we just comment-out the init call for the I2C version and add in the call to the SPI one:-


// Initialize the oled display for address 0x3c
// sda-pin=14 and sdc-pin=12
//SSD1306Wire display(I2C_DISPLAY_ADDRESS, SDA_PIN, SDC_PIN);
//SH1106Wire display(I2C_DISPLAY_ADDRESS, SDA_PIN, SDC_PIN);
SSD1306Spi display(RES, DC, CS);
OLEDDisplayUi ui(&display);

For all of the other required local settings for this app, please refer to Squix’s notes.

 

esp-link revisited

Regular readers may remember my article on hardware implementation (and my associated balls-up) for a serial console using an ESP8266 and JeeLabs’ excellent esp-link firmware.  Well this weekend I had cause to revisit it.  Another fairly ancient, headless server (a Soekris box this time) was in dire need of an update, so I reached for my trusty console adapter.

Except (there’s always an “except”, or a “but” nowadays …have you noticed?) that the Soekris has a console which, at boot-up, defaults to a (very useful and quite speedy, for the time) baud rate of 19,200  …and my v2.0-beta version of esp-link didn’t handle that as one of the selectable baud rates.  No problem!  One of the nice features of JeeLabs’ package (which I mentioned in the original article) is that you don’t even have to compile the code; they very conveniently provide the pre-compiled binaries on their site and, because I already have esp-link running on my ESP, I don’t even need to reach for the USB cable and FDTI adapter,  I can just flash over the air using the built-in utility.  Except…

Instead of doing a “make flash”, I decided to download the new firmware package, which consists of the binary files you need, as well as a little shell-script called “wiflash”.  Wiflash is a little helper script which basically wraps “curl” to do the heavy lifting.  You just give your ESP’s hostname (or IP address) and it’ll go off and do the actual programming for you.  Except that in my case it came back with an error message (from curl):-

HTTP server doesn't seem to support byte ranges. Cannot resume.

…which seemed a little strange, as at that particular point, all it was doing was fetching a 9-byte long file, /flash/next, which contained the plain-text name of the area to program this time round, “user2.bin”, and I wasn’t requesting, or expecting it to have to resume anything.

The curl manual page doesn’t seem to elaborate on whether the -C (–continue-at) option is a default or not, but it does say that prefixing option names with “no-” will disable them, so it seemed worth trying as a quick fix (remembering that today’s objective is to upgrade a system, not debug curl or the esp-link web server), so I simply modified line #82 in wiflash from:-

next=`curl -m 10 $v -s "http://$hostname/flash/next"`

to:-

next=`curl --no-continue-at -m 10 $v -s "http://$hostname/flash/next"`

…and blindly hoped that all of the other calls to curl in the script would just work.

As it turned out, work they did and that one simple change was all that was needed (a quick trip to the “issues” tab on the esp-link git page confirmed that I’m the only one, so far, to have seen this issue, so I’m willing to  believe it’s just a quirk of my fairly ancient OS combined with the old, original v2.0-beta version of esp-link already on the device).

Anyway, a minor problem solved and a nice, shiny, new version of esp-link installed on the ESP, with lots of new features and (almost! ‡) all of the baud rates you could ask for.

Screen shot of esp-link v3 console page

Note that the baud-rate and parity/stop configurations are now on nice, drop-down menus and there’s a separate console input box, as well as selectable history for all of your previous commands.

In addition, on the side panel we have new pages for “WiFi Station”, “WiFi Soft AP”, “Services”, “Upgrade Firmware” and “Web Server”.  While some of that information was available with older builds, the new pages give an uncluttered, neater feel to the application and, for most of the pages, there are new additions to the existing configuration options, giving you, for example, the option to set up a server and timezone for SNTP services.

All in all, a worthwhile update for a very useful utility and, while we’re here, I notice that JeeLabs and Thorsten von Eicken have created a tiny (and much neater) hardware solution than mine, specifically for programming one of their new products.  Neat!

 

‡ 74880 anyone?  (Yes, it’s that annoyingly non-standard squirt of debug info at ESP power-on)

Another Sonoff Family Member…

…and another Open Source package to run it.

I only recently noticed that ITEAD Studios have added a light switch to their Sonoff line-up.  Sonoff Touch from ITEADThe switch comes in either EU or US single-gang switch-plate sizes and has a glass front panel with a capacitive touch switch.  Inside there’s an ESP8285 module providing remote services via ITEAD’s EweLink cloud application.

There aren’t too many hardware details available on the Sonoff Touch at the moment (what sort of PSU is utilized, or even whether it’s a relay or a triac based device), but people have already started hacking it (no doubt spurred on by a statement in the comments section of the product page that this device “can’t be reprogrammed”).  David Pye seems to be first out of the gate with his (PubSubClient) MQTT implementation; not just identifying GPIO0 as the pin connected to the touch-switch, but also providing short write-ups (with photos) on how to prepare the device for programming, configuration and usage, but also providing bonus “long-touch” and “short-touch” modes in his firmware.

Note that, unsurprisingly, the Sonoff Touch requires that a neutral lead be available in the existing switch box, as well as the switched live lead.  This is something you need to check‡ before ordering a bunch of these (it’s very common for only the live lead to be available).

David’s additional switch handling looks like it might open up quite a few possibilities:-

  • Add an on-time limit for specific lights.
  • Control actual on/off based on time of day.
  • Control on/off by ambient light level (assuming you have MQTT capable sensors).
  • Put unit into OTA mode (ie:- limit reprogramming to those with physical access).
  • Use “long-press” to signal MQTT to switch all controllable lights in room on/off.
  • Additional ten-second press mode for all controllable lights in house on/off.

Seems like you could have tons of fun with this.  Nice one, David!

 

Hint – Don’t check a bathroom or toilet light switch and assume that all of the other switches in your house will be the same!