Fixin’ a Glitchin’ ESP8266

Fixin’ a Glitchin’ ESP8266 – or How to use two FNB58 as a Dual Channel Oscilloscope.

So I’ve been using the ESP8266 for quite a while now within the confines of the Arduino environment. It’s been hobby stuff – playing with humidity and temperature sensors, making WiFi data loggers, controlling strings of addressable LEDs using the awesome WLED firmware, and quite a lot if other gimmicky stuff.

 

Left: Wemos Wroom-02. Right: Wemos D1 Mini

 

To continue blowing money on an expensive hobby, this time around I purchased the compact Wemos D1 Mini. This was a clone board from a local supplier in India. As with most of my purchases – you buy the board after getting inspired by a YouTube video or an Instructable, but by the time the components arrive, you’re drowning under piles of mundane 9-5 work.

This Wemos board sat in my parts bin for a few months before I pulled it out. I wanted to try out the ultra low power, deep sleep modes of the ESP8266, so I wrote up some code and threw it onto a Wroom2 board. Things worked fine, and since I was looking for something physically smaller, I pulled out the D1 Mini. After burning the code, I waited for the board to connect to WiFi and write data to a Google spreadsheet. When it didn’t, I began the task of troubleshooting.

Initially, I thought the issue was something to do with my WiFi - my WiFi is provided by the building, and I need to access a captive login page, authenticate my device, and can only proceed after this. This is quite difficult to do with an ESP8266, and the additional code complexity is unnecessary in my opinion. The authentication/registration is MAC-based, so I use a TP-Link MR3020 running OpenWRT, clone the MAC of the ESP8266, use my laptop to log in via the TP Link router, after which the ESP8266 MAC gets registered onto the network. Yeah, tedious.

 

Logging in through a captive portal by MAC Spoofing

 

But after spending an hour or so trying to find out if the MAC was being blocked, I then moved on to thinking it was something to do with Google Scripts’ authentication – it’s changed in the past, or required re-validation, since the ESP module is treated like a separate device logging into your account. I managed to eliminate any pathway issues to Google Scripts by easily achieving what I wanted to using the Wroom-02.

Then I started looking at the serial monitor, which showed a crash log with “rst cause” and “boot mode”, as well as a stack trace. I decided to take a closer look at the debug output every time the ESP8266 reset. I saw that the reset code was not consistent. It would also spit out random strings of serial, indicative of a lockup. The ESPExecptionDecoder plugin for the Arduino environment is a handy tool to aid with debugging.

 

Crash logs – the reset cause would randomly change from ‘normal’ reset to ‘power cycle’

 

By this point I thought that the seller had given me a fake ESP8266 chip. Despite these chips being literally “as cheap as chips” it was entirely possible that the seller himself, had been a victim of fake chips from the black market.

Something I noticed was that occasionally, Google sheets would populate a sensor value. So it appeared that the chip was not ‘entirely fake’. Could this have something to do with the power supply? I was powering the device from my laptop USB port – I tried swapping to shorter, thicker USB cables. I even jammed a 470uF electrolytic on the 5v rail. This didn’t really improve anything.

I went so far as to desolder and replace the CH340G chip as well as desoldered and replace the ESP8266 module with a fresh one I had around – talk about trying everything!

I finally came across Reddit threads pointing to the culprit – an underpowered 3.3v regulator. Of course, that was it! The original D1 Mini schematic specifies a Richtek RT9013 500mA regulator. The regulator on my board was a 150mA Torex XC6204 with markings 4B2X.

 

The SOT23-5 is the under-spec’d XC6204

 

After smacking myself for being dumb enough to check the 5v rail, but forgetting to consider that there was a 3.3v rail on the board too, I proceeded to make some measurements on the Wroom board, since I knew that was working well. In the graphic below, the blue trace is the 5v rail, the green is the 3.3v rail, and the red is the current. Although the first time the board connects to WiFi is not very obvious, every power on and connection attempt from 105 seconds onwards is clear. You can identify the surge in current every 60 seconds or so when the ESP8266 tries to wake from deep sleep, transmit a packet over WiFi, and then shutdown for a minute. Current spikes go to more than 450mA on this board.

 

Expected Signatures: Current (Red), 5v Rail (Blue), 3.3v Rail (Green)

 

