Category Archives: ESP8266

Debugging ESP8266 units remotely using Jeelabs esp-link firmware…

I was hoping to be a little further on writing up and making video of my solar energy project, but a blown power steering pup in my Expedition left me stranded for a couple of hours on Tuesday night, and I’m still scrambling to get some of my intermediate goals up to date. But I did get some time to at least accomplish one of my goals for the week, and I thought I would share.

If you are “old school” like me (which is really just a nicer way to say “old”) you probably do a lot of your debugging with simple print statements. In the case of embedded systems, this are usually routed to a serial output, perhaps that is used only for that purpose. My solar satellite project is no exception: it spews a fair amount of informational data to its serial port as it goes about its business, mostly help me incrementally develop and test modules in the system.

But in the case of my solar project, I eventually want to deploy this system in a location where I won’t have any simple way to monitor the serial output. For a month, it sat on my patio, and being entirely powered by a small solar panel and battery setup, it didn’t seem like stringing a long serial cable out there was a good idea. I could of course rewrite the core of my system to include the ability to log serial data to a socket, and then listen for connections. But this adds a lot of complexity to my relatively simple application, and none of it is very interesting. I’ve also been thinking of experimenting with using other micro-controllers which may not have wireless capabilities of their own, and being able to debug (or reflash) those via wireless, and then perhaps removing the wireless logging once the system is working seemed valuable.

So, the solution would be to use a second separate wireless module that could monitor the controller’s serial port, and then do all the magic itself. And luckily, somebody has already done all the hard lifting, so there is already firmware out there to do it (and a lot more).

JeeLabs esp-link Wifi-Serial Bridge

For my test, I dug a second WEMOS D1 Mini module out of my pile, and flashed it using the directions for the 32Mbit module. I then configured it to use station mode, attached it to my home network, and then did the bare minimum set of connections: connected 5V and GND from the first module to the same on the esp-link module, and then connected RX/TX to TX/RX. And booted the system.

Worked like a charm. I could either use telnet or nc to connect directly to port 23 on the module, and you’ll be able to interact with the serial port on the target board. It also hosts a small webpage with an embedded terminal module (much like the Arduino Monitor from the Arduino IDE). This enables you to (for instance) toggle the reset on the target board (which I didn’t connect, but which could be enormously useful).

I’ve barely scratched the surface of the functionality provided by this software. It can be used (for instance) to provide WiFi services to microcontrollers without any WiFi hardware of their own, at a very inexpensive price. And of course I could choose to remove the module once I’m done with the need for debugging. Very versatile.

If any of this sounds good, check out their page.

Fun (and a question) with a solar energy project…

Yes, it’s me, back after a far too long hiatus. Sometimes life intervenes, and you just have to reset your priorities. But rest assured, the geeky stuff that I used to work on and chronicle in my blog continues, and on this long Labor Day weekend, I thought I might mention a project I’ve been working on.

Long time readers of my blog may remember that I experimented with using a Raspberry Pi and a Raspberry Pi Camera module to get pictures of my hummingbird feader. Here is a refresher in case you don’t remember or didn’t see it. But at the time it was just a prototype. In particular, I never constructed a permanent setup for it. It got put back into a box, and I didn’t think about for a while. Over the last year I had major construction in my back yard, replacing a retaining wall, and our feeders were down for a long time. But that ended, and I recently started to get a tiny amount of free time. So, I thought that it would be fun to try to make a more permanent version of this project.

But I decided to do a bit more. I decided that what I wanted to do was to create a small solar powered “pod” which could be used to hold the Pi, and which could be reconfigured for other uses.

So, I bought a few goodies to help me along the way:

  • Allpowers 20A Solar Charge Controller I didn’t have to go with a charge controller for this project, but I thought that I might as go with one a bit beefier than I needed for this project.
  • ML7-12 7.2aH SLA battery I just wanted an inexpensive SLA battery to go with my charge controller.
  • A Newpowa 10W 12V solar panel I wanted something a tiny bit bigger than the small 6V panels that you commonly see, and again, this one was modestly priced.

    • As it happens, this system is probably not really enough to run an Raspberry Pi with a camera for 24/7, even with pretty good sunshine during the day. But I wasn’t sure how far off it would be, and how efficient the charge controller would be.

    If you’ve never set up such a system before (I hadn’t) the basic idea is the charge controller has three sets of terminals:

  • the solar panel
  • the battery
  • the load, which is regulated 12v output to drive whatever it is you are powering

