Exercise 13 Output device...


This week’s Assignment is to use the board we have designed, and stuffed, to control output devices. Output devices ranging from RGB LEDs, WS2812 aka NeoPixels, Servo, DC motors, Relays and such. Yours truly is no stranger to controlling stuff with MCU. Back in 2014, he has modified a standard UK multiplug and stuffed it with a store bought (read: sparkfun) Solid State Relay (SSR) board, such that a MCU able to control AC with it. More details at his instructables here. With this contraption, yours truly then controlled an lamp running on AC over the Internet; instructables is available here

This week, I planned to hook my ESP8266 ESP12-E board to a servo for a quick test, then follow by SSR. In Fab Academy Inventory, the SSR model is CPC1964B. Unfortunately, we do not have it in stock. When I try to get it locally via element14, the stock status is awaiting delivery. The delivery date is way pass the submission date. I also discovered I could not find the footprint for CPC1964B is not in fab.lbr. therefore, more time need to be spent on learning how to create a part footprint via this tutorial here. update1: I have ordered an SSR of similar footprint but with twice of the load current of CPC1964B at 3A, the CPC1966B. Then I have created the custom SMD footprint for it. be sure to check the subsection below.

Instead of waiting, I have decided to use what that is available from our labs, the G3VM-351B, can is capable of a continuous current load of only 120mA, good enough to turn on off a small lamp.


On the week on input devices, I have documented my adventure on using my ESP8266 ESP12-E board that I have designed and stuffed to acquire temperature. From then on, I have made another board, with a slight variation to use regular header pins that are available a plenty at my secret stash. Thinking that my experience with this ESP8266 ESP12-E board a couple week back would be sufficient for the week on output devise. Thus this week, I intent to focus on the more pressing matters that concern my bread& butter. Well, one has to focus on tasks that pay the bill isn’t it. My original assumptions were to get the pressing matters addressed first, then follow by testing output devices such as servo and SSR.

Source files Download

The SSR G3VM-351B schematic, board, and gerber available here
The custom eagle CAD parts library of SMD footprint for CPC1964B or CPC1966B download here
The CPC1964B schematic, board, and gerber download here
The ESP8266 with servo source code is available here
The ESP8266 with SSR source code is available here


The following picture describes the items I used for testing. 2 variations of CP2102 usb to serial, assortments of USB cables, and my ESP8266 ES12-E board. The reason I have used that many USB cables, and different variation of USB to serial, is to help me troubleshoot and isolate potential issues.

The following picture describes my ESP8266 ESP12-E board

Assuming you stumbled upon my page with the myriad of error codes your ESP8266 have given. Do check out my best practices subsection. I learnt it the hard way. If you are only interested what that works, please jump to the what works subsection below. Else if you are interested what are the problems I faced during this output devices week, and some possible solutions, jump to the what doesn’t work subsection.

Best practices

I am using Arduino IDE with ESP8266 platform packages installed via board managers, on ESP8266 ESP12-E. Using default baudrate 115200 when burning the firmware.
Troubleshooting ESP8266 ESP12-E can be frustrating, especially when the variables are not held at a consistent state; the problem arises can be due to the hardware or software. If one could held either one always true, is easier to troubleshoot. I prefer to isolate the hardware problems first. Assuming the hardware is always true in working condition, one could program the firmware, and then boot from the firmware. Then, we can test the functionality or the correctness of the code in of the software. Think of it like the OSI 7 layer model when it comes to troubleshooting. My guess that is why it is called hard, and not easyware.

1.	Breadboard is the source of all electrical problems: loose jumper wires from moving about, jumper wires plug into the wrong positions, wires shorted accidentally, and the worst of all, jumper wires that are broken internally. Proceed with care.
2.	 Weak supply affects the functionality of the ESP8266. Intermittent connection is very hard to figure out during troubleshooting. Eliminate it by using external power source. It is tempting to use the 5V source from the usb-serial converter for sake of convenience.
3.	Common ground. Voltage is relative to ground.
4.	Use signal quality USB cables. I have some USB cables that are shielded, some with ferrite core, some are just very thin, some are just very long (1.2m).
5.	Do not be over zealous when testing the code functions in ESP8266. Test the software function by function. Start with the most fundamental functions. Code compile without error, firmware uploaded successfully does not mean it will automatically execute the software.
The following picture describes my always work setup.

