neRF

The purpose of this project is to augment the Nerf Mega Mastodon blaster with a Nordic nRF52840 dongle, RGB LED, and vibration motor so it becomes fly-by-wire and can optionally be controlled over Bluetooth. Without a Bluetooth connection the blaster's original operation is essentially unchanged.

The finished product, with barely-visible modifications -- a few screw heads and an LED

 

 About

The Mastodon is an interesting blaster because of its unique combination of fully-electric operation and deterministic dart handling. When fully loaded, up to 24 darts can be fired individually without further interaction from the user. The current replacements for the Mastodon either require the user to cock and/or press something to fire each dart (e.g. Ultra ONE) or shoot at an unpredictable rate (e.g. Prometheus MXVIII-20K). A common characteristic that is shared by all of these automatic blasters is a "flywheel" mechanism that throws the dart in a similar fashion to baseball pitching machines. The mechanism that sets the Mastodon apart is a motorized plunger that pushes each dart into the wheels, rotates the drum, and uses a switch to ensure that the plunger motor stays powered until the plunger is retracted (which would interfere with spinning the drum to reload it).

Without a Bluetooth connection the blaster's operation is changed slightly:

• After firing 24 darts the blaster automatically stops shooting until the triggers are released and pressed again
• No dart will be fired until the wheels have had a second to spin up
• An RGB LED on the top of the blaster signals that the wheels have spun up (green), a safety fault has occurred (blinking red), or a Bluetooth connection is active (blue)

Connecting to the blaster via Bluetooth adds the following functionality:

• The blaster's ammo count can be set so a "ammo remaining" notification will be sent after each dart is fired
• Three selective firing modes are available: single-shot, three-dart burst, and fully automatic
• Both triggers can be individually overridden
• Both triggers can be locked out
• Haptic feedback can be initiated for a specified amount of time

The blaster's safety mechanisms still function normally. Attemping to fire when either of these conditions is present will result in a safety fault:

• The jam door is open
• The drum is removed

If a safety fault occurs then the LED will blink red for 30 seconds before the blaster turns off. Rectifying the fault condition and pressing the triggers will reset it. The safety features can be disabled during development via CONFIG_NERF_SAFETY_FEATURES_ENABLED in the project file. The firmware for the project can be found here.

Although the blaster's wiring has been changed significantly, the original switches and triggers remain. The only modifications to the plastic housing are holes that were drilled to mount two PCBs (via standoffs), a vibration motor, and an LED. The bipod in the photo is off-the-shelf and attaches to the blaster's "tactical rail" using a picatinny rail adapter.

Original hardware

There are a couple of videos online that show how to rip out the blaster's internals and replace the two trigger switches with ones that can handle LiPos. That approach allows the blaster to shoot harder and faster, at least until the motors fail, but has the disadvantage of disabling the mechanism that ensures that the plunger is always retracted back to a known position. The point of this build is to add remote control while retaining -- and appreciating -- the blaster's original design.

Pro tip: the battery door has four sections, one for each size of screw. Use a bit of colored tape to mark each screw hole during disassembly to make life easier later.

Original wiring, including harness coloring

The blaster's original wiring is pretty straightforward. The only tricky part is the trigger override -- the gray wire -- that overrides the plunger trigger until the plunger has retracted. The configuration of the passives around each of the motors is a rough approximation.

A close-up of the motor passives

The two triggers are configured so that the "rev" trigger, that powers the "fly wheels", must be depressed before it's physically possible to depress the trigger that powers the plunger.

Two triggers: "rev" at the bottom and "plunger" above it

The "fly wheels" sit at the front of the blaster. When a dart is shoved into the passage between them the wheels catch it and throw it out of the barrel.

A little silicone curtain (on the left) covers the entrance to the "fly wheels". The tip of the plunger can be seen on the opposite side of the gap.

The plunger mechanism is self-contained and the plunger motor pokes through the top cover so it can engage the gearbox below. The orange switch to the left of the motor is engaged by a ridge on the plunger.

