Trying a quick turn hand-assembly prototype service


These Bus Pirate v5 prototypes were hand-assembled by a random PCBA shop on Taobao. Assembly took two days and cost 80RMB (~$12) for each board, we provided the PCBs and components. Normally we relish a prototype build because it’s a source of so many design improvements, but this was an emergency.

The USB Micro B connector on the Bus Pirate v5 and the Bus Pirate NG1 keeps breaking. In fact, the connector on v5 broke while we took pictures for a post. We soldered it on well enough to finish the photos, but we need to replace the trashed board ASAP to continue working on

How it worked

We contacted a random PCBA shop on Taobao using QQ messenger. The assembler reviewed the gerber files and quoted 80RMB (~$12) to assemble each piece. That’s just the assembly cost.

PCBs and all the components came from our own suppliers. PCBs came from the Dirty PCB factory, parts came from JLC and a few Toabao suppliers. Sourcing the components for the “kit” took quite a bit of time, maybe the same as soldering a Bus Pirate. After two days we had the PCBs and parts in our Shenzhen office, then it all went to the assembler by same-day courier.

Communication with the assembler

The assembler relied on the BOM and the PCB silkscreen to stuff the board. They didn’t need an image of the schematic nor do they accept Eagle files. All interaction happened over QQ, which is pretty typical for everything in China.


They had a single question about the orientation of a component. The dots marking pin 1 of the BL1551s was on the wrong layer and didn’t get printed on the PCB. We’ll make sure all the orientation markings are clear for a speedier build next time.


The assembler found a problem with the parts we sent too. The 74HCT4066 is in the wrong package, it should be TSSOP instead of SOIC. We ordered a replacement part from JLC and chose SF shipping for 12RMB (~$1.90). The replacement arrived at the factory the next day.

The result

Finished boards arrived in our office two days after the assembler received all the parts, about 5 days after we ordered parts. Soldering is very good, but you wouldn’t mistake it for a board done in a reflow oven. All the components are stuffed in the right place and in the correct orientation. There’s a tiny bit of flux around the LEDs, but otherwise the board is super clean.


Bus Pirates have a row of unpopulated indicator LED footprints on the back of the board named LED1A-LED4A. These are the same as the LEDs on the front (LED1-LED4), and just open up more case options at no additional cost. The BOM we sent to the assembler specified LEDs for LED1-LED4, and made no mention of LED1A-LED4A. The assembler soldered LEDs to both sides of the board.

Our instructions were too ambiguous. The LED silk labels are PWR, USB, MODE, and VREG, not LED1-LED4. There was no way for the assembler to tell which LEDs were supposed to be populated, so they stuffed them all. In the future we’ll make sure the BOM names match the PCB silk, and explicitly state which parts are “do not populate”.

Does it work?


Powered up, programmed a bootloader, flashed the latest v5 firmware freshie build. Every board works and passes the self-test.

Quick turn hand-assembly

It’s super nifty to send away parts and get back assembled boards a few days later. If the orientation of every part is really obvious on the PCB silkscreen then the assembler can probably handle the build without any questions. The boards all work perfectly, and outsourcing the build really did keep the project moving at a critical moment.

Sourcing the parts and kitting the components took a lot of time. It would be a lot easier if the assembler provided common resistors and capacitor values so we don’t have to find them. There’s also a lot of caveats: this was all handled in Chinese, requires Chinese payment methods, and our Shenzhen office was able to coordinated everything.

Glowing mercury thyratrons: Inside a 1940s Teletype switching power supply


Ken Shirriff take a look inside a bulky DC power supply REC-30 rectifier, how it works and contrast it with a MacBook power supply:

We recently started restoring a Teletype Model 19, a Navy communication system introduced in the 1940s.14 This Teletype was powered by a bulky DC power supply called the “REC-30 rectifier”. The power supply uses special mercury-vapor thyratron tubes, which give off an eerie blue glow in operation, as you can see below.
The power supply is interesting, since it is an early switching power supply. (I realize it’s controversial to call this a switching power supply, but I don’t see a good reason to exclude it.) While switching power supplies are ubiquitous now (due to cheap high-voltage transistors), they were unusual in the 1940s. The REC-30 is very large—over 100 pounds—compared to about 10 ounces for a MacBook power supply, demonstrating the amazing improvements in power supplies since the 1940s. In this blog post, I take a look inside the power supply, discuss how it works, and contrast it with a MacBook power supply.