Switching between programming the firmware and booting the ESP8266 requires flipping of the GPIO pins. programming firmware ESP8266
GPIO0  --> GND
GPIO2 --> NC
GPIO15 --> GND

boot ESP8266
GPIO0  --> VCC
GPIO2 --> NC
GPIO15 --> GND

ESP8266 ESP12-E tx --> USB-serial rx
ESP8266 ESP12-E rx --> USB-serial tx
ESP8266 ESP12-E gnd --> USB-serial gnd, and devices gnd
ESP8266 ESP12-E vcc --> USB-serial 5V; devices should follow specs for 3V3 or 5V
ESP8266 ESP12-E GPIO15 --> gnd
ESP8266 GPIO0 and GPIO2 to follow the parameters mentioned above

Output: SSR G3VM-351B

G3VM-351B is a SSR without Zero Crossing. The following picture describes the PCB designed and fabricated. One is with isolation method, the other is full copper removal. Both boards passed the continuity test.

The schematic and gerber available here Labs are not opened due to public holiday (labour day). I will get it stuffed and tested, soon. Update: I have got the SSR daughter board stuffed, and performed a functionality test with my ESP8266 ES12-E board and a digital multimeter. Always perform a test without load for the fuctionality, to verify the state of correctness. Otherwise, you risked of itchy fingers by fiddling it when the boards are operational with live AC. #YOLO some said, true, You Only Live Once. The following video describes this test.

WARNING The following steps are hazardous, please proceed with care.
when dealing with live AC, you should never work alone.
First, disconnect from live AC, then fiddle with the wiring to the electronics and what not. The following picture describes the wires used to connect between the SSR to the live AC outlet. The wires at the minimum have to be tinned. better, if cable lugs can be used.

The following picture describes the modified AC outlet box to be used with my SSR daughter board. CAUTION The "live" wire or "hot wire" is exposed. do not short it or touch the metallic surface when live AC is in use.

The following picture describes the connectivity guide betweem my ESP8266 ESP12-E board, the SSR daughter board, +5V supply, and the modified AC outlet.

WARNING Do not hook up the wiring to the electronics while the AC socket is plugged into the mains or turned on. Always switch off the mains, and then disconnect the AC socket from the mains before working on the boards or wirings.

The following video describes the SSR daugher board, ESP8266 ESP12-E board, modified AC outlet box, and live AC in action with the sample code "blink", turning GPIO4 on and off at 1second interval.

Output: SSR CPC1966B or CPC1964B

CPC1966B is SSR with Zero Crossing. Do not use conventional method such as continuity test listed in the subsection above to test for functionality of the output. As mentioned earlier, this part is not available in fab.lbr nor standard eagle parts library. I tried trawling the internet for it, but could not find any. So I have decided to create the SMD footprint for this part. The following picture describes the SMD footprint in eagle.

The part is made based on the data sheet provided by the IC manufacturer. The following picture describes the mechanical specifications.

I did not get to stuff my board yet, due to some lack of components. the following picture describes the dry fitting of the IC and the board fabricated.

The custom eagle parts library SMD footprint in script of CPC1964B or CPC1966B can be downloaded here here The following diagram describes the schematic and parts layout for the CPC1966B. I decided to modified the board milled earlier to save time and materials. The schematic, board, and gerber of the following diagram available here

The following diagram describes the modified board being stuffed.

One could test the functionality of the CPC1966B or CPC1964B zero crossing SSR at the input only. To verify the opto-isolating LED in the CPC1966B is still functional, use the diode mode on the digital multimeter to measure the voltage across the input pins of the chip without powering it up with VCC. The following diagram describes the testing.

next to test whether the opto-isolating LED is operational when VCC is applied. Remember to add a current limiting resistor to the -LED pin towards GND. use digital multimeter in dc voltage mode to measure the forward biase voltage. make sure it is within the allowable range (max 1.2v) as per described in the data sheet. The following picture describes the testing.

with the above tests done, one is confident that the SSR is functional at the input side, and reduce the risk of fiddling the SSR wiring when it is plugged into live AC. Now to test the output side of the SSR, hook it up as per the diagram below.

The following video describes the SSR in operation with my ESP8266 ESP12-E board.

Output: Servo

The following picture describes the setup of my servo. The data pin of servo is connected to GPIO4.

The following is a video of servo and ESP8266 in operation

The source code is available here

What works for my ESP8266 ES12-E

Please refer to the best practices subsection.