I used a FNIRSI FNB58 USB tester to check for the current and voltage profile. Not having a dual trace oscilloscope handy, I resorted to a bit of a hack. The FNB58 is capable of measuring voltage and current in both directions. Meaning, the ‘output’ can measure a voltage. Since I had two FNB58s, I planned to use one to monitor the voltage on the 3.3v rail, and the other, to measure current and voltage on the 5v rail. I cut the end off a USB cable, connected the ‘A’ part into the output of one of the FNB58s, disconnected the FNB58 from source power, and left only the data logging / device power cable in, and used crocodile clips to attach the bare ends of the USB wires onto the 3.3v rail of the D1 Mini. This allowed me to see what was happening to the voltage. I used the provided PC software to log data – each FNB58 is logged in a separate window. I did have get creative on how to sync the data from two logs – the way I did this was to start the recording on both FNB58s, and then plug in the power to the D1 Mini. This allowed me to synchronize the rising current from the 5v log to the rising voltage on the 3.3v log.

 

The Wemos D1 Mini being tested. The FNB58 monitoring the 5v rail is naked because it went through a teardown

 

FNIRSI’s USBMeter logging software creates a cfn file. didim99 has written a simple python utility to convert these cfn files to csv. After importing the CSV files into excel, I offset and aligned the values with respect to time, and then plotted them.

 

Logs: 5v Rail (Blue), 3.3v Rail (Green), Current (Red)

A brief explanation of the plots above - three tests were done:

• Test 1 – upper track – with the original XC6204 regulator and a 15uf capacitance on the output of the regulator
• Test 2 – middle track – with 100uf extra added onto the 3.3v output of the regulator
• Test 3 – bottom track – with the XC6204 regulator replaced by a TPS73633

Left image: all logged traces (5v, 3.3v, current), middle image: only voltages (5v, 3.3v), right image: only current

 

The issue was very obviously an underpowered 3.3v regulator that was unable to keep the rail suitably powered. The 3.3v rail with 15uf of decoupling (V3_15) clearly drops out. Although not shown on the graph, it dropped several time to below 2.6v – below the reset / brownout threshold for the ESP8266. You can also see lots of noise on the 5v rail (V5_15), and the current trace (C5_15).

I had a few options – I could replace the XC6204 with an RT9013 or equivalent, or I could throw a butt-load of capacitors onto the 3.3v rail. Simply jamming a 470uF electrolytic’s leads across the 3.3v and Gnd pins, ghetto-style, was good enough to get the D1 Mini working; pulling off the capacitor resulted in the earlier mentioned streams of serial gibberish and crash logs. This behaviour gave me enough confidence that it was indeed the regulator at fault.

Left: Streams of gibberish being spewed out of the serial port
Right: Ghetto-style decoupling on the 3.3v rail. Naturally, this is not as effective if placed across the 5v rail

Since I wanted to validate, I sucked off some tantalums from a junk board I had lying around and soldered a 15uF and a 100uF from 3.3v to Gnd, while simultaneously placing an order for a couple of Texas Instruments TPS73633.

When nothing works, throw a capacitor on it! Tantalum capacitor with a bodge wire soldered from the 3.3v rail to Gnd

 

Throwing on the 100uf capacitor significantly improves voltage and current response. There are still spikes on the 5v and the 3.3v rail is about 3.23v, but the system works.

The TPS73633 chips are 400mA 3.3v LDOs with a drop out of only 75mV; if ordered in a SOT23-5 package, these are pin-compatible with the XC6204 / RT9013 – perfect for the job. I didn’t want to use an LM1117-3.3v due to the high drop-out voltage of 1.1v, and the incompatible SOT-223 package – the advantage of this chip would have been 1A of available current. Comparison of specs below:

	XC6204	RT9013	TPS73633	AMS1117
Operating Voltage	2-10v	2.2-5.5v	1.7-5.5v	4.75-15v
Max Current	150mA	500mA	400mA	1000mA
Dropout	200mV @ 100mA	250mV @ 500mA	75mV @ 400mA	1100mV @ 1000mA
Quiescent current	70uA	25uA	400uA	5000uA

 

Left: the Wemos D1 R2. Right: Wemos D1 Mini with the TPS73633 soldered on.

 

