Member Since: January 28, 2009

Country: United States



I started at SparkFun in September of 2007 as an assembly technician. My experience in electronics had consisted of only running sound equipment for my band and fixing the occasional broken guitar cord. After only a few days on the production floor, my skills with a soldering iron improved dramatically, and I was building beautiful little widgets. It wasn’t too long before I started wondering how all these circuit boards actually worked. Whenever I had the chance, I would walk across the hallway to the engineers and ask for 5 minutes of their time. I learned words like micro controller, source code, op amp and many more. I was hooked.

My first project was an analog headphone amp. It was something I could use as a performing musician. This has since kept me busy on week nights (and most weekends) as I’ve grown my own business around audio products for musicians.

While perfecting my headphone amp design, I got into other DIY projects too. Before long, I was in my front lawn with my laptop and a few servos. I was hacking my sprinkler system. With some active pressure control, I was able to make my sprinkler shoot a perfect square. My neighbors thought I was a crazy :)

Little did I know that taking this position at SparkFun would open my eyes to a new favorite creative outlet, DIY Electronics. I get super stoked about a lot of things, but from the moment I felt that initial spark of interest, I knew this was something very special. I was learning tools that would allow me to truly harness my inner inventor.

In the last few years I have focused my energy at SparkFun to designing more efficient testing equipment and providing feedback to the engineers on how we can better design for manufacturing and testing. I can hardly call it a job, because I love it so much :)


QC Manager

Programming Languages

Arduino, Tera Term Scripts and Batch Files.


Rock On Audio


Incline High School (Lake Tahoe), Squaw Valley Academy, Cate High School, Golden West (Huntington Beach), Cal State Long Beach, CU Boulder, Sparkfun University




A nice fillet and clean layouts. DSP, particularly the Sigma Studio stuff from AD. Thermal updrafts and circling in them. Remote control Airplanes - Electric in the parking lot and Slope when the winds up.


http://www.rockonaudio.com, http://www.phillewisart.com (that’s my bro!)

Let's take a closer look at the quasi-random sequence generator for the Simon Says Trampolines project, and how a buggy first attempt was improved!

Continue reading

A re-creation of our Simon Says Soldering Kit using trampolines, spot lights and a ton of new sounds!

Continue reading

Join us for an epic journey into design for manufacturing, voltage spike suppression, stress testing, hex file analysis and more!

Continue reading

While designing our new Simon Tilts Through Hole Soldering Kit, we ultimately found that the best solution for the tilt sensor involved creating a custom plastic part. Here is the story of this project - including a couple interviews with the people that helped us along the way.

Continue reading

Dunk Tank Hack

In addition to the ongoing robot competition at AVC 2013, we included some carnival-type entertainment for the attendees. We rented a dunk tank, triggered it with a swiveling mallet, and challenged people to play "Trampoline Simon Says".

Continue reading

AVR-Based Serial Enabled LCDs Hookup Guide

August 2, 2018

The AVR-based Serial Enabled LCDs are a simple and cost effective solution for including a Liquid Crystal Displays (LCDs) into your project. These screens are based on the HD44780 controller, and include an AVR ATMega328p with an Arduino compatible bootloader. They accept control commands via Serial, I2C and SPI. In this tutorial, we will show examples of a simple setup and go through each communication option.

Pi AVR Programmer HAT Hookup Guide

July 26, 2018

In this tutorial, we will use a Raspberry Pi 3 and the Pi AVR Programmer HAT to program an ATMega328P target. We are going to first program the Arduino bootloader over SPI, and then upload an Arduino sketch over a USB serial COM port.

Raspberry Pi Stand-Alone Programmer

March 8, 2018

This tutorial will show you how to use a headless Raspberry Pi to flash hex files onto AVR microcontrollers as a stand-alone programmer. It also tells the story about production programming challenges, how SparkFun came to this solution, and all the lessons learned along the way.

Binary Blaster Assembly Guide

March 13, 2014

Learn how to assemble and play the Binary Blaster Game from SparkFun Electronics.

