Over the past couple of years,my Weller WESD51 soldering station had been getting progressively flaky. Sometimes, I would have to fiddle with it for a while to get it to heat up. Finally, one day, it just stopped heating altogether. I had trouble finding info on how to fix it, mainly because I couldn’t even find the pinouts for the soldering pencil attachment jack.
Finally, I hit the jackpot last week. I found this thread in AllAboutCircuits discussing a similar model, the WES51. The main difference between the WESD51 and the WES51 is that the WESD51 has a digital temperature display, while the WES51 only has a status LED. While the thread didn’t tell me how to fix it, I found the user/troubleshooting manuals attached! I have linked the manuals at the bottom of this post. Unfortunately, following the troubleshooting guide didn’t help me find the problem, because everything checked out OK.
Then I found this guy’s YouTube video on fixing a WES51 that wouldn’t heat up. As I suspected, the PCB’s in the two different models is very similar. In the guy’s video, he fixes it by replacing a 2.2uF capacitor that’s connected to the heater’s power transistor. I checked the corresponding capacitor in my WESD51, and sure enough it was bad. I found a in my junk parts bin to swap in and bingo, my WESD51 is working again! The step by step procedure is below.
Step 1: Open the case
First, you need to open up the case. Pop out the rubber feet at the bottom of the controller case. Underneath are philips screws.
After you remove all four of them, the blue upper body easily separates. Here’s what’s inside:
Step 2: Remove PCB
Separate the green PCB from the casing. You don’t have to remove the temperature adjustment knob from the faceplate. Locate the 2.2uF/50V capacitor. It’s circled in red in the photo below:
Step 3: Remove existing 2.2uF capacitor
Carefully desolder the capacitor circled in red above. If you don’t have a capacitance meter, just try swapping in a new part, and see if it fixes the problem.
Step 4: Solder in a replacement capacitor
Make sure to pay attention to the polarity of the electrolytic capacitor… the negative terminal faces the line of SMT resistors on the right of the photo above. I didn’t have an exact replacement in my parts bin, so I just used a 4.7uF/25V part… the circuit voltage is 24V, so 25V isn’t much headroom, but it’s easy to replace it again if it fails in the future. Before putting everything back together, I fired it up, and it was heating again!
Commercial mine machines are quite expensive, and often inflexible, containing only a few canned programs. In this series, I will show how to build an infinitely reconfigurable photic-stim mind machine on the cheap. Rather than build an oscillator circuit, we will drive our mind machine with computer-generated waveforms via an audio player. You can use your favorite audio playing program on your computer, or a portable MP3 player.
UNDER CONSTRUCTION: I still have a ways to go w/ filling in details, but I thought I would at least throw up the article first, since it might take me forever. Please pardon the omissions.
Photic-stim goggles cost typically more than $50, but they’re typically built with only <$1 worth of LED’s, and some cheapo ski-type sunglasses.
Below are the lightframes which came with my Sirius AVS machine, which I purchased from MindModulations.com.
Note how they are just as I described above, a cheap pair of ski-type sunglasses, with 8 LED’s wired into a sheet of black plastic. The plastic is attached to the sunglasses with double stick foam tape.
Below are the materials we need for our project:
Bill of Materials (BOM)
Ski goggle style sunglasses. I purchased this pair for under $10
Stereo wiring with 1/8 in phone plug. A cheap pair of earbuds from a local 99 Cents Only Store is perfect for cannibalizing.
Thin, flexible black plastic sheeting. A spare DVD case courtesy of junk mail from AOL will do fine.
LED’s. The type and number of LED’s is up to your own taste. Since my design uses the black plastic sheet insert, I picked 3mm LED’s… they need to be small enough that they won’t bump into your eyes when you’re wearing the goggles. If you want to drill directly into the goggle lenses and eschew the plastic sheet, you can use bigger LED’s. I bought my LED’s from UniqueLEDS.com. They have an extensive selection, and list detailed specs for the LED’s, including brightness. SUPERBRIGHT
Not pictured is a few inches worth of hookup wire. I had some kynar-insulated 40AWG wire wrap wire laying around, which was perfect, due to its extremly thin diameter.
How many LED’s you use is up to you, but the minimum is two, one for each eye. I decided to use 8 … 4 for each eye. Also, I used two different colors, green and blue, on alternating diagonals. Note that my LED’s have 3 leads instead of the usual two. This is because I had a wild idea of using bicolor LED’s so that I could get different color combinations, but I’m not very sensitive to the colors, so I decided to hook them up like one-color LED’s. There are various recommendations on the web for color selection. Personally, I like the bright white LED’s that my Sirius frames used, but I decided to experiment with colors on this set.
First, cut the black plastic which will support your LED’s. Ask I said above, you can skip this step, and drill directly into the lenses, but it will look a lot uglier, since the wiring will be exposed in the front. Also, the drilling method doesn’t let you easily reconfigure the frames if you change your mind about the layout. I used graph paper to make a paper template for my LED layout:
You should lay out the LED’s so that they’re fairly well-centered over your eyes. If you space them out a bit, it will allow for inaccuracy, and eye movement. Note that my layout is rotated 45 degrees with respect to the layout used by the Sirius. My DVD case was soft enough that I could just use scissors to cut out the template, but you may need to use an X-acto knife.You can use a drill for the holes, but I spun an X-acto knife around, instead, and slowly increased the size of the holes until I had a tight fit. (BTW, for the curious, those are not my hands in the photo).
I misaligned one of the holes a bit, as will be apparent in later photos, but it works fine, even though it’s a bit ugly.
Since we want to keep the LED’s far enough away that they don’t hit your eyes, we need to bend the leads as tightly as possible. I used a pair of needle-nosed pliers, but if you’re careful, you can just use your fingers on the edge of your desk:
Here’s what they look like when they’re done. Since my layout uses alternating colors on the diagonals, I first bent two of the green LED’s. Then, I bent another pair of green LED’s in the opposite direction. The opposite polarity of the bending is important, because the LED’s are hooked up in parallel. Here’s what they look like before I cut the leads:
Now, the wiring and layout of the leads will vary considerably, depending on how you want your LED’s to behave. The lightframes I built behave very differently from the Sirius lightframes, which utilize the industry standard wiring. In the Sirius setup, all 4 LED’s on a particular side light up synchronously. The left side responds to the left channel, and the right side responds to the right channel, so the two sides can be controlled independently. This is an example of how they can blink:
My design mimics the IC/D setting of TC-Softworks lightframes, hooks up each pair of diagonals together. The greens respond to the right channel, and the blues respond to the left channel. Therefore, both eyes are always lit, but the intensity and color can vary.
You can use your imagination to come up with your own unique design.
If you are building your goggles to work with a particular mind machine, be aware that there is another variation in the wiring, which affects the compatibility. All of the schematics I have shown up to now have used Common Ground (CG) wiring, where the cathodes (grounds) are all tied together. Some machines, such as my Sirius, use Common Power (CP) wiring, where the anodes (power) are tied together. Before wiring up your goggles, make sure you know if you need CG or CP wiring. As it stands, the goggles I built are incompatible w/ my Sirius.
You must also be aware that which polarity you choose will affect the polarity of the signals that you use to light up your goggles. CG goggles light up when the signal is positive, and CP goggles light up when the signal is negative. Thus, if we use the following signal, CG goggles would light up in the first half of the cycle, and turn off in the second half, where the signal goes negative.
On the other hand, CP goggles will do the opposite, and be dark in the 1st half cycle, then light up in the 2nd half cycle.
Next, I fit them into the plastic, and soldered the wires:
Be careful to solder as quickly as possible, and not to use a high-wattage iron, because LED’s are semiconductors, and can easily be destroyed by overheating.
The inner pairs of LED’s have to be bent a bit differently, so that the leads don’t touch and short out w/ the outer pair of LED’s.
In my case, they were the blue LED’s. Note that the LED’s w/ the extra bend actually go on the inside, so I had to take the first pairs out first. Here’s what they look like up close. Although the inner and outer wires look like they’re touching, there’s a tiny clearance. Here’s what it looks from the other side:
I know, I know, the holes are a bit off, but it’s accurate enough.
Next, I connected up the wiring. Since my goggles are wired up for CG, the center leads (the cathodes) of all of the LED’s are wired together. The anodes of each color are all wired together. NEEDS PIC OF TRS WIRING HERE
Typically, OpenEVSE firmwares are flashed into the board using a hardware programmer, such as a USBasp. In the past, this was required, because the firmware had grown so large that there was no space left in the ATMega328P‘s flash to fit in a bootloader. However, the latest versions of the AVR tools that come with Arduino have shrunken down the binaries to the point that we now have space for a bootloader. Once the bootloader is installed, OpenEVSE can be programmed in exactly the same fashion as an Arduino Pro Mini, via a USB->TTL UART adapter, such as a FTDI cable, using the stk500 (arduino) protocol.
Before we can program the chip with a bootloader, we need to make a minor hardware mod. After a reset, the bootloader waits to see if a new firmware wants to be flashed before proceeding with booting the installed firmware. It is only during this very small time window that the ATMega328P‘s MCU is ready to accept a firmware. In order to trigger a reset via software, we need to connect the DTR pin of the FTDI cable to the RESET pin of the MCU via a .1uF capacitor.
The DTR pin is on the far left of the 6-pin serial connector. The RESET pin can be accessed at either the left side of R10, as pictured above, or at Pin 5 of the ISP connector (red circle).
Once the hardware mod is in place, we must set the fuses to use a bootloader, and flash in the bootloader, using a hardware programmer. In this example, we will use OptiBoot, because it’s smaller and faster (115200 baud) than the standard Arduino bootloader.
Substitute your FTDI cable’s virtual serial port for COM5 above.
For those who are not comfortable with command lines, it’s also possible to use the Arduino IDE to burn the bootloader, and flash in firmwares.
Set your board to Arduino UNO by using the menu to navigate to Tools->Board->Arduino UNO
Select your hardware programmer via Tools->Programmer
Install the bootloader via Tools->Burn Bootloader
Disconnect the hardware programmer, and use Tools->Port to select your FTDI cable’s virtual serial port.
Thereafter, you may flash in your sketches with the upload button. The above procedure will also work with any DIY or other Arduino clone which is not wired for a bootloader. Note that the bootloader takes up 512 bytes, so your maximum sketch size drops from 32768 to 32256 bytes.
I’m working on an application where I need fine adjustment of PWM frequency. The existing PWM code that I found, such as the Arduino PWM Frequency Library, only allows integral frequencies to be selected. On pins supported by 16-bit timers, the Arduino PWM Frequency Library allows fine adjustment of duty cycle, but not frequency. After searching for a while, I found an interesting article in Udo Klein’s Blinkenlight blog: Flexible Sweep. In the article, Klein has an Arduino sketch which sweeps the LEDs of a Blinkenlight board from 0-999.9999 Hz in increments of .0001 Hz.
I hacked his sketch into PrecisionPWM, which outputs PWM to any arbitrary digital pin in increments of .0001 Hz. What’s nice is that since it doesn’t use the ATmega’s internal PWM generator, you can use it on any arbitrary digital pin, whether or not it supports hardware PWM.
AVRDUDE has a little-known command line parameter, -B, which sets the bitclock, and can dramatically speed up writing/reading firmware to/from an AVR MCU when using a USBasp or USBtinyISP. For a USBasp, simply add -B0.5 to your command line parameters. Example:
The speedup is even more dramatic with the USBtinyISP. In a specific test, I found that write/verify time dropped from 59 sec to 17 sec!
You can also speed up programming from the Arduino GUI. Simply edit your programmers.txt file. In older versions of Arduino, it can be found in <ArduinoFolder>/hardware/arduino/avr/boards.txt. For Arduino 1.8.x, it’s located in C:\Users\<YourUserName>\AppData\Local\Arduino15\packages\arduino\hardware\avr\<version>\programmers.txt.
For the USBasp, add the -B0.5 parameter to the usbasp.program.extra_params line:
In order to realize the speed gain in programming, the USBasp must have firmware which supports the setting of SCK. If AVRDUDE gives you this warning:
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
For wireless control of WS2812B (NeoPixel) LEDs, I initially played with Bluetooth SPP (Serial Port Profile), due to the simplicity of setting up the host software… from the host’s software’s point of view, the connection just looks like a physical serial port. Unfortunately, the flakiness of my Windows 8.1 PCs’ Bluetooth SPP support caused me to abandon that solution.
WIFI CONTROLLER HARDWARE
ESP8266 modules provide a very low cost method of interfacing WS2812Bs to WiFi. Adafruit’s Huzzah module costs $9.95, but on eBay, NodeMCU clones, such as the LoLin NodeMCU board can be had for ~$3 shipped from China. This makes it even cheaper than the Arduino/Bluetooth combination!
What’s more, the LoLin board has a CH340G onboard, so it doesn’t require a FTDI cable to connect it to your host computer for programming. I ordered a few of the LoLin boards, but in the meantime, I started playing with the Adafruit Huzzah boards I had on hand.
With the addition of ESP8266 support via the Board Manager, Arduino becomes an easy to use platform for code development. Also, there are easily obtainable libraries for both WiFi configuration and control of the WS2812Bs.
One extra complexity of using an ESP8266 to control WS2812Bs is that the ESP8266 is a 3.3V device, while the WS2812B is a 5V device, (usually) necessitating level shifting. The WS2812B datasheet shows a threshold of >= 0.7VDD for logic HIGH, and <= 0.3VDD for logic LOW. The allowed VDD ranges from +3.5-5.3V. Interestingly, some WS2812Bs can actually work when powered by 3.3V, and driven by 3.3V logic, even though it’s out of spec, but many cannot. On the other hand, it’s totally within spec to be powered by 3.7V and driven by 3.3V logic. So, if you use a 3.7V LiPo battery to power the WS2812B strand, the WS2812B data line can be connected directly to the ESP8266 without any level shifting! If you choose to go this route, power the Huzzah from its VBat terminal, so that the 3.7V will be regulated down to 3.3V to power the ESP8266. More details are available in Adafruit’s NeoPixel Uber Guide.
Since I want to be able to drive long strands of LEDs, I elected to go the 5V power with level shifter route. Also, I have lots of 5V power supplies laying around. There are many different ways to do level shifting, either passive or active. The WS2812B has tight timing requirements, and runs at 800KHz, so care has to be taken in order to avoid signal distortion. One of the most reliable methods is to use a 74AHCT125 level shifter IC. I decided to first try a simple diode and pullup resistor circuit (credit: RPi GPIO Interface Circuits):
The circuit is currently working flawlessly for me, driving my 5m long strand of 150 LEDs.
WIFI COMMUNICATION PROTOCOL
In order to send data to our WS2812Bs over WiFi, we need some sort of IP protocol. Art-Net is a royalty-free protocol, which sends DMX data embedded in UDP packets. I decided to go with Art-Net because it is an industry standard that is supported by a variety of Pro software, and Jinx! and Glediator can talk to it.
I will not go into how to set up Arduino to compile sketches for the ESP8266, as that is discussed elsewhere. To compile for the Huzzah, select it as the compile target from the Tools pulldown menu:
Tools -> Board -> Adafruit HUZZAH ESP8266
I created a sketch, which is a mashup of a few different projects from github. The code is in my github repo: WS2812ArtNet. I stripped the Adafruit NeoPixel library down to the bare metal, and added a captive portal for configuring the WiFi connection. Also, it supports a hardware pin to erase the WiFi settings. Configuration is done via a few defines in WS2812ArtNet.ino. See the #defines for PIXEL_CNT, PIN_DATA, PIN_LED, and PIN_FACTORY_RESET. At a minimum, PIXEL_CNT must be set to the number of LEDs in your strand.
PIN_DATA is used to select the pin that’s used to drive the data to the LED strand.
PIN_LED is used to select the a pin which blinks an LED every time an Art-Net packet is received. This makes it easy to tell if the board is receiving data. In addition, the LED is initially off at boot-up, and turns solid red when the ESP8266 connects successfully to a WiFi AP. By default, PIN_LED = 0, which makes it control the onboard red LED on the Huzzah.
PIN_FACTORY_RESET wipes out any saved settings and clears the EEPROM when it’s grounded for 2 sec.
To load the WS2812ArtNet sketch into the ESP8266, first press the GPIO0 and Reset buttons simultaneously, and then let go of the Reset button. The red LED will then glow dimly, indicating that the bootloader is active. Once the sketch is loaded, when the ESP8266 initially boots up, it will create a WiFi AP with SSID WS2812ArtNet_hh-h. Use a computer, phone, etc to connect to the AP. Upon connection, it should automatically present a captive portal for configuration:
If the captive portal doesn’t automatically launch, open a web browser, and point it to http://192.168.4.1. Tap on Configure WiFi, and the ESP8266 will automatically scan for available APs:
Tap the desired AP’s SSID, and type in the passphrase. Additionally, you can also choose a starting Art-Net universe, and configure a static IP. After you tap save, the ESP8266 will reboot. If it connects successfully to your AP, the onboard red LED will light. Then, the LED strand will go into the startup test sequence of lighting up red, green, and blue, and then turning off. Once Art-Net data is received, the LED still start blinking with every packet it receives. If you have trouble during setup, you can see debug messages by opening the ESP8266’s serial port in a terminal set to 115200,N,8,1.
When configuring Jinx!/Glediator, select GRB as the pixel data format.
I’ve been laying the groundwork for doing some projects using remote controlled RGB LEDs. My first attempt was Lampduino, which used discrete RGB LEDs, and an ITEAD Colorduino as a controller. In that project, I ran into several pitfalls:
though inexpensive, assembly of the LED matrix was very labor intensive
the LED’s were rather dim, due to the limited drive capability of the Colorduino
the frame rate was slow, due to limited baud rate and RAM
while it was scalable, I didn’t like the idea of having to use a separate Colorduino for every 64 LEDs
A few years have passed, and WS2812B LEDs have dropped enough in price enough to get into the range that I feel is affordable. They can be found on eBay and AliExpress very cheaply. Also, they can be controlled without any specialized hardware – all that is needed is one GPIO pin. There are libraries available for many of the popular microcontrollers. Some examples are Arduino, ESP8266, Teensy 3.x, and Raspberry Pi.
The other piece of the puzzle is control software. For Lampduino, I hacked uRaNGaTaNG’s mtXcontrol Processing sketch into rgbMtx, but I found Processing to be a very limiting platform, which was hard to debug. This time around, I found a couple of interesting free LED control programs, which are both quite powerful. The first one is Jinx! LED Matrix Control, which runs on Windows only, and the second is Glediator, which is a Java app. Both programs, while free, are not open source. However, they are both powerful enough to do some interesting things.
I decided to start my experiments with an Arduino Pro Mini clone, because they have a tiny footprint, are cheap (clones are <$2 shipped from China on eBay), and I happened to have some laying around. Also, the Arduino Pro Mini’s ATmega 328P MCU runs at 5V, so no level shifting is required when interfacing to WS2812Bs. Glediator’s creator, Solderlab, has barebones, fast serial client Arduino sketch which can be downloaded at: WS2812-Glediator-Interface. It can run on any 8-bit ATmega-based Arduino such as the Mega, UNO, Deumilanove, etc. The code that outputs the data to the LEDs is written in assembly language, and is thus, very fast & compact. Also, rather than using Arduino’s Serial library, it contains its own very compact serial code. At the expense of a little bit of speed, I decided to generalize it a bit, and add my own packet protocol. My code is on github at: WS2812Remote. The main changes that I made in my version of the code are:
Since I didn’t understand the Glediator example’s serial code, I reverted to using Arduino’s built-in Serial library. I’ve tested it with baud rates up to 1000000 and an FTDI cable on a Windows PC, and it works fine
I added support for my own packet protocol. Glediator’s serial protocol is extremely simple. Each frame starts with 0x01, followed by the pixel data stream. My simple packet protocol adds an XOR check byte, as well as a few simple commands such as color fill and blanking of the LEDs.
I also wrote a C++ program, called pkt_test, which demonstrates usage of my packet protocol.
Hookup of the WS2812B LED strand to the Arduino is quite simple. You can use any 8-bit Arduino. First, you must select a data pin to drive the strand. I arbitrarily decided to use pin PD2. For speed and compactness, instead of using Arduino functions to access the data pin, the code refers to the ATmega port and pin numbers, rather than Arduino’s rather arbitrary digital pin numbers. On the Arduino Pro Mini, digital pin 2 = PD2, as can be seen from the following pin mapping diagram:
Next, PIXEL_CNT needs to be set to the number of LEDs in your strand. I tested with an Adafruit NeoPixel ring containing 16 LEDs:
#define PIXEL_CNT 16
Connect your the data input pin of the first LED of your WS2812B strand to your selected data pin. Adafruit recommends a 300-500 ohm inline resistor to protect from voltage spikes. The NeoPixel ring I used already has a resistor onboard, so I didn’t need it. I connected the +5V and GND pins directly to the corresponding pins on the Arduino. To protect against current inrush when powering it up, Adafruit also recommends connecting a 100uf capacitor between the +5V and GND pins. However, it’s not necessary if you’re just going to power it from USB, which is what I did, since I was only powering 16 LEDs. For large strands, you will need an external power supply to supply sufficient current, as each LED can draw up to 60mA at full brightness. If using an external power supply, make sure to always apply power to the WS2812B strand before the data pin!
HOST SOFTWARE CONFIGURATION
I used the same FTDI cable that I used for programming the Arduino as a virtual com port for sending data to it. When configuring Jinx! or Glediator, select Glediator protocol. For speed, the sketch just receives raw pixel data, and dumps it out to the LED strand, so the data format is in native GRB order.
When configuring Jinx! or Glediator, select Glediator as the device type (Jinx!) or output mode (Glediator). Make sure that the baud rate of the corresponding com port matches BAUD_RATE as defined in your sketch. I tested 115200 and 1000000 bps with my FTDI cable, and both worked fine with both programs. It failed at 1250000 bps.
If you want to play around with my packet protocol, the pkt_test code is self explanatory. I tested it with Visual Studio 2015 in Windows 8.1, and g++ in Debian linux 8.2.0. Prior to compilation, set COMM_PORT to correspond to your Arduino’s serial port. Also, confirm that BAUD_RATE in ../WS2812Remote.h matches the value that was used when loading the Arduino sketch. To compile and run pkt_test in linux, use:
My first inclination for wireless control was to use Bluetooth, due to its simplicity. The Bluetooth SPP (Serial Port Profile) makes it easy to construct a wireless virtual serial interface between a host computer and the Arduino. This allows you to use exactly the same host software configuration that you would for a direct serial connection to the host. I had an Elechouse EHB Serial Bluetooth Module in my parts bin (very similar to the ubiquitous HC-05), so I decided to try it out.
Before using the EHB module can be used, it must be configured with a series of simple AT commands. I hooked it up to my Windows PC with my FTDI cable, and used PuTTY as a serial terminal to configure it. Connecting the EHB module to the Arduino is quite straightforward:
Arduino -> EHB
5v -> VCC
GND -> GND
RXD -> TXD
TXD -> RXD
Pairing the EHB to a host computer creates a virtual serial port for the host software to access. Unfortunately, I was using Windows 8.1 as my host computer, and its handling of Bluetooth SPP clients is rather flaky. Every time I powered down the LED controller, I had to unpair/pair the Bluetooth in order to get the virtual serial port to work properly. While it worked flawlessly when the virtual serial port was functional, ultimately, I abandoned Bluetooth due to the flakiness of Windows’ Bluetooth SPP support. Perhaps Linux can handle it better.
I recently upgraded to Arduino 1.6.13, and found that I could no longer program my boards with my Chinese USBasp clone programmer. When the Arduino IDE tried to load the firmware with my USBasp, AVRDUDE couldn’t find my USBasp, and gave this error:
avrdude: error: could not find USB device with vid=0x16c0 pid=0x5dc vendor=’www.fischl.de’ product=’USBasp’
It turns out that the that AVRDUDE 6.3, which is bundled with Arduino 1.6.10+, has timing issues with USBasps. The fix is to replace your libUSB-win32 driver with libusbK v126.96.36.199. An easy way to install libusbK v188.8.131.52 is to use zadig. Download the zadig from
Launch zadig, and from the menubar, select Options->List All Devices
Next, from the top listbox, select USBasp.
From the Driver selector box, click the up or down arrow key until libusbK (v184.108.40.206) appears.
Finally, click the Replace Driver button.
The screen should look like this:
You do not have to reboot or disconnect/reconnect your USBasp. After Zadig finishes installing libusbK, AVRDUDE 6.3 will start working correctly with your USBasp.
NOTE: the version of AVRDUDE that Arduino 1.6.x uses is actually controlled by the Boards Manager (Tools->Board->Boards Manager). Even if you have a version of Arduino 1.6.x prior to 1.6.10, if your Arduino AVR Boards by Arduino is version 1.6.10+, it will use AVRDUDE 6.3.
I just replaced the battery in my iPhone 6. When I attempted to power it up with the new battery, I was greeted with this ominous screen:
which is strange, because there’s no way that it was too hot, since it was just booting up, and it wasn’t even warm in the room where I was doing the work. I was worried that maybe I had broken something during the battery swap, but luckily, it was just bad contact in the battery connector. It turns out that there is a temperature sensor in the battery, and if it has a bad connection, then the iPhone will think that the battery is overheating. I tried pressing down on the battery connector, but that didn’t work. Next, I simply disconnected/reconnected the battery connector, and it booted up normally. Whew!
So, if you replace your iPhone battery, and it suddenly gets the over temperature warning screen, first check the battery connection. If the warning still won’t go away, but it goes away when you reconnect your old battery, then your new battery probably has a bad temperature sensor.
To remove the screen, I simply attached a suction cup at the end of the screen near the button. Then, while pulling up on the suction cup just enough to make a gap between the bottom of the screen and the back, I slid a guitar pick into the gap, starting at the bottom, and working my way down the edges of the phone, pushing it in gently. You can feel the clips releasing as you push the guitar pick in, and the screen will start to pop out, clip by clip. In Step 6 of the iFixIt instructions, they don’t emphasize the need to release the clips. If you just pull up, you’ll probably damage some or all of them.
I didn’t bother disconnecting the screen. In iFixIt’s instructions, they ask you to unscrew the screen connectors and completely remove the screen. Presumably, this is so that you don’t risk damaging the screen connector, lest you let it swivel back more than 90 degrees from the back. I didn’t bother disconnecting the screen, and instead, held it ajar with my left hand while doing everything else with my right hand. This is because the tiny connectors are very fragile in the iPhone, and I didn’t want to damage the screen connector when disconnecting it, or losing the screws (I had a very bad experience when I was trying to change the battery of my iPhone 4 a few years ago.. the replacement came with a connector that was very tight.. and when I tried to disconnect it, the whole socket broke off the PCB, rendering the iPhone useless).
I don’t have a pentalobe screwdriver, and I don’t intend to buy one. I’ve successfully removed/replaced the screws at the bottom of several iPhones using a Xacto knife as a screwdriver. The tips of my #11 Xacto blades always break off, and the broken off tip fits perfectly into the pentalobe screws.
Now, I’m waiting for the replacement battery to charge up, to see if it’s any good. I always have trouble finding replacement batteries that actually work better than the broken old batteries that they replace. There are a lot of shady suppliers out there who sell used or low quality batteries. I used the free Battery Life app to check the charge cycle count:
The vendor I bought the battery from claimed that it would have zero charge cycle count, and it has one, but that’s close enough, so I’ll let it slide for now. The capacity is also at 1752/1752, as expected. Of course, these stats could be faked, but at least they appear to be OK, which is some piece of mind. Only usage testing will reveal whether or not I managed to buy a good replacement battery, or another dud.
Update 20160804: So, it turns out that my phone was constantly running hot with the “hand picked” replacement battery I bought on Amazon. I highly recommend that anyone who replaces their battery on an iOS product check it with the free Battery Life app. I found out that the controller chip in the replacement battery was fake. The only stats that would change were the battery voltage and charge leve. The discharge current, temperature, capacity, and cycle count were fixed. After a month of using the battery, the Cycles were still 1! I contacted the seller, and they quickly refunded my money without asking me to send back the defective battery. Buyer beware!
It infuriates me how so many WiFi routers are designed with inadequate cooling. I have a whole pile of routers that got flaky or crapped out after a few years due to overheating. The only ones that are still rock solid after years of continuous service are my WRT54Gs. My Linksys E4200 has been getting long in the tooth lately. On hot days, I need to blow a fan on it, and lately, even colder weather, it slows down to a crawl at random times and needs a reboot. I could try installing a big heatsink in it, but I thought maybe it was time for an upgrade to one of the fancier new technology routers. What most people don’t realize about the latest crop of router technology, such as AC3200, is that unless you upgrade your clients, you’re not going to get performance anywhere close to what these things can do. Most of the devices in my house are 2.4GHz 802.11n and can’t even handle MIMO, but smallnetbuilder had an article which showed that you can get a speed boost with 802.11n on a 802.11ac router. I figured I might as well future proof myself and look for a midrange AC router.
After lots of research on smallnetbuilder’s site, I settled on the Linksys WRT1900AC. This router, built by Belkin, is a nod to the venerable WRT54G, and is designed to be hacked with open source firmware. The specs are pretty good, even in the 2.4GHz band, which is often neglected these days, and I was particularly impressed with the speed of its NAS function, which vastly outperforms anything out there. It has a USB 3.0 port + a combo USB3.0/eSATA port on the back, and lightning fast storage performance. When I received it, I was impressed with the build quality. This thing is a beast! It looks like a WRT54G on steroids, and makes its predecessory look like a toy. Big & beefy and heavy. I specifically got the V1 because it has a built in cooling fan which kicks in only when necessary (which isn’t very frequent, due to its gigantic heatsinks). The later V2, also known as the WRT1200ACS, no longer has a fan. This is not going to be a full review of the WRT1900AC, but only a synopsis of my experiences trying to get decent 2.4GHz throughput out of it.
I really wanted to like the WRT1900AC. It is a thing of beauty, and I spent quite a few hours trying to tweak it, but to no avail. Despite the 90Mbps 2.4GHz LAN to WAN downlink throughput measured by smallnetbuilder, I was not able to get more than about 30Mbps downlink out of any of the devices in my house, even when sitting only a few feet from the WRT1900AC. This is only about half what I get out of my old E4200, which works as fast wirelessly as it does through Ethernet, maxing out at almost 60Mbps, which is the speed of my Time Warner cable service. No amount of tweaking over two days (about 6 hours of mucking with it) could speed up the 2.4GHz downlink performance. I scoured google for tweaks and even tried OpenWRT. I figured that I could figure out to get more speed out of it with OpenWRT’s tweakability, but it actually got slightly slower.
Although the speed with a very strong signal was only half as fast as my E4200, at the edges of my house, where the signal was weak, the WRT1900AC performed admirably, giving not only better throughput, but also being able to actually function at distances where the E4200 signal was completely dead. This left me in a dilemma, because the extended range is actually pretty useful to me. Also, for some reason, the storage performance came up quite short of what was tested by smallnetbuilder. I have a Seagate 2TB USB 3.0 drive, which is normally connected to a hacked Pogoplug E02 running Debian linux. The Pogoplug only supports USB 2.0, and doing a file copy across the network on Windows 8.1, I the maximum throughput I get is about 11MBps. Disappointingly, when attached directly to the USB 3.0 port on the WRT1900AC, the throughput topped out at a measly 4MBps. This was the last straw for me.
The 5GHz wireless performance on the other hand, was terrific. It easily saturated my 60Mbps downlink. But I can’t just switch to 5Ghz, because its range is too short in my house, and the signal drops out in some of my bedrooms. Also, not all of my devices support the 5GHz band. So, with a heavy heart, I decided to return the WRT1900AC. Just as I suspected, upgrading to the fancy 802.11ac router doesn’t necessarily help performance with 802.11n clients. In fact, looking at smallnetbuilder’s testing, lots of the latest and greatest routers put less emphasis on 2.4GHz performance, so if like me, you don’t have any 802.11ac clients, you should save your money and buy something cheaper. As for me, I’m going to try hacking a temperature-controlled fan into my old E4200, and see if that makes it more stable.