Project Logs

Collapse logs

• V5 problems solved

  Matt Bradshaw • 11/21/2019 at 16:44 • 1 comment

  After some forensic investigation, I have identified (and, I think, solved) my two remaining issues with the V5 PCB, but I would be grateful for any feedback about my MIDI solution.

  ---

  Problem 1:
  

  The sound is too bright (too much carrier frequency remaining in audio output)

  Reason:
  

  This one was pretty dumb. I'm using the twin-T notch filter design from the Mozzi website but I made a mistake transcribing this circuit into my schematic, meaning that two of the capacitors have switched places.

  Solution:

  I (clumsily) desoldered C3 and C7 and swapped them over. The audio output now sounds fine.

  ---

  Problem 2:

  Connecting a MIDI input results in audible tones and clicks through the audio output.

  Reason:
  

  Something to do with grounding or decoupling? It feels as though the MIDI input's optoisolator (a 6N138) is perhaps being a bit heavy-handed with its use of the available electricity (please don't disqualify me from the site for this appalling lack of understanding).

  Solution:
  

  After lots of googling, I stumbled onto this seemingly similar problem and decided to whack a big (1000uF) capacitor across the 6N138's power and ground. I tried smaller values but to no avail. I suspect that adding a smaller (but still big-ish) capacitor to the LM386 and also maybe the ATmega328 might be a better solution, but I've already made a mess of the PCB! For now, the noise is virtually gone, so I'm calling that a win.

• V5 PCB almost working

  Matt Bradshaw • 11/15/2019 at 13:10 • 9 comments

  The fifth iteration of the DrumKid PCB arrived from China this week, and I'm pleased to report that it pretty much works! I had changed and added quite a lot since V4, so there were always likely to be a few problems, but overall I'm pretty happy.

  Assembly was made much easier by including the resistor and capacitor values on the silkscreen layer, which I didn't do in V4. However, I forgot to identify a few other components and polarities on the silkscreen layer. This isn't a big deal when I've got the KiCad files to refer to, but worth fixing on the next version, especially if I'm going to make DrumKid available as a kit.

  The two main problems I ran into were related to two of the biggest changes I made. I significantly altered the low-pass filter on the audio output to try and remove more of the PWM carrier signal, but I'm not sure I've done it correctly - the audio sounds much brighter than I was expecting, and has some issues at full volume (possibly related to running off batteries rather than a 5V USB supply).

  Another problem is that when a MIDI input is connected, each MIDI signal causes an audible click, or a loud tone, in the case of MIDI clock messages, which are sent very frequently. I had come across this issue on my breadboard prototype but assumed it was just due to the inadequate ground of the breadboard. I was wrong! I'm currently experimenting with a decoupling capacitor on the optoisolator to solve this problem.

  Oh, and one final, stupid mistake I made: I added a power LED so that it was obvious when DrumKid was on, but somehow managed to connect both legs of the LED to ground in the layout. Clearly KiCad's "electrical rules check" doesn't check for that...

  So, overall, a bit of a mixture of good and bad, but that was probably to be expected for a fairly major revision of the design. It's certainly going to delay the release (I've tried to remove mentions of a November release date from the web where possible!). I'll see what I can do to fix the issues by hacking this PCB, then design and order a minor revision ASAP.

  I always knew that this project would be a learning process. I was attempting to jump from having minimal PCB design skills to releasing a reasonably complex product with a mixture of analogue and digital circuitry, so although I did initially get a bit cross at V5 for not being perfect, I'm philosophical about it - we're getting there!

• New PCB (V5) Design

  Matt Bradshaw • 11/05/2019 at 13:47 • 0 comments

  Have finished designing a new PCB, the fifth iteration since I started the project. I'm waiting for it to arrive from China, but here's roughly what it will look like:

  The overall footprint is a little longer to make room for the MIDI ports, there's more info included on the silkscreen layer, there's an extra LED to show when the power is on, the volume and power controls are now aligned with the audio output, and there are a bunch of boring changes to the component layout on the other side. Oh, and everything is red now.

  I've also ordered some black nylon knurled thumbscrews to allow the batteries to be changed without needing a screwdriver.

  Meanwhile, coding continues, and I've sent a V4 prototype to Pasadena for Supercon. I won't be there, but hopefully DrumKid will!