The motor, spring, and switch of the plunger mechanism are visible when the cover is installed

Removing the cover exposes the plunger itself along with its gearbox

A raised ridge runs along the length of the plunger. The ridge is low along the section that engages the switch when the plunger is extended far enough to obstruct the drum. This allows the switch to override the plunger trigger in case it is released while the plunger is extended.

The large cog on the left has a section with no teeth. This allows the plunger motor to remain on constantly even when the plunger is being retracted by the spring; the cog that engages the plunger is momentarily allowed to spin backwards while the large cog continues to spin forwards.

The firmware synchronizes to the output of the plunger switch to ensure that the plunger is always returned to the proper position after the trigger is released.

Output of plunger switch when firing at 8.5V

Additional hardware

The original switches were retained but now they are routed to an nRF52840 dongle that is mounted on a simple PCB.

The microcontroller lives on a very simple PCB (voltage regulator not shown)

 

The finished product, minus the protective heatshrink

A simple trick that makes it easy to solder headers onto the dongle

The USB contacts of the Nordic dongle protrude far enough from the side of the board to allow it to be plugged into a PC for reprogramming.

The original motors were also retained but now they are driven by a quad, half-bridge driver.

This is an older driver but it's TTL-compatible and easy to use

The populated driver board

JST headers were used to so the two boards are removable. 

Heatshrink makes everything better

The inputs and outputs are labelled for easier assembly

The two boards were installed using standoffs. The modifications to are barely noticeable given the blaster's aesthetic. 

The driver board is not visible because it is installed underneath the plunger mechanism. The vibration motor is located a few inches to the left of the triggers.

An inexpensive bipod is the most elegant way to stabilize the blaster for remote operation. A plastic adapter was used to allow the picatinny bipod to attach to the blaster's proprietary rail.

Poly

Sometimes it's nice to carve out some time to build something that would make the 12-year-old version of you give you a high-five -- and, in this case, a five-year-old nephew.

Few things are cooler than RC airplanes.

A view of the servos and control surfaces.

