Making your e-drums neighbor-friendly(ish)

Drums are awesome instruments. I mean, you hit stuff with wooden rods and dope sound comes out. It’s the pinnacle of human engineering. 

They are, however, quite noisy, which makes them unsuitable for urban living spaces that cram more people per square-meter than Bangladesh. Luckily, electronic drumkits are a thing, and even more luckily, they don’t sound terrible anymore. Just plug your earphones, and presto, silent druming. Except… If you live in an apartment (as I do), the constant hitting of pads and pedals propagates vibrations through the floor, that will certainly be heard/felt by your donwstairs and nextdoor neighbors. 

The standard solution for this issue seems to be mounting the entire drumkit onto an MDF platform, and placing it on some insulating material: tennis balls are a common alternative, but some people go all in and use sylomer (an industrial-grade dampening polymer) instead. I wanted to save some money and avoid the hassle of getting a slab of MDF into my otherwise not-so-big-apartment (in particular, because the corona-induced lockdown makes it harder to get one cut to size), so I decided to try a 3D-printing route instead.

I own a Roland TD-1DMK kit with a double bass pedal, so I started off by taking all measurements of both the bass and hihat pedals, the diameter of drums feet poles/tubes, and checking up on the nominal sizes for tennis balls. Threw everything into Fusion 360, and voilà. Below is the assembly for the left bass pedal and hihat  – use the “Explode Model” option in the viewer to see the individual parts:

After some ~24 hours of 3D-printing, the end-result turned out nicely:

On the left, the assembly for the bass drum;  center, the hihat – it is connected to the left bass drum, or it’d tip over. On the right, the cups that replaced the drum kit’s original rubber feet. To actually measure the effectivity of the setup, I used a seismometer app on a phone placed ~50cm from the center of the drumkit, directly on the floor. You can see the results below:

As you see, for the tom/snare hits, the attenuation is very effective: you can barely see the vibrations in the scope. The pedals – by far, the biggest culprits – also get a suprising amount of attenuation:

This is the snapshot of both the bass- and hihat-pedal hits. In black, the dampened version, superimposed on the original signal in orange. You’ll notice that the original transients even clipped. From the image, one sees roughly a 1.5:4.5 ratio between the after/before peaks (on Z), which would boil down to a ~70% worst-case improvement. I’ll admit, this is very unscientific, but I didn’t have access to the raw data of the sensors. In any case, I’m actually quite satisfied with the result. Let’s hope the neighbors are too.

’til next time. 

Finding my way with Cura 10.06

I’ve been using Cura as my go-to 3D-printer slicer for quite some time now. Compared to Slic3r, it’s faster and produces more optimized G-Code (using the same settings in both slicers, Cura’s prints were faster for me- but as always, YMMV). However, Cura provides less tweakable options than Slic3r, so it takes some getting used to.

So, I was using Cura 10.04 under OSX (10.10 and 10.11), and all was nice and good. Suddenly, I wild bug appeared. As shown in the picture below, Cura uses some text overlays on the 3D-viewer to display information: print duration, filament usage, estimated cost, type of view, etc. On my machine, all text overlays were suddenly gone! Rebooting, reinstalling, re*ing, etc, didn’t seemed to solve the issue. And, needless to say, using a slicer without the aforementioned infos is quite frustrating.


Left: Fully functional Cura, with text overlays in 3D-view (image courtesy Tom’s Guides). Right: My wild bug in action – bye, text overlays.

Furthermore, this bug seemed to afflict only a handful of unlucky bastards: Google pointed me to one unanswered forum entry, and to one GitHub issue ticket. The latter got a response from one of Cura’s developers, which stated that they’re “not working on a fix, as we will be repacing the whole UI in a few months, which no longer uses this old font rendering code”.

All right then. The dev’s answer was posted mid-April 2015, so I figured a new version should already exist. Indeed, in the list of beta releases, Cura 10.06 was available for download. I grabbed it and got going.

