A few years back, I was meeting my friend Andrew for coffee and co-working at a downtown coffee shop. When I parked my car, I happened to catch an interesting sign on an unassuming little building. Intrigued, I wandered over and discovered that the proprietor made small, hand-built noise-making devices. We chatted a bit and I really wanted to take something home with me. He showed me Krankie, a manually cranked music box with a recording/playback capability. Additionally, you can alter the playback speed of the recording, providing hours of entertainment. The kids loved it, and we made a few music strips for it and mostly played around with its recording feature to record our voices. There is also an audio out feature, so I plugged it into my recording interface to see how it recorded. Unfortunately, the signal was way too loud and it clipped, no matter how low I put the preamp volume. So, I left it alone and thought I’d get around to it another day.
Fast forward to Feb 2021. I’d been recording more due to the pandemic keeping us at home, and I remembered that I was going to look into why Krankie’s output is so loud. So, I did a little of this and a little of that, but couldn’t tame Krankie’s levels. I even got on a chat with the creator via the web site and discussed some options. He hooked up a Krankie to his Focusrite Scarlett interface and was able to get a usable signal. He indicated that he needed to flip the “instrument” switch on that input to bring the level down. Ah, that was the problem. My interface has no such switch.
I assumed that the “instrument” switch was effectively an input pad. So, I googled up schematics for inputpads and found that it’s basically a few resistors. I breadboarded the circuit and used trial and error to find the magic combination of values that would tame Krankie’s rage. I tested the circuit and then experimented a bit more. I discovered that the whole thing worked with a single resistor between tip and sleeve. I don’t think I quite understand why, but it saves some soldering. With this information, I thought I could simply use a TS to TS cable with the resistor soldered in on one end. I clipped the resistor to the contacts on one end of the cable and tried it out. No joy. Krankie was too loud again. Then, I recalled the creator mentioning that I needed to make sure the cable coming out of Krankie is stereo, not mono. so, I switched out the mono cable for a stereo one and it worked. I ventured a guess that the output was being sent out on both channels and perhaps tip and ring were shorted. A test with the mulitmeter confirmed this.
I had a working solution so I set about looking for an appropriate cable. I had just purchased a TRS insert cable (one TRS end to two TS ends). These were a little on the pricey side, so I didn’t want to buy another one. All the inexpensive ones were molded ends, so I wouldn’t be able to solder in my resistor. Then, I thought maybe a little junction box might be the better solution. they make very small stompbox enclosures, and I really just need 3 jacks. This way, I could use cables I already have and wouldn’t have a hacked cable lying around. I priced out the parts and building a single box was cheaper than buying a cable. But the enclosures came in packs of 2. That was fine, because I have been meaning to build a foot switch for my older daughter’s guitar amp.
I ordered the enclosures, but they shipped very slowly. They finally arrived late March and I couldn’t wait to get this box put together. I had originally wanted to put the 2 quarter-inch jacks on the same side, but because of the screw housing inside the enclosure, they wouldn’t fit. So, I decided to put them on opposite sides of the enclosure. I went ahead and drilled the holes and test fit the jacks. They barely cleared each other, and when I put cables into the jacks, the tips of the cables touched each other. What to do? Looking closely at the jack, there is a slightly larger ring around the threaded part of the jack. as seen below. If I could somehow drill part way through the existing hole with this slightly larger diameter, I’d gain a little space.
I was able to fit a stepped drill bit into the enclosure, then stick the end of the driver through the opposite hole to bore out the indentation. Whew!
I made putting the rest of the circuit together a lot harder than it should have been. I mounted the connectors, then soldered it together in-place. I should have soldered it outside the enclosure, then stuffed it all inside. Live and learn.
So, what’s next? Decorating the case, of course! I think we’ll go for a robot head theme, since it kind of already looks like a robot head. We’ll experiment with a few different things. I think we’ll go for a vinyl sticker first, then maybe try laser engraving. I definitely want to try giving it a brushed finish and some clear coat to give it some class.
I’d like to thank Richard at Brand New Noise for making Krankie, and for spending time with me to debug the situation. Without his help, I wouldn’t have figured this out.
In late 2006, I began to notice that I was accumulating a lot of data on a lot of different hard drives. After a catastrophic disk failure on one of my systems, I decided that it was time to invest in a RAID-based storage solution. Being me, the decision came down to buy vs. build. My free time was about to evaporate, as we were preparing for the birth of our first child, so I opted to buy, hoping that the expandable RAID solution of the Infrant ReadyNAS NV+ would save me build, configuration and management time. It did! It was a great solution.
Fast forward through 3 complete (and a fourth, almost complete) disk set replacements, a power supply replacement in 2011 and a fan replacement in early 2020. I was running out of space, and the device didn’t have official support for individual drives larger than 2TB according to my last research. I had also been receiving numerous SMART errors from one of the disks for years, even after replacing that very disk a couple times. To me, this suggested an issue with the NAS, as the disks always passed SMART tests on another machine.
My Use Case
In anticipation of a new NAS solution, I got to thinking about how I wanted all of this to work together. What was my workflow? Did cloud storage finally make financial sense? Were SSDs cost-effective yet? I had lots of questions. During this planning phase, I recalled that my friend, Ted, had told me about a good deal on cloud storage with OwnCube. They are a hosted NextCloud provider. They sometimes offer a one-time flat fee special for unlimited storage so long as you have at least their basic plan. This made economic sense for me, and I bit the bullet. This would solve the storage capacity problem. I also wanted to run a home media server (not from the NAS, necessarily), which would require relatively low latency access to my files. I decided that having a mirror of what was in my cloud storage would be a good solution to that problem.
The need for a simple local mirror of my data drastically changed my requirements for a NAS. I didn’t need to worry about protecting against multiple disk failures. Really, I wasn’t worried about disk failures at all, as it would only impact the local copy of my files. This eliminated the need for hot swap bays, and any RAID levels beyond RAID-1 (disk mirroring). In fact, I ended up not using RAID at all, but we’ll get to that later.
My requirements/wishlist ended up looking something like this:
Relatively small form factor and quiet
RAID-1 or equivalent storage protection (would like ZFS)
Hot swap bays not necessary
Prioritize read speed over write speed
So, my solution was fairly simple. I’d build a 2 disk mirror that would run the NextCloud client and sync all my files on a regular basis. How Hard Could it Be?™
In my research, I came across a variety of solutions that would meet my needs. So, I took the opportunity to try something new. PIne64 builds small, powerful ARM-based SBCs. I thought their RockPro64 would be a perfect fit for my new NAS. They even sell a NAS-friendly enclosure made specifically for the RockPro64. It helped sway my decision that Ted built the same NAS a few months prior and reported satisfactory results. So, I loaded up my cart with the recommended parts and waited for my kit to arrive from China.
Putting the physical pieces together is quite well-documented, so I won’t detail it here. Assembly time was probably under 30 min., though I didn’t time it. When I received the SBC, case, and other parts, I hadn’t received my hard drives yet, so I set up the system with a pair of older 2TB disks that were spares for or rejects from my old NAS. It wasn’t important that they be reliable since I really just wanted to test out a few things with them. In fact, I ignored the errors that I saw, chalking them up to bad disks (spoiler: it ended up being a problem with the SATA controller).
Since I only needed to purchase 3 disks (the third for backup/hot spare), I thought I should buy higher capacity disks. After uploading all my data to my NextCloud instance, it appeared that I needed a tad more than 4TB of storage. Thanks to my friend Brian’s blog post, I decided to try shucking some low-cost 8TB external drives. They happened to be on sale for less than buying a bare internal drive of the same capacity. In my research I came across a technology called SMR. The big drawback with SMR drives is that write speeds are particularly slow, though read speeds are not affected. For my use case, this would not be an issue, so I didn’t have a problem if my shucked drives turned out to use SMR technology. Once I received my drives, I followed instructions from a few videos specific to my model and found that the drives inside were not SMR drives as far as my research revealed.
I removed the 2TB drives and swapped in the 8TB drives. This took several minutes since the NAS case doesn’t have hot-swap drive bays. The first thing I noticed on power-up was that the new drives were much quieter than the old ones. Pleased with that discovery, I set about configuring the software.
My goal was to keep the system setup as simple and “stock” as possible. In the event of a disastrous failure, I wanted to be able to get back up and running as quickly as possible.
Selecting an OS
The first OS/distribution I tried was OpenMediaVault. I downloaded the RockPro64 bootable image and wrote it to a microSD card using Etcher. I really wanted this to “Just Work”, because it would save me a lot of time and effort. The only thing really missing in my mind was ZFS support. Since this NAS would simply be a mirror of my cloud storage, I was willing to sacrifice ZFS support for ease of administration. Unfortunately, I couldn’t get OMV to work. It booted up just fine, but I was unable to get the web-based configuration tool to successfully store a static IP address. I decided to try setting static IP information from the console, but that failed as well. They have a convenient command line utility for configuration, but for some reason, it failed and exited when I tried to set the IP address. So, rather than try to debug this, I decided to move on and try the Ubuntu 18.04-based ayufan image. I was able to get this up and running with no issues.
Building the ZFS Kernel Module
The wrinkle here is that Ubuntu 18.04 doesn’t have a ZFS module by default. So, I’d need to build and install the kernel module myself. I know I said I wanted to keep things stock and simple, but this is the one area where I strayed from that principle. And, having done it now, it wasn’t so bad. To get started, Ted pointed me to this forum post, and pointed out that step 3 contained the key elements in getting ZFS built. The steps I completed were as follows (I have not gone back and rebuilt from scratch after I got this working, so I can’t promise this is 100% accurate):
install python 2 (may not be necessary)
sudo apt-get source zfs-linux
sudo apt install zfs-dkms
sudo dkms build zfs-linux/0.7.5( this succeeded and then sudo modprobe zfs succeeded)
lsmod shows it installed
Creating a ZFS Mirror Pool
Now that I had a working ZFS kernel module installed, I did a bit of research on ZFS pools. I discovered that I didn’t need to use RAIDZ2, I could simply create a ZFS mirror pool. I followed these instructions to create my mirror pool. The big advantage I saw in the simple mirror pool was that maintaining it appeared very easy. Disks can be added and removed from the pool. It’s even possible to add a disk, allow it to make a copy of the pool data (resilvering in ZFS parlance), and then remove the disk. This could be used as a makeshift backup in a pinch.
The fan that came from Pine64 connected directly to the SBC via a 2-pin connector, and is PWM-controlled. I tried setting the fan manually according to this forum post. However, my fan didn’t move. After an embarrassingly long time of trying to get this to work, I finally took the case off to check that the connector was properly attached and realized that one of the SATA cables was fouling the fan blades. I tucked the cable away from the fan with a good clearance, verified that the cable was connected properly, and tried manually setting the fan on. It worked. In my debugging of this issue, I came across a tool called ATS and installed it. The install was a tad convoluted, but it worked. There is a config file to control threshold temperatures, and it runs as a systemd service.
Syncing to my cloud provider is the key function for this entire build. I found that there is a command line option for starting a single sync action using the nextcloudcmd command. Unfortunately, this requires installing the entire NextCloud client, which isn’t onerous, but includes a lot of GUI libraries that seem unnecessary. I’m also not a huge fan of adding PPAs willy-nilly, but this is the major feature I wanted for my NAS, so I made the exception.
At some point in the future, I will create a simple systemd service that runs the nextcloudcmd command every 5 minutes. It will first check to see if the script is already running. If it is not running it will execute the command, performing a 2-way sync.
I also installed the smartmontools package that allows execution of SMART tests and fetches disk status. I may create a weekly report that gets mailed to me if I get around to it.
My old NAS had a UPS monitoring feature, so I wanted to keep that. I installed the apcupsd package, but I still need to set the threshold times for shutdowns. This should also alert other systems to shutdown as well, but I haven’t come up with a good solution for that yet.
Filesharing via NFS
On my network, all of my hosts support NFS, so that is the only remote filesystem I set up.
My old NAS was abysmally slow, and I was hoping that the new NAS would far outpace it in performance. I was not disappointed! I use iperf3 to test out basic network performance. The NIC on the RockPro64 was able to achieve between 937 and 943 Mbps in either direction.
During file transfers, I regularly see about 54MB/sec (432mbps) with large files through the Gnome Files GUI.
I realize that these are not exhaustive results, but they are indicative of what I’ve seen over the last few months of using the NAS, and give a rough idea of what to expect from this configuration. These are much better numbers than anything I ever saw on my old ReadyNAS.
So, that’s all the basic details for the build and configuration of my Pine64 NAS. I’m really pleased with the performance of the system, and the build quality of the NAS enclosure and the RockPro64 SBC. I’d definitely recommend the Pine64 NAS if your use case is like mine. The only thing that gave me problems was the PCIe SATA controller I purchased from the Pine Store. If you’re not interested in the gory details of that “adventure”, you can stop reading here. Otherwise, this is a good place to talk about …
Trouble in Paradise
Well, it sounds like everything went swimmingly, doesn’t it? If you’ve made it this far, you’re looking for the ugly truth. Remember those disk errors I ignored at the top of this post? Those should have been a big, fat warning. Unfortunately, I dismissed them as problems with the old disks.
The first symptoms that appeared were
Sudden CKSUM errors on one of the disks in the ZFS mirror (/dev/sdb), resulting in a “degraded” state, and then an “offline” state, indicating that the disk was unavailable. The disk was subsequently automatically removed from the mirror by ZFS.
When the disk became “unavailable” in the pool, smartctl was unable to read SMART data from the disk
Unexpected system reboots, usually during large file transfers
Rebooting and resilvering the mirror usually resulted in a repaired mirror, but it wouldn’t be long (24-48hrs) before the mirror failed again. The errors occured on both the original 2TB disks as well as the new 8TB disks, and usually affected the same device, /dev/sdb.
The problem(s) had to stem from one (or more) of the following components
My custom-built ZFS kernel module
So, I set about to isolate each of the components to determine where the issue cropped up. The simplest and least expensive thing to check was the SATA cables.
First, I swapped the cables with each other to see if the errors followed the “bad” cable. After swapping the cables, I rebuilt the mirror pool and started the NextCloud sync. Errors still appeared on /dev/sdb
To me, that result supported the notion that a bad cable was not at fault.
Next, using the “bad” 2TB drive (/dev/sdb) that reported errors earlier, I
Connected the disk to a SATA-to-USB adapter using the “bad” SATA cable from the new NAS enclosure and connected it to another computer
Ran short and long SMART tests on it
Created a ZFS pool with the single disk
Copied over 100 GiB of large files (DVD ISO images and .mkv files) to the pool
Ran zpool scrub on the pool
Then, I Connected the “good” 2TB disk (/dev/sda) to the same SATA cable and external adapter and repeated the above steps.
Next, I connected the “bad” 8TB disk (also /dev/sdb) to the setup and repeated the steps.
In my mind, this effectively eliminated both the “bad” cable and the “bad” disk as the source of errors, since I could write a large amount of data using the “bad” cable and “bad” disk combination on a different system.
I read many years ago that some USB drive adapters don’t pass SMART data through to the host system properly. So, to more completely test the disks and eliminate this possibly false information, I used the power adapter from the SATA-to-USB adapter and connected a SATA-to-eSATA cable between the drive and the second computer, which has an eSATA port. I then ran steps 2-5 again on both 2TB disks and both 8TB disks. This configuration had the added benefit of isolating the disks from the potentially “bad” cable.
Thinking through the past few days of experimentation, I recalled that when I did not limit the data rates for nextcloudcmd, the reboots occurred more frequently. So, I set the limits to 100mbps up and down and re-ran the sync. I noted that it took several hours longer for the reboots to occur. I also saw a few mentions in the Pine64 forums of the ASMedia asm1061-based SATA controller getting very hot. My controller was based on the asm1062 chip, but was functionally equivalent to the 1061. I noted that the chip got painfully hot to the touch, so I removed the cover of the NAS to allow more cool air access to the SATA controller and re-ran the sync. This appeared to gain a little more stable time before the CKSUM and SMART errors cropped up again. I decided to try attaching a small heat sink to the SATA controller chip. I ordered a few sets, rationalizing that if they didn’t solve my problem, I could just use them for my ever-expanding collection of Raspberry Pis. After attaching the heat sink, I performed a zpool scrub (~8hrs) and saw several CKSUM errors again, but no SMART errors. The mirror did not degrade this time. This looked promising! Until a few minutes later when the pool degraded and /dev/sdb was removed from the pool again.
By this time, I was quite frustrated, having spent the majority of a week tracking down this issue. But, I decided that this was an interesting enough problem to spend time on, so I persisted.
The next item to isolate was the power supply. Why the power supply? I began digging through the kernel log and saw lots of messages similar to the following:
A brief search revealed thisPine64 forum post, indicating that power might be the culprit. At this point, I didn’t have much to lose in trying, and it would eliminate one more potential source of the errors. The recommended power supply for the NAS case is rated at 12V and 5A, which should be plenty for 2 disks, the RockPro64 SBC and fan. I tested the output voltage of the power adapter with a multimeter and it read 12.3V, so the power supply appeared to be OK. For the next part of this test, I
Powered one drive (/dev/sda) with the power connector included with the NAS enclosure (12V 5A)
Powered the other disk with the SATA-to-USB adapter setup (the power adapter is physically separate from the USB connection)
My thinking was that this configuration would draw less current from the NAS power supply, potentially avoiding issues where the system wasn’t getting enough power, causing one disk to go offline. Even with this configuration, I still saw checksum errors and /dev/sdb became unresponsive to smartctl. So, this told me that it was less likely a power problem.
My Custom-built ZFS Kernel Module
Since the ZFS kernel module I installed wasn’t stock, I thought it would be worthwhile to try a stock kernel and prebuilt ZFS module. For this, I flashed another microSD card with the Armbian 20.04 Focal image, thinking there should be a kernel module and zfsutils-linux package. I got the image booted and tried installing the ZFS package, but it failed, complaining that the kernel module couldn’t be installed. Out of frustration, I took a simpler path. I decided to try creating the volumes using LVM and ext4. If i saw the same kernel errors, I knew the problem wasn’t isolated to the ZFS module. So, I set about creating physical and logical volumes. I wasn’t able to finish. During volume creation, the lvcreate command failed. I tried smartctl and /dev/sdb was unresponsive. The kernel log showed more of the now-familiar errors. OK. That ruled out my ZFS module.
I had proven (to myself, at least) that none of the other components in the system were likely sources of the problems, so the only thing left to try was the SATA controller. The previously linked Pine64 forum post also mentioned some SATA control chips that were know to work with the RockPro64, so I found a reasonably priced card based on the Marvell 9215 chipset and ordered it.
When the new card arrived, I swapped out the card, powered up the NAS with the microSD card containing the ayufan 18.04 image and crossed my fingers. I recreated the ZFS mirror pool and began the NextCloud sync, monitoring the kernel log and the ZFS pool status. After a complete sync (about 3 days) and a zpool scrub…
Well, that was painful. But, it was also informative and a lot of fun! Again, If you’re looking to build a simple NAS and your use case is similar to mine, I highly recommend the Pine64 NAS! But, don’t use an ASMedia asm1061 or asm1062-based SATA controller.
Back in 2015, there was a kickstarter for an all-analogue, tough-as-nails practice amp for guitar and bass. Intrigued, I followed the project. The project was successfully funded and I ordered my unit once the web site went live. It is a great little gadget! I ordered the kit, as it didn’t have that many parts and I needed to improve my soldering skills. I spent an evening assembling it and have used it mostly at night when the kids are sleeping. Another great use is taking it along with me to guitar shops so I can compare other guitars with the same amp.
My only complaint with the Whisper Amp was that I had to find a place to put it. Putting it in my pocket was a little awkward with the guitar cable protruding from the top. So I got to thinking about a way to attach it to my guitar strap. I wanted it to be relatively easy to attach and remove, so I knew Velcro would be involved somehow. As I often do, I turned to OpenSCAD to put my thoughts together. My first attempt was a solid band with a loop for a nylon strap. I would use 2 of these and fasten nylon through the loops. The problem with this design was that there wasn’t a good way to keep the bands secured to the body of the amp.
I quickly devised a second design and sewed together some straps with Velcro fasteners. This worked a little better, but it had the same problem. I needed a different approach.
The final design solved the attachment problem by securing a nylon strap between 2 “caps” on either end of the amp. This proved to be much more secure, but required a lot more design time to get the proper shape of the caps and the placement of the cutouts for the connectors. To get the curves on the edges of the caps, I resorted to tracing the shape of the amp on paper and calculating the radius of the rounded edge. Primitive, but it worked! To achieve this effect I used the minkowski sum function in OpenSCAD. It’s a really useful tool for nicely rounded edges. for the strap loops, I planned to use 1″ nylon webbing, so I made the loops accommodate one layer.
In a rare flash of maker inspiration, I got the measurements correct the first time. Well, on the rounded corners, anyway. I think I had to reprint due to the plug cutouts being a few mm off. I wasn’t sure how to finish the edges of the nylon. A quick search seemed to indicate that heating the frayed edges would melt them and nicely seal them off. I waved the cut ends over a gas flame on the stove, being careful not to hold it there very long. My caution paid off, as the ends melted quickly, finishing up very nicely. I sewed in a few pieces of Velcro and got it all assembled
Interesting note about using a 4-segement plug (TRRS). The output jack is designed for 3-segment (TRS) plugs, so you may need to slightly adjust the position of a TRRS plug to get stereo output.
And, finally, here’s a photo of the amp attached to a guitar strap while playing
Overall, I met my objective of making an easy-to-attach clip for the amp, which means it’ll be falling off of tables and other places a lot less. If you’re interested in making one, or just want to see how I designed it, I’ve put the STL files on thingiverse!
In early 2018, my friend Steve had an idea. His church supports missionaries, and for fundraisers, they sell lunches to the congregation. In the past, they had volunteers prepare and serve the food. It was a lot of effort, and Steve thought that it could be improved. He thought that having a restaurant make the food would allow them to charge a bit more for the food, and might draw more attention. He was right of course, and now he wanted a way to engage the participants even more. He wanted some kind of visual progress indicator. something that would get people excited about participating in supporting the cause.
“What if we had a big button that people could push when they buy a lunch, and then have a big display of how many lunches we’ve sold?”
That sounded like a cool idea to me. So, I set out to build just that.
I tried to make this as simple as possible. No, really I did! However, the constraints of the environment dictated otherwise. I thought the simplest thing would be to have a button attached to a Raspberry Pi, which would be attached to a screen via an HDMI cable. However, the display needed to be relatively far away from where people would be paying for lunch, and running a long HDMI cable was not acceptable. Steve mentioned that they had an extra laptop that they could connect to the TV, so this seemed like a reasonable solution.
After some noodling, I decided that I’d have a big button box with a Raspberry Pi inside. The Pi would host a web server that publishes a page with the count on it. The laptop connected to the TV would access the web page and display it on the TV.
Is this the simplest design? Not by a long shot. Would it be fun to build? Absolutely! I also like the idea that this solution is self-contained. If the TV has a browser, then the laptop can be removed from the setup.
The Button Box Design
The hardest and most interesting part of this project to me was the button box. I’d been itching for a project to use the laser cutter at our makerspace, theLab.ms. While I could have just used a tool to generate the dimensions of the box with appropriate notches for assembly, I decided it would be fun to figure it out on my own. Here’s what I wound up with…
I made the first prototype with cardboard, which worked out perfectly!
Happy with the results, I moved on to the 2nd prototype, which was made out of MDF scraps at the makerspace (I think I also got some hardboard in there, too).
Since this button box would be operated by non-technical folks, I decided I should add a shutdown feature to prevent damage to the SD card. When the button is held for 2 seconds, a shutdown command is sent to the Pi. Of course, nothing stops the user from just disconnecting power, but at least the capability is there. Since the Pi doesn’t have any built-in capability to shutdown the OS, I added a momentary contact button to the bottom of the box to serve this purpose.
Everything was going great until I received my acrylic sheets. I thought I was getting 3mm acrylic sheets, but I actually ordered 2mm acrylic sheets. *sigh*. But thankfully, I made the material thickness a variable in my OpenSCAD model, so I just needed to change that variable from a 3 to a 2, and adjust the placement of the power connector hole (that took a bunch of trial and error).
After the adjustments, I re-cut the box from the spare sheet of acrylic (always a good idea to get more than you absolutely need in case you make a mistake!).
To keep the wiring nice and clean, I used a Perma-Proto hat from Adafruit. I’ve used them in a few projects now and I’m hooked. For the relatively small circuits I’m making, they’re perfect, and don’t add much to the footprint of the project.
The RESTful Web App
I really enjoy projects that involve physical builds as well as software. In the spirit of over-engineering things, I decided to make my counter a RESTful Web Service. You can find the source code on bitbucket. When the big button is pressed, python code sends an HTTP request to the web server, incrementing the stored count. The web page showing the count updates every 1/2 second. For the shutdown, holding the button on the bottom of the box sends another request that executes a graceful shutdown of the web server and the Raspberry Pi.
Here is the whole thing in action!
Test it out in the target environment
I’d like to make the typeface fixed-width
There is code to set a target number. I’d like to add some animation that is triggered when the goal is reached
Over winter break 2017, my older daughter asked if she could make something. Before I even knew what it was, I was pretty excited. Finally after all these years of trying to show my kids that they can make things, I see a spark of interest. Here’s her idea in her own words:
“I want to build something that people can attach to their glasses so they can see who or what is behind them.”
So, we set to work on the design. I had her draw up her initial thinking on paper, and we took it from there. She decided that for the prototype, a clip would be the easiest way to attach the unit to her glasses
I wasn’t sure what we could use for the actual mirror part, but I remembered seeing mirrored acrylic somewhere, so we searched for mirrored acrylic sheets. We ordered the parts and set to work on designing the bracket that would hold everything together.
We decided that 3D printing the bracket would be the most efficient way to prototype it, and that turned out to be true.
Her first idea was a ball joint because it would allow the wearer to adjust the mirror’s position precisely. So, we found a ball joint on thingiverse and scaled it to the size we needed. The print didn’t work at all, and the joint wouldn’t fit together. Getting this joint to work for us would require a lot more engineering.
Discouraged but not hopeless, I decided I’d show her how to use OpenSCAD to design our own part. I mean, how hard could it be? We’d just create a static bracket for our first try and see what needed to be adjusted.
Using OpenSCAD was a great way to incorporate some of the math she’d been learning in school that year. We had to measure the dimensions of the clip with the vernier caliper and then calculate dimensions of the bracket based on those dimensions. She seemed to really enjoy the challenge.
The next step was to put all the pieces together for the first prototype.
We had some hot glue available to us, and that worked… for a few hours. The failure of the hot glue would later clue us in to a design flaw.
Despite that, the first prototype achieved its goal. She decided that the mirror was too close to the glasses, so we should move the mirror outward a bit. We fired up OpenSCAD and adjusted the dimensions and printed again.
This time, we used Loctite silicone to bond the clip to the bracket. That joint lasted a bit longer, but still failed after about a day. As a remedy, we decided to use Gorilla super glue.
After gluing the parts together, one part of the joint failed again.
I decided I wanted to figure out why the glue joints were failing. I inspected the action of the clip and showed it to my daughter. We hadn’t taken into account that the clip’s spring expands past the clip’s edge when the clip is actuated. The slight expansion was causing the glue joint to flex and eventually break.
She also noticed that she couldn’t see that much around her and we discussed concave and convex mirrors. So, we iterated on the design and came up with a curved mirror mount.
By this time, we were running out of time, so we weren’t able to make more prototypes before school started back up. We had a lot of fun doing this, though!
Issues for Further Development:
– how to make the fastener more generic to fit more types of glasses?
– carve out a small slot to accommodate the spring expansion.
In 2015, my church decided to revive their Fun Fair event. They encouraged folks to take a look at some of the old games and refurbish them if they were interested. I found an old game called “Dunk It”. It consisted of a toilet seat bolted to a green wooden frame. The goal was to toss a roll of toilet paper through the hole of the toilet seat to win a prize.
My inner 5yo. thought this would be my game. But, I couldn’t just leave it as is. I needed to make some… improvements. The premise of the game was simple, but it lacked something. There was no feedback for the player. So, I set out to give it a voice.
My first inclination was to use an Arduino with an audio shield. However, I was trying to minimize the cost, so I thought I’d use something I already had on hand, a Rapsberry Pi A+. This would handle the audio, and the programming would be relatively simple.
To prove the concept, I thought I would wire up a light sensor (Light-dependent Resistor) to the Raspberry Pi. This was not as straightforward as I’d hoped, since LDRs are analog devices and the RPi only has digital I/O pins. So, after a bit of searching, I found a technique to read analog values from a digital I/O pin using a simple circuit.
Once I got this wired up, I stole some code to make the LDR reading work. I combined that with some code to play back audio and the alpha version was working…
I foolishly ignored the advice to always put a resistor in series with an LED. And it bit me in the behind. An hour before the fun fair, the LED blew out, and I wasn’t able to leave and get a replacement. Lesson learned.
For Version 2.0, I wanted to make some significant improvements. First, I wanted to make a more realistic “experience” for the players. I was able to secure a toilet on freecycle (I love freecycle). After sanitizing it, I set to work wiring up the LED in the bottom of the bowl. This had the added benefit of making the code simpler.
I also wanted to improve the sound for the game, so I got an inexpensive power amp and car speakers. I mounted the speakers on the snazzy new platform with locking casters. This made the whole thing much easier to move around.
For version 3.0, I wanted to clean things up significantly, and make it easier to assemble/disassemble. I mounted the amp and Raspberry Pi on a board, that attaches to the inside of the tank with Velcro. I also used a connector for the sensor instead of being wired to the board.
I added a shutdown button for the system so the SD card doesn’t get trashed, and the Pi shuts down gracefully. and covered the wires with some flexible split tubing. I also added some code to avoid repeating the audio if the sensor detected darkness at the end of the previous audio playback. Finally, I added some other… apropos sounds.
I bet this is the first time the words “graceful” and “toilet” appear in the same context.
I’d like to use the flush handle to perform the shutdown/recalibration
When I was a kid I got an Aria Pro II XR Series Electric guitar as a gift from my parents. The mists of time prevent me from recalling if it was for my birthday or Christmas or some combination of the two, but I’m fairly certain that it was 1989.
I played the heck out of that guitar for many years, and it has moved with me everywhere I’ve gone. After our first daughter was born, I didn’t play very much at all and it languished until recently. I got back into playing a few years ago, and longed for a new guitar. I finally got that new guitar and passed on the Aria Pro to my older daughter. She liked it, but said that she’d like to have a blue guitar. That was exactly what I wanted to hear! I’d been contemplating modding a guitar for ages, and this was the perfect excuse to try it out. We decided to refinish it, upgrade some of the hardware, and maybe even audition some different pickups. Before tearing it apart, I thought I’d take some commemorative photos!
Step 1: Disassembly
To refinish the body, we needed to remove all the electronics, plastic covers, hardware and the neck. This was the easy part!
Step 2: Remove the finish
After reading a few different posts about refinishing late ’80s Korean guitars, I decided it’s probably safe to try the heatgun + paint scraper technique. I had no idea what to expect, but read several posts indicating that this vintage of low-cost guitars would likely have a laminate body. I was hoping that there would at least be some semblance of an interesting grain to the revealed surface. There’s only one way to find out, I suppose!
As it turns out, there was a thick coat of finish on top of the wood, then a layer of paint, and then a protective layer over the paint. Removing all of this revealed a somewhat porous laminate beneath. The layers of the laminate are about 1/16″ thick each, and actually revealed a very interesting pattern at the contours of the body. The top layer itself wasn’t particularly interesting, but that’s okay, since the laser-etched images should give it some visual interest.
Once the finish was completely removed, I set to work with the random orbital sander to get a nice smooth finish. I ended up with 300grit or so, and that gave a nice, almost glassy smooth sheen to the wood. I was able to remove much of the scorch marks caused by incautious use of the heatgun.
Step 3: Frickin’ Lasers
Not content with a plain design, I asked my daughter if she wanted to put any custom designs on the guitar. Of course she did! So she set about drawing a few things she wanted on the guitar. She said sloths and cats had to be involved. In our search for ideas, we came upon an adorable image of a sloth hugging a cat, and she had to have it. She then drew her own sloth and a cat from her favorite book series at the time, Warriors.
After drawing them up, we scanned the images and tested them on some scrap material to make sure we liked the results
Step 4: The Headstock
I wanted to really personalize the guitar, so I decided we should “rebrand” it. First, I sanded off enough of the finish to remove the paint and the logo.
I then took the Epiphone logo and played around with it in the Gimp and came up with this:
One of the goals of this project was to have a nice finish that was easy to apply and didn’t require a lot of equipment. I opted for tung oil, as I like the look and feel of the oil finish, and it can be applied by hand with good results. As for the new color, we originally chose a deeper blue, but found that it was too dark and didn’t seem to want to stick to the wood. We removed most of that darker blue, leaving traces of it behind for visual interest and tried a much lighter, transparent antique blue. This was a much more pleasing result.
After settling the stain issue, it was time to apply the tung oil. I think we applied 9 coats of tung oil. It really started to get a nice soft shine after about 4-5 coats.
Step 6: Re-Assembly and Upgrades!
So, this was the hard part. Getting all that stuff put in place and working properly is always a challenge for me. I tend to get myself into trouble by not documenting things as I take them apart. I was careful to avoid that mistake this time.
I’m not the best with a soldering iron (working on it, though), but it appears that I got all the connections together correctly. The guitar makes sound and it sounds like a guitar. I consider that a win.
I took this opportunity to do a few upgrades. I wanted to improve a few things. Firstly, this guitar broke a lot of strings. Like a ridiculous amount. Long ago, I suspected that the poor quality nut and bridge saddles contributed to the problem. During disassembly, I happened to break the nut, so I needed to replace it anyway. So, I ordered a Graph Tech Tusq nut and a set of their String Saver saddles.
I also noticed that the tremolo springs ring while playing, so I replaced them with some noiseless springs that are wrapped in plastic of some kind. Lastly, I wanted to install locking tuners, but they are rather expensive. After some digging, I stumbled upon these Wilkinson locking tuners. They’re pretty ingenious, effective, and best of all, inexpensive.
How’s It Sound?
Unsurprisingly, it sounds pretty much the same as before. We didn’t end up changing the pickups yet. But for the curious, here’s what a late ’80s Korean low-cost guitar sounds like
Well, we have a few pickups lying around that we might try out, but honestly, there’s not a lot more we want to change. The one thing I’d love to do is remove the tremolo system and replace it with a fixed bridge. But, due to the nature of the tremolo design, there isn’t a good way to make the conversion.
A very nice retired couple was giving away a Hammond N-222 on Freecycle (I love Freecycle!). So, I asked my friend, Sam, to help me bring it home. We barely managed to wedge it into a Prius V, but eventually got it back to my garage.
After a bit of research, I learned that this model has a built-in Leslie speaker. The organ wasn’t worth much, plus a few of the keys were non-functional. I also learned that over the years, guitarists have used Leslie cabinets to add a tremolo effect to their rig. I thought building a speaker cabinet out of the parts I could salvage from this organ sounded like a fun project.
What I wanted to achieve that differed from similar projects was to retain some of the original character and visual design elements of the organ.
It has taken all my will power to avoid the organ harvesting puns while writing this. As I was taking the organ apart, I got a better idea of which materials from the organ I could use to build the speaker cabinet, including some buttons, knobs and the Hammond nameplate. I was a bit disappointed to discover that much of the organ’s cabinet was made of particleboard. The parts that were either plywood or solid wood were not substantial enough to be used in building the speaker cabinet. At this point it looked like I would need to construct a new box from other materials.
I also discovered a spring reverb unit in the bottom of the cabinet. I had planned to incorporate this into the design, but I decided to keep things simple for this build. So, I’ll do something with the reverb tank in another project.
Once disassembled, I put some of the materials together to get a sense of the aesthetic. I think these elements together really preserve the look of the organ.
I wasn’t sure how to orient the parts in the cabinet, but here’s a first take at what I thought the resulting box might look like. If you can’t see the lighter strokes, I’d intended to have the flat sides of the spinning cylinder face the front and rear of the cabinet.
After some careful measuring and some reflection on how the sound will get out of the box, I changed the orientation of the sound wheel, and therefore the entire enclosure. In my research, I found varying opinions on geometry, construction techniques and preferred materials. I settled on 3/4″ plywood for the structure of the box, as it would result in a really strong box. One of my favorite design tools of late is OpenSCAD. I’ve been using it to visualize a lot of projects, and I thought it’d be useful to get accurate dimensions for this project. I’ve put my OpenSCAD files online if you’d like to take a peek, or use them for your own project.
Lastly, the 8″ speaker that came with the organ was a rather non-descript and blah-sounding affair. I chose to upgrade it with an actual guitar speaker. I found an 8″ Celestion Eight Fifteen (15W) speaker on Amazon warehouse for under $30. It had good reviews, so it seemed like it was worth a try.
I got lucky on the plywood front. My friend, Eddie, had lots of scrap 3/4″ plywood and was generous in letting me use that instead of buying new material. For the covering, I wanted to get tolex that would be similar in color to the wood of the organ. Mojotone Brown Marvel Leather seemed to be the right color, and it happened to be on sale!
I opted for black hardware to match the nameplate, and picked Reliable Hardware cabinet corners. I purchased a set of 3-screw corners for the rear of the cabinet and a set of 2-screw wrap around corners for the front. I decided against using straps, because of the size of the cabinet. I didn’t think adding straps would make lifting and carrying the cabinet any easier than picking it up from the bottom.
Step 1: Checking That the Motors Work
Before ordering parts, I wanted to make sure that I knew how the motor worked and what would be required to switch between speeds. I quickly wired up the motors to make sure they worked and that I understood how to switch between them.
Rather than having a variable speed motor, the system has 2 motors, one for each speed setting. This was unexpected, but led to a simple solution. I thought I would have a separate power switch and Leslie speed control. But my friend, Ben, helped me realize I could do everything I needed to do with a single 3-position switch.
This was my first project that used AC power, and of course, I forgot about a fuse! That was quickly remedied by using a fused AC power connector on the rear panel.
Step 2: Designing the Leslie Control and Power to the Motors
Since I wanted to use the original control button for the Leslie, I had to figure out a way to convert the button’s angular motion into the linear motion of a switch. First, I thought of using a toggle switch underneath the button, but Ben suggested a 3-position sliding switch instead. I figured I could 3-D print the parts I needed to make this work and set to work devising a harness for the switch and original button.
To incorporate the old Hammond buttons, I selected the one marked “Leslie Slow/Fast” to control the motor selection. I went to my local makerspace, thelab.ms, and 3D printed a housing and mechanism to actuate the 3 position switch. The switch cover plate for the button I 3D printed using a wood-impregnated filament that could be sanded and painted to match the cabinet. However, this proved to be too brittle at the dimensions I used, and so I opted to print in black ABS.
Step 3: Building the Cabinet Box.
Eddie cut the boards down to size on a table saw for me. then, I clamped the parts together to make sure the measurements were close enough. Things were really starting to take shape!
With everything test fitted, I decided to try out the sound and see if there was a discernible difference if the back of the cabinet were open or sealed. I preferred the sound of a sealed enclosure. Here’s a video showing the Leslie in action in both slow and fast speeds.
Satisfied with the resultant sound, it was time to put it all together. Eddie recommended doweling the walls of the enclosure for added strength. First, I glued and screwed the Leslie assembly to the bottom panel of the enclosure. Then, I doweled the side panels and glued it all up. Once it was dry, I screwed the top panel into the top of the Leslie assembly. To say the least, it is a solid build!
After constructing the box, I sanded the edges to even them up, then I hit the edges with a 3/8″ roundover bit in my router. The cabinet corner specs indicated a 1/2″ inner diameter, but it looked a bit smaller to me. The 3/8″ bit was a perfect fit.
Step 4: Covering the Cabinet in Tolex
I ordered a single yard length of the tolex, which had a 54″ width. I underestimated a bit, so I decide that the rear panel would be covered in grill cloth instead of tolex. I am happy with how it turned out despite the error in estimation. The hard parts with the tolex were cutting the corners. The How-to video from Reliable Hardware shows mitering the corners, but you have to be careful not to overshoot the corners or the cuts show. Sadly, I missed a few of them.
Step 5: Final Wiring of the Motors and Speaker
The next step was to do the final wiring of the speaker and motors. This was my first time using heat shrink tubing. This stuff is great!
Phase 6: The Finishing Touches
I wasn’t sure how I’d cut down the nameplate, but I had a lot of room for error. The final piece only needed to be about 12″ long, and I had about 36″ of material to work with. My first attempt was to use metal snips. It cut easily, but because the nameplate is c-shaped in cross-section, the snips bent the edges. The metal appears to be aluminum, so I decided to try a cutting wheel on the Dremel. This produced a much better edge, but was hard to steady. I mounted the Dremel on the press stand and elevated the nameplate to the level of the cutting wheel. I was then able to slide the nameplate across the wheel in a smooth fashion. After making the cut, I tried smoothing things out with a grinding bit, but it made the edge uneven. I then tried some medium grit sandpaper, and that worked well.
The Finished Project
Overall, I’m very pleased with the look and sound of this cabinet. I’m really impressed with the Celestion Eight Fifteen speaker. It has a lot of low-end for such a small speaker.
When the cylinder stops spinning, there isn’t a way to make sure the opening points toward the front of the cabinet. I’ve thought through a few ideas, but most are overly complex and require a lot of effort.
Because I wanted to keep the cabinet as compact and as simple as possible, I didn’t design in a way to replace the speaker. If it every blows, I’ll have to rip apart the cabinet.
Slow down when cutting the mitered corners of the tolex
Fill in any surface divots or other irregularities before applying the tolex. There’s a good chance they’ll show through.
Don’t touch bare AC wire connection points when they are plugged in.
I’d like to thank Sam for not blinking when I asked him for help picking up the organ. Big thanks to Eddie for donating the plywood and for cutting the big pieces on his table saw, as well as for suggesting the dowels (and letting me borrow the doweling kit). Finally, I’d like to thank Ben for helping me figure out the electrical bits.
I’ve been working downtown for a few months now. I’m trying to take advantage of that fact and snap photos of interesting/weird/silly things I see here. I’m usually using the craptacular camera in my phone, the horrendously named “KRAZR”. Anyway, here are some shots of things I’ve found recently…
Mamoun’s has the best falafel I’ve ever had. Not that I’m some kind of falafel connoisseur, but I do like falafel, and Mamoun’s delivers. $2.50 for a pita, $5 for a plate. Awesome! This one is on St. Marks between 2nd & 3rd.