VeloKey: A post mortem

Posted on February 19, 2017 by wyojustin

VeloKey is a Keyboard for your bike. I know. I know what you are going to ask: “Why do you need a keyboard for your bike?” Well, I guess you don’t. This is the story of a failed project. We break down why and how this project failed in hopes to learn from the experience.

First let me remind you why we thought VeloKey might have made a viable product.

Project goals: Many people ride bikes indoors for hours at a time. They use a computer to: run a training program (virtual world), watch videos, browse the web, and read email. These activities could be made easier with a cycling specific computer interface.

A full QWERTY keyboard would be too cumbersome to operate while you are pumping out the Watts, so we simplified the interface to three scroll wheels, a display, and a few buttons. If you need to author your manifesto, then by all means use a different interface. VeloKey is meant for typing the first few characters of a web address, not a dissertation.

Features:

Wireless — you don’t want to be burdened with cords on the bike. VeloKey uses the Bluetooth HID interface.
Full Keyboard — Letters, numbers, symbols, arrow keys
Full Mouse — Works like an etch-a-sketch, left/right clicks
Display — Select keys, change modes.
Magnetic handlebar mount — Allows rider to remove the VeloKey, and use with both hands.

Project design:

Open source hardware — Like all of our designs this was important to us. We are empowered by open hardware, and we will always publish our designs in the hope that others find them useful.
Off the shelf open hardware components — This really sped up development time.
High quality scroll wheels — this subtle clicking of these wheels are addictive like popping bubble wrap.
Custom back plane — Anool whipped up the board that ties the circuit together.
3D printed case — Snap together, magnetic base, Garmin quarter turn mount

Hardware:

The design is centered around the Feather M0. This M0 has plenty of program memory if you are used to programming AVR 328s found in the Arduino Unos. Its a fantastic little ship with multiple hardware serial ports, can act as an HID keyboard and mouse (which backs up the Bluetooth) and is well documented.

We used an arduino pro mini to provide guaranteed encoder readings. Kevin did have some luck reading the encoders directly from the M0, but never all three at the same time and also not with background tasking. Using the Pro-Mini was a quick and rely able way to implement the encoders. The Pro-Mini is connected to the M0 via a serial link.

The EZKey module provides the Bluetooth HID interface so that VeloKey does not require any software modifications on the host computer. The EZKey is connected to the M0 via a serial link.

Software:

The software was developed using Arduino. Upon startup, VeloKey launches into a software defined default mode (typically mouse mode). Scrolling the middle wheel allows you to change modes from mouse, to keyboard, to program, to movie. Modes are defined in an extensible object oriented manor so that VeloKey will play nicely with community defined modes. The Pro-Mini translates encoder events into serial events and sends them to the M0 where the events are handled.

The beginning of an extensible API was created to test VeloKey as a gaming platform. A few basic sprites and widgets were defined and the API was used to create Pong and Asteroids.

Cause of death: Lack of interest.

The main reason VeloKey Failed was negative feedback from three sources. First, the local bike shop said that “VeloKey” solved a non-existent problem. A virtual training company rejected hardware in favor of their phone app. And finally, a beta tester said that it was too distracting. Three strikes and VeloKey is out.

Contributing technical factors:

If it weren’t for these technical factors, we’d probably still pursue a crowd funding campaign. After all we have a lot of effort invested in VeloKey. Before we launched, we’d have to solve this technical issues and that would take more investment of time that we felt would not pay returns.

Feather M0 lock-ups. Frequently the M0 locks up especially when interfacing with the Bluetooth module.
Flaky Bluetooth. Several beta testers had trouble pairing the Bluetooth on Windows and Mac.
Draining battery. The Feather M0 has no way to shut off current completely. This meant that VeloKey could not be left on the bike, but would need to stay on the charger between uses.

Other uses?

VeloKey or something like it may be useful as a mobile computer interface, or game platform. We tested it out with Pong and Asteroids. The update rate was a little on the slow side for any graphic intensive games.

Building A Guitar Tuner With The New Ultim8x8 LED Panel

Posted on November 6, 2016 by Rohan Chandra