The basic idea of the charge controller is to make sure that the voltage and current from the solar cell are efficiently applied to the battery to charge it. The charge controller that I bought is also supposed to prevent over discharge by disconnecting the load from the battery if the voltage drops too low, and which also is supposed to prevent overcharging.

So, I thought I would test it out.

Instead of using my Raspberry Pi, I dusted of a WEMOS D1 Mini, my preferred < $5 ESP8266 module. To it, I connected a pair of INA219 modules, one that would read the battery and voltage directly from solar cell, and the other that would do the same for the circuit that leads to the battery. The ESP8266 would take all these measurements once a minute, and would upload them to the Adafruit MQTT server. You could view them directly from their dashboard, but I downloaded 24 hours of data, and made some graphs using matplotlib. The sensor data from the solar panel are in blue, whereas the data from the battery is in green.

Some of the data makes sense to me. Looking at the current data, you can see that the graph starts with no current from the solar panel, as it is starting in the dark. We see that there is a current running out of the battery (it’s discharging) at a rate of somewhere around 70mA. But as the sun rises, we begin to get current from the solar cell. It’s current climbs, and the current into the battery falls, eventually reversing as it begins charging the battery. That all seems great.

But here is what confuses me. If we look at the voltage, sunrise occurs around 15:00 UTC and the voltage begins to climb. It goes up, and up, and up. I believe that I had the “overcharge” setting to be around 13.7v. I would expect that as the solar panel becomes more brightly illuminated, it would pass that level, and I would expect the charge controller to reduce the amount of current to the battery. But we really don’t see that. The current stays quite high, eventually topping 0.5A at 17V, or about 8.5w. This doesn’t seem good to me. The voltage on the battery terminals gets quite high (topping 17v) and I’m worried that it might be overcharging. I’ve double checked my hookup, the settings on the controller, and I’m baffled.

Can anyone provide any insight as to where my understanding might be going astray?

I’ll eventually write up a complete description of this project, so if any of this doesn’t make sense and you have any questions, feel free to leave comments and questions, and I’ll try to explain further. Eventually the code and other bits of information will show up here.

Thanks everyone….

The ESP32 vs. the ESP8266

Over the last year I’ve spent a small amount of money and a larger amount of time accumulating a bunch of development modules from banggood. This began mostly with me getting some spare Arduino modules cheaply. Whereas an official Arduino might cost you $25 or so from Adafruit or Sparkfun, you can get a Geekcreit clone of the same board for about $4 including shipping from China.

But you can import some other fun things besides Arduino.

A year and a half ago, I had received my first ESP8266 boards based upon the Arduino form factor. These would cool boards, based upon the ESP8266 wireless module from Espressif. The cool thing about these boards is that you can use the Arduino environment that you might already be familiar with to program, but the controllers themselves are significantly more powerful, and include wireless access. I have a few of these Arduino formfactor boards around, but they turned out to be less helpful than I would like, as the pin outs are moderately different and few shields are compatible. So instead, I’ve accumulated a fair number of ESP8266 boards which are based upon the format called “Wemos D1 Mini”:

The Wemos D1 Mini

I’ve been having a lot of fun with these.

But in the last year, Espressif has started shipping a new chip, the ESP32, which has a number of cool new features, but which most notably include Bluetooth Low Energy (BLE) and a dual core processor. At first, these chips were fairly hard to get, and modestly more expensive, but now the pipelines appear to be full, and the necessary software support is in a pretty good state.

Banggood carries a good basic module for just $7.

And, you can get a module with an OLED module premounted for about $11.

I’ve had these ESP32 modules lying around for a while and haven’t done much with them. I thought today that perhaps I should dust them off and port my satellite prediction code to these modules, and make a tiny little gadget which could sit on my desk and notify me (maybe even via bluetooth on my phone?) of upcoming passes of the ISS or other amateur satellites.

I had prototyped such a thing using a small OLED display on the ESP8266, and had the code lying around, including the graphic display which is the same sort that is on my ESP32 board.  Here’s a video I made of the old code.

I was hoping that it would be straightforward to port the code to the ESP32. Sadly, a few minutes of work revealed that the interface to WiFi capabilities on the ESP8266 and the ESP32 were not entirely compatible. In particular, most of the networking on the ESP8266 was being driven by a series of callbacks which aren’t implemented (as far as I can tell) on the ESP32. I also used an NTP client library on the ESP8266 which might be unsupported on the ESP32.

So, it appears that I’ll need to do a bit more digging to make this work.

