The FT232 USB-to-serial converter is one of the most commonly-used methods of adding USB functionality to small projects, but recently I found that these chips are capable of sending more than just serial signals. With some creative programming, individual output pins can be big-banged to emulate a clock, data, and chip select line to control SPI devices. This post shares some of the techniques I use to bit-bang SPI with FTDI devices, and some of the perks (and quirks) of using FTDI chips to bit-bang data from a USB port. Code examples are available on GitHub, and links to additional resources are at the bottom of this post. After the final build I created a slightly more polished “ftdiDDS.exe” program to control an AD9850 frequency synthesizer from the command line by bit-banging a FT-232, and code (and binaries) are also available on GitHub.

Why Bit-Bang FTDI Pins?

The main reason I like using FTDI devices is because when you plug them in to a modern computer, they just start working! You don’t have to worry about drivers, driver versions, driver signing, third party drivers – most of the time it just does what it’s supposed to do with no complexity. If I’m going to build a prototype device for a client, a FT-232 USB to serial converter is the way to go because I can be confident that when they plug in, their device will start working right away. Yeah, there are third party drivers to get extra open-sourcey functionality from FTDI devices (libFTDI), but I don’t want to ask a client (with unknown tech-savviness) to install third-party unsigned drivers before plugging my device in (and heaven forbid the product doesn’t work in their hands and I have to ask them to verify the device is actually using the third-party drivers and not defaulting back to the official ones). In this project I seek to use only the generic, default, officially-supported FTDI driver and API access will be provided by libftd2xx. Don’t forget that USB ports supply 5V and GND, so in most cases you can power your project just from the USB port! All-in-all, the FT-232 is a great way to give a small device USB functionality. This post explores how to use it for more than just sending and receiving serial data…

Controlling FTDI Devices with C#

The goal of this post is not to describe every detail about how to control FTDI chips. Instead, the key points of the software are described here (and in the video) so you can get the gist of the main concepts. If you’re interested in additional detail, full code examples are provided on the GitHub folder for this project. All code examples were tested with Visual Studio Community 2017, are written in C#, and uses the FTD2XX_NET library installed with NuGet. Also, see the list of resources (including official FTDI datasheets and application notes) at the bottom of this post.

This block of code attaches to FTDI device 0 (the first FTDI device it sees) and sends the letter “a” using a traditional serial protocol. Since this code connects to the first FTDI device it finds, this could be a problem if you have more than 1 FTDI device attached. Alternatively you could have your program connect to a specific FTDI device (e.g., by its serial number). To see what FTDI devices are attached to your computer (and see or set their serial numbers), use the FT_Prog application provided by FTDI. Also, see the code I use to list FTDI devices from inside a C# program ftdiDDS program.

The full code of this example is here (GitHub)

public static FTDI ftdi = new FTDI();
public static FTDI.FT_STATUS ft_status = FTDI.FT_STATUS.FT_OK;
public static UInt32 bytesWritten = 0;

static void Main(string[] args)
{
	ft_status = ftdi.OpenByIndex(0);
	ft_status = ftdi.SetBaudRate(9600);
	string data = "a";
	ft_status = ftdi.Write(data, data.Length, ref bytesWritten);
}

LED Blink by Bit-Banging FTDI Pins

Here is a minimal complexity LED blink example. This code block alternates between writing 0 (all pins off) and 1 (TX pin high) over and over forever. Note that ftdi.SetBitMode is what frees the FTDI chip from sending serial data when ftdi.Write() gets called. The 255 is a byte mask which tells all 8 pins to be outputs (by setting all 8 bits in the byte to 1, hence 255). Setting bit mode to 1 means we are using asynchronous bit bang bode (sufficient if we don’t intend to read any pin states). For full details about these (and other) bit-bang settings, check out the Bit Bang Modes for the FT232R application note.

The full code of this example is here (GitHub)

ft_status = ftdi.OpenByIndex(0);
ft_status = ftdi.SetBitMode(255, 1);
ft_status = ftdi.SetBaudRate(9600);
int count = 0;

while (true)
{
	byte[] data = { (byte)(count++%2) };
	ft_status = ftdi.Write(data, data.Length, ref bytesWritten);
	System.Threading.Thread.Sleep(100);
}

Bit-Bang SPI with a FT232

In reality all we want to send to SPI devices are a series of numbers which we can place in a byte array. These numbers are transmitted by pulling-low a clip select/enable line, setting a data line (high or low, one bit at a time) and sliding the clock line from low to high. At a high level we want a function to just take a byte array and bit-bang all the necessary SPI signals. At a low level, we need to set the state for every clock cycle, bit by bit, in every byte of the array. For simplify, I use a List<byte> object to collect all my pin states. Then I convert it to an array right before sending it with ftdi.Write().

The full code of this example is here (GitHub)

List<byte> bytesToSend = new List<byte>();
bytesToSend.Add(123); // just
bytesToSend.Add(111); // some
bytesToSend.Add(222); // test
bytesToSend.Add(012); // data

BitBangBytes(bytesToSend.ToArray());

