So I’ve done lots of cleanup. Getting the board into 3d helped me fit components and realize what didn’t work well.
I’ve added a rotary encoder at the top, and further isolated some of the local ground-planes so that the regular ground wasn’t coming nearby to ruin the party, the local ground planes for my high frequency devices now have pours under the component, but still only contact through the single shunt with a filter capacitor nearby.
I utilized the local ground for my charging circuit as well, and indicated the isolation in silkscreen. This is a pattern I’ve seen on some boards, where they keep some isolation on their power/charging side, so it seems prudent. The silkscreen is mostly indicative for any sort of bodges, (IE, don’t pull from here unless it is power related).
I cleaned up a bunch of the silkscreen locations, and standardized on a minimum font size that is legible (as determined from other test boards)
I’ve removed the pointy bits near the antenna cutout (they are now nice and smooth) and I’ve opted for two through-hole resistors for the charging circuit so I can more easily adapt to different batteries. I’ve also added silkscreen with the formula and example battery to charging profile parameters (to help with self-documentation),
The board is slightly wider now (about 5mm wider) which makes it a square 100mm x 100mm. This gave me room to spread out the buttons to provide some breathing room for the keycaps.
I realized my linear slide potentiometers, while probably fine, didn’t have plated holes (I put just regular holes) for the mechanical connections. Those have now been plated to allow me to solder them in place.
I found a bunch of tiny dimensional errors that, likely not critical, were incorrect, so I adjusted those to clean them up.
I’ve also added the boot mode button for programming.
All the components were re-numbered so that they follow a nice flow (and are roughly in the order of if you were soldering by hand and wanted to validate the circuit as you went along).
I refactored some of the mounting holes to give more options for case creation.
I’ve sent a prototype of these off to get things rolling.
I got a chance to assemble the SMD components on one last night. To my dismay, the voltage regulator just sat there getting real hot, and the output voltage was wrong.
I figured I messed up the power circuit, so I popped off the ESD diodes, which were the only part not tested. No change.
I popped off the voltage regulator, which isolates the system power pins from the power management portion. This let me hook it up to a different 3.3v power supply and throw a multimeter in-between to measure current. It was drawing over 1 amp!
I went back to the data sheets, and poured through my schematic. Turns out I swapped the VDD/VSS pins on my two ADC chips. I sliced through those legs to disable them and my current went back down. It is still higher than I anticipated (around 100ma) but still not bad.
I made a bodge to swap the pins on one, but destroyed the other pads in the process of trying the bodge on the 2nd ADC.
After programming the ESP (and figuring out I really do need a reset pin, or at least the auto-reset circuitry). Originally I figured I’d just jump the pin, since I only need to program it once in production. But I really ought to build it into the board for programming ease (and maybe just not populate extra parts on build)
At the end of the day, I got all the buttons working and some analog inputs.
After getting everything working that I can on this board, I did a test with an 850mAh battery. It wasn’t a highly controlled test, but it at least let me know my ballpark. With an 850mAh battery that probably wasn’t 100% charged, I got 6.5 hours of active connection to a laptop and still had a buffer of about .2 to .3 volts before the cutoff voltage. I’m missing power management code and a second ADC, so this really only gives me a ballpark. I’ll ultimately size my battery based on my power efficiency and my expected battery life. I think 6-12 hours of somewhat active runtime is around the range I’m shooting for.
While I have a low-battery indicator (thanks to my power path manager) I would really like a better sense of the battery level. To do this, I’d need a battery fuel gauge (a coulomb counter). This is essentially a device that goes on one of your battery lines and measures how much energy comes in/out of your battery. I’ve chosen one with an i2c interface because I already have i2c lines for my ADCs. Extending my i2c lines was pretty easy.
I’ve already implemented in the bluetooth low energy battery profile service, so all I’ll need to do is periodically query the fuel gauge and update that value. There is an alarm pin, but given my draw is very small, I think a periodic update will be just fine.
I’ll probably make a warning mode for low battery that flashes everything to try to get attention in case it is nearing low voltage dropout…
I’d say this is feature creep, but if this is to be reliable, I feel like knowing your battery level is important.
This morning I sent off for a new prototype board with the new battery fuel gauge and the fixes from my first engineering test. Tonight I got my rotary encoder working (probably should have validated that before sending off the next board) but at least it worked without issue.
What hasn’t been tested so far is the LED output and having the 2nd ADC on there, but otherwise it all works so far, and I now have rudimentary software support for all my inputs.
Next step will be a race between building out a high fidelity test, and designing an initial case for this. Luckily I have the board in Fusion360 so I can design with the constraints there.
I’ve got my next iteration of the board in the mail, so you should see a full-functionality dress rehearsal on that soon. I still think I might increase the width a little to allow for larger knob caps and to give a little space between the sliders. Doing that would dramatically increase the PCB cost for small runs, but ultimately I think it is worthwhile for the final product’s sake.
The latest revision just came in from Seeed studio ( www.seeedstudio.com ), and this time I opted for PCBA (which is the PCB creation, plus assembly). I didn’t populate the entire board, I just wanted to try it out, kick the tires, and see how running some parts that they have in-stock would work out.
The boards themselves came out really nice. No mouse-bites on the edges (they are fully routed, you don’t see tabs left where someone clipped the board). Overall, I love the quality. This time I did white, just because I like the look over green, but I’ve now tried nearly all their colours. I’m thinking white or black for a production run at this point.
Each board came nicely packed in bubble wrap to protect it, and the solder joints were great. There were some slight little ‘Kling on’ bits of solder that wiped off by hand, so I guess one takeaway would be to maybe take a quick brush and do a once-over if you were to get them. In retrospect, I wish I had them populate more components, but I also am still iterating on this board. I think I might be getting close to my final design.
Seeed ran a promotion where they covered a lot of the assembly costs. That’s what put me over the edge for this one. It really helped me figure out how the process goes. I need to spend more time on my PCB documentation so that it is more clear where each part goes. They ask you to provide a documentation pdf and an smd placement file for a pick and place. For short runs, they don’t use the pick and place, as the setup probably costs more than just doing it by hand. My pnp files were fine, but my documentation files weren’t that clear for the specific components I was asking them to place.
They emailed me with a picture of the board, a description of what they were trying to figure out. One quick email later where I was able to mark up the image to guide them on what I had failed to be clear about and they were on their way. I really appreciated how good they were at helping me out.
I’ve so far really appreciated seeedstudio for my prototyping. Most of the parts I’m using aren’t in their open hardware list, so in interest of time (it takes them time to buy parts they don’t stock, of course), I left those off. I’d be interested to see how the whole process goes once I do a full board.
Having gone through the process, I now know what I need to do to make it clearer for assembly. They have great tutorials on their site about the technical procedure, but I think I have a more clear understanding on how to lay out my on-board documentation.
I’m looking forward to building this board, as I think it will be my first full-capacity board (all features working).
More to come after I finish assembly on the first one…
I have two small errors (just a filtering cap put on the wrong line and one of my voltage dividing resistors is wrong).
I have all channels working (though because of the voltage division, the analog inputs are scaled down), I have battery power-path working, and I have LED output (via MIDI output) working for indicators under the buttons.
Here’s a look at where I’ve mapped a deck switcher and an indicator for which of the four decks I’m on via LEDs.
Wow, I haven’t made a blog post in a couple weeks, but lots has been happening.
Primary Project
Board Progress
I sent off my next revision as an assembled board to both check the process and to see how manufacturable it is. They sent me an email back where they reversed a diode, so I’m losing a few days on that, but seemingly it is coming out well. They have agreed to rework the diodes on the built boards. I’ll need to validate if this was a human error or if this was a pick and place file error on my end before I go into production.
On this run I made the board a bit bigger to allow for better spacing between the analog inputs. The knobs were getting really close together. While this is a compact board, I don’t think going 20% (or depending on how they feel, it might even go up to 50%) wider will be a problem for its intended purpose if it makes a better feel.
Button Debouncing
After extensive testing, I think I’ve isolated some of my button debouncing woes down to a narrow case. I’m still checking the software to see how it can be fixed, but I’ll write more as I find out more.
I’m starting to consider a hardware debouncing solution rather than software. Software debounce is 99% of the time the right solution in today’s hardware situation. Micro-controllers are so dang fast that you can throw some cycles away, save yourself some complexity, save a little on your BOM, and add some other features at the same time.
The problem comes down to quick presses and latency. As I increase the utilization of my analog input sampling, it is seemingly disturbing my button sampling on the same core. I could try moving the button presses to another core, but that core is dedicated to network communication and I’d rather not muck with that.
If I add my RC+hysterisis to my buttons, I can use proper interrupts so I’m not constantly looping to sample my buttons. This would allow me to have more time for my other functions, as well as have a clear flip/flop accountability on my inputs. Right now I can get into a state where only one direction is reported which can get problematic. Especially software like Garage Band don’t disable an action when any Release signal is received. Instead, it seems they implement an accumulation buffer. So if my releases don’t equal my presses, a note is stuck on.
I’m sure I’ll get people telling me I’m wrong on these assumptions (if you want to see some passionate internet yelling, look up button debouncing), but I’m still in the investigation phase.
Testing Considerations
I ordered some Pogo pins to see how those work, and I’m looking at how to utilize those with a test fixture. Because I intend to sell this unnamed MIDI board as a kit, I want to make sure that even without all the components populated that it should work as expected.
This video has been an inspiration for a testing fixture:
My current idea is that I can design a test fixture that can:
Test that ground/power aren’t shorted
Test that the power circuitry is working as expected
Upload firmware to the board
Read analog reference voltaage (extra credit, auto-calibrate the AREF potentiometer)
Simulate button presses and analog inputs across all unpopulated devices
Test LED output
Test rotary knob
If I want to make this extra awesome, I’ll build a rPi to administer the tests, drop a bluetooth dongle on it and have it do a bunch of tests that also validate the input functions over bluetooth. If I do that, I’d also like to allow it to do a burn-in test where it runs a sequence over time to ensure that it is nice and stable and getting the midi sequence I expect.
If I add an rPi as a test controller, I can also script it to upload a firmware to validate user-upgradable firmware. If I do that, the first upload would probably a self-test firmware where it is designed to inspect itself, but also include the firmware upgrade code. The rPi would then update the firmware OTA at the end of the self-test and perform the production test, then the last step would be to repeat the same step after uploading the same firmware again. Its a bit overkill, but it makes sure I can have extra testing on my board, that I test all production features, including OTA updating.
Components
I’m getting a variety of switches to both have options, as well as feel the difference between them.
Some of my recent decisions to widen the board come down to knobs that I’ve chosen. They are a bit wider than normal knobs, but they come highly recommended.
I’m considering shipping with DJ Tech Tools’ chroma caps:
They are a bit more expensive, but anything that the end user interfaces with directly I want to feel great. This is a tool for passionate people, so I want to do right by them.
Meta Projects
Website
I’ve been slowly investigating a website (oh man, I hate making websites) and honestly, I’ve gotten nearly nowhere with the website.
Bikeshed Board
I’ve also gotten some of the bikeshed boards built. While that’s not strictly a BLE MIDI board, it was the test-bed for most of my power subsection, so getting that validated across multiple batteries and conditions has been quite validating for nearly the same circuit that I have on the bikeshed board.
I’m working on how to package up these kits. Ideally it’ll be easily recyclable packaging (thinking all-paper right now). Packaging for an SMD kit is important since it is easy to mix up or lose small parts.
I have a laser cuttable prototype for these and I’ll probably cut a few on the laser to see how they would work. I’d love to do a pulp thermoforming as a prototype for the midi controller but maybe out of scope for now.
While my part says 5.1k and is in the OPL database, lookinig further into the part, it is indeed mislabeled and it is a 1.5k resistor. :facepalm: I’ll have to specify another resistor
I didn’t ground my VREF- signal when I simplified my voltage dividers. This caused my ADCs to go haywire as the negative reference wasn’t tied to ground (but not quite floating due to internal chip stuff)
I mistook a 100mΩ for 100MΩ resistor. I’ll fix the problem and maybe I’ll get my fuel gauge working.
Even with the wiidening of the board, I still think the layout is a bit tight with the nice potentiometer caps installed. I’ll probably widen the board a little more. The vertical spacing is now nice. Widening the board will also open me up to other options for my slider caps. I don’t really want to widen the board too much both for cost and size considerations, but even if I widen it a bit more, this will still be a small controller.
Here’s an in-progress shot of one of my recent builds.
I don’t know if this is too late to make a difference, but a fun technique for prototyping is to laser cut or 3D print your PCB. You can laser /print the drills, too, and place your through-hole bits on top to get a good feel for how they all fit, or you can 3D print your sliders and larger components right on there as well if your footprints are complete with models.
I did the paper prototype but it seemed pretty good, but I changed which knobs I was going to put on as well as I was trying this out for an extended time with actual control
Hello - I’ve just come across your excellent blog. I’m sat surrounded by wires, knobs and code trying to make my own midi controller. Your project is very inspirational, if a little daunting about how much work is involved. Very impressive indeed, I wish you every success, keep going.
@mike I’m curious if you’d be interested in sharing more about MIDI over BLE in IDF. I’ve been playing around a bit but the examples of Bluetooth stuff in IDF but I find it pretty confusing (and am trying to avoid dropping down to Arduino libraries). Looks like you started with the Gatts Table demo - I don’t suppose you plan on open sourcing any of that?
Also I still want one of these when you start taking orders
