Nerf Mod Party

At our most recent family reunion, in addition to the traditional rock painting, this year we modified Nerf blasters and then had an epic family Nerf war. 

I really like the Nerf Disruptor for this type of "modding":

  •  They are inexpensive and available both commercially and at thrift stores.
  • The shell comes apart into several pieces for painting.
  • They are very easy for children to operate.

I made a short video that shows how to reassemble a Nerf Disruptor.  If you use another type of blaster, be sure to take a picture after you open it up to aid in reassembly!

I've published more details on how to do a Nerf Mod Party at:

An Experiment in Nerf Blaster Modification Performance

I've been dabbling in modifying Nerf dart blasters recently.  The modifications fall into two categories: appearance and performance.  Nerf "blasters" themselves fall into two broad categories: manual spring powered and electronic flywheel powered.  I've been drawn to all areas of the hobby, but have spent the most of my time with performance modifications of flywheel blasters.  I've been particularly interested in using Arduino microcontrollers to monitor and control the operation of the blaster.  You can see my published projects to date:
Most performance Nerf "mods" seem to fall into two categories: 
  • Cheap Chinese kits that are poorly documented.
  • Very cool custom builds that are complex, poorly documented, and hard to replicate.
My goal, as always, is to document inexpensive and easy to build projects geared towards a successful and rewarding "first mod" experience.  In working towards that, I've gathered quite a bit of data about what modifications provide the best performance.  Starting with the most popular modding blaster, the Nerf Stryfe, I looked at the effect of flywheel speed, motor current, and dart velocity for a number of configurations.

Batteries: The stock Stryfe is powered from 4 x AA batteries for a nominal 6V.  Upgrades to lithium polymer increases voltage (7.2 V) and significantly increases current delivering capacity.  

Wiring: The increase in current from LiPo batteries require upgrading the stock wiring to at least 18 AWG, and either replacement of the microswitches to higher rating or the use of a MOSFET control circuit.  The MOSFET control circuit lends itself well to microcotroller use, and eliminates the need to upgrade the wire to all but the short section from battery to motor.

Motors: Over-volting the stock motors would certainly be frowned upon from an engineering design standpoint, but going from 6V to 7.2V is fairly minor and I have noted no increase in motor temperatures or indication of degradation.  Given the short run-times of motors during typical use, the longevity of the motors does not appear to be an issue.  Aftermarket motors are designed for higher voltages, current, and speed.

Instrumentation: Motor speed and dart velocity are measured using infra-red emitter detector pairs monitored by Arduino.  Motor current is measure using an Adafruit INA260 breakout board attached to the Arduino.  Configuration tests are run twice, once measuring motor speed and current, and once capturing dart velocities of ten shots.  Data from the Arduino is outputted over a serial console and copied into spreadsheets.

Enough babbling.  The data!

Additionally, I was interested in the operation of the stock resetabble fuse.  This fuse limits current as it heats up, and resets itself after cooling down. This is clearly shown in a graph of current verses time for a stalled stock motor:

A lot of modders remove the fuses since the increase in current draw will trip the stock fuse quickly.  I have heard of and witnessed motor burnouts caused by stalls with removed fuses.  A novice who jams a dart on a modded blaster while continuing to hold down the rev switch with cause this in short order.  I advocating protecting your after-market motors with appropriate capacity fuses.  It is worth it if for nothing other than avoiding the smell of the magic smoke that come out!

  • It is very easy to get to 100 fps using stock motors by upgrading the battery and wiring.
  • The 2S Lipo and aftermarket motors were able to achieve near the 130 fps limit set by a number of competitions.
  • Aftermarket motors significantly decrease the motor spin up time at the cost of very high starting currents.  And noise.
  • Increase in dart speed using the aftermarket motors was only realized using aftermarket flywheels.
  • The use of 14500 Lipo batteries, while controversial in the Nerf community, appear quite compatible with the stock motor currents. These have the advantage of not requiring any shell cutting.  You will note that I did not try them with the aftermarkert motors for concern about the current draw.
  • It is interesting to note that stall current and starting current of the stock motor are nearly identical.  The listed stall current of the Meishel 2.0 motors are 18.8 A, or 37.6 A for a pair, which is close to 33 A starting current observed. This should be useful in choosing fuse size.