I’ve also begun to ponder that if the Arduino code between the ESP8266 and the ESP32 is less easy to keep compatible, then maybe I should simply not use the Arduino framework at all, and use the lower-level ESP-IDF framework for programming. It’s not clear how hard it will be to port the necessary OLED drivers (or what support already exists) but I might give it a try.

Ultimately my goal is to implement some code for the $11 module that wakes up, finds open or predefined Internet access, and synchronizes its time with NTP. It then contacts celestrak.com and downloads current orbital elements for the satellites I’m interested in, and then uses my satellite code to predict the position and passes of each satellite, displaying them on the tiny OLED display.

Hey, it sounds like fun. I’ll make the code available via github when I have it sorted out.

If this project sounds interesting, drop me a note on twitter (@brainwagon) or leave a comment.

pinMode v. digitalWrite: what’s with this use (abuse?) of internal pullups?

This post is the kind of round about post you get first thing in the morning.   I’ll get to the title question at the end.

This morning, I was interested in doing a tiny bit of tinkering. I had found one of these 4 digit 7 segment LED displays while digging around for something else. You can get these modules for about $2.50 from banggood, and potentially for as little as a buck on eBay.

A little over a week ago, I was tinkering with a WeMOS D1 Mini board that I had acquired, and decided to port my Plan-13 library to it. Long (long long) time readers may remember some years ago that I wrote this code to predict the position of satellites, first in Python, but then ported it to C and had it running on the Arduino as part of my ANGST (Arduino ‘n Gameduino Satellite Tracker) project. But that project had a number of shortcomings:

  • It was fairly complicated, and required a number of additional add-ons to work.  I used the Gameduino to generate graphics, had an external RTC and EEPROM to store orbital data, and used an optical shaft encoder to move around.  Yes, it was attractive and fun, but not cost effective.
  • It had no easy way to update orbital elements.  You had to connect it to a PC and reprogram it with new orbital elements each time you needed an update.

But these WeMOS boards are built around the ESP8266 modules, which have a number of advantages:

  • They are based around an 80Mhz 32 bit processor, instead of a 16Mhz 8 bit processor.
  • They have 4Mbytes of flash memory.  You can easily configure some small part of that to serve as a miniature file system, ample to store orbital elements without any additional hardware.
  • They are cheap: around $5.
  • And most intriguingly: they have WiFi. 

So, I worked on the spiritual descendent of ANGST.   Using the platformio system I moved a copy of my Plan13 library to a new project, and started tinkering.   As of now, the project:

  • Wakes up and connects to my local WiFi network
  • Establishes a connection to an NTP server, so I can get the time
  • Connects to Celestrak and downloads the latest orbital elements for the ISS
  • Predicts the next three passes from my home location
  • And then enters a loop, predicting the sub-satellite latitude and longitude, its location relative to some major world cities, and if it is above the horizon, then the azimuth and altitude of the satellite.

Here is the current data as I write this:

But the one thing it did not have until this morning was an external display.  Hence, the TM1637, and a little tinkering.

Time is in GMT, but eventually I will also have it have the option of using local time (it is more convenient to use GMT for the satellite computations.)

To get this to work, I could have dusted off the work to drive the similar TM1640 based displays that I used in another project, but I thought that I’d use a standard library instead.   The platformio system has a pretty nifty library manager, so I searched for a library, found one (cool!) and it claimed compatibility with the ESP8266.  Neat.

So I read some of the example code, patched it to output the time in the main loop(), and tried it.

It didn’t work.

I double-checked connections.

It didn’t work.

I tried their example.

It didn’t work.  The displays remained dark.

Grumble.  I opened up the code and tried to see what was going on.   It didn’t take me too long to figure out what was going on:

Here is a link to the code, and a screen grab of the offending lines:

Link to the source on github

It’s not exactly my first rodeo, so I was immediately suspicious when I saw that the initializer set the mode for the two pins to INPUT, rather than OUTPUT, but then immediately wrote to them.  That doesn’t seem right, does it?

Well, this isn’t even my second rodeo.  I know that Arduino’s ATMega328 processor has internal pull up resistors, and I’ve seen odd code which used pinMode to swap back and forth between high and low, not using pinMode.

But the ESP8266 (thought I) doesn’t have internal pull ups.   I’m pretty sure that’s true, but I never got to verify it, because all of a sudden, with no change whatsoever, my program started working.

I hate it when that happens. 

It’s been that kind of a week.

But it made me think about how this works.  Here is my guess, and I’d appreciate corrections.