After receiving and soldering the TPS73633, and going back to the schematic capacitors left the board working perfectly happily. Looking at the log, all traces (V5_15_reg, V3_15_reg, C5_15_reg) are much cleaner, and the 3.3v rail averages 3.24v.

Interestingly, my Wemos D1 R2 Arduino Uno style board has the same XC6204 regulator (markings 4A2D). But it also has a log of capacitive decoupling on its output.

Now to get down to actually building my project

Eye-Oh-Tee

I have finally jumped onto the IoT bandwagon, so this is a better-late-than-never kinda post.

IoT – the Internet of Things, is a revolution of sorts. IoT devices promise to connect all devices to the internet. Check out any of today’s consumer electronic devices – thermometers, humidity sensors, power meters, which traditionally lend themselves well to such ‘internet-linking’, as well as non-conventional devices – toasters that tweet when your toast is done, refrigerators that Whatsapp you when you’re low on milk, and potties that change your FB status to:

“Checked in….Emptied bowels ::feeling relieved:: ”

(There’s a strong debate that the poo emoji is actually an ice cream, but I digress). Here’s an interesting article to what 2016 has in store for us (and if you’re reading this in 2020 for some reason, don’t snigger at old tech!).

IoT devices have been around for quite a while now, however only last year, with the ‘discovery’ of the ESP8266, did they become cheap and accessible to everyone. How cheap and how accessible? To quote Brian Jepson from Make - “This is inexpensive enough to be very much in the territory of ‘thousands of sensors-launched-out-of-a-cannon’-cheap.”

 

The ESP8266

The ESP8266 is an amazing device. Made by Espressif Systems, the chip is a super-cheap WiFi device, that can be configured as a host (ie Access Point), or a client. Although the ESP8266 itself comes in an evil 0.5mm-pitch QFN with no on-chip flash memory, you can find complete modules with external SPI flash memory, status LEDs, pins broken out, selling for under USD5 at the time of writing (Dec 2015). Infact a bare-bones ready-to-start module can be had for Rs.270 (USD4) in India.

When I got back home for the vacations, I decided to give myself an early Christmas gift, and picked up an ESP-01 module, and an ESP12F module, along with a few other things.

Christmas comes early! 3.3v regulators, adapter boards, ESP8266 modules (ESP12F and ESP-01), and tweezer multimeter probes for SMD stuff

Everything in the picture was bought from Inkocean (other than the mini solderless breadboard, the adapter board in the middle, and the LED).

The white adapter board breaks out the pins of the ESP12F module into a convenient breadboard-compatible pitch. The ESP-01 module is not really solderless breadboard compatible due to its dual-row pin header. To use this module, I had to build an adapter board, which you see in the middle of the picture.

 

Getting Started – AT Commands

Out of the box, the ESP-01 responds to AT modem commands sent over 3.3v UART TTL signals. The AT commands allow you to talk to the chip, view WiFi networks, connect to a network, and do several other things.

I used an FTDI Basic (you could use any USB-TTL serial converter – the CP2102/MCP2200/CH340, which are cheaper) and a simple terminal program @ 115200bps to communicate. On power up, the module initially sends some seemingly random characters (at 115200bps), but if you set your terminal program to 76800 baud (2*38400), you should see some meaningful debug data.

AT+RST soft-resets the WiFi modem
AT+GMR shows the firmware version
AT+CWLAP lists all access points
AT+CWJAP=”SSID”,”Password” joins an access point
AT+CIFSR shows the IP address once connected

Connecting to a network was pretty easy, and I was able to ping the module from my laptop’s command prompt in a matter of minutes.

Simple interface circuit

 

The Adapter Board

With its AT command set, the ESP-01 plays nice with almost any microcontroller capable of reading and sending serial strings. However, IMHO, its real power lies in the fact that it can be re-programmed using nodeMCU (Lua scripting), or the Arduino IDE (Processing), or even a BASIC interpreter. Since I am already familiar with the Arduino environment, I chose to experiment using this.

The ESP8266 can be put into various modes by setting combinations of I/O pins high or low, thus allowing it to boot from SPI flash memory (normal), or go into bootloader mode to update firmware (via UART Rx/Tx), or boot from an SD card.

To use the 8266 with Arduino code, we obviously need to put it into bootloader mode. This is done by momentarily pulling GPIO0 to ground while resetting the chip (pull RST to ground or cycle power). Doing this multiple times with dangly bits of wire would be tedious, so I made a simple adapter board with appropriate connections:

• a 3.3v voltage regulator (LM1117-33), since I’m using the 5v FTDI Basic
• 10k pullup resistor and a button to ground on RST
• 1k + 2.2k voltage divider resistors on the 8266 Rx, (to divide the 5v TTL UART signals from the Tx of the FTDI)
• Tx of the 8266 can go straight to the Rx of the FTDI
• a button to ground on GPIO0
• CH_PD pulled to Vcc (3.3v)
• Gnd to ground (where else!). Don’t forget to short the grounds of the USB-to-serial converter and the 8266.
• GPIO2 can remain floating

 
Left: top of the adapter board, and Right: bottom of the board. All pins of the vertical header are not connected; only GPIO2 and Gnd are connected at the moment. I plan to breakout GPIO0, GPIO1 (Tx), GPIO3 (Rx), and 3.3v later

 

Basic Arduino Sketch

I had a few problems getting the adapter board to work (details in the next section), but once I got it running, I threw the standard hello-world/blinky test code onto the 8266 using the following Arduino code:

void setup(void)
{
	pinMode(2, OUTPUT);
	Serial.begin(115200);
	Serial.print("Setup done\r\n");
}

void loop(void)
{
	digital.Write(2,HIGH);
	Serial.println("Testing...");
	delay(500);
	digital.Write(2,LOW);
	delay(500);
} 

And when this worked flawlessly, I tried a webserver demo:

#include <ESP8266WiFi.h>
#include <ESP8266WebServer.h>
 
const char* ssid	 = "my_SSID";
const char* password = "my_password";
 
ESP8266WebServer server(80);


String webString="";
// String to display
 
void handle_root()
{
	server.send(200, "text/plain", "Hello from the ESP8266. Use /on or /off");
	delay(100);
}
 
void setup(void)
{
	pinMode(2, OUTPUT);
	Serial.begin(115200);
	// Serial monitor

	WiFi.begin(ssid, password);
	// Connect to WiFi network
	Serial.print("\n\r \n\rConnecting....");
 
	// Wait for connection
	while (WiFi.status() != WL_CONNECTED)
	{
		delay(500);
		Serial.print(".");
	}
	Serial.println("");
	Serial.print("Connected to ");
	Serial.println(ssid);
	Serial.print("IP address: ");
	Serial.println(WiFi.localIP());

	// clauses below handle different
	// subpages
	server.on("/", handle_root);

	server.on("/on", []()
	{
		webString="LED ON";
		server.send(200, "text/plain", webString);
		// send to browser
		digitalWrite(2, HIGH);
	});
 
	server.on("/off", []()
	{
		webString="LED OFF";
		server.send(200, "text/plain", webString);
		// send to browser
		digitalWrite(2, LOW);
	});

	server.begin();
	Serial.println("HTTP server started");
}

void loop(void)
{
	server.handleClient();
}

The connected serial terminal told me that my 8266 acquired an IP of 172.20.10.6. I used my computer’s browser to navigate to this page.

 
Left: the serial terminal provides a handy debug
Right: the landing page of the webserver

Turning the LED ON and OFF

Going to 172.20.10.6/on turns the LED on.

Going to 172.20.10.6/off turns the LED off.

 

Problems/Issues

I shouldn’t really call it a ‘problem’, but for lack of a better word, that’s what it is – the ESP-01 module has got 0.1in-spaced dual-row pin headers. This is not convenient for solderless breadboard prototyping. There are a few hacks/mods available online, but I decided to go the adapter board way.

The adapter board was not to difficult to make, and I faced no real problems while soldering. The board was a dual-sided proto-board, which made things a little easier. The LM1117 was soldered on the bottom side, as were the tiny 0201 resistors, scrounged from my junk box.

I had initially gone with a 10k pullup on the RST pin of the ESP-01, and a 10k-22k voltage divider on the FTDI’s Tx line. The choice of resistors for the voltage divider was the cause of a lot of grief. I was able to see all the debug messages coming from the ESP-01 (since the ESP’s Tx was directly connected to the FTDI’s Rx), but for some reason, no messages were being received by the ESP-01. I changed baud rates, checked and re-checked my circuit, measured voltages, tried a loop-back test with just the adapter board, all of which worked fine; it was just that the module would not respond when queried with an AT command. And since the loop-back test worked, the signal path along with the divider resistors was obviously good.