• MIDI and Sync

  Matt Bradshaw • 10/14/2019 at 15:10 • 0 comments

  After getting lots of feedback, I'm attempting to add MIDI to DrumKid. Many people have expressed a hope that DrumKid would feature the ability to synchronise with other instruments, and I've decided that MIDI is the best way to do this, because this also gives the option of using DrumKid as a MIDI controller, thereby greatly expanding its capabilities.

  (For the uninitiated, MIDI stands for "musical instrument digital interface", and is a type of serial connection which allows musical instruments to send data to each other, such as notes, timing, and other controls.)

  Outputting MIDI note data from DrumKid was very easy, and instantly convinced me that MIDI was a vital feature which had been missing all along - I was suddenly able to produce a much wider variety of sounds by triggering other drum machines' samples. However, generating synchronisation data has proven much harder. The MIDI "clock" standard requires a byte of serial data to be sent 24 times per quarter note. Had I thought about this from the outset, I probably wouldn't have designed my code around an arbitrary division of 16 pulses per quarter note, because these two divisions are basically incompatible! I was able to get my Korg synth to sync up with DrumKid, but only at lower tempos, and not with any great reliability.

  After several hours of trying to fudge the code, I decided it's time for a major rewrite. The code had become bloated and messy, and I was pushing right up against the RAM limit anyway. Now that I'm 90% sure that DrumKid will feature MIDI, I'm going to incorporate it properly, rather than as an afterthought.

  The next GitHub update might be a pretty major one!

• The "Final" Stretch

  Matt Bradshaw • 09/30/2019 at 15:49 • 0 comments

  Well, the Hackaday Prize final deadline is tomorrow, and I think I've squeezed as much progress out of DrumKid as possible in that time! I thought it would be nice to reflect on how far the project has come since it began.

  • February
    • Started exploring the idea of converting my DrumKid web app into a physical project
    • Got some good sounds from early breadboard prototype
  • March
    • Experimented with voltage regulator chips
    • Designed V1 PCB
  • April
    • Assembled V1 PCB (which worked, but was too quiet and had noise issues)
    • Designed and 3D-printed a case
    • Decided to increase number of potentiometers
  • May
    • New stripboard prototype to diagnose problems more rapidly
    • Added filter circuit
    • Designed V2 PCB
    • Hackaday Prize mentoring session
  • June
    • Rethinking the enclosure design
    • Designed V3 PCB
  • July
    • Assembled V3 PCB, instantly found routing issue
    • Designed V4 PCB (minor revision)
    • Designed and 3D-printed front and rear panels, to be laser-cut in final version
    • Sourced test laser-cut pieces (success!)
    • Assembled V4 PCB (success!)
  • August
    • Concentrating on coding
    • Added lots of features
    • Made demo video
  • September
    • Found local laser cutter and obtained enough pieces for three new (identical) V4 prototypes
    • Did a "test run" of assembly, successfully built three new units
    • Distributed DrumKids to testers
    • Received feedback from testers
    • Started V5 PCB design

  And that takes us up to today! I'm really pleased with where I've got to, and am excited to complete the V5 PCB design over the coming days. Good luck to all the other Hackaday Prize finalists, and if anyone wants to be kept updated about DrumKid's launch later this year, please go to mattbradshawdesign.com and sign up my mailing list.

• A Look Inside

  Matt Bradshaw • 09/30/2019 at 13:43 • 0 comments

  Here is a selection of photos showing the inside of the current version of DrumKid.