My nephew loves those giant (4' wingspan), $10, polystyrene gliders so the girl and I decided to spend some time experimenting with aircraft building.

It really does fly over 100' and is surprisingly durable.

 

The Build

We started by cutting out aileron and elevator flaps and using duct tape to create hinges. Fixing the various control surfaces at different angles allowed us to experiment with their effects. Next, we decided to add some servos to create an RC glider. The fact that the wings popped out during crashes seemed like a feature so we gave each wing its own servo -- the common, but less robust, alternative is using one servo mounted to the fuselage that is linked to both wings. We mounted one additional servo to the tail of the fuselage for the elevator. Even though the glider used a tiny 3.7V, 220mAh battery that was scavenged from a quadcopter, the whole aircraft was simply too heavy to sustain flight as a glider. The four motors from the now-battery-less quadcopter were still perfectly good so we built some brushed DC motor control boards and glued the motors to the fuselage. To power the whole thing we found an inexpensive 2-cell LiPo battery and a cheap Battery Elimination Circuit (BEC) to provide 5V to the servos, motors, and receiver. The result looked sweet but was woefully underpowered.

Rev 1: Lots of duct tape and disappointment

For the second rev, we replaced the duct tape with plastic hinges to save weight.

Cut slits in the wings, dab some StyroGlue on the hinges, and let it set.

To protect the servos on the wings the girl purchased small polystyrene globes from the craft store, cut them in half, and hollowed out spaces for the servos.

The globes are easy to hot-glue to the wing and look very natural.

After upgrading the hinges it seemed like a good idea to add landing gear. The local hobby shop had some foam wheels that we picked up for less than $10. The back wheel had its own plastic mounting plate that was easy to glue to the fuselage.

The rear elevator's servo is easy to embed and we found the perfect landing gear.

The front wheels fit nicely on coat hangers so we glued the coat hangers into wooden dowels and then glued the dowels into the fuselage.

The white is a plastic coating on the coat hangers -- we stripped that part off any spots that needed glue.

 

Mounting The Motor And Keeping It Cool

Now we were committed so we purchased a cheap "park flyer" kit from Amazon with a 1000KV brushless motor, 10"x4 prop, and ESC. We screwed the new motor into wooden dowels that had been glued into the front of the fuselage.

Dowels mounted directly to the motor provide very little crash protection and no thermal insulation.

We carved out some space at the bottom of the fuselage for channeling the motor's wires. The result was hilarious to look at but after a few crashes it was difficult to get the motor aligned correctly with the rest of the fuselage.

Looks a little fishy.

To make the motor easier to mount we ended up machining an aluminum plate that lays flat against the fuselage and includes two tabs for mounting the decorative cowling. This plate improved crash resistance and also helps to disperse the heat from the motor.

A couple of hours on a mini-mill can solve so many problems.

The motor and Electronic Speed Controller (ESC) can get quite warm so we used milkshake straws to ensure that the motor wires don't completely impede airflow in the ESC's cavity.

Milkshake straws, bubble tea straws, who can tell the difference?

The ESC lives in the skinny cavity, the receiver lives in the wider cavity beyond the tape.

The airflow from the front of the plane needs a place to exit so we mounted some additional straws on both sides of the fuselage at the back of the ESC cavity.

The exit straws have the fortunate side effect of looking really cool.

 

Final Tuning

To test various combinations of batteries, motors, and propellers we threw together a simple rig to measure thrust vs. amperage. It's not perfect, and certainly not calibrated, but it allowed us to make relative measurements for different setups.

TV tray + right-angle shelf brace + hinge + clamp + kitchen scale + cheap multimeter with 20A fuse = thrustometer

The great thing about chalk boards is that you can fill them with random notes and there's no hurry to erase them.

We waited until the plane was mostly finished and we had chosen a battery/motor/propeller combination before we carved out space for the battery so we could use the battery's location to balance the plane. Unfortunately, this required putting the battery pretty far back in the skinny part of the fuselage; this is the most likely part of the fuselage to break. We addressed this problem by lining the battery cavity with popsicle sticks for reinforcement.

The popsicle sticks were glued together to make sheets before they were hot-glued into the fuselage.

 

The Receiver

We used the SparkFun nRF52832 Breakout board as the receiver because it offered a nice form factor. Most servos and ESCs run at 5V but the nRF52832 tops out at 3.6V so we used a cheap level converter to interface between the nRF52832 and its outputs.

The level converter along with a capacitor to add some bulk capacitance to the 5V rail for brown-out resistance.

We also tacked a simple programming harness on to the breakout board so it could be programmed via an nRF52-DK. The two boards were joined together using 0.1" break away headers.

Sparkfun sandwich

We used right-angle 0.1" headers on one side to interface to the ESC. On the other side, we used labelled micro-JST connectors for the various servos (roll, pitch, yaw).

Power and throttle signal in the front, roll, pitch, and yaw in the back.

The ESC connected to the receiver along with the battery connector.

This harness connects the receiver on the left with the servos on the right. The large connector on the left is a 5V power and ground pass-through from the BEC.

 

The Transmitter

The transmitter is an nRF52840 development kit that is mounted on some foam board along with a couple of analog thumbsticks and a AA battery pack. The nRF52840 has +8dBm output power and the nRF52832 on the receiver has -96dBm RX sensitivity so range has not been a problem. Bluetooth Low Energy isn't particularly well-suited for this application so we created a proprietary, FHSS, 2.4GHz protocol that allows the transmitter to send packets to the receiver without waiting for a response.

Easy to carry, easy to hold, easy to take apart because I'm only borrowing the nRF52840-DK.

 

Conclusion

I can't really comment on the plane's flight characteristics compared to other aircraft because this is the only plane that I've ever flown. However, flying is not easy so it's nice that polystyrene can be repaired quickly. We also learned some things:

• StyroGlue works very well for small parts like hinges
• Hot glue works the best for large parts like dowels and fuselage repairs
• The big sanding drum in the Dremel kit chews through polystyrene nicely
• Amazon has fire suppression blankets and small fire extinguishers that can be carried discreetly

BLE-to-ShockBurst bridge for Syma X4 quadcopters

The complete set: quadcopter, nRF51-DK, Android device, and gamepad.

The Syma X4 quadcopter uses a radio protocol called ShockBurst that was made popular by Nordic Semiconductor sometime around 2004. Contemporary Nordic devices still support ShockBurst; the following video demonstrates the quad being flown using a cheap gamepad and an nRF51 development kit (nRF51-DK).

The next video replaces the gamepad with an Android app that uses Bluetooth Low Energy (BLE). Although the quad does not support BLE, the nRF51 can use its single radio to receive commands over BLE and translate them into ShockBurst packets before forwarding them to the quad.

The Quadcopter

The Syma X4 quadcopter is sold together with its transmitter for less than $40. It is fun to fly and is a solid quadcopter to use as the base for an embedded project:

• 2.4GHz control protocol with channel hopping
• 4 control channels (pitch, roll, yaw, throttle) plus a flip function
• Onboard, 3-axis gyro automatically stabilizes flight
• 6.0" x 5.5" x 1.1" 
• Weighs a little over 1oz with battery
• 3.7V 350mAh LiPO Battery
•  ~7 minutes of flight time per charge
•  ~50 minutes to recharge via USB

This little guy is surprisingly resilient to crash damage.

 

The Transmitter

The transmitter is easy to disassemble and the radio IC sits on its own module (marked "LOG1501E") along with a simple wire antenna.

The transmitter after removing a few screws.

Although the radio IC is covered in epoxy, there was reason to suspect that the radio was a clone of Nordic's nRF24L01+ transceiver.

The bottom of the radio module is pushed into a slot in the transmitter's main board and the module's leads are soldered to the main board on the opposite side. The module's pinout looks like this:

The bottom of the radio module where it interfaces with the transmitter's main board. The colored wires were added to make attaching probes easier.

The radio is controlled via SPI so capturing some traffic was the first step to learning more about it. The leads on the transmitter's board are easier to solder wires to than the radio inside the quad itself. The Logic 4 logic analyzer produced an SPI trace that looked like this. The nrf24l01p-decode utility was created to decode the SPI trace into a more readable version.

The Protocol

The quad uses the radio's 250kbps baud rate as well as a hardware-based, 2-byte CRC. Note that a software-based CRC byte must also be generated and included in every control packet.

The quad listens for bind packets on address {0xAB, 0xAC, 0xAD, 0xAE, 0xAF} when it starts up. It uses channel hopping to minimize interference and cycles through the following channels during the first step of the binding process: 75, 48, 64, and 9. The default bind packet for my transmitter is {0xA2, 0x00, 0x02, 0xDF, 0x1C, 0xAA, 0xAA, 0xAA, 0x00, 0x1E}. Note that part of this packet is the address that the quad will use to listen for control packets after the binding process is finished: {0x1C, 0xDF, 0x02, 0x00, 0xA2}.

A different set of channels is used for control packets. These channels are probably dependent on the control address that is assigned to the quad during the binding process but this has not been confirmed. For now, the control channels that are used are: 22, 30, 54, and 62.

Packets are sent every 4ms and two packets are sent in each channel.

Each type of packet that is sent during the binding process should be sent at least 30 times to ensure that the quad receives it. The process looks like this:

1. Send the bind packet so the quad can parse the address that it must listen to in order to receive control packets
2. Send a control packet with the throttle set to minimum
3. Send a control packet with the throttle set to 246
4. Send a control packet with the throttle set to minimum

After this sequence is finished the quad's headlights should switch from blinking to steady to indicate that the binding process was successful.

The control packet has the following format:

Control packet payloads are 10 bytes long.

Finally, note that the packets that are sent from the transmitter to the quad are not acknowledged by the quad so there is no way to know whether or not the quad is receiving packets or has completed the binding process.

The Development Kit

The nRF51 has a powerful feature called the Multiprotocol Timeslot API; this API allows the application on the nRF51 to access the radio whenever the radio is idle (even while in a BLE connection).

If the Android app does not accept the 30ms Connection Interval that is requested by the firmware on the nRF51 then the firmware disconnects. The radio requires about 10ms per BLE Connection Event and during those events as many as three ShockBurst control packets are cancelled. The quad assumes that these packets were lost due to noise so as long as the channel hopping stays in sync there is no problem resuming control after the Connection Event finishes.

As many as three control packets are dropped when the radio is busy with BLE.

The quad can be flown without issue even when the nRF51-DK is sitting adjacent to a WiFi router. Although the maximum range has not been determined, the quad can be flown far enough away that it is no longer possible to see which way it is pointing.

The Gamepad

The gamepad shown above has had its wires stripped so they could be poked into one of the headers on the development kit but it is otherwise unmodified. For reference, the gamepad's pinout looks like this:

The Trenro gamepad wires were colored: VCC:white, CLOCK:blue, LATCH:yellow, DATA:red, GND:black.

If the gamepad is used then its VCC and GND pins should be plugged into VDD (NOT 5V) and GND on the nRF51-DK. Additionally, the gamepad's LATCH pin should be plugged in to P01, CLOCK should be plugged in to P02, and DATA should be plugged in to P03.

The Code

The firmware is based on the Nordic UART Service (NUS) example project in the nRF51 SDK.

The ShockBurst protocol is provided by the micro-esb library. One of the features of the nrf24l01p-decode utility is that it will output configuration code for the micro-esb library.

The firmware (quad_bridge_fw) and the Android app (QuadBridge) have been published on github.

Robot Arm H25 Demo

Here is a video that I made that shows my Python library driving a robot arm via Bluetooth. The demo program is pretty short. Build instructions for the arm can be found here.

I borrowed a Lego Mindstorms EV3 from someone so I could get to know it. The platform is quite hackable but I didn't want to modify the brick's file system because it isn't mine. Instead, I wrote a simple Python library for executing commands over Bluetooth: EV3

RFID Garage Door Opener

    I spend a lot of time in and around my garage and encourage other nerds to do the same. I want to make sure that if someone is working on a project and I am not around that they can still access my garage. Giving people house keys is a bad idea because they are easily copied and give unlimited access to the entire house. RFID tags, however, are hard to copy, easy to revoke, and allow for time-based access. So I built a box to activate my garage door opener using an RFID reader.

    I started with a Parallax RFID reader from RadioShack. Then I added an Atmega 328p microcontroller, reed switch relay, DS1306 real time clock, LM386N-1 audio amplifier, speaker, and support circuitry to create an RFID control box.

    The smaller box contains only the RFID reader itself. It is pushed as close to the door as possible so tags can be read through the rubber trim surrounding the door. The following photo shows the metal race that the door travels along, the edge of the RFID reader box, the strip of rubber trim, and the box that I made using tape to delineate the area near the reader so that it can be located when the door is closed.

 The larger box contains the rest of the circuitry. I cut two breadboards to fit into the slots of a cheap project box from RadioShack and placed the noisy components on the bottom board and the sensitive ones on the top board.

    The bottom of the box has a DB-9 connector for RS-232 that allows for configuration via a separate computer. The microcontroller only has one UART so the DB-9 connector has to share it with the RFID reader. There is a small constant switch adjacent to the port to select between the two.

    The firmware is AVR-GCC C and I used Python to make a pygtk GUI for configuring tag information. Now I can grab an RFID tag out of the drawer and assign it a description (i.e. 'Rebecca's tag.') and a period of time for each day of the week (i.e. weekends between noon and 5pm) when it is valid.

    Contact me if you are doing something similar and have any questions or want a copy of the firmware (under the GPL). I didn't capture the schematic in Eagle but I did take photos of my notebook and adjusted the contrast until they are semi-legible.