Constant Innovation in Quality Control

December 11, 2013

In this article, we share our recent advancements in quality control. Along with making our tests more thorough, we have also made them more efficient and robust.

Simon Tilts Assembly Guide

December 3, 2013

This tutorial will guide you through assembling your Simon Tilts PTH Kit.

Simon Says Assembly Guide

January 20, 2011

No matter what flavor of the Simon Says Through-hole Soldering Kit you've purchased, this tutorial is here to guide you through the entire build process.

Simon Says Experiments

October 21, 2010

So you've built up a Simon Says kit? What next? This tutorial will get you up and running with Arduino software, guide you through a few example sketches, and send you on your way to create your own. Careful, this stuff is highly addictive. :)
  • Hey Sembazuru, Good points for sure!

    1. If you don’t plan on cleaning with water (or can’t), then maybe a “no-clean” solder would be a better option. We clean everything here at sparkfun, either in the big production batch washer or (if there’s rework), then with a brush and croc-pot. Having compressed air also helps get all of the water (and flux) off the board completely. I suppose we are also lucky that Colorado is such a dry climate.

    2. Sorry about that. The setting was already on F, so I was just reading it off the display. 710 F = 376 C. I should have mention both. And my parents are Welsh too :)

    3. Another good point. The bottom of the chocolate kiss model does indicate a poor connection at the bottom. Small regular chocolate kisses have a much better solder joint that taper down nicely to the outer edge of the annular ring. For what it’s worth, in the hookup guide, M-SHORT references a nice graphic with some good/bad solder joints. I hope this helps all the first-timers.

    Thanks for your input!

  • Hey 773, I definitely agree. The Weller WE1010 we used in the studio, the high-precision flush cutters and the matte are on the nicer side and cost a bit more than what’s necessary for a total newbie. We have a beginners tool kit that is a good option, or if you want to go super minimalist, just this iron and solder would get ya there.

    Also, good advice about the rosin core. We always just order up some more internally here at SparkFun, so I had forgotten about what other options are out there. I just looked at our solder and the ingredients read as follows:

    96% Sn (tin) 3% Ag (silver) 0.5% Cu (copper) 0.15% Sb (antimony) Eek! How dangerous is this? I’m wondering if we should look into our supplier and see if they can omit that.

    With this in mind, thanks for the reminder about washing hands. Definitely a good idea. As always, we appreciate you comments. Thanks!

  • Hey Brambleton, Nice post and thanks for sharing! Wow that soldering in space movie was so awesome to watch. I did not expect the top of the solder wire to start melting first. (I thought it would collapse at the point where the soldering iron tip was touching). And the spinning flux was also a surprise. So cool!

    FWW, at my soldering station at home, I still use (and love) my old weller iron. When I first took the hook here at SparkFun, I decided to spend a little more and have something that would last, so I bought a nice blue weller. It’s lasted me over 11 years, so it was way worth it!

    Thanks to Mike Schock for sharing those projects. What a fun Halloween project. Does it randomly pop, or does the rotating of the front thingy play into the timing?

  • Hey asciirory, Thanks for your comment. randomSeed() is definitely a good idea. Another tip I’ve learned is (if your project has some sort of user input - like a button press to begin a game) is to send randomSeed the value from millis().

    I did this each time a new game round was started here.

    randomSeed(millis()); // Seed the random generator with random amount of millis()

    Thanks again and happy randomizing!

  • Hey 278, Good point. I think you are correct that distilling it down to the problem function is a better approach for debugging. Also, the randomization does not depend on the user input in any way, so you are right, actual game-play should not be needed to debug this problem.

    At the time when I was first attempting to fix this, I only had a couple hours to troubleshoot, so I opted to heavily tweak my code and try the “on_deck_array” approach. I’ll admit, this was not the most thorough way to fix the problem (and I never got to the root cause). At the time, I was more concerned with getting a working solution in place asap.

    Also, I actually wanted to emulate the problem without changing anything on my installation. I was slightly worried that if I started tweaking code right off the bat, then I’d miss seeing the original problem, or create new ones. So I opted to try and experience the failures just like they were happening for the participants. But I suppose after I had caused a few, then trying out some new code on a different Arduino would have been better and potentially a lot faster. Should have brought another Pro mini with me to the museum. I’m gonna keep working on building up my “in-field” debugging kit.

    FWW, when writing this post last week, (a few months after the original debugging session), I did attempt to pull out the add_to_moves() function and cause failures, but I wasn’t able to emulate the same failure. I’m guessing that my “distilled down” version of the code was somehow slightly different (and fixed?), but I didn’t track it in github, so I’m not sure.

    Also, thanks to member 993 (see comments below), I now see there was a fatal flaw in my original rules between by “count” rules and my “non-repeat” rules.

    Thanks again 278 for checking out my code and I appreciate your feedback!

  • Hey 769, Thanks for checking this out. Definitely a good question. The “non-repeat” rule is only used after gameRound becomes greater than 1. There is one more if statement before it enters the dangerous “while loop with rules”. This is found at the top of add_to_moves():

    if(gameRound > 1) // only after you make it to step 3.

    And see the full code (at that commit time) here.

    Looking at it now, I see that my comment is slightly confusing too (probably out-of-date for a previous tweak). As it sits here, this would actually allow the first two buttons in the sequence to be simply called from random(), and this would explain why sometimes I would still see a repeat on the first two. It’s all becoming so clear now :)

    I seem to remember having an issue with the out-of-bound access potential problem early on during development. Always a bit risky calling a “-1” position of an array.

    Thanks for your feedback, and I appreciate you helping out to dig further into this code. Cheers!

  • “AHA!!!” Durp. My bad. Thanks 993.

    I totally forgot to think about the previous line…

    if (!((newButton == gameBoard[gameRound - 1]))) // avoid repeats

    Nothing like a fresh set of eyes to see the problem right in front of you.


  • Thanks 993! I love the FOR loop idea as a “suggestion” idea. That is a much safer approach!

    I’m slightly confused about the first problem you explained.

    Blue, Green, Blue, Green, Blue, Green, what happens now?

    I’m thinking that it would force a Red next. Yes, it may take a while, but the hope was that random() would eventually return a “0” (aka red), and this would make all of my rules false, so it would make it to the final else and break.

      if ((newButton == 0) && (RED_seq_count == 2)); 

    False (because RED_seq_count is 0)

      else if ((newButton == 1) && (GREEN_seq_count == 3)); 

    False (because random() finally returned “0” and newButton is “0”)

      else if ((newButton == 2) && (BLUE_seq_count == 3)); 

    False (because random() finally returned “0” and newButton is “0”)

      else break;

    We made it here, and so newButton will be “0” (aka RED).

    I must be missing something?

  • Hey Bryan M, Thanks for your comment! That is definitely a good idea to output the actual return values from random(). Now it seems like that is the most important thing to look at, and I can’t believe I didn’t think to try it out first.

    While writing up this blog post, I tried emulate the problem with a Redboard and some simplified code. (because I wasn’t at the museum with access to the actual problematic setup). My Redboard was simply generating random sequences to the gameBoard[] array, and then serial printing them. I was working quite well with the original method, and so I was having trouble getting it to fail. After this, I assumed it might have had something to do with the rest of my gameplay code (which doesn’t really work without the actual exhibit hardware).

    Ultimately, I’d like to understand what’s behind random(). The reference page doesn’t really give ya much as to what’s going on inside the function.

    The good news is that my new approach with on_deck_buttons[] didn’t cause any stall outs in the following 4 months that it was up. We actually just took down the exhibit this week, and it will be in storage for a couple weeks. Once it is setup again (hoping for the Lafayette children’s museum), then I will try out some debugging with the actual setup again.

    Thanks again, and if you come across any info on the Arduino random(), please let us know!

  • Dude, so rad! Can you make one for me??!! First thing I’d want to do is link the light effects to each of my effects pedals. And get it to react to what I was playing with one of these. How is power gonna make it’s way up to the guitar?