I had almost concluded that I either had a dud chip, or corrupted firmware, or a chip with a damaged Rx pin, and was about the go down the rabbit’s hole and break out my oscilloscope. Something made me change the divider resistors by an order of magnitude – I swapped the resistors to 1k-2.2k. Maybe the 8266 liked a stiffer drive? This was a bit surprising since the datasheet states that an 8266 input needed just 5nA drive current; the 10k-22k combo was capable of sourcing significantly more than that! I dunnno.

Once I changed the resistors everything worked fine. The chip happily responded to AT queries, and re-programming with Arduino IDE-compiled code was not a problem.

A deeper look into the datasheet showed that I/O pins of the 8266 are internally clamped to 6v. So technically, I could use a single series resistor on the FTDI Tx/8266 Rx and overdrive the Rx pin. The protection diode would do its work and clamp the voltage on the pin to 5.8v. However, I wanted to do things the ‘right’ way.

Apparently, ESP-01s from different manufacturers have different baud rates. Mine defaulted to 115200 for comms, and 76800 for debug. YMMV.

 

Further Stuff

Obviously, there’s much more you can do with this chip than just turning on and off an LED. The ESP-01 makes available at most 4 GPIOs – GPIO0, GPIO1 (Tx), GPIO2, GPIO3 (Rx) – with caveats.

During development, GPIO1 and GPIO3 may be reserved for UART functions. Connecting external hardware to these pins may interfere with the UART signal levels. You could easily wire up a port expander like the MCP23008/MCP23017 or a serial shift register like the 74HC595.

The ESP12F module breaks out all the pins into an easy breadboard pitch, and if you really want all pins for your custom board, QFN DIY soldering isn’t all that tough.

Happy IoT-ing!

 

Helpful Links

Arduino + ESP8266:
https://hackaday.io/project/5150-arduino-ide-for-esp8266-quickstart-guide

Another getting started guide:
http://www.madebymarket.com/blog/dev/getting-started-with-esp8266.html

ESP8266 Arduino command reference:
http://arduino.esp8266.com/versions/1.6.5-990-gc8a63ce/doc/reference.html

GPIO allocations:
http://www.esp8266.com/wiki/doku.php?id=esp8266_gpio_pin_allocations

Wiki:
https://en.wikipedia.org/wiki/ESP8266

8266 Community Wiki (very useful):
http://www.esp8266.com/wiki/doku.php?id=start

Look Ma, No Wires!

I’m blogging after aeons! Been really busy; work is such :-/ It’s not like I haven’t been tinkering at all, it’s just that I’ve been tinkering less, and haven’t had the time to document it.

A few weeks ago I decided that I needed a Bluetooth-to-audio adapter for my home (which has a decent but dated Sony home theatre) and car (which has an old stereo system). So this vacation I decided to make one.

Logitech’s Bluetooth Speaker Adapter has got a 3.5mm socket as well as RCA outputs

I was looking for an end result similar to Logitech’s Bluetooth Speaker Adapter, available on Amazon for INR1,100 (~USD16) as on Sep, ‘15. There are predominantly two types of Bluetooth audio adapters available online – one, which outputs analog audio through a 3.5mm jack, and connects to your sound system’s AUX/RCA input. The second, slightly more interesting version (to my mind, at least), plugs in to the USB port of more modern mp3-capable sound systems. The adapter ‘appears’ as a regular USB flash drive with an MP3 file on it. The audio streamed over bluetooth is constantly written and buffered to the ‘mp3 file’. Pretty ingenious!

As with most of my projects, I turned to the internet to do a little pre-hacking research. I took a look at a few DIY hacks – google “hack car stereo bluetooth”, and you’ll get links to several people who’ve given new life to the old cassette deck in their dad’s rickety jalopy.

Pretty straightforward: http://www.instructables.com/id/Add-bluetooth-to-your-car-stereo/?ALLSTEPS

A bluetooth speaker modified to do the business: http://www.instructables.com/id/Bluetooth-Speaker-Hack-Home-Theater-Streaming/?ALLSTEPS