• How Open Source?

  Matt Bradshaw • 09/30/2019 at 11:54 • 0 comments

  This is a brief post where I will discuss exactly how open source DrumKid is (spoiler: as open source as I was able to make it).

  My aim from the start of the DrumKid project has been to create a fully open source instrument, in terms of both hardware and software. I based the design on the Arduino platform, which is itself open source, and have shared all my schematics, CAD files, parts lists, etc under the MIT licence, so it's fair to say that the hardware side of my project is fully open source, which is great.

  The software side is a little more complex. My code (which is also shared under the MIT licence) relies on two external libraries. One library which I make some use of is the ArduinoTapTempo library, which also uses the MIT licence. However, my code is based heavily on the Mozzi audio library, which is shared under a Creative Commons Non-Commercial licence.

  Mozzi is a clever, extensive library that somehow squeezes complex audio out of an Arduino. The creator of Mozzi has (entirely fairly) released his code under this licence so that, while other people can use it to make cool projects, he reserves the right to negotiate a share of the profits if a commercial product makes use of his work.
  

  I reached out to Mozzi's creator while I was developing DrumKid, and we quickly came to an amicable agreement about future profits, which means that DrumKid is "good to go" from a legal standpoint. However, it does leave this project in a sort of open source limbo. All the code that I have written is fully open source, and I personally have permission to use all the code that DrumKid relies on, but if anybody other than me started making and selling DrumKids, they would be in breach of Mozzi's licence (unless, of course, they also reached an agreement with its creator).

  If somebody did want to sell DrumKid clones legally, one way would be to eliminate the need for the Mozzi library by "rolling their own" - while I do make extensive use of Mozzi, I only use a small subset of its features, so it wouldn't be that difficult to write some code that performed a similar function.

  Personally, I'm happy to keep using Mozzi and pay a small fee to the developer who made DrumKid possible, but I thought this was an interesting aspect of open source culture: when money starts to get involved, things do get more complex!