As in most hobbies, incremental increases in performance come at exponential increases in cost and effort.  People are spending hundreds of dollars to achieve 200+ fps blasters while experiencing diminishing, even deteriorating returns on accuracy and distance.  For now I intend to stay in the shallow end of pool while concentrating on the benefits of smart, Arduino-controlled blasters, such as ammo counting, clip capacity detection, battery monitoring, and select fire.

Stay tuned for a kit.  You may have seen a sneak peek in the first photo.

What Open Source Means to Me

When I look back at starting with electronics, I would point to Adafruit and Lady Ada.  I bought her Boarduino (which is still on sale!) back in 2008, and while I was able to solder the kit together easily, I was quite confused by by the difference between Atmega168 pin numbers, and Arduino pin designations. She answered my questions quite patiently:

And here is my first project with that board:  I went on to design a model railroad, a rocket telemetry system, and most recently, a deviously difficult surface mount challenge.

The Boarduino, while I paid for a kit, was free.  It was Open Source.  Lady Ada published the schematics and even the files necessary to reproduce the PCB.

Fast forward a decade.  I can design a PCB.  I can program an Attiny.  My first published project was a programmer for microcontrollers.  I published my designs for free.  Why?  Because Lady Ada did.  That is how I learned.  That is how I hope to teach.

One of the designs I am most proud of is my Drawing Robot.  I have spent a lot of hours designing and refining the 3D files, electrical design, and the firmware. I have used it to teach several workshops.  Many people of have copied it.  Several people have improved on it.  That makes me happy:

Recently, I was excited to see a picture on Twitter, but when I commented on it, I was surprised to see it attributed to someone else:

Wait!  What?  It is being used in a classroom:  Good!  But who is Josh Burker?  Well, apparently it is someone who used my designs,  and decided to sell a kit!  For $275?

Is that legal? Ethical?  Moral?  What I have been spending all my time doing this for?

The Instructable on which is project is based is published under a Creative Commons licence, which is pretty clear:

So far, so good.  He is sharing, and adapting, but:

Oops.  While I see a link to my Instructable on his webpage, I see nothing on his website to indicate the original design isn't his.  The fact that the teacher using the project attributes it to him would further indicate this failure.   Oh, and there is the noncommercial thing.  I assume that means the $275 is a no-no.

Let's take a moment of self-reflection.  A drawing robot is not my idea.  Did I attribute it?
Here is the robot that came closest to what I wanted to do: I don't have a laser cutter and shipping from England was prohibitive. I do have a 3D printer, so I guess you can see where this is going . . .
Mirobot claims to be Open Source, and has published repositories, but it is laser cut and Wifi controlled.  Way past what I want to get into.  I didn't use their design files or code. About all I used was the "pen in the center of the wheelbase" idea.  The Turtle idea goes back even farther, to the 1960s!

So, I'm mad.  Certainly not at the teacher, who is trying to bring ideas and concepts to their classroom to the best of their ability and under a tight budget. But, someone is trying to profit off my my work.  When I point out the CC License violations, I am told to "bugger off," and that "We redesigned the electronics: they use a completely different microcontroller and programming language."

I will give him that using the Logo language takes the project one step closer to it's 1960 roots, and if that helps with the classroom curriculum, I will adapt that and attribute him.  That is how Open Source works.  However, if he thinks that switching from an Adafruit Trinket Pro to an Adafruit Metro Mini constitutes "redesigning the the electronics", I would point out that they both use the Atmel ATmega328 microchip, and are both Open Source projects, by the same author, Adafruit.  Wow, did that just circle around, or what?

So, back to the original question, what does Open Source mean to me?  I learn, I play, I share, and I may even try to sell you a kit, but if you try and profit off my work, I'll get mad.  And do a blog post.  And probably get blocked by @joshburker on Twitter.  Wait, was I following him?  No.  Didn't think so.

If you want to follow me, and be the first to see the next generation drawing robot, or what ever Open Source idea I attribute or contribute to next, you can follow me at @TheMakersBox on Twitter.

Is Your LED in Backwards?

Since the Arduino I/O pins can sink and source current, it is possible to use one pin as the ground and the other the supply for an LED.  One of my very first projects, actually used bi-colored LEDs and you could change the color by reversing the pins.

I've been doing beginner soldering kits, and putting an LED in backward is a common mistake. It occurred to me I could use this trick so that a reversed LED could still be used without having to remove and reverse it. Better yet, could it be detected and accounted for automatically?