With the introduction of the Ultim8x8 boards came a desire to build something with them, and after bouncing idea after idea off of Mr. Shaw, we finally decided to build a guitar tuner. However, while one may have just resolved to use a simple vibration sensor in order to get the readings from the guitar, we decided to take the software up a notch, and now I am in the process of coding my very first Fourier Transform.

Essentially, the idea of this guitar tuner is that the player will play a note, which is then picked up by the microphone. A Fourier Transform is run on the note (the code will take the frequency of the code and round it to the nearest frequency, for instance, if I want to play an A440, but my guitar is tuned to play an A450, the program will assume that the player is trying to play an A440, and will accordingly notify the player), and then the note is displayed on the LED Panel, only its color will be an indicator that the note is either exactly tuned or it is a little off.

The process of building this guitar tuner has not been an easy one, but it certainly has been nothing if not an educational and overall exciting experience. Through Mr. Shaw, I was able to receive 3 microphones, as well as capital for the necessary parts for this project, which included a set of calipers, an Adafruit M0 Basic Proto Feather Board, a 2000 mAh LiPoly battery, a slide switch, some extra wire, and a delightfully colorful pack of heat shrink tubing. Below is a list of the steps I have taken so far in building the tuner:

I first tried designing a 3d printed mount for the LED panel in TinkerCAD. However, the design I made proved to be too small for the panel to fit. Plus, I hadn’t thought about how the placement of the panel would affect the sound made by the guitar. Since this was a problem that I could easily fix, I decided to move on to the more challenging part of this project, which was the software.
However, in order to test the software, I needed to set up the proper hardware. I soldered one of the Ramsey Electronics Microphones into the prototyping area of the Feather Board in order to test its effectiveness in picking up sound.
1. I pulled some sample code from the Adafruit website, who uses the same microphone in their microphone breakout boards, and tested to see if I was getting a reading out of the device. Sure enough, the microphone was wired correctly and reading the beautiful sound of my voice.
After a fruitful meeting with Mr. Shaw, who kindly explained to my perplexed self the art of the Fourier Transform, I started writing the software for the microphone.
1. The first draft of my code was marginally successful, meaning that it compiled and that was about it. After a few suggestions from Mr. Shaw, I was able to fix most of my errors, and am still today working on tweaking and improving the code.
My next step in the hardware side of this project was to solder the DATA, CLOCK, GROUND, and POWER pins from the Ultim8x8 board to the Feather so as to test it.
1. Similar to how I tested the microphone, I downloaded the Adafruit DOTSTAR library and ran one of the sample programs on the board. Sure enough, it lit up like a Christmas tree!

Thus I have relayed upon to you, the reader, my progress so far. My next steps in the project include designing a better mount for the panel, fixing my software (which mainly involves figuring out how to include the complex exponential (e^2 pi i f t ) into my code), and ultimately integrating the software with the microphone and the software with the panel together. After all that, I will hopefully have a badass guitar tuner in my hands.

Below is a photo of the tuner so far.

Below is a photo of the microphones I received. I am using the one on the left for this project

Finally, below is a photo of my first take at the 3d printed mount.

Uploading the New and Improved ClockTHREE Jr. Code

Posted on July 24, 2016 by Rohan Chandra

Hello! My last blog was about updating the ClockTHREE Jr. software, however, today I will be writing about the process of uploading the code all the way from the Arduino IDE to the master GitHub repository. Once I got the hang of it, the process was as easy as printing “Hello World” with Python.

First, I downloaded Git on my Ubuntu Linux computer using the command “sudo apt get update” and then “sudo apt-get install git.” However, you can also just install it from the URL listed here: https://git-scm.com/downloads
The, I logged into my own GitHub account and opened up the Wyloum repository. From there, I clicked the ClockTHREE Jr. tab.
Once there, I forked the repository by pressing the (Well what do you know?) “Fork” button in the top right corner. This created a branch of the master Wyolum ClockTHREEJr repository in my own account. I did this so I can freely modify the code without affecting the master repository.

Screenshot from 2016-07-24 15-59-47

