01/30/2015 at 02:34 •
I just finished up the rest of the project- at least pretty close. I etched the and assembled the second board (this one with red LEDs), and stuck it in its case. I also added a cap screw to each of them, approximately where the winding knob would be on a real pocket watch. This is partially for aesthetics, but it also serves as a way to attach a chain, if that's desired in the future.
I've also made a couple of tweaks that have definitely improved the performance. First, I lowered the op-amp's gain to around 1/4 of what it was initially. I finally took the time to look at the wave on a scope, and it was clipping even when I played notes at moderate volumes. It will still clip now if I play loudly right into the mic, but I'm calling it good. I'll consult my friends after giving it to them to see if it works for their use case.
The second change I made was firmware. The micro I'm using (barely) doesn't have enough RAM for a 512-element FFT, so I was using 256 elements. I then occurred to me that the performance hit for using things other than powers of 2 might not be so bad, especially if it gains me something in terms of accuracy. Well, I upped it to 384 elements (one power of 3 in the FFT, so probably not a huge deal), and it seems to have improved things nicely with minimal processing time increase. At least I don't see any great change.
The "(ish)" part of "Done(ish)!" concerns the little things- final tweaks to the gain, playing with the sample rate, expanding the range of notes the device will detect, etc. It's good enough right now that I'd be willing to give it to my friends and not be embarrassed about it, though.
And because everybody loves pictures, a couple more:
Showing both of the completed Pokey Watches.
Same thing, except from the front. You can see the cap screws a little better here.
The awesomely-obnoxious green charging LED. I actually like it... it produces kind of an alien effect when the watch is [almost] closed.
Anyway, I'm marking this as "done", despite the potential for future tweaks.
Oh, and I realize that the Git KiCad files are broken (missing schematic libraries). I'm getting to fixing it sometime. The layout should be usable, though, and the code is all set.
01/27/2015 at 19:29 •
A little testing- with a video!
Overall things look pretty good. The pitch detection seems to work reasonably well, with a few hiccups here and there. It even works with a real instrument, which is something I was a little concerned about. I'm still messing around with the sample rate and some algorithmic changes to get the best possible performance.
The most significant thing I've been considering tweaking is weighting the values from the FFT. Right now, it takes a bunch of samples, then performs an FFT on them. From there, it finds the peak frequency bins. The reported frequency is based on the weighted average of that peak, plus its two neighbors (weighted by the FFT output value). Adding additional weighting constants, or squaring the weights, or something else might produce a better result.
01/24/2015 at 02:27 •
The battery is soldered on, glued to the back of the PCB, and the whole thing stuck inside the case.
Time to polish up the firmware! And maybe add a fake winding screw thingy and chain, to make it look more pocket-watch-y.
01/22/2015 at 19:53 •
I got the cases' finishes cleaned up today, as well as hinge pins inserted. That turned out to be easier than anticipated, as I found a (hefty) paperclip of the correct diameter. All I had to do was cut a piece off of the appropriate length, flatten one end to make it stick in the hinge, and insert it.
Pictures of the results:
Now it's on to firmware and (back to) electronics.
01/22/2015 at 04:34 •
*Still requiring a little final polish
The first image shows the assembled cases, which is probably what everybody wants to see anyway. The second shows the holes I drilled for the hinges- a nerve-wracking process. Teeny-tiny drill bits plus having to redo TWO parts if I screw up is not a good time. Anyway, the third image is part of the process of cutting out one of the lids, and the final image shows the PCB fitting into the case.
That didn't work quite as well as I'd hoped (guess who forgot to pad the PCB inset in the case by a few mil?), so I had to sand down the PCB a bit. It wasn't too awful, fortunately.
Otherwise, making the cases themselves was something of an adventure in messing up gcode and manually fixing the results with a file. And spending more time getting things bolted down, zeroed, and aligned than actually milling.
Regardless, I'm pretty happy with the results. I should just need to finish up the software side of things, actually find/make a hinge pin, and polish up the cases (a Scotch-Brite pad works wonders- it adds a slightly brushed finish, while smoothing out the rough edges). Maybe one will be fully assembled tomorrow.
09/11/2014 at 20:53 •
Things are moving slowly mostly because milling cases is turning out to be a huge pain- I keep screwing things up. This last iteration was trying to mill a lid. Somehow the part moved during milling, so the top and bottom weren't in alignment. Bah. I would have thought 3 bolts holding it down would have been enough. Pictures should be available at some point, once I have a camera.
My latest thought (since I have to do it again anyway) is to add a little lip on the lid, plus an indent on the bottom part of the case. That way, when the device is closed, there won't be the opportunity for large torques on the hinge itself, just linear forces on the lip and the hinge. That, of course, means milling a new bottom and lid, probably another several hours.
I'm working on a number of ways to reduce milling time (a lot of the time is just setup/cleanup; actual milling time is MAYBE as much as an hour between the two sides of the two halves), which means back down the CNC rabbit hole. So if this sits idle for a while, that's probably why. Any CNC work will probably show up here: https://sites.google.com/site/dbtayl/cnc-mill/build-log (stuff about this project will also show up on said site, though I'm trying to also put it here).
08/24/2014 at 16:04 •
After receiving a suggestion to use the autocorrelation of the signal as a means of detecting pitch, I thought I'd try to compare it with my current, FFT-based approach.
I used a simple test to measure the accuracy of the FFT method- simulate some ideal signals (pure sine waves), then run the algorithm and see how close the pitches detected are to the actual frequencies. The program resulted in the following output:
Freq detected: 219.410355 Hz; note is 0, error is -4.507992 cents
Freq detected: 233.667511 Hz; note is 1, error is 4.361612 cents
Freq detected: 246.473740 Hz; note is 2, error is -3.266289 cents
Freq detected: 261.698944 Hz; note is 3, error is 0.455947 cents
Freq detected: 277.329346 Hz; note is 4, error is 0.932582 cents
Freq detected: 293.225464 Hz; note is 5, error is -2.559881 cents
Freq detected: 311.743774 Hz; note is 6, error is 3.412675 cents
Freq detected: 329.036469 Hz; note is 7, error is -3.115676 cents
Freq detected: 348.626007 Hz; note is 8, error is -2.993082 cents
Freq detected: 370.542023 Hz; note is 9, error is 2.581400 cents
Freq detected: 391.442657 Hz; note is 10, error is -2.460130 cents
Freq detected: 414.754150 Hz; note is 11, error is -2.274323 cents
Freq detected: 440.689392 Hz; note is 12, error is 2.710940 cents
Freq detected: 465.703400 Hz; note is 13, error is -1.694892 cents
Mean error: 2.142857 cents
Note 0 ... 13 correspond to A3 ... Bb4. The maximum error, in this ideal case, is roughly 4.5 cents- not TOO bad, given the limited number of FFT bins.
For the autocorrelation approach, I don't have hard figures, as I have yet to get a reliable algorithm working in C. What I have done is everything up to generating the autocorrelation coefficients for different time delays. I then output that data to a text file, loaded it into MATLAB, and semi-manually found the fundamental frequency that way.
I wasn't pleased with the results- it was almost never closer than 1 Hz from the true pitch, and frequently off by 3-4 Hz. And this was after tweaking the sampling rate and sample window length to whatever values I wanted. 3-4 Hz is something like 15-20 cents, depending on what note you're talking about, so I don't see this as being usable, at least not in the current state.
For reference, I used the algorithm described on this site. If anybody has a better version or other suggestions, post away in the comments section!
08/17/2014 at 20:20 •
This is just a brief discussion of some of the choices that were made in the design of this project.
First and foremost, everything was designed to be fabricated and assembled by me, "in house" so to speak. That meant that any chips had to be hand-solderable, any boards had to be CNC-millable, and the enclosure hand to be machinable either by hand, CNC, or both.
The IC selection was easy- I knew I wanted an ARM Cortex part, mostly because I've recently started playing around with them, and also because a 32-bit platform seemed more useful for some of the larger data values I was going to work with. I chose the NXP Cortex-M3 because I had a dev board already that had a similar chip, and because it came in an easily[-ish]-solderable package. The voltage regulator and battery charger are ones I'd worked with in the past and had lying around, in addition to being easy to solder. The other parts (op-amp, LEDs, etc.) were chosen based on whatever fit.
For the board itself, the fact that I was milling it meant that keeping vias to a minimum was ideal. I have to hand-solder vias, and that's no fun. I managed to get just about everything on one side, with the exception of one trace for the lithium ion battery. As it turns out, this is good, since the battery would be under the board anyway, so having its connection point there is no problem.
The enclosure design was a little trickier. I started out by trying to find out how big a pocket watch was (not having one, I really didn't know). Through sampling eBay auctions, looking at pictures online, and some guesswork, I decided 50mm across by 10mm tall was reasonable. That eventually grew to 54x11mm, based on wanting some more space for the PCB and battery.
With the size determined, I had to actually machine the part. Using my lathe was my first thought, since it's a round part, but that was quickly found to be a dubious option, as cutting off an incredibly thin (3mm for the lid) section after machining was... difficult. At least for me. So I turned to a CNC-milled design. The whole thing is roughly 2.5D, except for the USB connector cutout. I'm still working on how to mill that out... I made one prototype (lid and base), but my hinge design was awful. I had left ~3mm square of metal for the hinge, which didn't play well with a 1/16" hole (sorry for mixing units- my tooling is Imperial, but some of my design is metric). Hence the new design that can be seen in the images at top.
Finally, the software. I decided on an FFT because that's pretty much the limit of my DSP knowledge, and when you only have a hammer, everything seems to look like a nail. That said, I haven't found a better approach, and this one seems to be working pretty well. There weren't really any other significant software design decisions; it's pretty simple stuff.
If I had to do the whole thing again, I think the only thing I would really change is the microcontroller. Since starting out with NXP parts (because they were easy to program over a simple serial connection), I've found that the STM32 parts are also easy to work with, and seem to play a little nicer with a GCC toolchain, mostly with regard to linkers. I could be less of a sissy and just write my own linker scripts, but that's not my idea of a good time (I want to build stuff, not fight with my tools). It seems especially nice since evidently the Bus Pirate can be used as a programmer, eliminating the need for me to buy one specifically.
That's all, folks! (at least all I can think of at the moment)
08/14/2014 at 03:00 •
A system design document has been linked to above; it can also be found here: https://docs.google.com/document/d/1FCr_1DzBJ3AlNbu3_3PSzmd7HQe7VcK2Rn7YlFluygg/edit?usp=sharing
It gives an overview of how the system works, as well as some of the technical details- how the software works, why design choices were made, etc.. It should eventually include technical[ish] drawings of the enclosure with dimensions and stuff. I don't have a good CAD package for doing that, so it'll probably be pictures taken from OpenSCAD with dimensions drawn on. It's pretty simple, though, so that should suffice.
Milling a lid is still in the works... I'm working to dial in my CNC mill for better aluminum cutting performance. And I still need to actually write the GCode. That's kind of important.
08/12/2014 at 00:42 •
I updated the code in the repository... it turns out in the initial commit I missed some relevant files. As in, ALL of the relevant files. Oops. Anyway, it's fixed now.
I've also done some testing and made a video- it's working pretty well! When playing an 'A' on the piano (440 Hz nominal), the Pokey Watch hovered around 442 Hz (about 8 cents sharp), while the real tuner showed somewhat higher, maybe 14 cents sharp. I'd call that a win. This was with a 3-sample averaging filter applied to try to smooth the results. In the video, the LEDs correspond to within 21, 14, and 7 cents (outside->inside) from the nominal pitch. I think 15, 10, and 5 cents would be more helpful, but I want to make sure that kind of precision is at least semi-realistic before I start claiming as such.
Video here: http://youtu.be/ehbkRbINHs4