I am Airzone, otherwise known as Michael. I design and build advanced software defined blasters. It gives me great joy to know that something that was originally a kids toy is now crammed full of technology and hits like a truck.
So things have started to become a new normal.. A shipment of Narfduinos to Europe seem to have gotten misplaced on a boat. And a shipment to the US took 3 months. Parts shipments from China have been delayed..
Now it seems to have sorted itself out a bit more. I will shortly have more stock online to purchase, however with the following provisos:
1 – Australian shipments will be as before. 2 – Untracked international shipments will not be available. 3 – In some cases, express international shipping will be the only option. In other cases, shipping to your country may not be available. 4 – International distributors are coming into stock soon. They may increase their prices to cover the additional shipping costs.
I understand this may not be the most ideal situation for some people. I would encourage people to buy from their local distributors. Hopefully we can get back to normal soon.
If you’re here, you are probably have, or want to have a Brushless Blaster. And that’s great! Now in the middle of one of these awesome bits of kit is the ubiquitous ESC – or electronic speed controller.
Now before we talk about the developments in the world of ESC’s, it’s important to know a few things about them:
All BLDC (i.e. brushless) motors require an ESC
You can’t really share an ESC between motors
ESC’s use a variety of techniques in order to track the motor position – Hall sensors (like in power tools); BEMF detection (like blasters, FPV drones, etc); FOC (like skateboards).
An ESC is much more than a piece of hardware, the software plays in integral role in it’s performance.
Now that’s out of the way, there are 3 overarching developments in the field of ESC’s in respect to Brushless Nerf..
Dyno Characterisation Ultrasonic2 has embarked on a project to build a working dyno for the purposes of understanding ESC’s better. He’s asking questions such as the impact of all the blheli32 settings in a blaster context, and just how do ESC’s stack up against each other in terms of raw performance. You can find out more info from the first video in his new series: On YouTube
SimonK supply and behaviour modifications TorukMakto4 has been plugging away addressing a few issues with the SimonK line of ESC’s.. Firstly that you can’t really buy them anymore. He’s addressed that simply by designing some modern, open source PCB’s and released them for the world to have. He has a few designs made, and a few in the pipeline to address a few different market segments. I’m sure he’ll start making them for sale at some point. Secondly to enhance the characteristics of SimonK in respect to Nerf. In addition to just tuning the firmware for Nerf use, he has also devised an additional governor protocol in the PWM to take a lot of the headache out of his SimonK’s closed loop mod. Find out more here: On Reddit
Ground-up ESC design specifically for Nerf This is more of the start of a -very- long journey, but when people say to not reinvent the wheel, I’ll scoff and do it anyway. And so I have started a bit of a part time project to develop a working ESC that may have a home in Nerf space… One day. Find out more here: On Reddit
3 different guys, 3 different projects, 1 outcome: better brushless blasters.
Narfduino has been making it’s way into Software Defined Blasters originally designed for other control systems. While this is in no way a bad thing from my perspective, please remember to honour the licenses of any community designed blasters you are modifying.
Once upon a time, a few months ago, solenoids were considered to be something mythical, reserved for the most hard-core modder, and for those crazy enough to build with them, they imparted god-like Nerfing prowess and serious street cred.
These days though, it seems that the Nerf hobby is awash with solenoid conversions. I’ve released conversion kits for Stryfe, Swordfish, Dominator, Rapidstrike, and even a Jolt. FTW have kits for Retaliator, and have work in progress for Deploy and Longstrike. And some dude even got one to work in a Hurricane – of all things!
Surely this means something, right? Solenoids are the be-all and end-all of pusher technology?
Like everything, solenoids have their advantages and disadvantages. I suspect their recent popularity is a result of conversion kits (such as mine), 3d printed blasters built for them, and recent releases of the miniturised smart electronics used to drive them – such as Suild’s kits, and my own software defined blaster configurations. Perhaps the mainstream “newness” is also drawing people into using them. Who knows?
Jumping straight into it, here is the high level view of solenoids in a blaster
They are easy to wire up
They are fairly easy to get working
They give very distinctive tactile and audio feedback
They are immune to gearbox stripping, burn-out, and locked pushers
When programmed well, you can sustain up to 16 DPS
You need a single switch and wire for semi-auto use
They are quite large and need room in front, and to the rear
They are heavy
They are hard to perfect operation
They impart less force and are more likely to skip darts
They are only reliable for 8-10 DPS without closed-circuit monitoring
You need electronic control systems for auto / burst / select fire
There are a couple of high-level themes that stand out.
Wiring Solenoids are generally easy to wire. In a normal situation, you would use a single mosfet to control it, and something to generate a pulse to activate the mosfet. On the other hand, in a software controlled blaster, a motorised pusher requires a half-h-bridge. This is not a trivial prospect, generally requiring 3 mosfets, with their pullup/down resistors, and the flyback diode. This is a half-h-bridge for a Woozi:
Of course with the release of Narfduino and my independant half-h-bridge board, this is much less of an issue and presents no wiring difference. Of course, building your own electronics is still an issue.
Control System Solenoids are easy to write firmware for. You pulse the mosfet gate on and off, and that’s it. However they are not easy to write good firmware for. The thing about solenoids is that their pushing power is directly proportional to the battery voltage, and it matters a lot. The behavior of a 12v solenoid on a fully charged 4s battery and a depleted 3s battery is significantly different, and this needs to be catered for.
I have had suggestions to use a buck converter to power a solenoid, but I don’t believe it’s a great solution for these reasons:
A buck will only reduce voltage to a set point. If you are trying to keep a constant 12v on your solenoid using a 3s battery, it’s not going to happen. You need to use a 4s battery – and you will lose out on the performance that extra voltage gives
Your buck will need to be appropriately sized to prevent failure, and therefore will take additional space in an already cramped blaster
Instead, a variety of sensors can be employed to adjust your solenoid performance. Return and full extension switches will provide excellent feedback, and monitoring the battery voltage and adjusting the pulse time works quite well.
How does this stack up to a motorised pusher? It’s much of a muchness. Good half-bridge pusher control is equally complex, and has it’s fair share of challenges. They are just different challenges. However if you fuck up half-bridge control, it’s entirely possible to blow your mosfets and control system… So there is more real risk involved.
Speed Once you’re above 10dps, does it really matter? In an 18 stick mag, you’ll deplete your darts in 1.8 seconds instead of 1.5 or 1.2 seconds. Where a solenoid is really good at is a consistant, responsive pushing speed. Your first dart out will occur at the same rate as your 10th.
A gearbox pusher needs time for the motor to accelerate and get to operating speed. For a neo 180 pusher motor, it may not be a big deal. But for honeybadgers on 3s, it takes a few shots before you’re hitting over 20dps.
And for a motorised pusher, actually decelerating the motor is a thing too. So for a high speed motor, by the time you take into account acceleration and deceleration times, a single shot might take quite a while to come out, and the time to be ready for the next shot will be a little slow too. However, because the pusher isn’t being constantly stopped and started (like a solenoid), sustained DPS is higher than a solenoid can usually achieve.
Tactile Feel There’s no getting past the feel of a solenoid. The fact is you love it, or you hate it. They’re dak-dak-dak noisy, and they have kick. You know you’ve fired a dart, because your blaster is feeding that back to you. There is nothing even close to this on a motorised pusher. Personally, I love it.
Reliability This is interesting… The failure mode of a solenoid pusher and a motorised pusher is quite different. For a motorised pusher, if the dart jams, the pusher will generally as well. So you will need software controls to detect this, and stop the pusher’s drive mosfet. Failure to do this will lead to motor burnout, gearbox stripping, and all sorts of nasty stuff.
Of all motorised pushers, Toruk’s T19 has the most unique control system and mechanical setup. First – it uses a stepper motor (similar to original FDL-2’s) and is therefore immune to stall-induced burnout, and secondly it’s control system won’t just detect the jam, it will reverse the pusher back into it’s home position and will attempt to strike the dart again. Wow.
The failure mode of a solenoid is vastly different. First, they don’t stall. A jam has no impact on the longevity of the solenoid. And secondly, they auto-home under spring force. So by default they will keep beating at a dart until it either goes through the flywheels, or you stop. A solenoid’s weakness is actually it being quite weak. They have very little mechanical advantage and in the retracted position, they are at their weakest. A poor tune will mean there is not enough power applied to the solenoid, and it will jam. It may take a few shots to fire a single dart in this state, or it may be so poorly tuned that it’s no exerting any force on the dart.
In general, you could say that the reliability of a motorised pusher equates to longevity of it’s parts, and not buying new motors & gearboxes. Reliability of a solenoid pusher equates to a consistent play experience. An unreliable solenoid pusher setup won’t cost you money, but it will cost you tags.
Conclusion Well is there a conclusion? Not really. One is like coffee, one is like tea. It’s all a matter of personal preference. If you have not tried a solenoid pusher yet, I would encourage it. IMO, they are super fun and very engaging. But having a solenoid in your blaster will not make you a Nerfing demi-god. Sorry!
There’s a lot to get excited about when programming stuff. Tough challenges, wily algorithms, and the feeling of success when it all comes together. When adding electro-mechanical aspects, this also brings a rather theoretical concept, and makes it a physical reality…
But like everything in life, there are chores. You have to wash the dishes. You have to wash your underwear. You have to tie your shoelaces. And you have to debounce.
For those who don’t know what debouncing is, well simply it’s compensating for bouncing. And bouncing is the world being imperfect, practical, and not cleanly theoretical. When you close your switch, there is never a perfect electrical connection.. It takes time to settle. Us humans aren’t fast enough to see what happens, but your microcontroller is. They are very sensitive to this, and will think you have pressed the button a few times really quickly… And it looks like this:
You can see in this graph at least 4 falling edges before the signal settles. You see one button press, Arduino sees 4.
This manifests in many ways… An ammo counter counting extra darts. A pusher firing less darts. And the bane of all existence – a rotary encoder that skips and does other weird shit.
And so there are as many ways to combat this (i.e. debounce) as tying your shoes. There are quick and dirty knots, I tie fresh double knots every time I wear shoes. Other people have them loose and just slide their heathen feet in and out. And some people don’t tie their shoes at all….
Ultimately it doesn’t matter how you debounce, as long as you do (*). However, if you don’t debounce, like the idiot who walks around with untied shoes, you will eventually fall flat on your face. (*) Fine print: Of course there are circumstances where it’s not necessary. Sometimes just merely detecting an edge is good enough. Other times you’re not worried about the edge, but rather the logic level at a particular point in time. But in general, things like trigger’s, pusher return switches, UI buttons, etc will benefit from it.
What are some ways of doing it?
Software using a library (like bounce2.h)
Software using your own algorithms (e.g. watching for interrupts and waiting a few milliseconds… Or shifting the pin register bit values through a serial buffer)
Hardware by using your ADC (i.e. analogRead)… Please don’t do this, you heathens.
Hardware by monitoring both your switch’s NO and NC position, and considering the input true when both lines agree
Hardware by using a series of resistors and/or capacitors. I have actually released a board that encapsulates this for 4 channels.
Each way has their advantages and disadvantages. You can get away with any of the above techniques on a simple switch or a button, but if you are using rotary encoders, your options are rather limited. I have had luck with both hardware solutions and attaching the encoder to an interrupt, and I have also had luck with a pure software solution.
The only thing I would say about the solutions is that using an ADC to sample the average pin voltage, as opposed to using something to watch for a rising / falling edge is barely better than not debouncing at all. ADC in an Arduino is slow. When you perform an analogRead, the function sets up the *single* ADC to sample your pin through the onboard multiplexer. It then waits a period of time, while the ADC gets about collecting and averaging these readings. An register flag is used to indicate when the reading is complete, and your execution then resumes. If you are constantly polling a pin using analogRead, your code will be slow.
The only time that you should be using the ADC to read a digital switch is if you are multiplexing a number of switches on a single pin using a voltage divider network… There are other ways to do this (such as using a shift register), but given the additional complexity, this is a reasonable compromise. However this is another story for another time.
Narfduino is a pretty handy gadget. You get all the configurability of an Arduino Nano, with the convenience of having some Nerf specific circuitry installed on the board.
Normally, using an Arduino is a fairly benign thing. You apply power, and as long as you’re not silly, they work fairly well. But if you stuff up, the worst you’ll get is a bit of magic smoke.
Narfduino is a little different. It has an integrated Half-H-Bridge and runs on a LiPO battery. If you aren’t careful with it, it’s possible to cause the mosfets to directly short the LiPO battery you are using. If you are lucky, a violent explosion will be your prize. If you are unlucky, your LiPO battery will pop as well. And your computer, if you have it attached. And any ESC you have attached.
Therefore, when using the Half-H-Bridge hardware, exercise caution.
Luckily, I have a library that takes all the headache out of using a half-bridge and makes it fairly safe to use. If you are not entirely sure what a half-bridge is, or what dead time, or shoot through means, please use the library provided.