What doesn’t work for my ESP8266 ES12-E

My adventure began when I used my regular USB port CP2102 with the long USB extension cable to program my ESP8266 ESP12-E, instead of the previous short & shielded USB cable. The firmware downloading process was disrupted while I looked away. Which I am still not quite sure what caused it? So, I thought I bricked my ESP8266, or my serial-usb malfunction.


I have tried different things to get the firmware to be burnt successfully on my second ESP8266 ESP12-E board, but was greeted with a different error message at each try. That is when the confusion and frustrations arise. The second board is almost identical to the previous one that worked, just that it sports a different type of header pins.

First, I revert into boot mode, hopefully to be able to observe ready via putty on a baud rate of 115200. Instead, the blue LED on ESP8266 ESP12-E is constantly BLUE, and I observed the following on putty via baudrate 76800. I shall call this case1

Fatal exception (0):
epc1=0x40100000, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x0                          0000000

Again, I change to programming mode on the ESP8266 ESP12-E, trying to burn the firmware one more time. This time, I got a different error message, which is the same as per recorded at the input devices weekhere

I call this as case0. So I went to check the wiring of GPIO(0/2/15),which they are in GND/NC/GND. Out of curiosity, I measured GPIO2, and found that it is at 0.7V. The funny thing is, GPIO2 supposed to be pulled up to 3V3 via a 10K resistor. I suspected something is shorted on my board, so I made some jumpers to pullup 3v3 on GPIO2. Configured into programming mode again, and try to burn my firmware. This time, the programing of the firmware is successful with GPIO(0/2/15) as GND/3V3/GND. This should not be the case, because GPIO2 is supposed to be NC in both modes.

After that, jumpers are set to boot mode, and I observed the following on putty 115200 baud, GPIO(0/2/15) as 3V3/3V3/GND
ets Jan  8 2013,rst cause:4, boot mode:(3,5)
wdt reset
load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42

Some other times I observed the following using putty at 76800 baud.
¦@*r¦¦P¦¦¦K¦t¦dr¦.@¦¦.¦?¦Ko8a /t¦$v'¦¦¦*¦T¦¦¦¦¦¦P¦¦*¦¦*¦¦¦¦nzAl )¦m~¦T[¦r¦(¦?¦/¦¦
 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42

The following picture described the above

I call this case 2A and case 2B.

With the same code, and GPIO settings, I have tried a A/B test with both of my USB-serial, and also different USB cables; advices I trawled from from internet forums. In any of the experiments described above, I cycled between case1, case2A, and case2B. The Blue LED on ESP12-E is either constant blue, flashing rapidly, or no light.

Thinking I might have bricked my second ESP8266 ESP12-E board, I followed advices here and here to flash it to stock firmware and hope that I could get back to the default AP mode. The following firmware describe the flashing done. Note there is no wire connected to my board to reset automatically.

The following picture described my second ESP8266 ESP12-E board back into default soft AP mode and receive some AT commands. Note the rst cause error message that is different from the one earlier.

As of now, I established that my ESP8266 ESP12-E chip is functional. I can burn the firmware (occasionally), but it will not boot. So it is either the wiring (GPIOs), the usb-serial, the power supply, or the firmware. Trawling on the internet again for prior cases, but the leads provided not very helpful in my situation. A lot of time wasted……………

Barking at the wrong tree

I am at my wits end of thinking what may go wrong with the second board. If I only have 1 board, perhaps I will continue with the testing of different hardware. Since I have a functional first board that work in the input devices week, I just have to use it with the existing setup that consist of the microusb usb-serial, GPIO(0/2/15)=GND/NC/GND, and external power. Guess what? The firmware compiled, and downloaded successfully. Upon boot mode, I was greeted with the following message.

Then I reverted to the source code for input devices week, the first board operates as normal. Swap in the second board with the same code from input devices week, operates as per normal too. Then it struck me: the hardware is fine, the peripherals are fine too. Code that compiled & burnt as firmware successfully onto the board does not mean it will work when rebooted. the error code displayed not necessary reflects the true error nor useful for troubleshooting. I was held hostage again by my own assumptions and experience.

Just to have a proper closure on my previous experiments w.r.t the usb-serial and usb cables. I try to recreate the “hardware” issues faced earlier (with the simplest functional code), the one that gives the least times on case0 is still the short&shielded usb cable with regular usb-serial converter. Other combination stated earlier works too, but with occasional hiccups.