Misadventures with an ESP-01 board (ESP8266 wifi module)

To add wifi capability to an electronics project, the ESP8266 chip is apparently a popular choice.  It is a microcontroller with a wireless ethernet stack built in.  We got three ESP-01 boards that feature this chip, an antenna, and some flash memory (1 MB).  They are very small!

The tutorials on this board are generally quite confusing, as you can incorporate it easily into a project of your choosing in many ways.  Many makers are familiar with the Arduino platform and are comfortable with its development tools, even though this isn't entirely necessary.  Also, there appears to be a tradition of "hello world = flashing LED" tutorials for Arduino.  This tradition extends to ESP-01 boards in a somewhat unfortunate way. 

The ESP-01 board ships with an old-school Hayes-modem "AT" command interface.  It talks to a host via serial at 115200 baud out of the box -- though with 3.3 V signaling instead of 5 V or RS-232 levels.  (Nearly everyone warns you that 5 V will kill the device, but that actually seems a bit suspect.  I imagine RS-232 levels would really toast it, though!)  In any case, if you hook up a serial terminal, you can talk AT commands and pretty easily connect the board to a nearby access point.  The commands are

AT+CWMODE_CUR=3
AT+CWJAP_CUR="<ssid>","<pwd>"

If you want to see what access points are visible, use

AT+CWMODE_CUR=3
AT+CWLAP

If you want to see what IP you've been assigned once connected, use

AT+CIFSR

The documentation for all the commands is located here. a nice short listing of commands is here.  It's essentially like a cross between old-school modem commands and sockets programming.

Since modern computers don't have a hardware serial port (and most old hardware serial ports don't support 115200 baud), you typically use a USB-to-serial converter.  There are many of these available -- I have several -- but for a quick hack you can coerce an Arduino into helping.  Actually, "coerce" is the right word, because what you do is hold the Arduino in a reset state (it's effectively disabled) while you hijack its USB-to-serial chip.  Here's the circuit that I used.  The resistors form a voltage divider that brings the Arduino's 5 V signaling down to 3.3 ish volts.  (It didn't make much of a difference when I hooked the RX lines directly together, though that is apparently ill-advised...) 

Since I am using an Arduino Mega held in reset, it seems that plenty of 3.3 V is available for the ESP-01, contrary to the many tutorials warning that a separate power supply is required.  I imagine you might have problems if you allow the Arduino to boot up.

OK, back to the unfortunate part of the story.  Since the tradition is to make an LED flash as your first project, there are many tutorials explaining how to make an ESP8266 flash an LED.  This involves -- naturally enough -- overwriting the flash memory with a program that simply toggles one of the GPIO pins.  However, this means that the modem firmware gets overwritten!  If you're a newbie (or even if you're not), this means that the ESP-01 board is now useless as a wifi dongle!  Putting the original firmware back is not exactly a trivial task.

I was faced with the task of reflashing 2 of the 3 ESP-01 boards we have.  (The remaining one was fortunately unharmed, so I was able to figure out how it was supposed to work!)

First of all, you need special software that understands how to flash memory on the board with the ESP8266 chip.  Fortunately, the right tool for the job is an open source python script esptool which has minimal dependencies.  Starting this up was no problem, and I started by re-using my existing circuit.  I figured that I would start by clearing the flash memory, since I already knew it to be useless...

$ python esptool.py --port /dev/ttyACM0 erase_flash

Sadly, this just hung while "connecting".  I hooked up my logic analyzer to the TX and RX lines, and was able to verify that data was getting transferred, so it looked like the chip was merely ignoring the commands.  After digging some more, I found that the right course of action was to ground the GPIO0 pin first.  This puts the ESP8266 chip into a "flash mode", which is required for programming it.  To start programming, you briefly pulse the RST pin to ground to reset the chip.  Then it happily started flashing the memory, or so I thought. 

However, as it turns out my board has a flash chip that doesn't like the default SPI settings.  Unfortunately, they appear to work just fine, and the files I flashed even verify correctly through esptool.  But they are wrong!  There are some dark words in Amazon reviews for the ESP-01 about defective boards, but that didn't seem to add up.  The boards were indeed talking -- I could watch the data transfer both directions on my logic analyzer -- so I didn't think they were defective. 

After a bit more poking, I found the solution.  The problem is that the default setting in epstool optimizes runtime, using the fastest protocol to write the flash.  Apparently this isn't supported by all flash chips, and it silently causes problems with some of them.  There's a detailed explanation of what's going on in the esptool documentation and on the Wikipedia page for the Serial Peripheral Interface. 

OK.

Let's flash the board correctly!

You can use the stock firmware, by following detailed instructions about the flash map in their documentation.  But there is also an enhanced version of the firmware that adds a few additional AT commands.  It's a little easier to flash the enhanced version since it's all in one contiguous block starting at address 0x00000 rather than several separate files flashed into different addresses, which is how the stock firmware is distributed.  In any case, the command to do the job is