// given a byte, return a List<byte> of pin states
public static List<byte> StatesFromByte(byte b)
{
	List<byte> states = new List<byte>();
	for (int i=0; i<8; i++)
	{
		byte dataState = (byte)((b >> (7-i)) & 1); // 1 if this bit is high
		states.Add((byte)(pin_data * dataState)); // set data pin with clock low
		states.Add((byte)(pin_data * dataState | pin_clock)); // pull clock high
	}
	return states;
}

// given a byte array, return a List<byte> of pin states
public static List<byte> StatesFromByte(byte[] b)
{
	List<byte> states = new List<byte>();
	foreach (byte singleByte in b)
		states.AddRange(StatesFromByte(singleByte));
	return states;
}

// bit-bang a byte array of pin states to the opened FTDI device
public static void BitBangBytes(byte[] bytesToSend)
{
	List<byte> states = StatesFromByte(bytesToSend);
	
	// pulse enable to clear what was there before
	states.Insert(0, pin_enable);
	states.Insert(0, 0);

	// pulse enable to apply configuration
	states.Add(pin_enable);
	states.Add(0);
	ft_status = ftdi.Write(states.ToArray(), states.Count, ref bytesWritten);
}

Bit-Bang Control of an RF Synthesizer

The AD9850 is a SPI-controlled DDS (Direct Digital Synthesizer) capable of generating sine waves up to 65 MHz and is available on breakout boards for around $20 on eBay and Amazon. It can be programmed with SPI by sending 40 bits (5 bytes), with the first 4 bytes being a frequency code (LSB first) and the last byte controls phase.

To calculate the code required for a specific frequency, multiply your frequency by 4,294,967,296 (2^32 – 1) then divide that number by the clock frequency (125,000,000). Using this formula, the code for 10 MHz is the integer 343,597,383. In binary it’s 10100011110101110000101000111, and since it has to be shifted in LSB first (with a total of 40 bits) that means we would send 11100010100001110101111000101000 followed by the control byte which can be all zeros. In C# using the functions we made above, this looks like the following.

The full code of this example is here (GitHub)

int freqTarget = 12_345_678; // 12.345678 MHz
ulong freqCode = (ulong)freqTarget * (ulong)4_294_967_296;
ulong freqCrystal = 125_000_000;
freqCode = freqCode / freqCrystal;
bytesToSend.Add(ReverseBits((byte)((freqCode >> 00) & 0xFF))); // 1 LSB
bytesToSend.Add(ReverseBits((byte)((freqCode >> 08) & 0xFF))); // 2
bytesToSend.Add(ReverseBits((byte)((freqCode >> 16) & 0xFF))); // 3
bytesToSend.Add(ReverseBits((byte)((freqCode >> 24) & 0xFF))); // 4 MSB
bytesToSend.Add(0); // control byte
BitBangBytes(bytesToSend.ToArray());

If somebody wants to get fancy and create a quadrature sine wave synthesizer, one could do so with two AD9850 boards if they shared the same 125 MHz clock. The two crystals could be programmed to the same frequency, but separated in phase by 90º. This could be used for quadrature encoding/decoding of single sideband (SSB) radio signals. This method may be used to build a direct conversion radio receiver ideal for receiving CW signals while eliminating the undesired sideband. This technique is described here, here, and here.

Polishing the Software

Rather than hard-coding a frequency into the code, I allowed it to accept this information from command line arguments. I did the same for FTDI devices, allowing the program to scan/list all devices connected to the system. Now you can command a particular frequency right from the command line. I didn’t add additional arguments to control frequency sweep or phase control functionality, but it would be very straightforward if I ever decided to. I called this program “ftdiDDS.exe” and it is tested/working with the FT-232R and FT-232H, and likely supports other FTDI chips as well.

Download ftdiDDS

Command Line Usage:

  • ftdiDDS -list lists all available FTDI devices
  • ftdiDDS -mhz 12.34 sets frequency to 12.34 MHz
  • ftdiDDS -device 2 -mhz 12.34 specifically control device 2
  • ftdiDDS -sweep sweep 0-50 MHz over 5 seconds
  • ftdiDDS -help shows all options including a wiring diagram

Building an Enclosure

Although my initial goal for this project was simply to figure out how to bit-bang FTDI pins (the AD9850 was a SPI device I just wanted to test the concept on), now that I have a command-line-controlled RF synthesizer I feel like it’s worth keeping! I threw it into an enclosure using my standard methods. I have to admit, the final build looks really nice. I’m still amused how simple it is.

Beware of the FT232R Bit Bang Bug

There is a serious problem with the FT-232R that affects its bit-bang functionality, and it isn’t mentioned in the datasheet. I didn’t know about this problem, and it set me back years! I tried bit-banging a FT-232R several years ago and concluded it just didn’t work because the signal looked so bad. This week I learned it’s just a bug (present in every FT-232R) that almost nobody talks about!

