Killer (ESP8266) Apps for the Weekend

Sometimes, while browsing GitHub for ESP8266-related projects, I come across a user’s page which just happens to “push all the right (ESP8266) buttons” for me.  One which I came across recently was from martin-ger and he has several projects which tickle my fancy.

Those three should keep you amused over the weekend and give you a sample of what Martin is capable of.  Definitely a page worth bookmarking!



This bandwagon is starting to get pretty crowded…

With every passing week we get another ESP8266 “killer”, but usually not quite as cheap and almost always without the same software or toolchain support that we (now) have for the ESP.

Regular readers will know by now that I’m an old Unix guy and that I’m quite a fan of the new, low-power ARM boards which are popping up all over the place, although as with the ESP8266 killers, they tend to be short on the software and support side.  Recently though, I have been impressed by the folks over at FriendlyArm, who seem to put a lot more effort than most of their rivals into making sure that a board has an actual working OS (usually more than one) before it hits the marketplace (see “Headless Server Worth Having” from a couple of weeks back for some details on the very cheap NaniPi NEO).

Nano-Pi Neo board imageSo, it was with more than just a tiny spark of interest that I noted the latest rumour from that denizen of the Armbian development team, tkaiser.  He’d found a couple of references in some of FriendlyArm’s publicly available documentation referring to something dubbed the “NanoPi AIR”.  Apparently this will be the NEO, minus the ethernet, but with an AP6212 wireless/Bluetooth module instead.  Now remembering that the pricing for the NanoPi NEO starts at $7.99, we can safely assume that the AIR will be roughly in the same ball-park.  Price-wise that doesn’t make it an ESP8266 killer, especially as FriendlyArm add (a fairly reasonable) postage charge onto their orders, but it does make it a very, very interesting alternative.

Remember that we’re looking at a fully-fledged, multitasking system here, booting Linux from an SD card with 256MB (or optionally 512MB) of RAM and with all of the GPIO broken out to standard-sized headers (no castellated, sub-millimetre spaced weirdo connections).  The board is roughly half the size and one-third/half the cost (depending upon where in the world you are and how much postage you have to pay) of the Raspberry Pi.  You can write your code in C, Fortran, Lisp, Perl, Python, or just about any other language you want (Linux has ports of pretty much everything) and be reasonably certain that the drivers for whatever hardware interface you want to use will already be available to you and, while your IOT device isn’t fetching temperature readings (or whatever), it can also be serving NTP, DHCP and DNS traffic on your local  network and running an MQTT broker, all without breaking into a sweat.

As icing on this particular cake, one of tkaiser’s areas of interest with this specific ARM processor (the H3) is tuning the system for the lowest possible power dissipation by slowing down the processor clock during periods of inactivity.  The clock should go down to about 240MHz (from the max of 1.2GHz) and my recent experience with the NanoPi M1 (one of the NEO’s predecessors) is that it will very happily run at 480MHz with no obvious indication at all  to the user that anything has changed.  This means less heat dissipated and less power used, so although the NEO and AIR are unlikely to be useful as remote sensor nodes running on a couple of AA batteries, they would be useful in situations where a higher capacity battery was available (for instance, a multi-cell lead-acid unit on a solar charger).  For mains-powered projects they’re almost a no-brainer.

A couple of dampers on this; first, as I mentioned above, the AIR is just a rumour at the moment (it might be April the first on somebody’s calendar, somewhere).  The second thing is that the AP6212 is actually a pretty expensive part in small volumes, so I could be miles off in my parity-pricing estimate.  We’ll probably find out fairly soon.