$ python esptool.py --port /dev/ttyACM0 write_flash 0x00000 AiThinker_ESP8266_DIO_8M_8M_20160615_V1.5.4.bin --flash_mode dout

This set things right, and the boards once again respond to AT commands!

Morse code trainer

This is a quick weekend project.  I wanted something that would send random strings of characters in Morse code, grouped into sets of 3 or 4 at at time.  This little box has a power switch, a speaker, a knob for volume, and a knob for sending speed.  It's powered by a 9v battery, and is controlled by an Arduino Nano.  There's really not much else to it except for the code.

Restoring a pdp-11/45

When I was a student at RPI, I found a pdp-11/45 on the JEC loading dock.  The machine had no power supply and had a destroyed memory management board (M8108).  I cobbled together a power supply and replaced the board, and it was running well enough to flash its lights. 

That was about eleven years ago -- the little boy in the video above is turning 13 tomorrow -- and the machine stopped working shortly after the video was taken.

This month I started investigating the cause of the trouble.  I found that the +5V power was sagging severely when the machine was powered, which isn't terribly surprising because the CPU alone draws something like 40A!  Evidently the industrial power supply I had purchased wasn't doing its job.  Unfortunately, what used to be a $50 power supply was now upwards of $400, since the manufacturer had closed.  A little looking around, I decided to replace the +5V only at 50A. 

The resulting power supply got the machine to start up, but it was very erratic. It would crash at various weird places, and for no particular good reason.  This had me going for a long while, but fortunately the machine was made to be debugged... you can select from two internal clocks: a crystal (the default) and an RC oscillator.  You can adjust the frequency of the RC oscillator, but it's not very stable.  You can also wire in a single-step switch, which I had done in the past.  None of this seemed to help, but I learned that my frequency counter is pretty stable in the process.

Accidentally, I found that the machine would crash when I bumped the power supply wiring harness.... and found that the screws that connected the harness to the power supply were loose. 

Tightening the screws fixed that problem!

But there were more problems.  Several of them were easily resolved by polishing all of the card edge contacts.  This is not hard, but takes some doing.

This got the machine to the point where it had been before it stopped working.  It could load my custom, simple OS, EMON, and run programs entered from the console. 

But I had previously wanted to load other software, could I do that now?  Since I do not have any peripherals aside from serial lines, using a emulated TU58 tape drive seemed the best option.  Since I last checked about a decade ago, tu58fs has been written, and seems to be the most convenient.  So I tried to get XXDP and RT11 running, but both failed.

XXDP in particular was stopping at address 000550, this seemed to be similar to what was described here.  Using the disassembly provided there, I agreed that this was a checksum error.  But since the tape file booted on SIMH, I knew I had a good image. 

By manually digging through what the boot loader had loaded into the pdp-11's memory, I verified that everything was perfectly loaded.  The checksum was being computed incorrectly!  I wrote a simple program to compute the checksum of that good block... and the checksum came back wrong.  After simulating the code carefully in python, I determined that the cause was that the carry bit was getting set way too often. The carry was set whenever it should be, but also whenever the highest bit of the destination register was set.

I traced this back to the output of one multiplexer chip.  It was being held low when it shouldn't be, but only about 0.9V... an uncertain level.  Fearing the worst, I replaced the chip.

I socketed the replacement just in case I had to replace it again.  This is perhaps unnecessary, and it might cause issues if I ever get a floating point unit.  But since this board is the frontmost large board, it's not a problem.

Sadly, this didn't do the job... the carry still was getting set incorrectly.  Tracing forward, it turned out that the destination register's highest bit has a special active LOW line that runs on a trace parallel to the carry bit.  A tiny bit of solder had bridged those two lines at the following chip.

Evidently, this chip had been replaced previously -- not by me -- and the job was not done carefully.  Cleaning up the solder job and removing the bridge fixed the carry problem.

The machine now boots XXDP!

But, as the screenshot shows, there are still problems...  I originally had 32 kW of memory loaded, for a total of 28 kW available for programs.  (The top 4kW is always reserved for memory mapped I/O.)  I have verified that all of this memory can be accessed and used without issue.  Although the memory management unit is not needed to access 28 kW of memory, apparently XXDP prefers to have it available.  The memory management unit (embodied in the M8107 and M8108 boards) is actually installed, but it is evidently not working correctly.