And for those people still rocking cassette tapes in 2015 (my mom, for example), this guy made a ‘bluetooth cassette’: http://car-mods.wonderhowto.com/how-to/hack-your-cars-cassette-deck-into-wireless-bluetooth-music-player-0139843/

I was initially thinking of modifying the BT earpiece I use with my phone, however that would limit me to a mono output only (there are earpieces which have stereo outputs, so these too, may be good contenders for a hack). I had an old Corseca/Byte brand on-ear headphones lying around. The ear pads were crumbling, and the sound quality was absolute rubbish. But it was still working, and I was pretty certain that the poor audio was only due to the low cost sound drivers. So naturally, I took a screwdriver to the headphones, hehe.

Not sure if the brand is ‘Corseca’ or ‘Byte’

Disassembly was rather painless – just a few screws and plastic retention clips. The electronics were crammed into the plastic cover over one ear, and the battery was stuck with double sided tape in the other cover. The cover which had the electronics also had control buttons on the other side – FF, REW, Vol Up, Vol Down, Call Answer.

Teardown time!

No surprises about the main chip being from CSR (now acquired by Qualcomm). CSR is a major in BT consumer electronics ICs, and you’d find CSR chips in everything from keyboards, to headsets, to smart microwaves. The main chip is a CSR57F68 A2DP streaming audio chip. The chip is fully integrated, and has two onboard differential audio outputs, button handling capabilities (debounce, etc), GPIOs, and of course, the BT radio itself.

 
The electronics were on a double-sided board – one side with the chips and support circuitry (Left), and the other side with buttons and status LEDs (Right)

The TSSOP chip is an L24C32, 32kbit I2C EEPROM, which probably stores config data, descriptor strings, etc.

I then desoldered the sound driver and battery wires.

  
Desoldering the mini-USB charging socket, and replaced it with a micro-USB connector for convenience. The micro-USB’s pin pitch didn’t fit the board perfectly, and the connector itself had a different footprint, so I had to use mod-wires

I also removed the mini-USB charging connector, and soldered-on a micro-USB connector (side rant: just like everyone else, I get totally frustrated pulling out ten different cables to charge ten different devices. With most manufacturers now standardizing around the micro-USB connector, things have become a bit easier, but Apple still stubbornly pushes its weird proprietary connectors, each one different from the previous).

 
The covers, before (Left) and after (Right) modification

My idea was to use the two covers – one from each ear – to form a sort of ‘case’ for the final product. I used my Dremel to trim away the plastic standoffs for the screws on the plastic covers. I then fashioned some new screw inserts out of acrylic. The inserts were hot glued into place. Small holes were drilled into the inserts and the bottom cover to allow for the screws.

 
The acrylic inserts/standoffs for screws, and the 3.5mm audio connector

I had a 3.5mm audio socket (probably scavenged from an old motherboard or CD drive) in my junk box, which I also hot glued in place. Wires were then used to connect the audio outputs from the board to the socket. I took care to connect the left and right channels to the correct legs on the socket. The negative output of each differential pair was soldered to the ground pin of the socket.

Connecting the wrong output to ground would result in an out-of-phase output from the speakers. While this may not be such a big deal with headphones, it would result in sound ‘cancelling’ itself out (primarily poor bass response) if I used the BT adapter with speakers. The AudioCheck website has cool online audio files that help you determine if your speakers are connected correctly.

 
 
The finished project – screws on the sides, and the PINK (!!) audio socket sticking out – not the prettiest

A small slot had to be cut in the bottom cover to accommodate the audio jack. The covers are held together by three screws. The final device is not the prettiest, but it’s functional and works really well.

   
Charging through the hacked-on micro-USB connector

I Got Spinners Dawg!

I am an engineer. By profession, by hobby and therefore, by passion. And being an engineer requires me to browse through PDFs several pages long, or plow through code confusing enough to make your eyes pop out. I may do this just to look cool, but all the same, I have to do it. Using a mouse scroll wheel with its annoying ‘click’ makes my index finger sore pretty quick. So then I switch to my middle finger. And pretty soon I find that I can’t give someone the bird.

Griffin’s $40 PowerMate

Now the simple solution would be to buy myself a jog wheel / spinner. Give the jog wheel a slight twist and its momentum would keep it gliding over pages and pages of the boring PDF. But I’m an engineer. So I decided to build myself one (obviously the phrase “Why buy a cow when milk is so cheap” does not apply to engineers).