See the full post on Ken Shirriff ‘s blog.

App note: Challenge and Response with 1-Wire® SHA Devices


Another app note from Maxim Integrated about challenge-response security on 1-wire devices. Link here (PDF)

Challenge-response can be a secure way of protecting access to any privileged material if implemented correctly. In this document, many options for challenge-response access control are discussed but the most secure method given is presenting a different random challenge on each access attempt and having a response that only the host can interpret without giving out any secrets. This document shows why Maxim’s SHA-1 iButtons® and 1-Wire devices are ideal choices when implementing this kind of challenge-response system

MIUI and tethering

My smartphone is a Xiaomi Redmi Note 3 Pro, running the “Global” MIUI ROM. Some days ago I brought a SIM card from a new italian operator, ho-mobile, which allows to use the tethering feature of the phone to connect external devices to the Internet.

I faced some problems before being able to use that feature… this blog post is to describe how I solved them.

Tethering was not working due to the incorrect configuration of a property of the Android operating system, called


As explained in Android source code, this property tells the O.S. if it’s necessary to use a DUN (dial-up networkAPN for the tethering funcion. Actually, as well explained on Taming the Droid:

This refers to an outdated method for using your phone to emulate a dial-up modem and is not the way that modern smartphones do tethering anymore. There should be no need to use this value.

To set the property to 0 (= not required), you have to send a command in the smartphone’s shell.


You need to:


In the Developer Options menu, enable the following 3 items:

  • USB debugging
  • Install via USB
  • USB debugging (Security settings)


You’ll be prompted, if not already done, to login with your MI account.

It may happen that, when you enable an item, you get the following error:


The error means that your phone cannot contact Xiaomi servers, probably because of the Great Firewall of China.

You can solve the problem thanks to an app that establishes a VPN with a chinese server, that is behind the firewall. Install, from Play Store, the Flit VPN app and run it.

Choose Start without registration, then click on Connection Settings and choose one of the Jangsu server, the one with best performances:


Click on Connect and wait until the connection is established:

x-teth004Now you should be able to enable all the debugging items without any problems. When enabled, you can disconnect the VPN and uninstall the app.

Connect your smartphone to the computer via USB and run Minimal ADB and Fastboot.

Type the command adb shell to open a console connection with the phone.

Using the settings get global tether_dun_required command you can read the current value of the parameter. If you read null or 1 the setting is wrong:


Use the settings put global tether_dun_required 0 command to set the value to zero. You can test if the command was successful re-entering the get command:


NB: if you see a permission denied error, it means that not all the debugging features have been correctly enabled:


Now you can use the tethering of your phone, happy surfing!

Homemade Atari 5200 analog controller


Dr. Scott M. Baker made a custom controller for the Atari 5200 vintage gaming console, that is available on Github:

I decided to make my own Atari 5200 analog controller, using a sparkfun thumbstick together with ADC and digital pot to do the potentiometer scaling. The controller is aesthetically a bit rough, consisting of a pcboard mounted to a chunk of hardboard, but it’s fully functional. I also recommend Ben Heck’s “Atari 5200: Making a Better Controller” video.

Project info at

Check out the video after the break. Compile PIC and ARM firmware on a cheap server


The Bus Pirate project currently has four firmware builds (v3/v4/v5/vNG1) under two toolchains (PIC C/ARM C). To make this more manageable, we use a cheap VPS to check for new code in our git repo and compile the firmware automatically. Fresh compiles are available for everyone immediately, without any intervention from developers or friendly forum members.

We wanted extremely tight integration with so we rolled our own script instead of using a tool like Jenkins. This post covers:

  • Installing MPLABX and PIC XC16 compiler for automated builds
  • Installing ARM GCC and libopencm3 for automated builds
  • A simple build service to periodically update repos and compile firmware

Is there new code to compile?

Creating builds for a bunch of platforms is boring, let’s automate it! First we find out if there’s new code to compile. With git we can check the log before and after a ‘pull’ command.

#git log --pretty=format:'%H' -n 1

Check the git log for the long hash of the current local repository.

git pull

Pull the latest commits and update the local repository.

git log --pretty=format:'%H' -n 1

Check the long hash again. The hash changed! Let’s compile some code!

make clean && make

Compile the latest code and then do something useful with the output.

Server setup

A build server can definitely run in your basement or at the hackerspace, but a $5/month VPS from Vultr or DigitalOcean is a super slick option. We run Ubuntu 14.04 LTS 64bit because some of libraries we need aren’t available for newest versions of Ubuntu.

Install instructions for both toolchains are in shell script .sh format. You shouldn’t run these! Defaults and version numbers change. Some user interaction is needed. Open a shell terminal and paste the lines one at a time. Notes in the .sh file explain each step.

Setup PIC MPLABX and XC16 compiler for automated builds

PIC firmware can be compiled on a headless Linux server since Microchip released MPLABX and the XC compilers. Installation is a bit tedious, but the toolchain works great. documents our setup. Credit to this solution.

The Bus Pirate MPLABX project needs a little preparation before compiling on the server. There’s three active hardware versions to compile for the PIC-based Bus Pirate. Each hardware version needs a separate MPLABX project, the project configuration passes the hardware version #define via a compiler flag.

Setup ARM GCC compiler and libopencm3 for automated builds

ARM GCC is easier to setup than the PIC toolchain. Install the compiler, pull the source, then compile libopencm3 and the Bus Pirate NG firmware. documents our install.

Install and configure automated build service runs ‘git pull’ every 10 minutes. If there’s new commits, the source is compiled and the firmware is uploaded to a server for further processing. Follow the steps in to install and configure the build service. has settings for the repositories and builds. Each repository can have multiple build tasks. The PIC-based Bus Pirate repo is pulled once, then compiled for three hardware configurations (v3/4/5).

The service can be started from the command line with:

/etc/init.d/bp-build start

And stopped with:

/etc/init.d/bp-build stop

If the service is installed in /etc/init.d it will start with the operating system. The script has been stable for months at a time, but we play it safe and use monit to restart the service if it crashes.

Backend processing


The firmware and build logs are packaged into a JSON file and uploaded to an API at Here’s an example of the JSON output, the important variables are described in the table below.

‘error’ 0 if make executed, 1 if make returned system error (build failed with errors).
‘timestamp’ start/stop build timestamp
‘firmware’/’hardware’ Identifying info
‘starthashlong’/’endhashlong’ Commit hash before/after git pull command
‘gitoutput’ Output from the git pull’ command
‘makeoutput’ Output from the make command
‘apikey’ Identifying info
‘firmware_type’ The file extension of the firmware. Added to automate naming in the backend. PIC uses .HEX, ARM uses .BIN
‘base64encbin’ Base 64 encoded firmware file serves up the fresh build and notifies anyone subscribed to the mailing list. We also grab all the commit notes and change history from GitHub so it’s easy to see what’s in the build. You can check it out here.

Up next

For the rest of this week we’ll be testing a new version of Dirty Cables at

Later next week we’ll receive a few hand-assembled Bus Pirate v5 prototypes. We ruined another Bus Pirate v5 prototype by tearing the USB Micro B connector and traces off the PCB. Instead of building another board in-house, we sent the parts to a Chinese PCBA that does two-off hand-assembled prototypes. Let’s see how they turn out! Automated documentation updates


Up-to-date documentation makes a project easy to learn about, but its a really boring job that takes a lot of time. Even great documentation eventually has outdated examples and screenshots that don’t quite match the latest version. has a hacked together toolchain to keep the documentation fresh.


It’s a three part process:

  • Test scripts run demos on actual Bus Pirate hardware
  • Results files are uploaded to
  • Tutorial templates and the results files are merged to make updated docs

Hardware and firmware specific docs


Bus Pirate documentation is full of version caveats like “Hardware v4+ only” and “Firmware v5.1+”. docs are versioned, and just shows the stuff that matters for your version. Choose a hardware and firmware from the menu to see the docs for that specific combination.

Automated updates

Developers still need to add new feature information manually, but the huge task of “refreshing” everything after a firmware release can be automated. We took a three step approach: test scripts that run commands on actual Bus Pirate hardware, results files that capture the test output, and templates that merge with result files to create version-specific documentation.

Test scripts


Test scripts are just a list of commands to run on the Bus Pirate, for example running a self-test.  A test has multiple steps, and each step has one or more Bus Pirate commands. We build the demos with a simple editor, then dump them to JSON in a file. Here’s the test script that runs all the commands shown in the reference manual.

Results files

buspiratecom-pipepy sends commands in the test script to a Bus Pirate. It also records the terminal output to a results file. Result files are uploaded to Here’s the results file from the reference manual test script.



Demos and docs are blade templates. A template merges with a results file to show the tutorial exactly as it appears on a hardware and firmware combination. It’s not super elegant, the version specific stuff is done with a bunch of PHP if statements.

Taking it further

Command Reference, Self-test guide, Pull-up resistors guide, and Number entry guide are up now on the new site. More will come soon.

Ideally the update process will be triggered by an automated firmware release. An RPi in the workshop will bootload the new firmware into the Bus Pirate, run the test scripts, and upload the results without any intervention.


A test rig with a bunch of devices might be a cool way to do release testing.  Scripts could test various firmware features on real devices.  Comparing the scripted test results with a previous release would highlight things that may be broken. Our goal is to hack together something that does comprehensive release testing with no manual effort.

Thursday we’ll document the automated build server that’s kicking out freshies every time there’s new code in the git repo. A dedicated website for docs, firmware, tutorials


Bus Pirate documentation and demos are all buried in a huge wiki and around the blog, this is less than ideal for such an expansive project. We’ve been working on a new site just for Bus Pirate stuff.

This site is full of hacks that automate boring development stuff.

  • Documentation and tutorials are updated through test scripts and a templating system
  • The latest code in the git repo is compiled continuously and always ready to download
  • Firmware releases are packaged and announced automatically

There’s a broad overview of the site features below, we’ll follow up with detailed posts later this week.

Big obvious menu options


It’s a simple thing, but it makes a big difference. Obvious menu options dedicated to the Bus Pirate are a nicer experience than digging through a wiki with stuff about dozens of (partially) completed prototypes.

Versioned tutorials you can download in PDF


Bus Pirate documentation is full of version caveats like “Hardware v4+ only” and “Firmware v5.1+”. docs are versioned, they only show info that applies to a specific hardware and firmware combination.


Docs can be downloaded as a PDF. We tried to use PDF specific stylesheets so the docs look as good printed as they do in a browser. wkhtmltopdf handles the conversion to PDF, it’s by far the best conversion tool we’ve worked with.

Automated firmware builds and release packages


An automated build server compiles new firmware every time there’s a commit to the git repo. This is a huge improvement for everyone. Users get the latest bug fixes without compiling from source, and developers don’t have to make interim releases for a bunch of platforms.

Currently the build server compiles firmware for four hardware versions (v3/4/5/NG1) under two different compilers (MPLABX/XC16, ARM GCC).  We’ll document the build server on Thursday.


Firmware releases are packaged and announced automatically. The release is a tidy archive with the latest firmware, update tools, readme.txt and updated history.txt.

Notification of new tutorials, releases, and firmware builds


Subscribe to be notified of new developments. Firmware builds and releases mailing lists can be limited to a specific hardware version to cut down on noise.

Taking it further

Later today we’ll post about the system to automate updates of the Bus Pirate tutorials and documentation. Thursday we’ll show how we setup an update automated build server to compile PIC and ARM firmware on a $5/month virtual private server.

Pocket Pi


A Raspberry pi zero w pocket terminal project from Facelesstech, that is available on Github:

So if you have been following my blog lately you may have noticed me rambling on about trying to get a Xbox 360 chat pad and an ps3 keypad working with a raspberry pi to make a portable terminal. I have finally finished my quest so join me below to see how I did it

More details  on Facelesstech blog.

Check out the video after the break.