Consider trying to blink a LED with { 0, 1, 0, 1, 0 } sent using ftdi.Write() to the FT-232R. You would expect to see two pulses with a 50% duty. Bit-banging two pins like this { 0, 1, 2, 1, 2, 0 } one would expect the output to look like two square waves at 50% duty with opposite phase. This just… isn’t what we see on the FT-232R. The shifts are technically correct, but the timing is all over the place. The identical code, when run on a FT-232H, presents no timing problems – the output is a beautiful

The best way to demonstrate how “bad” the phase problem is when bit-banging the FT232R is seen when trying to send 50% duty square waves. In the photograph of my oscilloscope below, the yellow trace is supposed to be a “square wave with 50% duty” (ha!) and the lower trace is supposed to be a 50% duty square wave with half the frequency of the top (essentially what the output of the top trace would be if it were run through a flip-flop). The variability in pulse width is so crazy that initially I mistook this as 9600 baud serial data! Although the timing looks wacky, the actual shifts are technically correct, and the FT-232R can still be used to bit-bang SPI.

Unfortunately this unexpected behavior is not documented in the datasheet, but it is referenced in section 3.1.2 of the TN_120 FT232R Errate Technical Note where it says “The output may be clocked out at different speeds … and can result in the pulse widths varying unexpectedly on the output.” Their suggested solution (I’ll let you read it yourself) is a bit comical. It’s essentially says “to get a 50% duty square wave, send a 0 a bunch of times then a 1 the same number of times”. I actually tried this, and it is only square-like when you send each state about 1000 times. The data gets shifted out 1000 times slower, but if you’re in a pinch (demanding squarer waves and don’t mind the decreased speed) I guess it could work. Alternatively, just use an FT-232H.

Update (2018-10-05): YouTube user Frederic Torres said this issue goes away when externally clocking the FT232R chip. It’s not easy to do on the breakout boards, but if you’re spinning your own PCB it’s an option to try!

Alternatives to this Method

Bit-banging pin states on FTDI chips is a cool hack, but it isn’t necessarily the best solution for every problem. This section lists some alternative methods which may achieve similar goals, and touches on some of their pros and cons.

  • LibFTDI – an alternative, open-source, third party driver for FTDI devices. Using this driver instead of the default FTDI driver gives you options to more powerful commands to interact with FTDI chips. One interesting option is the simple ability to interact with the chip from Python with pyLibFTDI.
    While this is a good took for hackers and makers, if I want to build a device to send to a lay client I won’t want to expect them to fumble with installing custom drivers or ensure they are being used over the default ones FTDI supplies. I chose not to pursue utilizing this project because I value the “plug it in and it just works” functionality that comes from simply using FTDI’s API and drivers (which are automatically supplied by Windows)
  • Raspberry PI can bit-bang SPI – While perhaps not ideal for making small USB devices to send to clients, if your primary goal is just to control a SPI device from a computer then definitely consider using a Raspberry Pi! A few of the pins on its header are capable of SPI and can even be driven directly from the bash console. I’ve used this technique to generate analog voltages from a command line using a Raspberry PI to send SPI commands to a MCP4921 12-bit DAC.
  • Multi-Protocol Synchronous Serial Engine (MPSSE) – Some FTDI chips support MPSSE, which can send SPI (or I2C or other) protocols without you having to worry about bit-banging pins. I chose not to pursue this option because I wanted to use my FT232R (one of the most common and inexpensive FTDI chips), which doesn’t support MPSSE. ALthough I do have a FT232H which does support MPSSE (example project), I chose not to use that feature for this project, favoring a single code/program to control all FTDI devices.
  • Bus Pirate – If you don’t have a Bus Pirate already, get one! It’s one of the most convenient ways to get a new peripheral up and running. It’s a USB device you can interact with through a serial terminal (supplied using a FTDI usb-to-serial converter, go fig) and you can tell it to send/receive commands to SPI or I2C devices. It does a lot more, and is worth checking out.

Resources

  • Saleae logic analyzers – The official Saleae hardware (not what was shown in my video, which was a cheap eBay knock-off) can do a lot of great things. Their free software is really simple to use, and they haven’t gone out of their way to block the use of third-party logic analyzers with their free software. If you are in a place where you can afford to support this company financially, I suggest browsing their products and purchasing their official hardware.
  • DYMO Letra-Tag LT100-H label maker and clear tape – When labels are printed with black boxes around them (a tip I learned from Onno) they look fantastic when placed on project boxes! Don’t buy the knock-off clear labels, as they aren’t truly clear. The clear tape you need to purchase has the brand name “DYMO” written on the tape dispenser.
  • FT232H breakout board (adafruit) – This is where I got the FT232H board used in this video. You can find additional similar FT232H breakout boards on Amazon.
  • FT232R breakout board – Everyone sells these. I got some lately on Amazon, but I’ve gotten them before on eBay too.
  • TTL-232R cable – If you’re making a device which you want to appear a bit more professional, this cable has the FT232R built-in and it just has several pins (in a female header) you can snap onto your board.
  • Bit Bang Modes for the FT232R – FTDI datasheet detailing how to Bit-Bang the FT232R chip. In practice, the terms, language, and code examples in this datasheet seem similar enough to the FT232H that it probably is all you need to get started, since it’s the large-scale concepts which are most important.
  • Introduction to the FTDI BitBang mode – A Hack-A-Day article from 2009 mentions FTDI chips can be used to bit-bang pin states and they have their own LED blink examples. Their article does hint at using this method to bit-bang SPI, but it fails entirely to note the FT232R bug that surely has confused multiple people in the past…
  • FT232R BitBang SPI example – This code uses libftdi, not the default driver supplied by FTDI (libftd2xx).
  • FT232R BitBang mode is broken – an article from 2012 detailing how bad the timing is when bit-banging pin states on the FT232R.
  • Official acknowledgement of the FT232R timing problem is described in the TN_120 FT232R Errate Technical Note in section 3.1.2 where they state the problem as: “The output may be clocked out at different speeds to allow for different pulse widths. However this clocking stage is not synchronized with the incoming data and can result in the pulse widths varying unexpectedly on the output.
  • AD9850 Complete DDS Synthesizer Datasheet