• Feedback

  Matt Bradshaw • 09/28/2019 at 17:23 • 0 comments

  Designing for other people is a lot harder than designing for yourself, which makes this project harder than almost all of my previous ones - the aim is to get DrumKid into the hands of as many musicians as possible, which means I actually have to listen to constructive criticism. I've tried to elicit feedback throughout the project, but this has ramped up recently as I approach my self-imposed deadline of making the first batch of finished DrumKids by November.

  I've now received comments from all three musicians who are currently using the latest prototype of DrumKid, so I thought this was a good point to share the feedback I've had throughout the project and how I've adapted the design based on it (or plan to in the near future).

  My main sources of feedback/criticism have been:

  • Informal feedback from friends (usually when I bring the latest prototype to the pub)
  • YouTube comments (I'm one of the few creators whose comments are nearly always nice)
  • Hackaday (comments, chat, and mentoring session)
  • E-mail (usually unsolicited but very helpful!)
  • Feedback from musicians who are currently using DrumKid

  Overall, spread over these various mediums, I've had a lot of helpful comments throughout the project! I thought it would be helpful to document them here, roughly in chronological order.

  Source	Comment	Response
  Early feedback from friends	Too much high-frequency noise	Improved the filter circuit
  Early feedback from friends	Output is too quiet (this was with the volume on max in a noisy pub - the filter was reducing the output too much)	Added an amplifier chip to boost the signal
  Early feedback from friends	The early single-knob design was too confusing and difficult to play	I agreed with this comment and redesigned DrumKid to feature four knobs instead of one
  Email and YouTube comments	DrumKid should be compatible with Eurorack synthesizers, and the different parameters should be controllable via external control voltages	Creating a DrumKid Eurorack module would be a separate, complex project, but there seems to be a lot of demand for it, so I've started making notes about a potential future design, maybe using a Teensy
  Email and YouTube comments	DrumKid should be able to synchronise its tempo with other instruments	This has come up quite a lot, often enough that I'm considering adding this feature to the final design, although it might delay the release by a couple of weeks
  YouTube comment	It would be good to be able to load custom sample sets (different kicks, snares, etc)	Although it would be hard to make this part of the core, supported features of DrumKid, switching the samples is such an obvious customisation that I'd like to document a way for people to do it. This has made me realise that I should write a secondary "hackers' manual" for DrumKid to help people who want to customise their instrument
  Tester	There should be more different styles of basic drumbeat, such as drum 'n' bass, reggae, waltz, etc	I agree with this, and will spend some time adding more beats for the next version
  Tester	The volume knob seems to be mounted backwards	This is true - either the KiCad footprint is wrong or I did something stupid, but I will fix this in the next version of the PCB
  Tester	There should be more than six slots to save beats in	This is probably fair. There is plenty of space in the EEPROM to save more beats, but I wanted to keep the user interface nice and simple (six buttons, six save slots) - I'm considering increasing this to six banks of six (36 slots)
  Tester	The loading process is unreliable and confusing	I hadn't noticed this before, but I think there is a bug in the code, so I will investigate
  Tester	The LEDs are too bright	I noticed this, too, and had already planned to reduce the brightness for the next version, which should also have the benefit of increasing battery life
  Tester	Beats in non-standard time signatures have strange emphases	My previous, slightly lazy approach...

  Read more »

• Money Talk

  Matt Bradshaw • 09/23/2019 at 14:39 • 2 comments

  Apologies for what may be a boring post, but as my target launch date (November 2019) approaches, I'm starting to think more seriously about the financial side of my project.

  I'm currently planning to make small batches of DrumKids myself, perhaps 5 or 10 at a time. If there were to be a really big demand for DrumKid in the future, it would certainly be possible to redesign it in a way that would be more suited to mass production. There are surface-mount versions of all the components I use, and the case is not a particularly complicated shape, so it would be possible to design a version for injection moulding.

  However, this post will focus on the economics of manufacturing on a much smaller scale. The current design uses only through-hole components, partly so that I can make DrumKid without a reflow oven, partly so that I can sell DrumKid as a kit, and partly to make each one easier to repair or hack. I'm also using a laser-cut enclosure for the same reasons.

  This is my first time making anything that will be sold to the public, so it's entirely possible that I'm leaving out some major part of the calculation. With that caveat in mind, though, here are the various costs involved in making a single DrumKid unit (including both time and money as costs, since I obviously want to be paid for my time working on each unit!):

  • Materials (total £19)
    • Circuit board (£3 from China)
    • Laser-cut parts (£2 each from local maker)
    • Electrical components (£12, from three different suppliers)
    • Structural components (£2, from one supplier)
  • Assembly time (total 60 minutes)
    • Soldering (40 mins)
    • Uploading firmware (5 mins)
    • Testing (5 mins)
    • Screws etc (5 mins)
    • Bug-fixing (5 mins?)
  • Miscellaneous (total 30 mins?)
    • Postage and packing cost (can be passed on to customer)
    • Time spent packaging each unit
    • Time spent going to the post office
    • Time spent ordering parts
    • Time spent organising parts
    • Repairs (at my expense if within X years?)
  • Development costs
  • Time spent developing DrumKid (maybe 200 hours?)
  • Cost of components etc used in prototypes (approx £200)

  I have given actual values for the materials (because I can look up the prices I paid for them) and assembly time (because I kept a log of how much time each process took when I built a test batch of three units). I have only given values to the nearest GBP, since these costs will fluctuate quite a bit anyway.

  My ballpark (rounded-up) figure at the moment is £20 (or $25 USD) of materials per unit, with roughly an hour of assembly time. The other time costs are a bit harder to estimate right now, since they will depend on factors (partly) beyond my control, such as how many units I sell. My rough estimate is that ordering parts, shipping, and general organisational tasks will add perhaps 30 minutes, on average, to each unit. This means each DrumKid unit will require £20 plus 90 minutes of my time.

  This sounds pretty good so far, but I haven't yet taken the development process into account. I've spent countless hours developing DrumKid, trying out different circuits, playing with the code, soldering prototypes, researching components, etc. If I were to start the project again, perhaps I would have documented all the time I spent on development, in the same way that I fastidiously document my time when working as a freelance web developer. However, it's not as simple as adding up all the time I spent working on this project and trying to make sure I'm paid for it - a lot of my time working on DrumKid has involved learning new skills which will help enormously on future projects. Before DrumKid, I knew barely anything about PCB design, filter circuits, decoupling capacitors, or PWM audio, so I'm not sure I can strictly add the time learning those things into the "development time" column.

  Since I didn't record how much time I spent on each task, this is all moot anyway - it's just an interesting point to consider. I'm going to have a wild guess...

  Read more »

• Warholing

  Matt Bradshaw • 09/20/2019 at 16:12 • 2 comments

  I showed my latest laser-cut plywood prototypes to a carpenter friend of mine, since I wasn't sure how to darken the wood to fit the aesthetic I was aiming for. After exploring a few options with him, I decided that using wood is perhaps more trouble than it's worth at this stage. While I would prefer to limit the amount of plastic I use, for environmental reasons, I think that perhaps it's justified in this case: it will probably be more hard-wearing, and I'm not using a huge quantity. Since I will be making DrumKid in relatively small batches myself, rather than mass-producing it, I can always re-evaluate this decision in the future.

  With this decision made, I've been using my (not very advanced) image-editing skills to try and get an idea of what the first batch of units should look like. I can independently vary the following:

  • PCB (top panel) colour
  • Small front plastic laser-cut panel colour
  • Large rear plastic laser-cut panel colour
  • LED colour

  I already know what an all-black design with white LEDs looks like:

  I'm pretty pleased with the monochrome design. It looks slicker than I imagined. However, the black solder mask actually looks slightly grey in real life, and the colouring has been slightly inconsistent between batches (the previous, unsuccessful PCB design was also ordered in black, but came out much darker). Also, my preference has always been for bright, even garish colours, and I'd like to include this part of my personality in the final design, if possible. With this in mind, I attempted to simulate a few different colour combinations.

  First, I decided to try some bold, single-colour designs. Red, green, and blue are all available solder mask colours, so I wanted to see what it would look like to match the laser-cut parts and LED colours to the solder mask:

  I quite like all three of these, but with a mild preference for red. I've also had trouble finding bright, pure-green LEDs in the past (they often look more yellow-green or fluorescent yellow), and I also worry that a green solder mask would look less stylish than another colour, since green is the traditional, "default" colour for circuit boards.

  My next idea was inspired by my favourite Lego theme: M-Tron. For the unfamiliar, M-Tron was a successor to the classic Lego space theme, with a bold colour scheme of red, white, black, and fluorescent yellow (specifically transparent fluorescent yellow). Here's an example:

  And here's my M-Tron-inspired DrumKid mock-up:

  I really like this colour combination. I could even use transparent fluorescent yellow plastic for the rear panel, showing the circuitry and giving the characteristic edge-glow effect of laser-cut coloured transparent plastic. Sadly, I can't really do the same with the front plastic section, because it would show the soldered leads of the components, which (in my opinion) are a lot less attractive than the components themselves.

  I mocked up one other design, inspired by chunky Fisher Price tape recorders - I rather like the idea of using a "toy" aesthetic, because DrumKid fits into a category of toy-like electronic instruments that have become popular in the last few years (Teenage Engineering being the foremost proponents of this style). Here are a couple of images of Fisher Price tape recorders that inspired me:

  And here's my "toy" DrumKid design:

  In the UK, we have a brand of savoury spread called Marmite, whose slogan is "you either love it or you hate it", the idea being that its taste is so strong that you can't have a neutral opinion of it (for the record, I love it). The idea is pervasive enough that "Marmite" has entered the dictionary as a word to describe something inherently polarising. I feel like my colourful ideas are, perhaps, Marmite designs, and I'm torn about whether this is a good thing....

  Read more »

View all 29 project logs