During initialization, it sets pinMode to INPUT, and writes a LOW value to the data pin.   Even though we’ve written a LOW, the pin is pulled HIGH by the action of the (external) pull up resistor.

When the driver wishes to shift the output pin to LOW, it uses pinMode() to shift the type for the pin to OUTPUT.   When it wants it to be high, it sets pinMode() to INPUT.

I find this odd in a couple of ways:

  • It is not any shorter or more efficient than using digitalWrite.
  • It is certainly no clearer.

Is there something I’m missing about why you would code this stuff this way?

Of course, I wouldn’t have dug into this code at all had I not had a mysterious (and fleeting) failure at the beginning, so I am not sure how it really matters.

Addendum:  While I was typing this, the ISS did a 65 degree elevation pass which was captured thusly.  I only then noticed that it was producing duplicate messages for each five second message.  Must have goofed when I installed the code to blink the clock’s “colon” segments.  I’ll get it sorted later.

 

How making an ISS clock turns into researching an optimization problem involving spherical Voronoi diagrams…

A few years ago, I got seriously interested in amateur radio and satellites. I would often haul out a small Yagi antenna and my trusty Kenwood TH-D7A and try to talk to other hams by bouncing signals off the various satellites which acted as amateur radio repeaters. During that time, I wrote a Python version of G3RUH’s Plan-13 algorithm for predicting satellite locations. Eventually, I converted that code to C++ and made an Arduino/Gameduino version that I called “Angst”.



But there were a number of problems with it as a general project. Most notably, it utilized some special hardware which made it more expensive than I would like, and it required an external display. I suppose I could have found a small composite display, but one serious issue remained: there was no simple way to update the orbital elements that are used to predict the satellite locations. The ISS is particularly problematic, since it is in low earth orbit and frequently fires its engines to boost it to a higher orbit, which is not something that can be accounted for statically.

But in the years since I did that project, the ESP8266 has taken the world by storm. Not only is it cheap (I got some WeMos D1 Mini clones for less than $5 shipped from China) but it is faster (an 80Mhz 32 bit processor) and most importantly includes WiFi.

For the last couple of days, I’ve been tinkering my old Plan-13 code together with some new code written especially for the ESP8266 to create a “clock” that will automatically tell me the position of the ISS and details about the next pass. The nice thing is that since the ESP8266 has WiFi, it can update itself automatically. Right now, I have code running that contacts celestrak.com, finds the latest orbital elements, predicts the next three passes, and then enters a loop where it shows the current position of the ISS every five seconds. Right now, it just echoes that information out on the serial line, but eventually I’ll get a tiny TFT or LED display to display the live information:

But just seeing the latitude and longitude of the “sub satellite” point didn’t really help me know where the satellite was in its orbit. Sure, I could (and probably will) make a little graphical display for the gadget sooner or later, but I thought it might be nice if I could have it tell me when it was passing close to certain major cities. To give this a try, I found a list of world cities and their coordinates and population, and selected the top fifty cities of the world and within the United States (make one hundred cities total) and then when I do a prediction, quickly compute the distance and bearing to each of the cities and display the closest one. And that works, and doesn’t take too much time. You can see in the run above that the closest city was Honolulu.

But, I noticed a problem.

If you imagine that the earth is a sphere, and imagine that the each city is a point on the surface which you can think of as a seed. If you collect all points on the sphere that are closest (in the great circle) sense to that point than any other seed, you end up with the globe being divided up into a number of regions, each bounded by arcs of a great circle. If you took the same computer and math classes as me, you can recognize this as a “spherical voronoi diagram”. You can read about them here where I swiped the illustration from. Here is the Voronoi diagram of the earth with seeds at each of the World Airports:

You’ll notice something: the regions are widely varying in size. If I had loaded my ISS code with these locations, it would spend a lot of time talking about how it is thousands of miles from some remote airport in the middle of the Pacific, but when it was flying over the United States, it would rapidly shift from region to region. Indeed, because population centers are often close, it might be fairly rare for it to be closest to New York City, even though it is perhaps an obvious landmark, more obvious than the smaller ones that surround it. It might also be the case that if you have two population centers which are fairly close to one another, that approaching from one side would be masked by the other city.

Ideally, we’d like a collection of cities which:

  • are well known
  • divide the globe into a number of Voronoi regions which are nearly the same size
  • and where shape of the Voronoi regions are not too lopsided, so the cities are near the center of a roughly circular region

I haven’t figured out how to do this yet, but I’m betting that I am going to use some kind of genetic algorithm/simulated annealing approach. Stay tuned.