In order to get XXDP to boot, I had to pull the top 16 kW out, which is the four cards above that are obviously displaced.  (The memory lives in a separate cabinet above the CPU because I had trouble finding a sufficiently powerful power supply for it.  Since it takes unusual voltages, I didn't fancy building an appropriate power supply from scratch.)

Here's a video of the entire boot process, in which I key in the boot loader using the front panel.

Metronome flasher

Here is a circuit Edwin built this morning.  It's not complicated, but it is clever...

He figured out that the metal mechanical parts of the metronome are all in contact with one another.  He attached a wire to the winding knob, which was therefore attached to the pendulum.  By aligning the pendulum carefully with a snap circuits wire, the metronome intermittently completes the circuit.

Here is a video of it in action!

80 meter antenna

We built several Cricket 80a kits, which operate in the 80 meter amateur band.  Since we don't have any antennas specifically for this band, I decided to make one.  The design is a basic dipole fed with coax and a current balun at the feedpoint.

Here are the feedpoint parts: 

The coil is bifilar wound with 13 turns of 22 AWG speaker wire through a toroid.  It measures around 350 microhenries.  The extra loop is for a support cable to lift the feedpoint.  The enclosure is a watertight plastic container that has holes drilled for the SO-239 connector and mounting hardware.  I found that it was easier to control the drilling by hand (rather than by power drill), and a step drill made the holes cleanly deburred.

The two wires attach to the coax center and shield, while the other leads attach to the antenna.  It made sense to do the electrical work first...

... and then install it in the container.  I applied plastic epoxy to each of the pass-throughs before installing hardware in an attempt to seal out any water.  After the hardware was installed, I screwed in the antenna connections tight.

Here is the final enclosure, ready for the radiating wires.

Connecting from the hooks to the radiating wire segments is done with a short feeder segment of stranded wire.  Loops are soldered in the stranded wire while it's installed on the enclosure.  To avoid melting the plastic, I gripped a hemostat onto the plastic side of the junction to draw the heat.

Here are the feeder segments ready for the radiating wire segments. 

The next step was to design the radiating wire segments.

For the radiating structure, we are constrained by the feedline length (25 feet of RG-58) and the confines of our lot.  We're lucky that the antenna basically runs the length of one side of our property, basically touching the ground on one end due to ground slope.  Here is what NEC seems to suggest:

• Height of antenna above ground: 2 meters
• Length of each leg: 20 meters = 65 feet

Here is the impedance and VSWR according to NEC:

Here is the radiation pattern according to NEC, which clearly indicates that the main beam is vertical, which should be good for near vertical incidence skywave (superimposed on the antenna structure):

Given this plan, I measured out two runs of 67 feet each; better to cut long and trim than the other way around.

The wires are attached to the feeders.

Ready for installation!

Then I strung the works into position.  This took a while; after trimming off the excess wire, I got a near perfect SWR around 3.560 - 3.580 MHz, right where I wanted it.  As NEC predicted, the antenna seems to degrade higher in the band, with a 2.5:1 SWR around 3.800 MHz.

Extreme IC repair

For Christmas, our family of hams got Cricket 80A transceiver kits.  They are not terribly hard to assemble and are good soldering practice. 

One problem we had with two of them was that the local oscillators did not start up.  It turned out that the 2N7000 MOSFETs are susceptible to electrostatic discharge (ESD) damage.  For whatever reason, the Q1 local oscillator transistor seems more vulnerable to this.

But in one of the kits, there was a problem with the audio amplifier IC, an NJM-2113D.  In the process of soldering and apparently removing, three pins broke off.  These are not exactly standard, at least they're not in my junk box. So although I put in an order for a replacement, Donna pointed out that I could probably fix it anyway.

The issue is that pin 1 (GND) broke off at the case, so I set about using a four fluted 1/8" endmill to cut the case to expose more of the pin.  I gripped the endmill in a collet in the headstock of my lathe.

My biggest concern was part-holding.  Fortunately, I was able to grip the IC in a toolpost, which also didn't break it.

After a few passes, I successfully exposed what seemed like enough of the pin to take solder.

I started by soldering the intact pins to the board and then the third pin, which was broken off, but not all the way at the case.  For this, I ran a piece of tinned copper wire through the hole, soldered it to the board, and then to the IC.

Then I ran another piece of tinned copper wire through the hole for pin 1 until it stopped on the exposed part of the IC, and soldered it to the board.

Finally, I soldered the new pin 1 to the IC.  I used a bit too much solder, but it's a good connection.

And, it works!  Here is the happy owner of the completed radio.

Transistor oscillator

I have been looking for a simple, easy to understand oscillator circuit that uses a single transistor.  Well, I found one!  Twice, it seems.  The first place was in a classic vacuum tube circuit, as described in

Morecroft, Elements of Radio Communication, Wiley, 1929.

After suitable edits to make it transistorized, I then found the same circuit in a hand-drawn schematic that my father had squirreled away in the 1944 edition of the ARRL Handbook. Certainly not new!

For my and Edwin's benefit, I built the circuit using snap circuits.
 

Here's the schematic:

The different parts of the circuit are indeed easy to understand:

• The tank resonator is an inductor-capacitor (LC) circuit, which sets the frequency.
• The keying turns on and off the oscillator.
• The bias ensures that the transistor is turned "on" and not saturated.
• The transformer affords feedback from the tank to the input of the transistor.  It also contains the inductor part of the tank.  In the snap circuits version, we don't have much control over this (it's in a plastic package), but too little inductance will cause the circuit to fail to oscillate.
• The 200 ohm feedback resistor sets the gain of the transistor amplifier.  Reducing the resistance increases the gain, which drives it harder.  Increasing the resistance makes for a cleaner signal, but can also stop the oscillations. It seems to stop around 1000 ohms or so, but with the 200 ohms it is noticeably overdriven.
• The signal purity can be increased by selecting a higher voltage for the power supply.  I got it to work with 3 volts, but the output was more clipped.