Conclusion

Bit-banging pin states on FTDI devices is relatively simple, even using the standard drivers and API. The FTD2XX_NET library on NuGet provides a simple way to do this. The output of the FT232H is much more accurate in the time domain than the FT232R. Although there are crazy timing issues with the FT232R, it works fine when driving most SPI devices. Here we used this technique to write a console application to control an AD9850 DDS directly from an FT232R using command line arguments. When given a formal enclosure, this project looks (and works) great!

If you make something cool by bit-banging a FTDI device, let me know about it!





Additional Resources

The Internet of Things now includes Festivus poles! Festivus is a holiday celebrated on December 23rd, and its customary practices include a Festivus pole, Festivus dinner, airing of grievances, feats of strength, and Festivus miracles. The internet contains a few nods to the holiday, including what happens when you Google for the word Festivus (a Festivus pole is displayed at the bottom of the page). In 2015 I had the honor of gifting the world with the first Festivus pole video game, and today I am happy to unveil the world’s first internet-enabled Festivus pole. Every time somebody tweets #Festivus or #FestivusMiracle, the light at the top of the pole illuminates! All in the room then excitedly exclaim, “it’s a Festivus miracle!”

The IoT Festivus Pole is powered by a Raspberry Pi (a Pi 2 Model B, although any Pi would work) running a Python script which occasionally checks for tweets using the twitter API (via twython, a pure-python twitter API wrapper) and controls the GPIO pin 12 with RPi.GPIO (extra docs). After writing the Python script (which should work identically in Python 2 or Python 3), I got it to run automatically every time the system boots by adding a line to /etc/rc.local (surrounding it with parentheses and terminating the line with & to allow it to run without blocking the startup sequence). The LED was added to the end of a long wire (with a series 220-ohm resistor) and connected across the Raspberry Pi header pins 12 (PWM) and 14 (GND). I set PWM frequency to 100 Hz, but this is easily configurable in software.


To build the Festivus pole I got a piece of wood and a steel conduit pipe from Lowe’s (total <$5). Festivus purists will argue that Festivus poles should be made from aluminum (with its very high strength to weight ratio). I live in an apartment and don’t have a garage, so my tool selection is limited. I cut the wood a few times with a jigsaw and glued it together to make an impressive stand similar to those of traditional Festivus poles. I have a few hole saw drill bits, but none of them perfectly matched the size of the pipe. I traced the outline of the pipe on the wood and cut-out a circular piece with a Dremel drill press in combination with a side-cutting bit. The hole was slightly larger than required for the pipe, so I used a few layers of electrical tape on the bottom of the pipe to “seal” the base of the pipe into the hole, then poured acrylic epoxy into the empty space. Clamping it against a desk allowed the epoxy to set such that the pole was rigidly upright, and the result was a fantastic-looking Festivus pole! It’s a bit smaller in size than the famous one featured in Seinfeld, but I think it is appropriately sized for my apartment.

Adding the computer was easy! Internet capability was provided via a USB WiFi card. Code is at the bottom of this page. The LED was connected to Raspberry Pi header pins 12 and 14. The wiring was snaked through the conduit.

The code will work on Python 2 and Python 3.
Pip can be used to install RPi.GPIO and twython: pip install python-dev python-rpi.gpio twython

import RPi.GPIO as GPIO        
import time
from twython import Twython

APP_KEY = 'zSNYBNWHmXhU3CX765HnoQEbm'
APP_SECRET = 'getYourOwnApiKeyFromTwitterWebsite'
twitter = Twython(APP_KEY, APP_SECRET)
auth = twitter.get_authentication_tokens()

GPIO.setmode(GPIO.BOARD)
GPIO.setup(12, GPIO.OUT)
p = GPIO.PWM(12, 100)
p.start(0)

if __name__=="__main__":
    tweetLast=0
    checkLast=0
    duty=100
    
    while True:
        if (checkLast+5)<time.time():
            checkLast=time.time()
            print("checking twitter...")
            tweetLatest=twitter.search(q='festivus')["statuses"][0]["created_at"]
            if tweetLatest!=tweetLast:
                print("IT'S A FESTIVUS MIRACLE!")
                tweetLast=tweetLatest
                duty=100
            else:
                print('nothing')

        if duty>=0:
            p.ChangeDutyCycle(duty)
            
        time.sleep(.3)
        duty-=1