4. After clicking the Fork button, I went back to my personal account and I had the forked repository as rohanius/ClockTHREEjr. Next I cloned this repository to my hard drive. I did this by copying the git link by pressing the green button labeled “Clone or Download” (Make sure that when you push the button, the words “Clone with HTTPS” appear, not “Clone with SSH”).

Screenshot from 2016-07-24 16-37-52

5. I then opened a terminal and made sure that it was currently pointing to my “projects” folder (make sure next to the original line it says /projects). After that, type in “git clone https://github.com/rohanius/ClockTHREEjr.git”. This cloned the repository to my hard drive and created a folder in my “projects” folder and named it the same name as the repository – ClockTHREEjr

Screenshot from 2016-07-24 16-08-31

6. I was then able to edit the code as I pleased in my local repository.

7. After accordingly editing the code (which I explained in my previous blog), After compiling and testing that my code changes worked, I opened the terminal once again and changed the current directory to be /home/rohan/projects/ClockTHREEjr

8. In that directory, I typed “git commit -a -m “Updated code for Arduino 1.6.9”. This command committed all my local changes to the local git repository that I had cloned.

“-a” means “all the files in that directory that have been modified” and “-m” just allowed me to type a small message once I committed the code.

9. After committing the code, I simply pushed it to my GitHub repository using the command “git push”

10. Finally, I went back to my GitHub repository (rohanius/ClockTHREEJr.) and clicked the pull request tab. From there, I made a new pull request for the original owner of the ClockTHREE Jr. repository. Mr. Shaw was then able to pull all my changed and merge them to the master ClockTHREE Jr. repository.

Screenshot from 2016-07-24 16-23-37

Updating the ClockTHREE Jr. Software

Posted on July 3, 2016 by Rohan Chandra

One of my first tasks here at Wyolum was updating the old ClockTHREE Jr. software for Arduino 1.6.9, the newest version. I focused specifically on updating the file specified in the original tutorial for reprogramming the ClockTHREE Jr., ClockTHREE_04.ino. At first, when I tried compiling the sketch, the number of error messages that popped up frightened me. It was just a sea of blaring orange text, informing me on the multitude of errors spanning a variety of different documents. The task seemed to be very daunting, and I did not know if I would be able to complete this task. However, after I had gotten over my initial shock, i decided to be brave and actually read the error messages, rather than judge the difficulty of the task by their quantity. This act turned out to be immensely helpful, as after my analysis, I discovered that there were only 6 documents that needed to be changed, as opposed to my crazy original assumption of 20 or 25. Furthermore, there seemed to be one term that resonated throughout the error messages: “const.” With these 2 helpful facts in mind, I got to work. Below is a detailed analysis of what I did to the 6 documents:

In the original file itself, ClockTHREE_04.ino, I included the english_v3.h file, uncommented the line that let the ClockTHREE Jr. account for Daylights Savings Time, and most importantly, changed “prog” in the line “PROGREM prog_uint32_t DST[] = {“ to a “const.”
In the next document I changed, english_v3.h, I simply added a const after the “uint8/32_t” in the lines with WORDS[] PROGMEM, DISPLAYS[] PROGMEM, MINUTE_LEDS[] PROGMEM, and MINUTES_HACKS[] PROGMEM.
The next file I had to change took me away from the ClockTHREE Jr. file and into the CHRONOGRAM2 file, where I had to update the english2_v1.h file. In this file, I changed “prog_char” to “const_char” in the lines with HOUR_WORDS[], HOUR_SEQ[], MINUTE_WORDS[], and MINUTE_SEQ[].
In the files font.cpp and mem_font.cpp, I respectively changed “PROGMEM static char prog_char font8x8[] = {” to “PROGREM static const char font8x8[] = {“ and “static prog_char font8x7[] PROGMEM = {“ to “static const char font8x7[] PROGMEM = {.“
In the final document I changed, DateStrings.cpp, I added a “const” to:

char monthShortNames_P[] PROGMEM = “ErrJanFebMarAprMayJunJulAugSepOctNovDec”;
char dayStr0[] PROGMEM = “Err”;
char dayStr1[] PROGMEM = “Sunday”;
char dayStr2[] PROGMEM = “Monday”;
char dayStr3[] PROGMEM = “Tuesday”;
char dayStr4[] PROGMEM = “Wednesday”;
char dayStr5[] PROGMEM = “Thursday”;
char dayStr6[] PROGMEM = “Friday”;
char dayStr7[] PROGMEM = “Saturday”;
PGM_P dayNames_P[] PROGMEM = { dayStr0,dayStr1,dayStr2,dayStr3,dayStr4,dayStr5,dayStr6,dayStr7};
char dayShortNames_P[] PROGMEM = “ErrSunMonTueWedThrFriSat”;
char monthStr1[] PROGMEM = “January”;
char monthStr2[] PROGMEM = “February”;
char monthStr3[] PROGMEM = “March”;
char monthStr4[] PROGMEM = “April”;
char monthStr5[] PROGMEM = “May”;
char monthStr6[] PROGMEM = “June”;
char monthStr7[] PROGMEM = “July”;
char monthStr8[] PROGMEM = “August”;
char monthStr9[] PROGMEM = “September”;
char monthStr10[] PROGMEM = “October”;
char monthStr11[] PROGMEM = “November”;
char monthStr12[] PROGMEM = “December”;
PGM_P monthNames_P[] PROGMEM =

After saving all of my changes, I compiled the code in Arduino 1.6.9, and to my utter delight, it worked!

a TiM Moodlight

Posted on April 17, 2016 by anool

A couple of weeks ago, I noticed a pair of old, first version TiM boards lying around at my local maker space, Maker’s Asylum and decided to put them to use by building a MoodLight. We love crazy names at WyoLum, and TiM is “The Intelligent Matrix”. We even tried building a controller for it called TiNA but it didn’t work out 🙂

TiM (The intelligent Matrix) is an array of 8×16 individually addressable 5050-WS2811 RGB “smart” pixels. It is essentially 8 rows of 16 LED’s but with a very flexible connection scheme that allows you to control the whole array (128 LEDs) with a single pin or up to 10 boards (1280 pixels) chained together using 8 input pins. TiM boards can be linked together to create larger matrices. Stacking can be done in the vertical and horizontal orientations, and the pitch between individual LEDs is maintained when boards are stacked. Here’s the TiM User Guide.

I had two boards on hand, which I joined together to form a 16×16 matrix of 256 LEDs. TiM boards need an external controller, and I used an Arduino Clone that I designed for use at the Maker’s Asylum called MAPone (Maker’s Asylum Project #1). MoodLights require some form of user interaction, and I decided to use one push button (digital input) and one potentiometer (analog input). The whole thing is powered by a 5V wall wart.

For the software, I tried some code I found on the web, but none of it did what I wanted – change modes by pressing the button, and change colors using the potentiometer. I can’t code if my life depended on it, so I chucked the problem at my go-to guys – Justin and Kevin. Justin is quick, like the Energizer bunny, and threw back code at me on the rebound. But it required using four potentiometer’s to control the colors. Since the HW was already wired up, I waited to see Kevin came up with something different, which he did. Nice code which allowed different modes to be selected by a button press. The first mode is the standard Rainbow colors from Adafruit’s StrandTest. Then, there’s a color changing mode, Breathing LEDs, Connection Machine (which looks something like Conway’s Game of Life), and finally a scrolling Text mode. This is enough to start with, and I’m sure if anyone at the Asylum wants to hack and dig in to the code, there’s a lot for them to play around with.

I designed the enclosure in OpenOffice Draw. A laser cut piece of MDF that wraps around the TiM PCB using some “living hinge” bends. I tried some junked 3mm MDF first, but the material was kinda bad – some parts cut well, while other areas were left with a charred and burnt top layer, so I had to scrap that. Next, I tried 5mm MDF that way lying around, and while it cut well, it was a tad thicker than I preferred and the hinges were stiffer being designed for thinner 3mm MDF. Anyhow, it worked and I was keen on just finishing this off. I also cut an additional square piece of 2mm white polypropylene sheet for the front diffuser. Most of the electronics was stuck in place using generous globs of hot glue. I added some hand drawn graphics to wrap it off, and left it at the asylum. Let’s see how they mount it up.