The UI got heavily revamped, and lots of options were made available (bringing a Slic3r-y level of tweakability to Cura). A quick tour in Cura’s Preferences > Settings allows you to select which options you want to edit in the main window. No need for much detail here, as the help pop-ups on each option make the whole experience nicely intuitive.


Cura 10.06 revamped UI.

Unfortunately, as new options were added, others were lost. When first configuring Cura, you need to add a printer. In previous versions, you could choose from a list of models or just go with a “generic” machine – to which you’d add dimensions and other relevant informations. This option is no longer readily available – you have to pick a model from the list! Having a DIY printer that looks like nothing on the list, I was quite frustrated. For test purposes, I picked the Prusa-i3 preset (though my printer uses a bed roughly four times as big).

On top of that – and that was the killer for me – there is no option to edit the Start/End G-Code procedures. While this sounds trivial/useless for most off-the-shelf printers, it won’t (probably) work with a custom machine (e.g., like mine). For instance, due to the form and size of my printer’s bed, I can’t go homing XYZ like a Prusa-i3 would do (and as the preset G-Code insists on doing).

After shelving Cura 10.06 for some days, I stumbled on this page on the RepRap Wiki. It shed some precious light on the workarounds required to solve these (and other) problems. As it turns out, much of Cura’s printer configurations are set in JSON files – a file per printer model, stored in Cura’s installation folder, under resources > machines. To add my custom printer, I’ve copied the prusa_i3.json preset to a new custom_3dcnc.json in the same folder, and went on editing it. The JSON entries are pretty self-explanatory:

Changing the id and name fields makes your custom printer appear on Cura’s list. Also note: AFAIK, you need a STL model for your printer’s bed (commenting out the field platforms won’t work). By default, they’re stored under resources > meshes. I could reuse one, but I’ve simply exported my printbed’s STL from my CAD program.