This Festivus pole has been up and running for the last few days and I’m excited to see how much joy it has brought into my household! Admittedly the Raspberry Pi seems to be overkill, but at the time I was considering having it also output audio every time a tweet is made but I never decided on the clip to use so I omitted the feature. An ESP8266 WiFi module interfaced with a microntroller can do the same job with more elegance and lower cost, so I may consider improving it next year. Until then, Happy Festivus!

 

 





Additional Resources

After a long day it can be really nice to have a relaxing hobby to clear your head, and few activities shut down your brain as effectively as video games. However, a newly released video game is physically hurting me as my impulse to move quickly causes me to perpetually click the run button. After a few days of game-play and a really sore left thumb, I decided to do something about it: hack-in a microchip to automatically click the button for me. Modifying game controllers to do things like automatically rapid fire is nothing new. I once modified a USB computer mouse to add an extra “rapid fire” button (link). Hackaday ran a story about a guy who hacked a PS4 controller to add mouse and keyboard functionality. Today’s hack isn’t quite as elaborate, but it’s very effective. Here I show how I modified a PlayStation 4 controller to automatically click the L3 button so I am always running. This auto-run functionality mimics the auto-run feature built into many games (like Titanfall 2 which spoiled me to expect this), but I built the circuit so it can be toggled on and off by clicking the L3 button. After playing Titanfall 2 for the last few months, the recent release of the Call of Duty WWII beta is driving me crazy as it requires me to click the run button over and over (every two seconds) which, after an afternoon of playing, is actually painful.

Assessing the PS4 Controller

I started out by looking online to see what the PS4 controller looked like inside. Imgur has a great PS4 dualshock controller teardown photo collection which was an excellent starting place. From these photos I realized this hack would be pretty easy since the L3 “click” action is achieved by a through-hole SPDT tactile switch placed under the joystick.

I was surprised to find my PS4 controller (below) was a little different (green for starters), but the overall layout was the same. I quickly identified the 4 pins of the L3 tactile switch and got to work…

After probing around with a multimeter and an oscilloscope, I was able to determine which pins do what. Just from looking at the trace it’s pretty obvious that two of the pins are the positive voltage rail. In this controller the positive voltage (VCC) is about 3 volts, so keep that in mind and don’t hook-up a 5V power supply if you decide to debug this thing.

To test my idea I attached 3 wires to VCC, GND, and SENSE and ran into the other room where my PS4 was. As I held the left joystick up in a game, shorting the SENSE and GND wires (by tapping them together) resulted in running! At this point I knew this hack would work, and proceeded to have a microcontroller control voltage of the L3 sense line.

Simulating L3 Presses with a Microcontroller

I glued a microcontroller (ATTiny85) to the circuit board, then ran some wires to the points of interest. Visual inspection (and a double check with a multimeter when the battery was in) provided easy points for positive and ground which could power my microcontroller. The “L3 sense” pin (which toggles between two voltages when you press the L3 button) was run to pin 3 (PB4) of the microcontroller. In a production environment current limiting resistors and debounce capacitors would make sense, but in the spirit of the hack I keep things minimalistic.

The device could be easily reassembled, and there was plenty of room for the battery pack and its plastic holder to snap in place over the wires. Excellent!

While I was in the controller, I removed the light-pipe that carries light to the diffuser on the back. The PS4 has an embarrassingly poor design (IMO) where the far side of the controller emits light depending on the state of the controller (blue for in use, black for off, orange for charging, etc). This is a terrible design in my opinion because if you have a glossy and reflective TV screen like I do, you see a blue light reflect back in the screen and bobble up and down as you hold the controller. Dumb! Removing the light pipe dramatically reduced the intensity, but still retains the original functionality.

Programming the microcontroller was achieved with an in circuit serial programmer (USBtinyISP) with test clips. This is my new favorite way to program microcontrollers for one-off projects. If the pins of the microcontroller aren’t directly accessable, breaking them out on 0.1″ headers is simple enough and they make great points of attachment for test clips. The simplest code to continuously auto-run is achieved by just swinging the sense line between 5V and 0V. This is the code to do that:

for(;;){ // do this forever
	// simulate a button press
	PORTB|=(1<<PB4); // pull high
	_delay_ms(50); // hold it there
	// simulate a button release
	PORTB&=~(1<<PB4); // pull low
	_delay_ms(50); // hold it there
}

Sensing Actual Button Presses to Toggle Auto-Run On/Off

Simulating L3 presses was as simple as toggling the sense line between VCC and GND, but sensing manual L3 presses wasn’t quite as easy. After probing the output on the scope (see video) I realized that manual button presses toggle between voltages of about 2V and 3V, and the line never really goes down to zero (or below VCC/2) so it’s never read as “off” by the digital input pin. Therefore, I changed my strategy a bit. Instead of clamping between 5V and 0V, I toggled between low impedance and high impedance states. This seemed like it would be gentler on the controller circuit, as well as allow me to use the ADC (analog-to-digital controller) of the microcontroller to read voltage on the line. If voltage is above a certain amount, the microcontroller detects a manual button press is happening and toggles the auto-run functionality on/off. The new code is this:

for(;;){ // do this forever

	// simulate a button press
	PORTB|=(1<<PB4); // pull high
	DDRB|=(1<<PB4); // make output
	_delay_ms(50); // hold it there
	
	// simulate a button release
	DDRB&=~(1<<PB4); // make input
	PORTB&=~(1<<PB4); // pull low
	_delay_ms(50); // hold it there
	
	// check if the button is actually pressed to togggle auto press
	if (ADC>200) { // if the button is manually pressed
		_delay_ms(100); // wait a bit
		while (ADC>200) {} // wait until it depresses
		while (ADC<200) {} // then wait for it to be pressed again
	}	
}

It works! My Call of Duty character is running just like a Titan Pilot. After giving it a spin on the Call of Duty WWII Beta, I’m happy to report that this circuit is holding up well and I’m running forever effortlessly. I still suck at aiming, shooting, and not dying though.

Follow-up: After playing the fast-paced and highly dynamic Titanfall 2 for so long, I rapidly became disenchanted with the Call of Duty WWII game-play which now feels slow and monotonous in comparison. Although this auto-sprint controller hack works, I don’t really use it because I barely play the game I made it for! I’m going back to exclusively playing Titanfall 2 for now, and if you get the chance I highly recommend giving it a spin!

 

 





Additional Resources

Here I demonstrate how to use a single microcontroller pin to generate action-potential-like waveforms. The output is similar my fully analog action potential generator circuit, but the waveform here is created in an entirely different way. A microcontroller is at the core of this project and determines when to fire action potentials. Taking advantage of the pseudo-random number generator (rand() in AVR-GCC’s stdlib.h), I am able to easily produce unevenly-spaced action potentials which more accurately reflect those observed in nature. This circuit has a potentiometer to adjust the action potential frequency (probability) and another to adjust the amount of overshoot (afterhyperpolarization, AHP). I created this project because I wanted to practice designing various types of action potential measurement circuits, so creating an action potential generating circuit was an obvious perquisite.

 

The core of this circuit is a capacitor which is charged and discharged by toggling a microcontroller pin between high, low, and high-Z states. In the high state (pin configured as output, clamped at 5V) the capacitor charges through a series resistor as the pin sources current. In the low state (pin configured as output, clamped at 0V) the capacitor discharges through a series resistor as the pin sinks current. In the high-Z / high impedance state (pin configured as an input and little current flows through it), the capacitor rests. By spending most of the time in high-Z then rapidly cycling through high/low states, triangular waveforms can be created with rapid rise/fall times. Amplifying this transient and applying a low-pass filter using a single operational amplifier stage of an LM-358 shapes this transient into something which resembles an action potential. Wikipedia has a section describing how to use an op-amp to design an active low-pass filter like the one used here.

The code to generate the digital waveform is very straightforward. I’m using PB4 to charge/discharge the capacitor, so the code which actually fires an action potential is as follows:

// rising part = charging the capacitor
DDRB|=(1<<PB4); // make output (low Z)
PORTB|=(1<<PB4); // make high (5v, source current)
_delay_ms(2); // 2ms rise time
	
// falling part
DDRB|=(1<<PB4); // make output (low Z)
PORTB&=~(1<<PB4); // make low (0V, sink current)
_delay_ms(2); // 2ms fall time
_delay_us(150); // extra fall time for AHP

// return to rest state
DDRB&=~(1<<PB4); // make input (high Z)

Programming the microcontroller was accomplished after it was soldered into the device using test clips attached to my ICSP (USBtinyISP). I only recently started using test clips, and for one-off projects like this it’s so much easier than adding header sockets or even wiring up header pins.

I am very pleased with how well this project turned out! I now have an easy way to make irregularly-spaced action potentials, and have a great starting point for future projects aimed at measuring action potential features using analog circuitry.

Project code (GitHub)

Notes

  • Action potential half-width (relating to the speed of the action potential) could be adjusted in software by reducing the time to charge and discharge the capacitor. A user control was not built in to the circuit shown here, however it would be very easy to allow a user to switch between regular and fast-spiking action potential waveforms.
  • I am happy that using the 1n4148 diode on the positive input of the op-amp works, but using two 100k resistors (forming a voltage divider floating around 2.5V) at the input and reducing the gain of this stage may have produced a more reliable result.
  • Action potential frequency (probability) is currently detected by sensing the analog voltage output by a rail-to-rail potentiometer. However, if you sensed a noisy line (simulating random excitatory and inhibitory synaptic input), you could easily make an integrate-and-fire model neuron which fires in response to excitatory input.
  • Discussion related to the nature of this “model neuron” with respect to other models (i.e., Hodgkin–Huxley) are on the previous post.
  • Something like this would make an interesting science fair project




Additional Resources