Simple tests using the WeMos D1 R2…

I didn’t have a ton of time to tinker when I got home, but I did play a tiny bit more with the WeMos D1 R2. I got it mounted on an old breadboard that I had previously used for Arduino experiments, and then tried reflashing it with new, fresh NodeMCU firmware that I built on the cloud. That did not result in success, but I’m willing to bet that was because of something stupid I did, although what precisely that may have been is still a mystery to me. But I then dusted off some old “clock” code that I wrote for the Arduino, and tried a quick port to the WeMos. Several of the libraries that I used on the Arduino (RTClib and TimerOne) were not supported on the ESP8266, so for the moment it’s not a real time clock: it just counts in seconds, and uses the Ticker library instead. But in the span of fifteen minutes that I eeked out just before bed, I got it working:

IMG_0036

Pardon the poor quality snapshot against all the clutter on my desk.

So far, I’m having fun with the WeMos. I will probably a sketch which uses the WiFi next, and perhaps the MQTT framework.

New WeMos D1 R2 boards have arrived…

wemosI just got a trio of WeMos D1 R2 boards from Banggood this morning. I haven’t had a chance to do anything with them yet, other than power one of them on and check it for basic function, but I thought I’d give a brief review.

For those of you who maybe haven’t been tracking the ESP8266 based boards, they are basically a small 32 bit processor which run at 80Mhz and include WiFi. What’s really astonishing is how cheap they are: simple ESP-01 boards are available for around $3. These super cheap boards don’t have a lot of expansion pins, and are a little bit of a hassle to program though, since you’ll need a FTDI or similar serial cable.

The WeMos D1 R2 takes one of these modules (the tin package to the right) and mounts it with all the necessary interface logic to interface to USB. When I plugged it into my linux box, the following messages showed up in the output to “dmesg”, indicating that it had connected it to the serial port ttyUSB0:

[48095.058498] usb 1-3.3: new full-speed USB device number 7 using ehci-pci
[48095.186475] usb 1-3.3: New USB device found, idVendor=1a86, idProduct=7523
[48095.186482] usb 1-3.3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[48095.186485] usb 1-3.3: Product: USB2.0-Serial
[48095.191571] ch341 1-3.3:1.0: ch341-uart converter detected
[48095.251692] usb 1-3.3: ch341-uart converter now attached to ttyUSB0

Then, I ran “sudo screen /dev/ttyUSB0” and connected to it. It was booted into a custom build of the “nodemcu” firmware, which runs the open source language “lua”. You can read the documentation and figure out how to access many of the peripherals and libraries.

The quality of the boards seems quite high. One thing to note is that while the pin layouts and physical form factor of the boards is identical to the Arduino, the ESP8266 board supports much fewer pins. There appears to only be a single analog input, and the labeling of the digital “D” pins are somewhat odd, and it appears that multiple pins may be connected to the same input. It also appears that there are a different set of labels on the bottom of the board, which is truly confusing.

I’ll dig in a bit more when I have some time and figure out what the deal is.

Here is the link to the Banggood page for them. I found a 15% off coupon code “BG15%OFF” using the Honey Chrome plugin, so the cost for three shipped was about $16.

Ordered some ESP8266 boards in an Arduino form factor…

r2_1The ESP8266 is an amazing little processor: cheap and capable and (most interestingly) WiFi enabled. I have some of the older “nodemcu” boards that I got for about $7 each, but there are newer alternatives that include up to 4M of flash memory, and a variety of interesting form factors.

I noticed that WeMos was producing these boards which nominally have the Arduino Uno form factor. With a 15% discount coupon from banggood.com, I got three of them on order for under $16. I’ll let you know how they work out. I’m normally not a fan of the classic Arduino shape, but I do have a number of 3d printed cases and bumpers that can be used, which makes them relatively easy to mount and wire up.

If you want to program the ESP8266, you might try using platformio, which makes it easy to use both the native SDK as well as a simpler Arduino based framework. It also supports a number of other embedded architectures, including the Arduino, but allows you to use your own editor and the like to build and organize your code. Worth looking at.

The ESP8266…

I’ve been quiet lately, but mostly because what tinkering I’ve been doing has been relatively limited in scope. But one thing I have begun to play with a lot are various tiny development boards based upon the Espressif ESP8266 WiFi chip. I’ve mentioned them a bit before, but I’ve made some progress since then (and the platform has as well) so I thought I would give you an update.