Since the LED only allows current to flow one direction (unless it is bi-colored), and we have the ability to read the pins as well as output to them, we should be able to figure this out. If we apply voltage (via the internal pull up resistor) to one leg of the LED, if it goes high, near the source voltage, we can assume we are dealing with the cathode, or negative side since no current is flowing. Conversely, if the voltage drops, we can assume we have the anode, or positive side since current is flow.

Enough theory. Time for proof. With the LED correctly installed, an analogRead() on the pulled up port reads ~350, or 1.7 volts.  With it in backwards, it reads nearly 5 volts.  Since the voltage drop is more than half, the digitalRead() can be used and the resulting true/false value assigned to correct or incorrect orientation.

Seems like a silly thing, but then again, silly things can be useful at times.

Here is my code if you want to try it for yourself:

int ledPinNeg = A0;  // assume negative lead
int ledPinPos = A1;  // assume positive lead

void setup() {

  // test: with a weak pullup, the pin will read HIGH if LED in backward (no path for current)
  pinMode(ledPinPos, INPUT);
  pinMode(ledPinNeg, OUTPUT);
  digitalWrite(ledPinPos, HIGH); // turn on pull up
  digitalWrite(ledPinNeg, LOW);  // sink current
  int testVal = digitalRead(ledPinPos);  // reads < 400 if orientation is correct
  Serial.print("Pin ");
  Serial.print(" = ");
  // set both pins to OUTPUT and LOW
  digitalWrite(ledPinPos, LOW); // turn off pullup
  pinMode(ledPinPos, OUTPUT);

  if (testVal){// LED is backward, just swap pins
    int temp = ledPinPos;
    ledPinPos = ledPinNeg;
    ledPinNeg = temp;
    Serial.println("LED IS BACKWARDS OR MISSING");
  else {
    Serial.println("LED APPEARS CORRECT");

void loop() {
  // put your main code here, to run repeatedly:
  digitalWrite(ledPinPos, HIGH);
  digitalWrite(ledPinPos, LOW);

How to Price a Kit

- VS -
I've seen a couple of post recently on Hack-a-day and Twitter about my Geek Spinner (and US based kits in general) being priced too high.  As both a maker and consumer of kits, let me first say that I am sensitive to this issue. When I price a kit, the first question is always, "would I pay this much for it?"  Consider the following:

  • I publish my BOM and PCB files along with instructions and firmware, so you don't need to buy anything from me.
  • I sell kits to cover the cost of my developing them.  I usually build at least three versions before I'm willing to put it out there for others to try.
  • I price the kits to cover the cost of materials and my time for packaging the kits.
  • I enjoy designing and making kits and helping others make them.  I do not enjoy kitting or selling them. It is a lot of work.
  • I'm selling at very low volumes, usually in multiples of ten, where the scale of economy has barely begun.
I think, in general, what we fail to recognize when we look at the price of kit, are the intangibles:
  • Well documented, well supported.
  • Quality components from known sources.
  • Design files and schematics so we can understand or modify the design to our own purpose.
  • Tutorials and examples files.
I've sold enough kits to know that I'm at least in the ball park.  I'm making enough so my wife doesn't need to see the credit card bill for the weekly Digi-Key delivery, or to sweat making a medium-run OSH Park PCB order when I'm ready to face the public.  I'm also sure, that if I total it all up, I'm  making below minimum wages.  But then again, I'm doing something I enjoy.  For the most part.

So, vote with your dollar.  But also ask yourself, "is the seller adding any value?"

Building Your Own Multimeter

An experienced hobbyist should be able to build a well designed project from the BOM (bill of materials) and the markings on the PCB.  The rest of us need some help. I recently put together an $11 multimeter that had very little documentation, and I figured I might add some tidbits to the interwebs that might help others get through this.  Like a Jedi and their lightsaber, what could be better than building your own instruments!

This is a DT-830T "Digital Multimeter Electronic Training Kit from  If by "training", they mean figuring things out on your own, this is a winner.  My first plan of attack was to sort the resistors and mark the PCB diagram with values (why don't they do that to start with?)  Ironically, since I can't identify anything other than 330, 1K and 10K by sight, I used a multimeter to test and label the resistors.  Kind of a chick-and-egg thing. There are more 220K resistors than any other, so getting them out of the way significantly lowers the others than need sorting.
The only thing that tripped me us was the fact that resistors R17 and R38 have switch position between the diagram and the PCB silk screen.

With resistors out of the way, I turned my attention to capacitors. Again, I'm not good with reading values, but another recent project, a GM328 Transistor Tester, got put to go use.

Here are the values and markings:

  • C1 - 100 pF - "101"
  • C7 - 220 pF - "221"
  • C2, 4, ,5 ,6 - 100 nF - "104"
  • C3 - 220 nF - "224"
  • C8 - 1 uF - "105"

The final unidentified component was marked "4B DMZ".  This is a re-settable thermal fuse, and by this point there are only a couple of empty spots on the PCB it could go (R32).

There are some springs and ball bearings that were not obvious (to me) where they went. I found a Youtube video of someone assembling this as a clue.

With everything assemble, it worked, and I tested it against known voltage and resistance, and it was pretty close. There is an a potentiometer (VR1), which I assume is for adjustment, so I tweaked it to match the known voltage.

My main use for a multimeter is as a continuity checker with the buzzer.  That is where this meter shines.  Instead of having to rotate the selector switch to the resistance setting on the Fluke and then press a button to get the speaker, I can leave the rotary on the DT-830T on continuity and just turn it on and off with the push button.  Not many meters work that way. That alone makes it a keeper.  Plus, I can say "I made this myself".

And, if it helps you, here is my scratchpad:

How Fast is Your Fidget Spinner?

You never know what people will do with your ideas, and it is always fun to see someone do something I would have never thought of with them.  I got a video from someone who built my Programmable Fidget Spinner, and used a leaf blower to see how fast they could get it to go.  Fortunately, they were wearing safety glasses, and no, it didn't come flying apart.  It did, however, start displaying erratically at about 3600 RPM (the fastest I can get it by hand is just under 2000 RPM).

So, what is going on?  TLDR: I figured it out and fixed it, and here is proof.

One of the reasons I love Arduino is because it is so easy to write and understand it's code.  All the hard parts that scare beginners away have been abstracted out.  Case in point, to turn on a single LED, all I have to do is call the function digitalWrite(LED, HIGH).  The only thing I need to know is what pin number the LED is attached to and that "HIGH" means "ON" (and "LOW" means "OFF").  To display on the eight LEDs on the fidget spinner, I can use
    for (int led=0;  led<8;  led++) {
      digitalWrite(LEDS[led], state[led]);
Which means to iterate over the eight pins the LEDs are attached to, one at a time, and turn them on or off based on the value held in the state array.  Easy-peazy, and all is well, unless you are doing something that becomes time limiting like turning those LEDs on and off in an ever decreasing amount of time as the figet spinner speeds up.  At some point (about 3600 RPM), there just isn't enough time, and the CPU moves on to something else, leaving the LED output garbled.

Now intuitively, I know the Arduino is more than fast enough to do what I want, the problem is that the digitalWrite() function hides a lot of dirty work under the hood, and calling it in a loop only multiplies the problem by eight!  When you realize that each of the eight pins is actually an 8-bit port, and that you can set all eight at once using a PORT command, you can increase your speed by almost an order of magnitude.

Of course, there is a lot more detail (and math) to this than I feel qualified to try and explain, but I did try a few timing experiments a while back that probably helped me figure my current conundrum out. Perhaps the most instructive thing to do here is demonstrated how to do the venerable "blink" sketch using ports.

First step in leaving the comfort of Arduino abstaction is figuring out from a Pin-Out chart  that Digital Pin 13 (the built-in Arduino LED) is actually bit 5 of Port B on the Atmega328 chip, a.k.a "PB5".

Instead of pinMode(13, OUTPUT); we set the data direction bit of DDRB for bit 7 to 1 using the command DDRB = B00100000; 
Now to turn the LED on, we set bit 5 of port B high using PORTB = B00100000, and off using PORTB = B00000000

Realize, off course, that we are controlling all the bits of the port the same time, and that there are clever ways to hit just the bits we want, but I'll save that for a later post.

The most instructive part of this experiment is seeing the difference in the sizes of the regular blink sketch (1030 bytes), and the port manipulation equivalent (634 bytes) is almost 400 bytes!  That doesn't seem like much if you are thinking about 32K of memory, but realize that each byte represents an instruction, and you can see we are not just wasting program space, but also using a lot instructions to do the same thing.

I think the bottom line here is to realize that Arduino is great, and abstraction makes life easy, but at some point, you will have to get your hands dirty if you want to go fast!