Loop antenna

Since HF antennas tend to be rather large, I wanted to try a small resonant loop.  After doing some research, I found a few sites that seemed rather detailed.  This one seems about the best.

I constructed mine from 3/8" copper tubing, and it is mounted on a camera tripod base.

It is fed using a gamma match.

The tuning is accomplished by a scavenged broadcast FM tuning capacitor and a homebrew air-variable butterfly capacitor.

The antenna can be tuned on the 20 meter through 10 meter bands.  Here I am using it on 20 meters...

Dell Venue 11 pro keyboard fix

My main computer is a Dell Venue 11 pro, which I am generally happy with.  It runs Linux nicely, has an active digitizer stylus, a touch screen, and does just about everything I want.  (The only exception is that it uses micro-HDMI for display output, which is uncommon on projectors... so I can't use it to present at a conference, which is a bummer.)

It's a convertible tablet with a detachable keyboard.  There are various kinds of keyboards: (1) a desktop docking station that I use on my desk at work (I have a USB keyboard, trackball, wired ethernet, and an additional display), (2) a thin folio keyboard that is very lightweight, and (3) a heavier keyboard that also has a spare battery.  The thin keyboard is a little less nice to type on and feels delicate, but I use it when I don't want to carry extra weight.  I usually use the heavier one because typing is nicer.  It basically makes the computer into a laptop.

A few weeks ago, the computer started having issues charging the keyboard's battery.  Worse, it refused to boot at all!  It was quite badly stuck and would not even show the BIOS Dell logo...  Uh oh.

After looking around the forums, I found that the thing to do was to open up the machine, disconnect the battery and the RTC battery (marked), and

then hold the power button for a few seconds.  Upon reassembly, this procedure seemed to restore life to the machine.  Plugging the machine into its dock or the folio keyboard seemed fine, but plugging in the heavier keyboard killed it again!  Figuring that the cause was the keyboard, I ordered a replacement.

The replacement seemed OK except that the spare battery was not detected.  This is apparently a "design feature", and requires you to charge the keyboard separately first.  So I did that, and then trouble struck again...  When the keyboard battery was charged, it bricked the machine again!  Uh oh... evidently the keyboard was not the problem, even though it seemed otherwise.

More searching of forums revealed that the problem is actually that the pins on the bottom of the tablet had retracted into the case and therefore where not making good contact anymore.  The dock uses a separate connector, and is therefore unaffected, and the folio keyboard connector pins are apparently longer.  Since I had to take apart the machine again anyway, I followed the forum post's advice and removed the rest of the case to expose the pins.  This being a modern-ish computer, not only are there screws (with standard heads, thankfully) there are also many delicate-but-stiff spring clips.  I think I managed to avoid breaking them!

It was straightforward to very delicately and gently tap the pins using my staking set from the inside of the case ...

... until they slightly emerged from the bottom of the case as they should.

 
I reflowed the solder (using lots of flux) around the connector to make sure I hadn't accidentally broken any connections in the process.

This seems to have fixed the problem, as I am posting this using the keyboard and both batteries are indeed showing up as present!

Update (4/24/2017):
When I got to work, the desktop dock didn't work... and later the machine flaked out on the keyboard again.  Argh.  It turns out that the two ribbon cables for the daughterboard at the bottom of the case under the battery (one for the dock, labeled as such on the cable and "DOCK 41 PIN" on the board, leftmost, and the other labeled "LCM" on the cable and "DOCK 45 PIN" on the board, next to it on the right) needed to be reseated.  The cable displacement was not visible (to my unaided eyes) but was visible under a 5x loupe.  In any case, reseating both cables seemed to fix it.  Indeed, the loose ribbon cables might have been the problem all along!

More links about this problem:

• Reseating internal ribbon cables: http://www.dell.com/support/article/us/en/19/SLN291143/venue-11-pro--5130--tablet-keyboard-does-not-function-when-docked-on-a-travel-keyboard?lang=EN  
• Detailed debugging thread: http://en.community.dell.com/support-forums/mobile-devices/f/4586/t/19568048