Open Barbell: Modifying the User Experience

My fantastic trainers Lance and Kelley at Get Strong First got their hands on a few of the Open Barbell V2 units. Joseph over at Squats and Science was kind enough to provide me with a pre-production version of the firmware, which runs on an RFduino board.

Adding Real Time Reporting

I watched the Open Barbell device being used for eccentric training, where the lifter attempts a slow controlled lower and rapid lift. The accurate information about lowering time was helpful. Unfortunately, the phone app only displays time information after a rep is completed. A lifter could make better corrections if shown real time feedback. After explaining the idea Kelley lent me a device. I discovered the current implementation of the firmware only sends a result packet after rep completion, but there’s no reason the Open Barbell couldn’t give some form of feedback to the user in real-time. This series of posts will track my progress bringing up the Open Barbell firmware and implementing the feature.

Arduino IDE Bringup

The wiki has some step-by-step directions for bringing up the Arduino IDE, but as of December 2016 the required libraries zip on the wiki doesn’t contain all the requirements. The Filters library isn’t included, and there’s a small fix to a test method needed to get the library to compile on the RFduino board. I’ve forked the library and the wiki now includes a step to clone or copy the library into your Arduino libraries folder.

Filter library fix

For future reference, here’s a quick rundown of the problem and simple fix. In the original library the RunningStatistics.cpp file has a test function that gathers filter data off the analog pin A0. Since the RFduino libraries don’t have the analog pin aliases, I’ve moved the test functions to a new file RunningStatisticsTest.cpp/h and added #ifndef __RFduino__ guards to avoid compiling it in an RFduino project.

Remember that the Arduino IDE must be restarted after adding a new library. While pulling in a code change in an existing library file only requires rerunning sketch verification.

Future Tasks

This is part one in a series documenting an Open Barbell development environment on a chromebook running GalliumOS 2.0 (a Ubuntu 16.04 based distro). This section will serve as a living table of contents of project goals and progress.


  1. Adding an on-rack accessory display with current rep data via BLE is the first step towards real-time reporting.

Environment Setup

  1. Get my Gtest/Gmock bootstrap repo going with an arduino mock library.
  2. Setup a CMake project to build and bootload the project outside Arduino IDE.
  3. Setup Vim environment to navigate the codebase.
  4. The codebase needs an automated test suite to help refactor from an Arduino sketch in a single file.

Feature additions

  1. The tach is not used for user interface input. This would be an interesting and novel method for navigating menus or making other selections.
  2. The RFduino bootloader doesn’t seem to have a way to query the payload checksum. The firmware should calculate a checksum and store it in flash on first boot. Then add it to a menu or BLE report.

Managing Dotfiles

A dotfiles repo enables simple configuring of new installations, configuration syncing between multiple machines and configuration backup with a few git commands. Dotfiles stored in source control can be shared and iterated. There’s a couple of methods for doing this.

Make your home folder a git repo

Jeff Cole provides a method to initialize a git repo in the home directory. It adds all files to .gitignore and requires dotfiles be added manually:

cd ~
git init
echo "*" > .gitignore
git add -f .bashrc

The home directory as a repo has some downsides. It preserves directory structure in the dotfile repo, making it harder to share with others. It requires the same configuration files across all hosts, making a universal configuration more difficult. Files are manually added to the repo, making it easy to lose dotfiles that haven’t been added.

However, for new Linux users there are advantages to a personalized solution. Deploying only requires cloning. It’s very quick to start and it helps learn the structure of config files. Forking a bootstrap repo requires significant customization to meet an individuals needs. That customization will be easier to do after some time spent learning your needs.

Bootstrap Scripts for Dotfiles

My dotfiles repo uses this method for an out of tree directory structure with a bootstrapping shell script to symlink the files into their correct destinations. When I bring up a new system I just have to run

git clone
cd dotfiles
git submodule update --init

My personal repo works for now, but I’d recommend forking one of the github dotfiles repos. They are robust, mature configuration and environment bootstrap repos. They’ll be less hardware dependent. I’m looking at the holman repo as it also handles provisioning to configure development environments.

Embedded Development on Cheap Chromebook Hardware

Why Develop on a Chromebook?

In embedded and web development the interesting cycles happen on the target hardware. The development host doesn’t have to be a powerful machine. A chromebook with a dual core i3 and 4GB of RAM will connect to remote web servers and compile embedded programs quickly. They come in a lightweight laptop form factor with 8 hours of battery life and boot quickly. Having a long-lasting development rig makes it easy to have your development environment with you anywhere. Embedded development has some other challenges to decouple from physical location, but that’s another blog post.

They’re Cheap

An Acer 720P with a 128GB SSD is only $400 (at list) and leaves an extra 32GB SSD to drop into an enclosure. The Acer Chromebook 15 looks to be a worthy successor. The 1366×768 resolution on the 720P is workable, but the extra viewing area on a 1920×1080 screen is worth the extra 100. Look for models with the core i3 processor, as much RAM as possible, and a replaceable SSD.

It’s already running Linux…

For web development a chroot installed with crouton gives enough access to Linux tools to develop. The chroot can control USB devices, like a USBUART or JTAG programmer, so some embedded work can be done. Unfortunately, within a chroot, systemctl commands such as starting a TFTP server for an embedded Linux device running u-boot are replaced with NOPs. Most embedded development environments will want to run a full-blown Linux installation.

…and has its own Linux distro

That need brings us to GalliumOS. A distribution, based on xubuntu and xfce, targeting chromebook and chromebox hardware. Since the developers test on ChromeOS devices they have already fixed configuration problems with trackpads, keyboard backlights, function keys and most other hardware problems encountered using the xubuntu distribution directly. GalliumOS 2.0, which went into beta at the end of May 2016, is based on upstream Ubuntu 16.04 Long Term Support release. Giving the development team five years of security and bug fixes upstream leaves the developers free to tackle the particulars of running Linux on ChromeOS hardware. If you ask good questions, the project has an active subreddit and irc channel, so support is readily available.

Replacing ChromeOS with GalliumOS

The GalliumOS wiki has comprehensive installation instructions for most hardware. If the device is listed on the chrx compatibility list, run the chrx scripts from ChromeOS to setup dual booting. Chrx can also be used to install other distros, but those will need updated configurations for the hardware.

  1. Lookup hardware on the compatibility list. The C720P is a Haswell device, codenamed PEPPY, and can be used with factory firmware, which is nice.

  2. Follow the directions for Preparing the device.
    If the factory firmware supports the RW_LEGACY boot option that’s the easiest to get running, requiring only some flags to be set within ChromeOS. RW_LEGACY allows you to dual-boot with ChromeOS, if desired. However, it requires pressing Ctrl+L at the white developer screen during each boot to enter the legacy boot system. To remove the developer screen and enable a boot with no input, you can reflash the BOOT_STUB or complete Firmware. Unless you have the tools to reflash via the JTAG interface, updating the firmware brings a very small risk of bricking your hardware. Completely read through the instructions before following along.

  3. Download the ISO

  4. Write it to a USB drive or SD card

  5. Reboot into GalliumOS live
    Make sure to press Ctrl+L if the white developer screen appears

  6. Run the installer
    The defaults install a single partition for the entire SSD. A separate partition for /home will preserve user data across fresh installations.

  7. Reboot into GalliumOS
    Enjoy your cheap new Linux box.