Few biological cells are as interesting to the electrical engineer as the neuron. Neurons are essentially capacitors (with a dielectric cell membrane separating conductive fluid on each side) with parallel charge pumps, leak currents, and nonlinear voltage-dependent currents. When massively parallelized, these individual functional electrical units yield complex behavior and underlie consciousness. The study of the electrical properties of neurons (neurophysiologically, a subset of electrophysiology) often involves the development and use of sensitive electrical equipment aimed at studying these small potentials produced by neurons and currents which travel through channels embedded in their membranes. It seems neurophysiology has gained an emerging interest from the hacker community, as evidenced by the success of Back Yard Brains, projects like the OpenEEG, and Hack-A-Day’s recent feature The Neuron – a Hacker’s Perspective.

In pondering designs for complex action potential detection and analysis circuitry, I realized that it would be beneficial to be able to generate action-potential-like waveforms on my workbench. The circuit I came up with to do this is a fully analog (technically mixed signal) action potential generator which produces lifelike action potentials.

 

Cellular Neurophysiology for Electrical Engineers (in 2 sentences): Neuron action potentials (self-propagating voltage-triggered depolarizations) in individual neurons are measured in scientific environments using single cell recording tools such as sharp microelectrodes and patch-clamp pipettes. Neurons typically rest around -70mV and when depolarized (typically by external excitatory input) above a threshold they engage in a self-propagating depolarization until they reach approximately +40mV, at which time a self-propagating repolarization occurs (often over-shooting the initial rest potential by several mV), then the cell slowly returns to the rest voltage so after about 50ms the neuron is prepared to fire another action potential. Impassioned budding electrophysiologists may enjoy further reading Active Behavior of the Cell Membrane and Introduction to Computational Neuroscience.

The circuit I describe here produces waveforms which visually mimic action potentials rather than serve to replicate the exact conductances real neurons employ to exhibit their complex behavior. It is worth noting that numerous scientists and engineers have designed more physiological electrical representations of neuronal circuitry using discrete components. In fact, the Hodgkin-Huxley model of the initiation and propagation of action potentials earned Alan Hodgkin and Andrew Huxley the Nobel Prize in Physiology and Medicine in 1936. Some resources on the internet describe how to design lifelike action potential generating circuits by mimicking the endogenous ionic conductances which underlie them, notably Analog and Digital Hardware Neural Models, Active Cell Model, and Neuromorphic Silicon Neuron Circuits. My goal for this project is to create waveforms which resemble action potentials, rather than waveforms which truly model them. I suspect it is highly unlikely I will earn a Nobel Prize for the work presented here.

The analog action potential simulator circuit I came up with creates a continuous series action potentials. This is achieved using a 555 timer (specifically the NE555) in an astable configuration to provide continuous square waves (about 6 Hz at about 50% duty). The rising edge of each square wave is isolated with a diode and used to charge a capacitor*. While the charge on the capacitor is above a certain voltage, an NPN transistor (the 2N3904) allows current to flow, amplifying this transient input current. The capacitor* discharges predictably (as an RC circuit) through a leak resistor. A large value leak resistor slows the discharge and allows that signal’s transistor to flow current for a longer duration. By having two signals (fast and slow) using RC circuits with different resistances (smaller and larger), the transistors are on for different durations (shorter and longer). By making the short pulse positive (using the NPN in common collector configuration) and the longer pulse negative (using the NPN in common emitter configuration), a resistor voltage divider can be designed to scale and combine these signals into an output waveform a few hundred mV in size with a 5V power supply. Pictured below is the output of this circuit realized on a breadboard. The blue trace is the output of the 555 timer.

*Between the capacitance of the rectification diode, input capacitance of the transistor, and stray parasitic capacitance from the physical construction of my wires and the rails on my breadboard, there is sufficient capacitance to accumulate charge which can be modified by changing the value of the leak resistor.

This circuit produces similar output when simulated. I’m using LTspice (free) to simulate this circuit. The circuit shown is identical to the one hand-drawn and built on the breadboard, with the exception that an additional 0.1 µF capacitor to ground is used on the output to smooth the signal. On the breadboard this capacitance-based low-pass filtering already exists due to the capacitive nature of the components, wires, and rails.

