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

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, 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:


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, 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 data server on 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. write_flash 0x0000 0x40000

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…



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