51oc+lvXC3L._SX300_First of all, the hardware. There are lots of different development boards which use this chipset. The smallest and least expensive is the ESP-01, which probably costs around $3.50 if you look around, maybe even cheaper via eBay. You’ll pay about $7 or so from Amazon or the other major dealers, but companies like ElectroDragon have them for half that. The ESP-01 is really small, but not very breadboard friendly, since it has its 8 pins in a 2×4 array. They also have a fairly limited number of GPIO pins: notably, two (and GPIO 0 needs to be able to be pulled low to start the flash bootloader).

You can get a plethora of other modules (popular ones are the ESP-12 surface mount modules) that bring more pins to the output, but I wanted something with the ability to be put in a breadboard for experimentation, so I stared at three different modules:

  • The NodeMCU which I purchased from Electrodragon. This was the first version of this board, which has a couple of quirks: it’s wide, almost takes up the entire width of the breadboards that I have, which is kind of annoying. It also has a yellow soldermask with white lettering, which is pretty difficult to read, even with bright light and magnification. And, it uses an offbrand serial/USB chip which is supported under Linux, but might require driver downloads if you have Windows or Mac OS X. I’m told that their new version fixes that: it’s narrower because it is based upon an ESP-12E module, it uses the slightly more common CP2102 chip for serial/USB and as a bonus, it doesn’t require you to hold down the rest key to reprogram. I don’t have one of those yet, but it seems like a pretty nice little module.
  • The Adafruit Huzzah board is similar to the ElectroDragon, but has a couple of nice changes. First of all, it’s a product of Adafruit, and I like to support companies that actively support user communities. It’s similarly small, but has much nicer labels that are reasonably easy to read. Unlike the ElectroDragon board, it has just a raw TTL serial connection (six pins on the end) so you’ll need a USB/Serial cable to talk to it and program it. Luckily, this design has included circuitry to change the levels of the TX/RX lines to be compatible with 5V programming cables, which are a bit more common. Note: there is no level shifting on the other GPIO pins. The board comes shipped with a couple of rows of header pins you have to snap off and solder in place yourself. I would have liked it had they included a 6 pin right angle set too: when you solder in the programming pins, they are pretty close to the reset button which you need to hit fairly often, making them right angle would have helped. It comes programmed with the NodeMCU firmware, which is based upon the Lua programming language, which is a compact programming language that has gained some popularity in the game world. More on that later…
  • The Sparkfun “Thing” board is a similar board which is a bit more expensive ($16) but has some additions that make it attractive. Most notably, it has an on-board LiPo battery charger and power supply, which means that if you wanted to do something battery powered, this might be a good way to go. Like the Huzzah board, it needs an FTDI cable, but it does NOT have levelshifting, you should use the 3.3V programming cables. I don’t have one of these yet, but I probably will soon. It should also be noted that Sparkfun also has a $15 WiFi Shield that you can attach to the Arduino, which is basically has the same brains, but put in a formfactor that can easily attach to an Arduino. Very nice.

Out of the box, each of these boards except the Adafruit Huzzah supports the “AT command” firmware. If you are as old as me and remember the days of the Hayes Modem, you might remember issuing AT commands to the modem to get it to dial a remote BBS. This firmware works kind of the same way: there are a bunch of commands which begin with AT that allow you to connect to local WiFi networks, establish network connections, and send and receive data. If you have a project which uses the Arduino (or almost any other small micro like the Teensy) that you want to connect to the Internet via WiFi, using one of these modules with the AT command firmware might be a reasonable way to go. You merely attach the serial port on the ESP8266 board to your Arduino, and then you can send commands to it and receive data back. Very cute.

But the system itself is more powerful. The processor on the board is surprisingly capable: it’s a 32 bit processor, running at 80Mhz, with 64 K of instruction RAM, 96K of data RAM, and 64K of boot ROM. It has 9 GPIO pins, and can do I2C, SPI, PWM, and even has a slightly odd ADC channel (max voltage 1.8v). And, what’s pretty neat is that the manufacturer has done quite a bit to encourage people to program them. They release a set of SDK libraries which are reasonably complete, and lots of people have starting writing their own programs in C/C++. When used this way, the boards may not even need a separate microcontroller like the Arduino: it can do all the work itself.