A few improvements naturally come to mind when considering this completed, functional circuit:

  • Action potential frequency: The resistor/capacitor network on the 555 timer determines the rate of square pulses which trigger action potentials. Changing these values will cause a different rate of action potential firing, but I haven’t attempted to push it too fast and suspect the result would not be stable is the capacitors are not given time to fully discharge before re-initiating subsequent action potentials.
  • Microcontroller-triggered action potentials: Since action potentials are triggered by any 5V rising edge signal, it is trivially easy to create action potentials from microcontrollers! You could create some very complex firing patterns, or even “reactive” firing patterns which respond to inputs. For example, add a TSL2561 I2C digital light sensor and you can have a light-to-frequency action potential generator!
  • Adjusting size and shape of action potentials: Since the waveform is the combination of two waveforms, you can really only adjust the duration (width) or amplitude (height) of each individual waveform, as well as the relative proportion of each used in creating the summation. Widths are adjusted by changing the leak resistor on the base of each transistor, or by adding additional capacitance. Amplitude and the ratio of each signal may be adjusted by changing the ratio of resistors on the output resistor divider.
  • Producing -70 mV (physiological) output: The current output is electirically decoupled (through a series capacitor) so it can float at whatever voltage you bias it to. Therefore, it is easy to “pull” in either direction. Adding a 10k potentiometer to bias the output is an easy way to let you set the voltage. A second potentiometer gating the magnitude of the output signal will let you adjust the height of the output waveform as desired.
  • The 555 could be replaced by an inverted ramp (sawtooth): An inverted ramp / sawtooth pattern which produces rapid 5V rising edges would drive this circuit equally well. A fully analog ramp generator circuit can be realized with 3 transistors: essentially a constant current capacitor charger with a threshold-detecting PNP/NPN discharge component.
  • This action potential is not all-or-nothing: In real life, small excitatory inputs which fail to reach the action potential threshold do not produce an action potential voltage waveform. This circuit uses 5V rising edges to produce action potential waveforms. However, feeding a 1V rising edge would produce an action potential 1/5 the size. This is not a physiological effect. However, it is unlikely (if not impossible) for many digital signal sources (i.e., common microcontrollers) to output anything other than sharp rising edge square waves of fixed voltages, so this is not a concern for my application.
  • Random action potentials: When pondering how to create randomly timed action potentials, the issue of how to generate random numbers arises. This is surprisingly difficult, especially in embedded devices. If a microcontroller is already being used, consider Make’s write-up on the subject, and I think personally I would go with a transistor-based avalanche nosie generator to create the randomness.
  • A major limitation is that irregularly spaced action potentials have slightly different amplitudes. I found this out the next day when I created a hardware random number generator (yes, that happened) to cause it to fire regularly, missing approximately half of the action potentials. When this happens, breaks in time result in a larger subsequent action potential. There are several ways to get around this, but it’s worth noting that the circuit shown here is best operated around 6 Hz with only continuous regularly-spaced action potentials.

In the video I also demonstrate how to record the output of this circuit using a high-speed (44.1 kHz) 16-bit analog-to-digital converter you already have (the microphone input of your sound card). I won’t go into all the details here, but below is the code to read data from a WAV file and plot it as if it were a real neuron. The graph below is an actual recording of the circuit described here using the microphone jack of my sound card.

import numpy as np
import matplotlib.pyplot as plt
Ys = np.memmap("recording.wav", dtype='h', mode='r')[1000:40000]
Ys = np.array(Ys)/max(Ys)*150-70
Xs = np.arange(len(Ys))/44100*1000
plt.figure(figsize=(6,3))
plt.grid(alpha=.5,ls=':')
plt.plot(Xs,Ys)
plt.margins(0,.1)
plt.title("Action Potential Circuit Output")
plt.ylabel("potential (mV)")
plt.xlabel("time (ms)")
plt.tight_layout()
plt.savefig("graph.png")
#plt.show()

Let’s make some noise! Just to see what it would look like, I created a circuit to generate slowly drifting random noise. I found this was a non-trivial task to achieve in hardware. Most noise generation circuits create random signals on the RF scale (white noise) which when low-pass filtered rapidly approach zero. I wanted something which would slowly drift up and down on a time scale of seconds. I achieved this by creating 4-bit pseudo-random numbers with a shift register (74HC595) clocked at a relatively slow speed (about 200 Hz) having essentially random values on its input. I used a 74HC14 inverting buffer (with Schmidt trigger inputs) to create the low frequency clock signal (about 200 Hz) and an extremely fast and intentionally unstable square wave (about 30 MHz) which was sampled by the shift register to generate the “random” data. The schematic illustrates these points, but note that I accidentally labeled the 74HC14 as a 74HC240. While also an inverting buffer the 74HC240 will not serve as a good RC oscillator buffer because it does not have Schmidt trigger inputs.

The addition of noise was a success, from an electrical and technical sense. It isn’t particularly physiological. Neurons would fire differently based on their resting membrane potential, and the peaks of action potential should all be about the same height regardless of the resting potential. However if one were performing an electrical recording through a patch-clamp pipette in perforated patch configuration (with high resistance between the electrode and the internal of the cell), a sharp microelectrode (with high resistance due to the small size of the tip opening), or were using electrical equipment or physical equipment with amplifier limitations, one could imagine that capacitance in the recording system would overcome the rapid swings in cellular potential and result in “noisy” recordings similar to those pictured above. They’re not physiological, but perhaps they’re a good electrical model of what it’s like trying to measure a physiological voltage in a messy and difficult to control experimental environment.

This project was an interesting exercise in analog land, and is completed sufficiently to allow me to move toward my initial goal: creating advanced action potential detection and measurement circuitry. There are many tweaks which may improve this circuit, but as it is good enough for my needs I am happy to leave it right where it is. If you decide to build a similar circuit (or a vastly different circuit to serve a similar purpose), send me an email! I’d love to see what you came up with.

 

UPDATE: add a microcontroller

I enhanced this project by creating a microcontroller controlled action potential generator. That article is here: https://www.swharden.com/wp/2017-08-20-microcontroller-action-potential-generator/