[fichl] plays electric guitar, and with that hobby comes an incredible amount of knob twisting and dial turning. This comes at a cost; he can’t change the settings on his small amp without taking his hands off the guitar. While larger, more expensive amps have multiple channels and footswitches, this tiny amp does not. Instead of upgrading, [fichl] came up with a device that turns his single channel amp into a completely programmable one, with just an Arduino and a handful of servos.

The amp in question – an Orange Dark Terror head – has just three knobs on the front of the chassis, volume, shape, and gain. [fichl] had the idea of controlling these knobs electronically, and the simplest solution he came up with is cheap hobby servos. These servos are mounted in an aluminum box, and mount to the knobs with a few shaft couplings.

The footswitch is the brains of the setup, with three buttons, four LEDs, and a DIN-5 output jack that delivers power, ground, and three PWM signals to the servo box. With the help of an Arduino Nano, [fichl] can change any of the knobs independently, or switch between twelve programmed settings. It’s an interesting setup, and something that could serve as a prototype for a much larger system on a much larger amp.

Motion control is a Holy Grail of input technology. Who doesn’t want an interface that they can control with simple and natural movements? But making this feel intuitive to the user, and making it work robustly are huge hills to climb. Leap Motion has done an excellent job creating just such a sensor, but what about bootstrapping your own? It’s a fun hack, and it will give you much greater appreciation for the currently available hardware.

Let’s get one thing straight: This device isn’t going to perform like a Leap controller. Sure the idea is the same. Wave your hands and control your PC. However, the Leap is a pretty sophisticated device and we are going to use a SONAR (or is it really SODAR?) device that costs a couple of bucks. On the plus side, it is very customizable, requires absolutely no software on the computer side, and is a good example of using SONAR and sending keyboard commands from an Arduino Leonardo to a PC. Along the way, I had to deal with the low quality of the sensor data and figure out how to extend the Arduino to send keys it doesn’t know about by default.

The Plan

The plan is to take an inexpensive SONAR module (the HC-SR04) and an Arduino Leonardo and use it to perform some simple tasks by mimicking keyboard input from the user. The Leonardo is a key element because it is one of the Arduinos that can impersonate a USB keyboard (or mouse) easily. The Due, Zero, and Micro can also do the trick using the Arduino library.

I wanted to determine how many gestures I could really determine from the HC-SR04 and then do different things depending on the gesture. My first attempt was just to have the Arduino detect a few fingers or a hand over the sensor and adjust the volume based on moving your hand up or down. What I didn’t know is that the default Arduino library doesn’t send multimedia keys! More on that later.

How the SONAR Works

The SONAR boards come in several flavors, but the one I used takes 4 pins. Power and ground, of course, are half of the pins. In fact, my early tests didn’t work and I finally realized the module requires more power than I could draw from the Arduino. I had to add a bench supply to power the module (and, of course, I could have powered the module and the Arduino from the same supply).

The other two pins are logic signals. One is an input and a high-going pulse causes the module to ping (8 cycles at 40kHz). There is a delay and then the other pin (an output) will go high and return low when the module detects the return ping. By measuring the time between your signal to ping and the return, you can judge the distance. In my case, I didn’t care about the actual distance (although that’s easy to compute). I just wanted to know if something was farther away or closer.

The scope trace to the right shows the sensor pointing at something relatively near. The top trace is the start pulse and the bottom trace is the input to the Arduino. The center trace is the output of the SONAR transducer. All the signal conditioning is inside the sensor, so you don’t need to worry about the actual signal processing to generate and recover the audio. You only need to measure the width of that bottom pulse.