The inspiration for the build was not really ‘direct’. I never really got down to building one until I watched one of Dave’s excellent teardown videos. I was actually googling how VCR heads have a helical scan and then opened up a myriad other links, this instructable being one of them.

Osgeld has done a pretty fine job with his jog wheel

I had torn down a VCR about a year ago and mined it for parts, so I already had the basic stuff at hand. I also had an old USB mouse picked up from a dorm trash can. The tactile buttons had gone bust, but the chip itself was pretty useable.

 
The crusty old VCR head. Oxidized and rusted

Some more googling led me to these tutorials:
http://www.instructables.com/id/Computer-scroll-wheel-bearings-version/step5/Finished-future-improvements/
http://www.instructables.com/id/Desktop-Scroll-Wheel-and-Volume-Control/

Disassembly of the head was was relatively easy. I’m just going to explain it through pictures.

 
A brushless motor drives the head assembly

 
The magnetic pickups are clearly visible in the image on the right

 
The rotary transofrmer

[Digression - the pickups feed the signal to the coils of a rotary transformer. The transformer helps couple a signal across two rotating elements without the use of mechanical elements like slip rings. I’ve never seen a rotary transformer before, so this was the most interesting part of the teardown. The transformer ‘core’ was glued down. A blast of hot air from my heat gun helped dislodge it.]

My mouse chip was an all-in-one solution with the USB comms, the optical sensor, and the click/scroll encoders integrated onto one chip. This is good since I was able to make my circuitry compact. Some mice (mouses?) distribute USB and sensor duties across two separate chips. The particular chip that I used was the A1198. Googling for the chip’s pinout or datasheet proved useless. So I used a multimeter to reverse engineer the PCB. An MSPaint pinout is below; hopefully someone else will find it useful.

Vreg gives out approx 3.3v All V should be connected to Vreg. Resistors pulldown the quadrature inputs Q0, Q1 to Q_pulldwn. If a mechanical encoder is used, then the common pin of the quadrature encoder should go to Vusb. Xtal is a 12MHz ceramic resonator.

The pin spacing for the chip was a bit odd. Luckily the pins weren’t staggered like you find on some sensors. I had some 2mm pitch veroboard, which, after wiggling the pins a tad, worked just fine. I used the ceramic oscillator from the original mouse, and sprinkled a few SMD capacitors which I had scavenged from old electronics.

 
Left: IC pins splayed out
Right: I drilled a small hole for the aperture of the optical sensor to sit in

The original mouse used a mechanical quadrature encoder for the scroll wheel. I converted this into an optical encoder by using some cheap IR LEDs and phototransistors. The resistor-phototransistor-combo’s output swung from 0.1v to 3.3v. I found that I didn’t even need to use a comparator on the sensor output since the signal was fairly ‘clean’. The encoder wheel was designed and printed using shimniok’s Wheel Encoder Generator.

  
Left: The first sensor board I made used one IR LED and two phototransistors ground flat. This didn’t work well at all – very poor resolving power.
Centre: On the second board I used SG-105 photoreflective sensors. They’re tiny and low profile compared to my earlier sensors.
Right: The back of the SG-105 board. SMD resistors used to bias the opto-elements; 220ohm on the LEDs, 470kohm from the phototransistor collector to Vusb.

For the base I used a Canon lens holder given to me by a photographer friend. A little bit of drilling here and there made it an excellent base.

 
A Cannon lens cover was used as the base.

 
Left: The completely soldered ‘mouse’ board was stuck with some double sided foam tape in the Canon lens holder.
Right: The sensor board was fixed using a screw and a spacer. The USB cable was secured with a dot of hot glue.

 
Testing the sensors with the help of my third hand and a DSO. The signal is typical of a quadrature encoder and is quite clean, as you can see in the trace.

Overall I’m really happy with the way this jog/spinner wheel has turned out. No more sore fingers, and zipping over pages in a PDF, or lines of code, or through frames of a movie has become easy and super fun! Infact I’ve used it extensively while editing this very document :-) One possible addition at a later date would be to add a push button at the bottom of the shaft so that the whole spinner can be ‘pushed-to-click’.

Edit: I’ve uploaded a video to Youtube

Jog Wheel