I’m not going to explain all the details here, but you’ll need a compiler and a tool for downloading code to the ESP8266. There are several ways that you can do that:

  • I like to use PlatformIO, which supports ESP8266. If you are interested in doing code for embedded development boards, check out platformio. I’ve mentioned it before, and I’m super glad that the ESP8266 is supported. Basically, it’s a simple command line shell that enables you to ignore a lot of the download/compile/configuration of the tools you’ll need. You simply tell it to build a project for the ESP-01 with the command “platformio init –board=esp-01” and it makes sure that you have all the right libraries/compilers/utilities. It also installs the Arduino framework for Espressif, which means that if you are used to writing Arduino code with the setup/loop structure, you can write code the same way for the ESP8266. Earlier last week, I used this to code up a simple sketch which took temperature readings from a DS18B20 1-Wire temperature module, and upload it to the phant.io data server on data.sparkfun.com. It’s been running for a few days, and if I pull down the information, you can see how the temperature in my living room has been varying…temp
  • You can use ESP8266 support in the Arduino environment. Modern versions of the Arduino software support installation of third party packages that allow you to use the Arduino IDE with third party platform packages. I haven’t tried this, but this is probably the easiest way to get into programming the bare metal.
  • You can use pfalcon’s Open SDK. I think this is a tiny bit misleading: it’s really just an easy way to build the necessary cross compilers: the SDK is still the no-source binary blobs that Espressif sends you. I also had some difficulty getting this to work properly on Mac OS X. But if you want to recompile the “nodemcu” firmware from source, you’ll need this.

There are a couple of issues which seem to be different between the various boards as well. Most of them require that you pull the GPIO 0 pin low (tie it to ground) to reflash the chip. On the ESP-01 boards, you usually do this by moving a jumper to tie it low, then powering up the chip. On the NodeMCU boards, they have a nifty little button, if you hold it down before starting programming, it will do the right thing. The Adafruit Huzzah board is a little bit odd, you hold down the GPIO 0 button, and while holding it down, click the RESET button and release it. I understand that the Sparkfun boards might actually use the DTR (or some such) pin on the programming cable to do the switching for you, which means that it can do so without button pressing. Whatever board you get, check documentation online and see what you need to do to make it work.

Another issue is labelling of pins. If there is one thing that Arduino got right, it was that if you use the pin number which are printed on the board to identify each pin, you’ll be fine: the table which converts between those numbers and the proper port/offset is well handled, and things mostly just work. On the ESP-01, there are simply no labels. On the NodeMCU, many of the pins are labelled D0-D7. On the Adafruit, pins are labelled with the underlying GPIO port numbers. But if you use those numbers in a sketch, imagining that something labeled pin 16 should enable you to call it pin 16, you’d be mistaken. And, it’s far from clear to me that boards do this at all consistently: you might need to think really hard to find out what the mapping is, and it might vary (I’m pretty sure that the NodeMCU hardware and the Adafruit Huzzah have different mappings, so the code will have to be different to address the same pin.)

All that being said, the ESP8266 in its many forms is a very cool little processor, all priced at a pittance. Worth exploring. I’ll have more information on projects as I move forward on them.

Weekend Update: Maker Faire, new gadgets, and I ground myself…

Greetings readers. I’m hopefully wishing there is still more than one.

This weekend was the Bay Area Maker Faire 2015, the 10th incarnation of an event which has become increasingly (even frighteningly) popular. I’m tempted to channel Yogi Berra, who said “Nobody goes there. It’s way too crowded.” Anyway, I got out of my house around 9:00AM, with the plan of parking at one of the offsite parking lots and shuttling in. It took me about an hour to get to the Oracle lot on 10 Twin Dolphin Drive, and there were already probably six or eight busses lined up, but probably a thousand people lined up as well. As it happens, it took slightly more than an hour to make it onto a shuttle, drive in and enter the gates. Bleh. Not the most fun, but I had a good nights sleep the night before, so I was mostly in good spirits as I entered the park.

It was very crowded. I was by myself, so I just started wandering. When I go to these things, I am mainly looking for three things:

  • Projects that inspire new projects.
  • Cool new products, especially inexpensive dev boards and gadgets for future projects.
  • Cool artwork that I haven’t seen before.

Sadly, I didn’t see a ton of projects that made me think of new projects, but there were a couple. I had a nice chat with Ben Krasnow who brought some low-tech versions of his excellent rheoscopic coffee table, which were just plastic cells that rotated on a lazy susan. You’ve probably seen identical gadgets in science museums. Fluid flow is always interesting. He said the instructions were already on the Make Magazine site, but I forgot to copy the url, and didn’t find it. He also said it would be in the print edition sometime soon.