Configured Cura (with my printer's crazy-ass printbed on display).

Configured Cura (with my printer’s printbed being displayed).

Last, but not least, machine_start_gcode and machine_end_gcode are what I was looking for. Add the G-Code inside a single pair of quotes, with commands spaced with a newline character (\n) and you should be golden. Save the file, reload Cura, and you’re good.

’til next time.

Biohand: first short video

I submitted my biohand project as an entry to the 2015 Hackaday Prize. Cool. So, after spending a long month in a [21st-century] cave while writing my thesis (about the biohand), I discovered on August 16th that I needed to post a descriptive video of my entry until August 17th. Today.


Here, have this sexy pic of the prototype, for no reason.

So yea, biohand‘s main control board survived the smoke test and all, but it’s not finished. So I drove a couple of biohand‘s motors and the thumb’s servo with an ever-trustworthy Arduino, just to show it doing SOMETHING.

There you go:

’til next time.


Biohand boards, fresh from the boardhouse

This page has been gathering some dust now, but this will change in the next weeks.

I’ve been working on a new project, the biohand. It’s a low-cost 3D-printed hand prosthesis, that aims at offering technical qualities similar to multi-thousand dollar devices. More details shall come in another post.

For now, I’m just willing to share the nice fact that the first iteration of the biohand main control boards (a.k.a. the BIOHAND_BOARD_V1) arrived from the boardhouse.

Biohand bare boards

As soon as I finish soldering one of them and it survives the smoke test (or perhaps doesn’t), I’ll post further results and schematics.

’til next time.


It’s said that no man is without sin, and neither am I. In an act of brilliance, I’ve managed to swap two VDD/VSS pairs from the STM32 while designing the board. While I didn’t burn a thing, I did cost me over 24h to figure out what was happening and to solder some workaround-wiring. In the end, the I got the ARM running a simple blink program (pic below). YEY!

Minimal test of the board. Disregard the workaround-y bond wires.

Minimal test of the board (Blinking LED, YEY!). Disregard the workaround-y bond wires.

Now it’s time to keep on soldering the remaining components (hoping not to find other mistakes like that). I’ll upload corrected gerbers once everything works without bursting into flames.

’til next time.

Chronicles of my 3D printer, part 2: the electrical Pandora’s Box

Having finished the mechanical assembly of my printer, it was time to assemble the electronics to get everything moving.

As I stated in the previous post, my intention to build a large-volume printer/mill made me choose NEMA 23 stepper motors for the X and Y axis. Larger motors would be capable of handling greater forces and more aggressive acceleration profiles, that regular NEMA 17s would not. After some research, I purchased 2 Applied Motion’s HT23-601. With a holding torque a little below the 2N.m, I was (and still am) pretty sure that those motors would be overkill (which isn’t a bad thing). For the Z axis I got 2 Applied Motion’s HT17-275 – good quality NEMA 17s that would do the job.

The thing with the larger NEMA 23s is their current requirements. The maximum current for the HT23’s bipolar parallel arrangement is rated around the 4.3A. Regular 3D printer stepper drivers, such as the A498 or the DRV8825 handle up to 2.2A (with active cooling!), so they are way off the range. Also, keeping the ICs operating constantly at their max is guaranteed to greatly reduce their lifespan. Operating the NEMA 23s on lower currents also wasn’t an option, simply because I wouldn’t be able to make the most out of them. At that point, I thought I’d have to get industrial stepper drives that would leave my pocket echoing. Luckily enough, Google (oh, my dear) pointed me to the Powerlolu, a 10A stepper drive that still falls in the $50 range.

After getting the Powerlolus and my RAMPS 1.4 (the printer’s control board), the wiring-fun started. I quickly noticed that, even for small test setups, the amount of wires hanging all over the place was increasing rapidly. Besides being annoying, messy wiring is the best spice for cooking your components. In order to prevent that, I mounted everything in a proper enclosure box, and tried to keep the wires, buses and connectors as neatly organized as possible. The result, after dozens of boring hours, was worth it:


Main electronics box. Bottom, the 12V/33A supply. Middle/Right: Stack of 3 Powerlolus. Top/Left: RAMPS.

For the record, there goes a somewhat simplified wiring diagram of the box’ contents. I’m using a 12V/33A power supply, so I added a 5A circuit breaker on the mains’ power input to avoid burning down my house if anything went wrong.


Simplified wiring diagram of the printer’s electronics. Some wires were omitted or labeled to keep the drawing understandable.


As the picture below displays, the components (motors, hot end, heat-bed, etc.) are attached via connectors mounted on the side of the box. This makes the connection more robust to vibration and eventual pulls. For the stepper motors, I used 3 4-pin circular connectors (the four, from the bottom). They resemble XLR connectors with extra pins and screw caps, and I’m not really sure how they’re correctly called. The heat-bed also uses such connector, in it’s 2-pin version. Such connectors handle up to 5A per pin. Though they can’t support the Powerlolu’s full 10A, they were (sadly) the most cost-effective solution I found. The bed’s thermistor and the endstops are connected to the RAMPS via P2 audio jacks. Lastly, a DB-25 plug handles all the wiring for the extruder and hot-end: stepper motor wiring, hot-end cartridge, thermistor and fans.

Connectors for the printer's parts.

Connectors for the printer’s parts.

Finishing up, a sideways view of the closed box, showing the USB plug, a fan, the power switch and the mains’ power input.

Everything has two sides.

Ready to rumble.

’til next time.

Printing something useful, for a change

After lots of bad prints, random parts, new extruders, a couple of bears and a Darth Vader, it was about time to print something with at least a bit of practical use. A bit. I’ll let you be the judge of that:


The hook... Holder... Thingy.

The hook… Holder… Thingy.

The making (and usage!)


The sad part is that I didn’t come up with that idea on my own. But then again, that’s what the internet is for. I guess.

’til next time.

Chronicles of my 3D printer

So, just a little throwback. I’ve always wanted to build a 3D printer (or any CNC machine, for that matter) on my own. Around two years ago, I’ve decided to take that desire seriously, and started doing some research on designs for 3D Printers and CNC mills. After some googlin’ I set myself with goals of building a machine that:

  1. Had a large working volume (around 35 x 35 x 30 cm)
  2. Enabled fast prints (80mm/s and faster)
  3. Was cheap-ish (I live in Brazil, and getting proper mechanical/electrical components here is insanely expensive)
  4. Enabled both 3D printing and milling (at least of softer woods and plastics)

So, pretty much a godmode machine – what every engineer desires, but only unexperienced newbies strive for. The last point there is specially tricky. Milling and printing are very different activities, that shape machines in very different ways.

Milling usually requires more robust and rigid machines that can handle the high (read: tremendous) opposing forces applied on the end-effector (the cutting tool). Cutting speeds are relatively low, and depend on the material that’s being milled. Arrangements with a moving portal carrying the Z gantry are quite common, since they allow the workpiece to remain stationary, and provide a stable frame. Such configuration, on the other hand, means that A LOT of mass has to be constantly moved around: the motors for the Y and Z axis, the portal, all mechanical components attached, and so on – which constraints aggressive acceleration profiles. Partially because of that, CNC mills are normally leadscrew driven. Most of such leadscrews present pitches in the 2 to 5 mm range, allowing increased torque transmission and movement precision, but reducing the overall speeds. From the beginning of this project, I knew that I would be working with a 12V power supply and NEMA 23 steppers – the most cost-effective solution available to me. From the graph below it’s easy to see that, even with such a 5mm pitch leadscrew, achieving speeds of around 80-100mm/s on that configuration is hard/impossible. Leadscrews were a no-go.

Typical NEMA 23 stepper motor (torque vs. rotation speed)

Typical NEMA 23 stepper motor (torque vs. rotation speed)

3D Printing behaves quite differently. During a print, the end-effector (hot-end) moves practically freely, with almost no opposing forces whatsoever. Machines are built with a minimum rigidity to prevent vibration or backlash in the moving parts, but the goal usually is to reduce the inertia of the moving elements. Classical setups include floating Y axis, and are often built out of off-the-shelf screws and 3D printed parts, MDF sheets, etc. Timing belts are the default means for movement transmission, enabling higher speeds. This comes at the cost of reducing torque, precision and general frame rigidity – but good print qualities are generally attainable.  Note: I’m clearly addressing low-cost, desktop hobbyist printers in this description.

My faith on joining those two worlds in a single machine grew after I saw the Shapeoko 2 milling aluminum. The Shapeoko 2 is a desktop-ish CNC mill that is built out of many elements that figure on a regular 3D printer: NEMA 17 motors, GT2 belts, makerslides, and so on. With all that in mind, I started designing my machine. After a couple weeks, I came up with a design that made me happy:


Everything looks cooler raytraced.

Yeah, it ended up looking an awful lot like a Prusa i3 on steroids. But I took it as a good sign, that a lot of thinking took me to the same tested-and-proven design. Though I could’ve spared the time. And now the CoreXY looks darn interesting. Whatever. Anyway, I had no 3D printer available at the time, so I struggled to keep all the custom parts “laser-cuttable”.

After purchasing all the couplers, screws, belts, pulleys, aluminum profiles and other bits, I sent the designs to be laser cut on 3mm aluminum sheets.  All parts came in; the build started.

Starting to build. And to complain.

Starting to build. And to complain.

As the pic above shows, I had originally chosen a different arrangement for the Z axis: each screw was coplanar to only one linear rail (instead of being coplanar to both simultaneously). Soon enough I saw that the smallest wobble of the screw would cause the whole gantry to wobble along, rendering even the coarsest prints impossible. Couple more days in front of SolidWorks and the mistake was fixed [the rendering above is the fixed version]. There, no one saw it. Move along.

A couple parts for the fix had to be recut. They came in, and the result soon popped out:


Assembled printer. Disregard the extruder, that one never worked.

Everything looked OK. Rigid enough for me. Next up; assembling the electronics. I’ll leave that for a next post. I’ll also put the CAD files up anytime soon.

Ah, I’ve obviously ‘Instagramed’ it. “The experience is not complete if you don’t post it on Instagram”, said someone once.

From concept to finish (almost). 🙂

Uma foto publicada por Martin Vincent Bloedorn (@martinbloedorn) em

’til next time.