The scope has persistence and you can see that the bottom trace does not always come out right at the same time (look at falling edge and you can see “ghosts” for previous samples. It shouldn’t come as a surprise that it may take a little effort to reduce the variations of the signal coming back from the SONAR.

Noise Reduction and Actions

Averaging

I wound up trying several different things to attempt to stabilize the input readings. The most obvious was to average more than one sample. The idea is that one or two samples that are way off will get wiped out by the majority of samples that are hovering around some center value. I also found that sometimes you just miss–especially when looking for fingers–and you get a very large number back. I elected to throw out any data that seemed way off when compared to the majority of received data.

Verifying

One other tactic I used was to verify certain elements with a second reading. For example, the start event occurs when the SONAR reports a value under the idle limit. The idle limit is a number less than the reading you get when the SONAR is pointed at the ceiling (or wherever it is pointing) and you don’t have anything blocking it. To recognize a valid start, the code reads twice to make sure the value is under the limit.

The code inside the Arduino loop is essentially a state machine. In the IDLE state, it looks for a reading that is below the idle limit. When found, that causes a transition to the sampling state. When the reading goes up or down more than some preset value, the code in the sample state sends a volume up or down key via the keyboard interface. If the sample goes back over the idle limit, the state machine returns to IDLE.

I got pretty good results with this data reduction,  but I also found the NewPing library and installed it. Even though it isn’t hard to write out a pulse and then read the input pulse, the NewPing library makes it even easier (and the code shorter). It also has a method, ping_median, that does some sort of data filtering and reduction, as well.

You can select either method by changing the USE_NEW_PING #define at the top of the file. Each method has different configuration parameters since the return values are slightly different between the two methods.

I said earlier that the code sends volume up and down commands when it detects action. Actually, the main code doesn’t do that. It calls an action subroutine and that subroutine is what sends the keys. It would be easy to make the program do other things, as well. In this case, it simply prints some debugging information and sends the keys (see below). I didn’t react to the actual position, although since the action routine gets that as a parameter, you could act on it. For example, you could make extreme positions move the volume up two or three steps at a time.

Sending Keyboard Commands

I wanted to send standard multimedia keys to the PC for volume up and down. Many keyboards have these already and usually your software will understand them with no effort on  your part. The problem, though, is that the default Arduino library doesn’t know how to send them.

Fortunately, I found an article about modifying the Arduino’s library to provide a Remote object that wasn’t exactly what I had in mind, but would work. Instead of sending keys, you have methods on a global Remote object that you can call to do things like change or mute the volume. The article was for an older version of the Arduino IDE, but it wasn’t hard to adapt it to the version I was using (version 2.1.0.5).

The action routine really only needs the UP_IN and DN_IN cases for this example. However, I put in all four branches for future expansion. Here’s the action subroutine:

void action(int why, unsigned value=0)
{
 Serial.print(value);
 switch (why)
 {
 case START_IN:
 Serial.println(" Start");
 break;
 case STOP_IN:
 Serial.println(" Stop");
 break;
 case UP_IN:
 Serial.println(" Up");
 Remote.increase();
 break;
 case DN_IN:
 Serial.println(" Down");
 Remote.decrease();
 break;
 }
}

The Final Result

The final result works pretty well, although the averaging makes it less responsive than you might wish. You can turn down the number of samples to make it faster, but then it becomes unreliable. You can download the complete code from Github. The first thing you’ll want to do is check the top of the file to make sure your module is wired the same (pin 3 is the trigger pin and pin 8 is the echo return pin). You’ll also want to select if you are going to use the NewPing library or not. If you choose to use it, you’ll need to install it. I flipped my Leonardo upside down and mounted it on a breadboard with some adapters (see picture to right). It really needs a more permanent enclosure to be useful. Don’t forget to give the SONAR module its own 5V power supply.

If you look near the top of the loop function there is an #if statement blocking out 3 lines of code. Change the 0 to a 1 and you’ll be able to just get averaged data from the sensor. Put the module where you want it and see what kind of numbers you get. Depending on the method I used I was getting between 4000 and 9000 pointed up to the ceiling. Deduct a bit off of that for margin and change IDLETHRESHOLD (near the top of the file) to that number.

The DELTATHRESHOLD is adjustable too. The code sees any change that isn’t larger than that parameter as no change. You might make that bigger if you have shaky hands or smaller if you want to recognize more “zones”. However, the smaller the threshold, the more susceptible the system will be to noise. The display of samples is helpful because you can get an idea how much the readings vary when your hand is at a certain spot over the sensor. You can try using one or two fingers, but the readings are more reliable when the sound is bouncing off the fleshy part of your palm.

If you want to add some more gestures, you may have to track time a bit better. For example, holding a (relatively) stationary position for a certain amount of time could be a gesture. To get really sophisticated gestures, you may have to do some more sophisticated filtering of the input data than a simple average. A Kalman filter might be overkill, but would probably work well.

If you look around, many robots use these sensors to detect obstacles. Makes sense, they’re cheap and work reasonably well. There are also many projects that use these to show an estimate of distance (like an electronic tape measure). However, you can use them for many other things. I’ve even used a similar set up to measure the level of liquid in a tank and earlier this week we saw ultrasonic sensors used to monitor rice paddies.

If you really want to get serious, [uglyduck] has some analysis of what makes spurious readings on this device. He’s also redesigning them to use a different processor so he can do a better job. That might be a little further than I’m willing to go, although I was impressed with the 3D sonic touchscreen which also modified the SONAR units.

Making someone a birthday cake is very thoughtful, but not if they are watching their weight. [MrFox] found a way around that: an Arduino-powered birthday cake. Even if you don’t mind the calories, an Arduino cake is a novelty and sure to be a hit with a hacker who’s another year older.

The cake uses a UTFT LCD shield which eats up a lot of pins and memory, so the project uses an Arduino Mega. A speaker plays the happy birthday song (which may even be legal now) while a microphone detects the birthday boy or girl blowing out the virtual candles.

We’ve seen similar cakes with a fixed number of LED “candles” before, but the LCD screen makes this a cake of a different color. If you want, you could look into something that is actually edible. On the other hand, we’re kind of partial to the Jolly Wrencher with red eyes and fireworks, ourselves.

The video shows the birthday cake in action. Given the screen, we were surprised that nothing popped out. Not a life-changing project, but still fun for your next hacker party, even if you have a real cake as a backup.

Announced at the 2014 Maker Faire in New York, the latest Arduino WiFi shield is finally available. This shield replaces the old Arduino WiFi shield, while providing a few neat features that will come in very handy for the yet-to-be-developed Internet of Things.

While the WiFi Shield 101 was announced a year ago, the feature set was interesting. The new WiFi shield supports 802.11n, and thanks to a few of Atmel’s crypto chip offerings, this shield is the first official Arduino offering to support SSL.

The new Arduino WiFi Shield 101 features an Atmel ATWINC1500 module for 802.11 b/g/n WiFi connectivity. This module, like a dozen or so other WiFi modules, handles the heavy lifting of the WiFi protocol, including TCP and UDP protocols, leaving the rest of the Arduino free to do the actual work. While the addition of 802.11n  will be increasingly appreciated as these networks become more commonplace, the speed offered by ~n isn’t really applicable; you’re not going to be pushing bits out of an Arduino at 300 Mbps.

Also included on the WiFi shield is an ATECC508A CryptoAuthentication chip. This is perhaps the most interesting improvement over the old Arduino WiFi shield, and allows for greater security for the upcoming Internet of Things. WiFi modules already in the space have their own support for SSL, including TI’s CC3200 series of modules, Particle‘s Internet of Things modules, and some support for the ESP8266.

Hardware and software combined, Arduino does many things right. It lowers the entry level into embedded systems development with a nifty hardware abstraction layer. It aims for cross-platform compatibility by supporting Windows, Mac OSX, and Linux operation systems. It throws out the need for an external programmer to get you up-and-blinkin’ those LEDs quickly.

One thing most of us never cease to curse about, though, is the IDE. Many have cried out wildly against the Java-based text-editor for its cryptic compiling-and-linking process, its inability to accommodate bare C or C++ source files, and (shh!) its lack of Vim keybindings. Fortunately, our cries have been heard, and the like many community-based projects, the community fights back with a custom solution.

Calling all Grumpy Engineers: The Arduino-Makefile

Enter the Arduino Makefile.

What began as [Sudar’s] lightweight program to escape the IDE has become a fully-blown, feature rich Makefile that has evolved and adapted to grow with the changes of Arduino. With a community of 47 contributors, the Makefile enables you to escape from the IDE entirely by writing code in the cushy text editor of your choice and compiling with a simple incantation of make into your terminal, be you in Linux, Mac, or Windows.

Without further ado, let’s take a walking tour of the project’s highlights.

Cryptic Shortcuts–Begone!

For many beginners, writing (or even editting) a Makefile can cause some serious confusion with most Makefile authors’ shameless shortcut use. Make no mistake, the cryptic syntax of many Makefiles forms a concise list of instructions for compiling and linking your executable, but this recipe does seem a bit hard to parse for the uninitiated. What’s more, Makefiles also tend to throw bizarre errors (trailing whitespace anyone?) that are difficult to track down–especially when we want to spend most of our time bringing up embedded systems, not understanding the mechanics and syntax of a Makefile. Fortunately [Sudar] and the rest of the development team have made the interface very human readable.

Their solution: A two-part Makefile. For a simple project, your Makefile need be no longer than this snippet (inspired from the Makefile Examples):

BOARD_TAG    = uno
include $(ARDMK_DIR)/Arduino.mk

Project-specific settings (like which board you’re using) are outlined in this brief Makefile that then includes the larger Makefile which contains the actual nuts and bolts for building your code. The assumption here is that you’ve defined two environment variables, both ARDMK_DIR and ARDUINO_DIR that point towards the (1) Arduino Makefile directory and the (2) Arduino Installation directory. In addition, if you have additional libraries, you can include them with a line in your top-level Makefile that defines the filepath.

 USER_LIB_PATH += /home/my_username/my_libraries_directory

You’ll also need to add all libraries you’re using (both user-added and built-in) to the list of libraries like so:

ARDUINO_LIBS += Wire \
                SPI \
                my_custom_lib

The benefit of a “split-Makefile” setup is that the short, top-level Makefile hides the gritty compiler gymnastics involved in compiling and linking against the default and user-added Arduino Libraries. On the flip-side, this “mini” Makefile becomes a brief, informative summary of a few minor details, such as which Arduino Libraries are being used, that are likely more relevant to the author and future developers.

Raw C and C++ is In–if you prefer such things

Tired of that *.ino file extension? Tired of having to constrain yourself into those setup and loop functions? With the Makefile, you can quickly wish these away and write your code in raw C or C++. You can even neglect to #include <Arduino.h> if you want to work in vanilla C or C++ and disregard the Arduino libraries altogether.

That said, if you’re mixing C and C++, keep in mind that you’ll need to insert guards around your C header files like so:

#ifdef __cplusplus
extern "C" {
#endif

/// the rest of my C header file 

#ifdef __cplusplus
}
#endif

Adding Project Libraries

Possibly my favorite aspect of the Arduino Makefile is its flexibility to accomodate a richer file structure and painlessly split your project into multiple files. Let’s say I have a one-off project where it makes sense to include a custom library. Given the flexibility of the Makefile, you can define:

    USER_LIB_PATH+=.
    ARDUINO_LIBS += my_custom_library

in your project Makefile and produce a directory tree like so.

 ├── main.ino
 ├── Makefile
 ├── my_custom_library
 ├── my_custom_library.cpp
 └── my_custom_library.h

If you need more flexibility, you can also split your source code across several directories, keeping the Makefile in the same directory of your code that acts like a “main.” (In this case, main.ino defines setup  and loop.) To do so, your Makefile will, instead, have:

    USER_LIB_PATH+=../libs
    ARDUINO_LIBS += my_custom_library

in your project Makefile, and your directory structure will look like so:

 ├── libs
 │   └── my_custom_library
 │     ├── my_custom_library.cpp
 │     └── my_custom_library.h
 └── src
  ├── main.ino
  └── Makefile

Finally, we don’t need to constrain ourselves to writing just C++ classes to split projects into multiple files.  Since we’re really working with vanilla C++, you can freely split your project into multiple source (*.c, *.cpp, *.ino, *.pde) and header (*.h, *.hpp) files that live in the same directory as the Makefile, and the Makefile will compile them into one executable.

Other Micros are Fair Game Too

Finally, the Arduino-Makefile is also compatible with a host of other microcontrollers and programmers, not just the ATMEGA328P on the Uno. In short, this feature is an exposition of the features of AVRDUDE, the program for downloading and uploading code to various AVR microcontrollers. Last, but not least, it’s also Teensy-compatible.

Define Our Standard

If you’re looking to get comfortable with the Arduino-Makefile workflow, have a quick look at their examples directory for a host of different use-cases. You can also take a peek at my i2c_demultiplexing_demo source from a couple weeks back for yet another example. At the end of the day, Arduino, with its giant library collection, makes project prototyping fast. For bigger projects, though, we don’t tend to see any standard practices for file organization to make projects easier to navigate. That’s where you come in. With the flexibility of the Makefile, you get it all: the text editor you always wanted, the separate header and implementation files, a clean directory… Now it’s your shot to take this tool and refine your workflow into a method worth sharing with the rest of us.

Over on hackaday.io, [Arduino Enigma] posted the code for his clock that runs on a KIM Uno (the KIM-1 clone we mentioned late last year). Although the KIM Uno has a few demos preloaded (including Microchess and a scientific calculator), all of them take some interaction. The clock makes the KIM Uno a more dynamic desk display since it does something useful without any user interaction (once you set the clock, of course).

The project shows the code stored in ROM, but you can’t directly enter the program into ROM (which is really EEPROM on the host Arduino). The trick is to enter the address (that is press AD and then 0, 4, 0, 0) and then mash down the reset button for about a second. Then you can press DA and enter the hex codes provided (pressing + after each byte). Since the code is in nonvolatile storage, you can start it at any time by setting the time in RAM and executing the code at address 400.

The program is short and sweet, making it is easy to enter and a great opportunity to brush up on understanding your 6502. However, the simplicity means it doesn’t range check your initial time settings, so don’t tell it that it is 32:99 or something like that. The code isn’t commented, but it is pretty simple, once you realize one thing: the first instruction, SED, sets the 6502’s decimal mode so no conversion between hex and decimal is needed.

Each part of the time (hours, minutes, and seconds) is stored in RAM at locations 0024, 0025, and 0026. The NEXTD routine uses the X register to scan through each part of the time, adding 1 or 0 as appropriate (stored in RAM location 0029). If the time part matches the corresponding table entry at CARRYT (that is, 60, 60, or 24 also indexed by the X register), then the code does not take the branch to CONTIN and reloads the increment (location 0029) with zero, so the next digits will not advance. If it does match, the increment stays as 1 and the current part returns to a zero value.

You may notice the time is stored back to locations starting at 0024 and 00F9. That’s because 00F9 is where the KIM-1 ROM looks for data to write to the display when calling the ROM-resident subroutine at 1F1F. The X register ranges from 0 to 2, corresponding to the seconds, minutes, and hours. Once all the time is updated, the loop at L1 displays the time and delays for about one second.

A neat piece of coding and a great example of the power of the 6502’s decimal mode. This would look even better with [Scott’s] enhanced version of the KIM-1 UNO.

Visualizing how electronic signals work can be difficult. A physical model can be darn useful in overcoming that difficulty. At a recent workshop entitled “Unboxing Black Boxes” [Julian Hespenheide’s] group created a device to show Baudot Code in operation. This amalgam of wood and Arduino they dubbed émile in honor of Émile Baudot (1845-1903).

Baudot developed his code to transmit telegraph signals from one machine to another, in contrast to Morse code which was principally for human communication. Both codes were used throughout the 20th century. For example, those big clattering, mechanical teletype machines use a minor variation of Baudot code.

Baudot is a fixed length code of 5 bits, as opposed to Morse’s variable length code. Morse has a separate code for each characters while Baudot uses “shift’ codes to change between alphabet and figure characters. For instance, a binary 11 would represent either an ‘A’ or a ‘-‘ depending on the shift state. If the shift code was missed the receiver would get gibberish.

In émile the Baudot code is sent by marbles. That’s right, marbles. There are five marbles, one for each bit in the Baudot code. Each marble rolls in a track toward the Arduino. How does the machine know which marbles to send? “Punch cards”! These are a marvelous aspect of the design.

Each card represents a code. Each position in the card has a gap to allow a marble to pass ( a set bit), or no gap to block the marble (an unset bit). The operator loads 5 marbles and a punch card and launches the marbles via a spring mechanism.

[Julian’s] really created a great visualization of Baudot code with this project! Take a look at émile in action after the break.

Last spring [Mike] built a foam rocket launchpad which was a hit with the kids in his neighborhood. But the launch system was merely a couple of buttons so the early enthusiasm quickly wore off. He went back to the drawing board to make improvements and really hit the jackpot!

The original launch system had one button for building up air pressure with a second big red button of doom for launching the rocket. The problem was a complete lack of user feedback; all the kids could do is guess how long they needed to hold the button to achieve the highest launch. This revision adds flashing LEDs to hold the attention of the wee ones but to also function as a gauge for the new pressure control system. The visually fascinating control board also includes a removable key to prevent accidental launches.

The particulars of this are as you’d expect: it’s a bunch of plumbing to manage the air pressure, an Arduino to control it all, and additional electronics in between to make them work together.

We’re especially impressed by the leap in features and quality from the first version to this one. It’s a testament to the power of quick proofs-of-concept before committing to a more involved build. Great work [Mike]!

We’ve seen rocket launchers for adults and some neat mission control panels but [Mike’s] kid friendly launch controller really is out of this world (sorry, couldn’t resist). You’ll find a video demo of this launcher after the break.

You may wonder why anyone would want to learn Morse code. You don’t need it for a ham license anymore. There are, however, at least three reasons you might want to learn it anyway. First, some people actually enjoy it either for the nostalgia or the challenge of it. After all, . Another reason is that Morse code can often get through when other human-readable schemes fail. Morse code can be sent using low power, equipment built from simple materials or even using mirrors or flashlights. Finally, Morse code is a very simple way to do covert communications. If you know Morse code, you could privately talk to a concealed computer on just two I/O lines. We’ll let you imagine the uses for that.

In the old days, you usually learned Morse code from an experienced sender, by listening to the radio, or from an audio tape. The state of the art today employs a computer to randomly generate practice text. [M0TGN] wanted a device to generate practice code, so he built it around an Arduino. The device acts like an old commercial model, the Datong D70, although it can optionally accept an LCD screen, something the D70 didn’t have.

You can see the project in operation in the video below. Once you learn how to read Morse code, you might want to teach your Arduino to understand it, too. Or, you can check out some other Morse-based projects.

In August of 2014, something new started showing up in the markets of Shenzen, the hi-tech area of China where the majority of the world’s electronics components are made. This is the ESP8266, a WiFi SoC (System on a Chip) that can connect to 802.11b/g/n networks on the 2.4GHz band. It can be addressed with SPI or a serial connection, and has an AT command set that makes it behave rather like an old-style modem. Basically, it has everything you would need to connect a device to a WiFi network, with the ESP8266 chip itself handling the complicated business of finding, joining and transmitting/receiving over a WiFi network.

That’s nothing particularly new in itself: WiFi connection devices like the TI CC3000 have been around for longer, and do much the same thing. The difference was the price. While the TI solution costs about $10 if you buy several thousand of them, the ESP8266 costs less than $7 for an individual board that can plug straight into an Arduino or similar. Buy the chip in bulk, and you can get it for less than $2.

The ESP8266 is more than just a WiFi dongle, though: it is a fully fledged computer in itself, with a megabyte of flash memory and a 32-bit processor that uses a RISC architecture. This can run applications, turning the ESP8266 into a standalone module that can collect and send data over the Internet. And it can do this while drawing a reasonably low amount of power: while receiving data, it typically uses just 60mA, and sending data over an 802.11n connection uses just 145mA. That means you can drive it from a small battery or other small power source, and it will keep running for a long time.

It wasn’t an easy ship to write applications for in the early days, though: it was poorly documented and required a dedicated toolchain to work with. This made it more of a challenge than many hackers were comfortable with.  That changed earlier this year, though, when the Arduino IDE (Integrated Development Environment) was ported to the chip. This meant that you could use the much easier to write Arduino functions and libraries to write code for the chip, bringing it within reach of even the most casual hacker.

Why Is the ESP8266 Important?

The ESP8266 almost achieves the holy trifecta of electronics: cheap, powerful and easy to work with. Before this, if you wanted to add a wireless connection to a project, you had to use more power-hungry devices like USB WiFi dongles, or squish everything into a serial connection and use a wireless serial link. Either way added to the complexity of the project: you either needed a system that supported USB and had WiFI OS support, or you had to put up with the limitations of wireless serial links, which typically offer very limited bandwidth. The advent of WiFi SoCs removed these limitations because the SoC did the heavy lifting, and WiFi offered much more bandwidth. And the ESP8266 did this all at a very low cost: do some digging on eBay and you can get an ESP8266 board for less than $2. So, it is no surprise that we are starting to see the ESP8266 showing up in commercial products. 

How Can I Use the ESP8266?

With the popularity of the ESP8266 for adding WiFi to projects, it is no surprise that there are a lot of options for trying it out. On the hardware side, ESP8266 development boards are available from a number of places, including Seeedstudio, Sparkfun and Olimex. Adafruit also has a nice ESP8266 board that breaks out all of the signals for easy breadboard use, and adds a 3.3V output, so it can drive an external device. It is also FCC approved, which is important if you are looking to sell or use the devices you build commercially. Some users have also been building their own development boards, which add features such as LCD displays and buttons.

On the software side, the easiest way to get into the ESP8266 is to use the Arduino compatible mode. This involves loading custom firmware that turns the chip into a mid-range Arduino board, which makes for much easier programming. The people behind this project have produced a list of supported ESP8266 boards: buying one of these will make the installation process easier, as they have noted which data lines in the Arduino SDK correspond to the physical pins on the board. These boards also provide easy access to the reset lines that you have to use to install the Arduino compatible firmware.

This does include some limitations, though: it is rather complicated to upload new sketches over WiFi, and you can’t produce multiple PWM signals, which would make controlling multiple devices difficult. To get access to the full capabilities of the ESP8266, you’ll need to go to the source, and use the SDK that the manufacturers offer. [cnlohr] published an in-depth guide here on Hackaday for bare-metal programming the ESP8266 whih was mentioned earlier. Espressif also offer a pretty good getting started guide that covers creating a virtual Linux machine and connecting this to their chips.

The third option is to flash NodeMCU to the ESP8266 module. This turns it into a Lua interpreter. Scripting can be done in real-time to prototype your program, then flashed to the EEPROM to make your program persistent and remove the need for a serial connection.

Beginners will be comfortable with both the Arduino and NodeMCU approaches, but experienced users should be able to wade straight in and start writing code for this cheap, powerful and fairly easy to use chip.