I had a nice chat with Erin Tomson of Modulo Labs LLC. She’s a former Pixar colleague, who has gone off and created Modulo, a set of pluggable programmable modules that can be used to assemble modules in a tiny, secure network, without the hassle of routing jumper wires on breadboards. (In fact, a system like this would have prevented a lost hour of my time tonight, I’ll tell that story below.) It’s a very slick little system, and I’d like to see something like this take off. I can particularly see this as useful in education.

Check out her Kickstarter video.

I particularly like optical gadgets like telescopes and microscopes. My buddies Rich and Dave from the Chabot Telescope Makers Workshop were there, grinding away and answering questions about telescopes. Nice to catch up with them. They said that quite a few people came up to them and asked “So, you guys sell telescopes?” Sigh. This is the Maker Faire. If you are in the North Bay and want to learn how to build a telescope, click on the link above, and think about attending one of their free workshops (every Friday!).

I like projects which reuse camera phones, and this microscope project seemed pretty cool. They had a little gadget that allowed you to swap out three different lenses to get different magnifications. Their system seemed pretty cool, but the basic idea is pretty simple (in fact, it’s basically a version of Antonie van Leeuwenhoek’s first microscopes, but instead of holding it close to your eye, it’s held close to your cell phone, which can use nifty features like zoom and exposure adjustments, and can of course record video and stills. I should design such a gadget myself.

I also had a nice chat with Alan Yates who was demonstrating some “Lighthouse” technology that he’s been working on at Valve. The basic idea is to create a set of “beacons” that can be scattered around an environment, and a sensor that can (for instance) be mounted on a VR headset and can be used to figure out the position and orientation of the headset with high accuracy and low latency. I don’t have a link for this work yet (did I miss it, Alan?) but when I do, I’ll try to update it.

That was kind of it. I did poke my nose into various people experimenting with aquaponics, which I find interesting. I had a brief chat with the creators of Chip, the $9 computer currently on Kickstarter (I hope to have more information on that soon, stay tuned.) I didn’t spend much time in the “Dark Room”, the noise and flashing gives me a headache. I did spend some time looking at the various gardening and bee keeping exhibits.

And, I did pick up some new gadgets. Here’s a short video of my purchases, along with some links to the various items mentioned.

And that’s about it. If anyone thinks I missed something super cool, drop me a comment below and I’ll check it out.

Today, I had a bunch of chores to do, but I did start to play around with my AD9850 project a bit more. Since I spent so much time driving around yesterday, I had lots of time to think, and realized that the code the determined the tuning word (the 32 bit value used to select the frequency of the oscillator) was probably going to not work properly, since it used floating point arithmetic, and that probably didn’t have sufficient precision to do the calculation the way that I had coded. Indeed, when I got home, I hooked up and Arduino and found that I was not getting the sub-Hz spacing that I requested. I played around with the math a little bit, and got it working better, and then set it up and started it going. I had the output of the AD9850 going into my oscilloscope, so I could monitor the waveform.

And it was glitchy. Intermittent. Not working properly. Had I made a programming mistake?

I spent the better part of 45 minutes trying to understand how I had broken the program. Nothing made sense. I was cranky. I decided to step back and go buy some cat litter than I had forgotten, and give it a rest.

And of course when I got back, I stared at the board again. And it was immediately obvious. I had the AD9850 module on a breadboard, with all the RESET/CLOCK/LOAD/DATA lines going to the Arduino. And… that was it…

There was no common GND. I had somehow tugged out that little jumper wire. Without a common ground, it was surprising that there was any communications between the module and the Arduino.

Plugged it back in and voila. All works. Sigh. An hour of my life, wasted.

Suddenly, Erin’s Modulo setup seems pretty nifty. 🙂

Time from the ESP8266…

Yesterday, I mentioned the idea of using the cheap ESP8266 as a clock source for a WSPR beacon transmitter. My initial idea was to basically write code for the Arduino that connected to a remote NTP server, formulate UDP packages… sounds like a pain. But then I found that there was alternative software I could upload to the ESP8266 that would implement the NTP client on the ESP8266 module, and then simply fetch it with an “AT” style command.

So, I downloaded the firmware, and gave it a shot.

esptool.py write_flash 0x0000 eagle.app.v6.flash.bin 0x40000 eagle.app.v6.irom0text.bin

I rebooted, and then told it to connect to my local wifi network, and then told it to start the NTP client with the following commands…

AT+CWJAP="ssid","password"
OK

AT+CIPNTP=0

And it works! I can get this connected to the Arduino and write up a simple sketch, and it should be able to update the time really easily. This is cheaper and probably easier than using a GPS as a time source. Very cool.

Screen Shot 2015-05-14 at 9.23.10 PM