Archive for Projects

Jet

As with most of my projects lately, I’m finding that I’m playing catch up with the documentation, so this is an old one.

This project is a bit of a twofer, because it was the demo project for Stretch, my Kicad plugin. Did I say I have a backlog? Stretch was a pandemic project, initially written in March-May of 2020.

Stretch was the product of me being a little bit frustrated with the state of doing PCB art. Or even just a normal PCB that has some weirdness to it. Something more than the standard utilitarian rectangle with silkscreen labels.

Tools to do art existed, as well as tools to create sophisticated PCBs, but nothing really bridged the gap. The idea is that you can work in Inkscape (or Illustrator, or any other vector tool), which works great for drawing images or curvy lines, but lacks any kind of net information, or DRC, or the limited pallet of a PCB tool.

So the workflow is like this:

Users can start by drawing a schematic and laying out a PCB, then bring it into Inkscape to arrange a thousand LEDs into a flower arrangement, then bring it back into KiCad to lay out traces, back into Inkscape to curve the traces, back into KiCad to change their microcontroller and few pin assignments, back into Inkscape to draw out some silkscreen patterns, back into KiCad to run DRC, and so on. The workflow is intended to be seamless and painless to go back and forth.

The important part is not that you should do that, it’s that you can do that. The feedback loop is the point. The loop should be painless.

See the repo here. It still, as of this writing, mostly works, but it will likely choke up on certain fields in the file format and need fixing. Regrettably, after tracking KiCad file format changes for three versions, I’ve had to abandon work on this. It’s a constant moving target that is poorly documented because, to be fair to the KiCad dev team, this is way off-script for how you’re supposed to build KiCad extensions.

If I were to do this more recently, there are now a few projects that parse the KiCad file structure that I could piggyback off of. But at the time, I was one of the first people doing a bunch of “parse an evolving undocumented format” work myself, which is exactly as fun as it sounds.

Even more recently, KiCad 9 has a new (still somewhat work-in-progress) scripting system that seems promising. I have plans for future projects, as soon as certain features get implemented.

So now we get to the project that I built alongside Stretch. I really wanted to polish this off before posting about it, but I have to get it off my plate.

The F-22 is one of the two best looking fighter jets in existence, along with the MiG-29. I wanted to build something out of PCB material, with traces crossing the boundaries of different PCB sections.

 

The F-22 lends itself well to this:

 

 

The MiG-29 has a lot of flowing lines that don’t:

 

Alongside that, I really like flatpack model kits.

 

 

So I built my own, out of FR4 PCBs. The idea with also using an ECAD package was that I could route traces through the object, in 3D, and wind up with circuitry in cool areas.

 

The obvious first thing I did was put LEDs on the wingtips, fed from a battery in the base (which can also act as ballast). Initially I wanted to also add some pulsing circuitry, right on the wings, but this project also blew up a little in terms of time/work, so I kept it simple and just added PCB art. In the same plane-type vein, it would be totally possible to add a (spinning, but not useful) propeller to the front of a biplane, using PCB motors.

Obviously this particular model shown doesn’t have any of the components soldered, or the mousebites filed down.

I started by modelling the pieces and fitting them up in OnShape.

 

 

Then a simple LED and battery schematic was drawn in KiCad, transferred to a PCB, and then using Stretch, brought over to Inkscape, where the outline of each piece was added, exported from OnShape. And then back and forth between KiCad and Inkscape for a bit, drawing nice details, or making sure the LED nets go properly through each of the soldered joints.

(Shown here before mousebites added)

Anyway, it worked! It looks pretty nice. Combining all of the difficulty of designing a flatpack sculpture with all of the difficulty of a nice / functional piece of functional art, while also writing the tooling to make it less painful turned out to be a lot of work. And then building it at the end, too! It tested my patience.

This first version was missing a couple copper pours in the corners with which to solder the joints together.

The first version was manufactured by PCBWay, which is coincidental because I have another project coming up that they helped me with. So they’re not even incentivizing to talk about how great they are, with this one. After sending this in for review, they asked me if they could change some stuff to improve yield, which I reviewed, and even got them to send back their suggested changes on the gerber file.

Fun manufacturing details: Copper etchant likes a roughly even amount of copper on the whole surface. So if you have a PCB that has almost no copper on one half of a layer (ie. everything etched away), and almost entirely copper on the other half of the layer (nothing etched), then the etching process won’t have a happy medium and cause either over- or under-etching in some areas of the board.

PCBWay looked at my files, figured this would be an issue, and here’s the cool part: determined that the corner of my board wasn’t part of the art piece, and filled only that area up with the copper polka dots you see there. Anyway, I was impressed.

For revision 2, I went with a different boardhouse (slightly cheaper) and the quality was actually a bit unacceptable, if I wanted to produce these for anything other than this one-off project. Here’s the R2 model – Check out the terrible soldermask bleed in the cockpit area, and there are some other cosmetic issues.

 

 

Getting the electronics working, or maybe doing something cooler with them, and cleaning up some areas (like mousebites in less obtrusive areas) may be a future project when I pick this up again. Something that could be cool as a model kit.

1 Pound Combat Robot

This post is about three years late, but I’m catching up.

 

Combat robots like Battlebots are seeing something of a revival right now.

The ones on the Battlebots show are 250lbs, and cost tens of thousands of dollars – most of that in batteries.

Much more accessibly, there are a bunch of regional competitions, at a variety of weight classes. 3 and 30 pounds are the most popular, as a trade-off between expense, challenge, and excitement (heavier has more of the latter, at the cost of the first two).

Someone local to me was trying to start a one pound league, so I took the opportunity to build one as a way to dip my toes in.

Unlike my previous hacky RC car, the roadmap for the electronics is a lot better defined.

 

A wedgebot (that is, just a driving platform, no active weapon) consists mostly of these components:

  • Wheels
  • Wheel motors
  • Chassis
  • Power switch
  • ESC
  • Receiver / RX
  • Battery
  • Transmitter / Controller

All of these are easy commodity parts.

I 3D printed the chassis and then the internal frame to hold everything together – PETG for most of it, and then some soft rubbery TPU shockmounts to attach the internal and external components, ideally kinda cushioning the electronics. Similarly the motors are held on with some thin PETG to allow flex to absorb shocks.

 

 

The motors are 800 RPM DC motors. That seemed like a good compromise on speed vs. control with this size of wheel.

The wheels are 45mm rubber/foam wheels.

The ESC is a 5A board, that can take a forward/direction control, and turn it into left/right tank steering. Originally I had an ESC designed in for each motor, but the ones I specced out didn’t work with the tank steering setup. This one nicely controlled both motors, after translating the two data channels into what I needed.

This was critical because my controller is a Spektrum DX3s, which only has forward/back and left/right channels. The controller also came with a compatible receiver.

The battery is a tiny 550mAh thing.

There are two philosophies on power input from the battery. Some people run power from the battery-positive to a pin on a connector, with the rest of the system connected to the connector’s other pin. This allows the whole system to be powered up by plugging in the mating connector with both pins soldered to each other. This is cheap and easy, but it’s pretty common to see the link fly off during fights.

The other solution is a custom power switch that a few industry people sell. It seemed rather expensive for what it is, so I made my own with a copper bolt and copper plate and 3D printed PLA.

 

Anyway, shortly after I finished it, the prospective event organiser of the 1lb league had to skip town, so this has just been lying in a box since then. That’s a pity, it would be fun to smash it up. I would undoubtedly learn a lot.

It’s pretty zippy.

 

Key Storage

I’m on a home improvement kick. When I walking my home, there’s a long, featureless hallway with kitchen at the end of it. I was using a tray on my kitchen counter to toss keys onto when I walked in the door. This takes up valuable kitchen counterspace, and being at the end of the hallway, was not ideal.

 

I designed up a wall-mounted tray that looked kinda nice. Then I CNCed it out of a scrap chunk of pine. I did a bad job estimating the size, so it turned out way too small and not really usable.

 

Instead of just recreating it, but larger, I an additional feature to hold cards would be useful. Additionally, the CNCed wood required some hand sanding that I didn’t really want to deal with again, not to mention the CNC setup time.

None of that was particularly time consuming or difficult, but honestly, it was faster and less tedious to 3D print it and cast it in cement than to break out the CNC again.

With the larger size, I wasn’t so sure about just slotting it into a piece of plywood without supports, so I added a steel cable. It’s a nice design accent regardless.

Note the knotted up steel cable in the mould. I also used XTC-3D, a resin coating designed to smooth out 3D prints. It was expired and a little chunky, but still seemed to work well. I’d use it again. The resulting cement form was smooth and required no post-

processing.

I also designed a tensioning mechanism for the cable. There’s a captive screw that drags a nut up and down. The nut assembly holds the cable end. The whole assembly slides into a 3/8″ drill hole. At the top of the assembly, there is a hole that is sized just right for a screwdriver to come in and engage the screw, dragging the nut assembly closer, tightening the cable tension.

 

For the backing, I made a drill jig to be able to drill straight down the 3/4″ plywood without breaking through either side. The steel cable goes in, and then I attached it to the tensioning mechanism with a combination of melting the plastic to it, and some CA glue for good measure. The whole assembly then also got glued into the drill hole.

After all of that was set up, I used plumber’s putty epoxy to fill in all of the gaps between the tray and the plywood, and bolted it to the wall!

 

This project went just about as smoothly as possible, probably about 6 hours all told.

The Worst RC Car in the World

Quite some time ago now, I wanted to make some of remote control car. And, also, eventually turn it into an autonomous sumobot or similar.

This project was done a few years ago, but I’m writing it up now.

In the interest of getting something into my hands that I can iterate on, I did it as quickly as possible.

Yes, that is a structural q-tip. The cardboard was collapsing.

This crappiness is actually a feature – because I introduced this as a workshop to a bunch of people. Mostly beginners, with minimal exposure to electronics or microcontrollers.

Operation is simple. You program it in with your WiFi credentials, then when you turn it on, it creates a webpage that is just a joystick. That controls the car. It’s surprisingly satisfying.

The repo is here. It includes materials and code.

Everything in this sort of direction in the future will be a little bit more complicated or interesting, I just wanted to break the seal.

The fun in this project is quickly and cheaply building something simple, that can be controlled easily. No part of this is too hard to understand, and therefore, improve.

So with that in mind, I ran a few workshops to get other people started.

As a fun detour, I took the opportunity to play around with a vacuformer.

I modified a VW beetle model to remove the front fenders to better fit the single castor front wheel, then 3D printed the buck.

This is in parallel with designing an internal frame to hold all of the components together. For personal stuff, I usually use OnShape for my CAD, lately. The free version forces designs to be open source / publicly searchable, which is pretty great when banging together AliExpress modules. And also for the base VW model to modify into a tricycle.

Rock Planters Rock

I’ve been wanting to play around with concrete for a while, as a project material. I’m not sure what the end goal will be, but once I’m familiar with the material, I’ll be able to shoehorn it into other projects in unexpected ways.

Concrete (actually cement, as I don’t intend to add aggregate) is different from other casting materials like silicone or resin in the cost/quantity proposition. Silicones are quite expensive, often purchased in 1L volumes or so, while cement has the opposite problem. It’s cheap, but I’m stuck buying 40 pound bags of the stuff.

Initially, I found some geometric molds off the internet and started with that, along with a convenience store drink cup.

It was easy and worked quite well.

 

I used RapidSet cement. The box is blue. There are many different kinds, and apparently this is one of the lightest in colour, while being a little smoother than most.

To make these into decent planters, there are also two additional steps: soak it to get all the lye out, and then seal it so it doesn’t shed cement dust all over.

 

The sealant foams up all strangely. It’s a granite countertop sealer.

 

This was all just practice, so that I would have a feel for how it works before I put a ton of time into something cooler.

I wanted to cast a mountain range (or two!). I really like mountains.

I started with Mount Currie – A distinctive skyline feature near a town called Pemberton. Also as a learning exercise with Blender; I’d never used it before.

Here’s the view from a place I stay at sometimes:

 

I grabbed the geodata with TouchTerrain. Here are my settings:

 

Then in Blender, I set up the camera in the same-ish position and focal length of my camera.

 

Yeah, I’m very satisfied with that.

 

Next step, make the renderer export a depth map instead.

 

Then map it around a cylinder as another displacement map. The nice thing about this is that the Blender portion of the work, which I’m not very comfortable with, is done. So I’ve got it set up just right, and I don’t have to touch it – The rest of the fiddling on this model is with 2D depth maps in Krita, an open source Photoshop facsimile.

I faked the sides of the mountain range a bit, because they don’t just drop off to nothing.

 

When I got it how I liked, I 3D printed it to get a feel for how it looks in the real world. A few back-and-forths with that, and I built a mould around the positive model in Blender.

 

Each piece took about 24 hours to print. This is surplus PLA that will never otherwise get used so the volume of plastic used is totally okay, and the size (and therefore weight) of the cement involved is a concern for a mould that would be more plastic efficient and less beefy.

And then I poured.

The thermal camera shows how hot it gets as the cement starts to kick. It got past 60 by the time I left it for the night.

I actually did it twice. The first one I didn’t mix up enough, so ended up scrambling to mix more, which didn’t fill in the mould completely. Honestly, I kinda like it.

 

For the second attempt, the mould had warped enough that the seam lines were very visible. After the second pour, the mould had warped enough that it wasn’t viable to pour a third time. This is a really interesting datapoint. It’s possible that PETG or some other higher temperature material would fare better. And this issue doesn’t crop up in the smaller castings I did. The cement only gets hot enough to deform the plastic when there’s a large volume curing at once.

 

 

But regardless. The result!

It’s decent. I’m about 80% happy with it. It’s recognisable as the target mountain range, but it’s not instantly identifiable. This is done as the actual aspect ratio of the mountains, with the focal length of the (cellphone) camera I took of the mountains, and it looks a little too shallow. Perhaps the aspect ratio would be a good knob to turn for future experiments, to get the mountains in the casting to look a little taller.

Force-Directed Circuit Board Footprint Autoplacement

From Wikipedia:

Force-directed graph drawing algorithms are a class of algorithms for drawing graphs in an aesthetically-pleasing way. Their purpose is to position the nodes of a graph in two-dimensional or three-dimensional space so that all the edges are of more or less equal length and there are as few crossing edges as possible, by assigning forces among the set of edges and the set of nodes, based on their relative positions, and then using these forces either to simulate the motion of the edges and nodes or to minimize their energy.

Force-directed graphs are a common way to display things like mind-maps. It’s a good way of spreading out the whole collection, while grouping related items together, and minimizing the path length between the closely related items. In my mind, this has a lot of similarities with how PCBs are laid out.

Well, there’s only one way to prove that theory.

KiCad Footprints animated in an exploding fashion

Using KiCad PCB parsing code I wrote for another project, I was quickly able to grab the nets and footprints out of a KiCad project. Displaying the nets and allowing specific ones to be turned off was a feature I identified as critical early on, because the ground or power nets would overwhelm any of the others, rendering the important nets useless.

Truthfully, a significant part of this was wrangling TKInter to build the Python GUI that I wanted. It was a success, but I’ve never used it before, and I am not a fantastic UI designer.

Under the hood, the system essentially treats each of the nets as a spring, and applies a simplified version of Hooke’s Law to each connection. Each of the centre point of the footprints acts as a charged particle, and a simplified version of Coulomb’s Law acts upon it to repulse all of the other footprints. These algorithms are a pretty typical way to do this, by essentially setting up a physics simulation. One tweak on this strategy that is unusual, is that the nets don’t act on the footprint origin. They act on the pad itself, which allows a torque to impart a rotation on the footprint.

I’ve gotten this project as far as “fun tech demo”, and it’ll likely fall dormant for a while in this state. At some point, I will build an appropriate PCB using this technology, because I love making unusual designs that are electrically fine.

The repo is here. Have at it.

Brass Lamp

I haven’t properly built anything with my hands in a while, so it’s time.

 

I mocked up a few lamp ideas, and this one seemed fun. Really, really rough mock-ups.

 

That was neat looking, so I fleshed out the hinge section, which I expected would be the hardest part to figure out and build.

 

 

 

 

First, I 3D printed the hinge, just to get a feel for if my sizes felt right – I am bad at judging size in CAD, things often turn out way larger or way smaller than I expect, and therefore really difficult to build.

 

These looked fine, though.

 

I picked up a ton of brass from a hobby shop. Can you guess what the main focus of the hobby shop is?

 

 

For the hinge pieces, I didn’t have the right shapes or size of brass stock available, so I needed to cut a bunch of smaller pieces and then braze them together with silver solder. And then took them to the belt grinder.

 

Pretty close!

 

And then tried to add one more piece, dropped it while the solder was molten, and had them splatter apart on the ground.

 

 

Okay one more time.

 

 

It’s always better the second time, anyway. I used an M1.5 brass screw as the hinge pin.

 

For the stand, I 3D printed some saw guides so that I could get the tube angles perfect. The stand wouldn’t end up with the right geometry unless the cut angles were just right.

 

Then, after brazing:

 

 

It matches up with my CAD perfectly, I’m stoked.

 

Some blu-tak was used to hold the hinge pieces and light backing together to get a sense of how it was all going to go together.

 

 

The light panel itself was a circle of aluminum that I spraypainted black. Then I riveted the hinge on and laid out my LED tape.

 

 

Wiring.

This could have been done much neater. Next time.

Encircling the LED panel, I bent some flat bar aluminum, riveted it, glued it, and painted it. Then glued on a plastic diffusion circle. This was all done quickly, so I didn’t take many pictures.

 

For the base, some nice dark wood would be ideal, but that would have required a fair amount of material acquisition and hunting down tools I wasn’t up for, for this project. So I took my base, and split it up into easily printable chunks.

I was going to attach them together, sand, patch, sand, and paint them to turn them back into one object, but I kinda liked the jigsaw effect, so I left it. PETG sands really well, and I treated it with a light oil coating to keep it from taking on fingerprints.

The pieces are just bolted together, and mostly hollow to allow mounting of the electronics.

For the controller, I have a surplus prototype lighting controller of dubious origin, and wrote some firmware to handle fading and mixing the two LED channels. The 24V power supply comes from AliExpress.

Similarly, for the knobs, I went for an easy and quick solution using 3D printing for the ends to retain a little bit of the brass tube onto the potentiometers. The left knob controls the light intensity, and the right knob controls the light’s colour temperature. This lamp can fade in between a really cool white and a really warm light.

Running the wires through the brass tube was a fun adventure. What I ended up doing was fill the tube up with oil, run a single wire up through the bottom, then solder it onto the other three wires. After that, I could use the first wire to pull the whole mess back through the tube. Then I flushed the tube with alcohol to clean it all out.

And, final wiring, and it works! It looks great. I can see all the small defects, but that’s okay. I’ll do better on the next one.

Watching Plants Grow

 

I’ve been into timelapse photograpy for a long time, often focused on driving the cost down by hacking existing digital cameras.

That follow up post (already written almost two years after the original work) promised project pictures that were never delivered, so here, I went spelunking in some nearly decade-old backups for them.

 

 

Recently, I came across the ESP32-Cam, which basically hits all of the cost/hardware requirements I was aiming for, nearly a decade ago.

It uses an Espressif ESP32, which I’m very familiar/comfortable with, and is about $6. The camera sensor is 2MP, which is small for images, but fine for video.

There are a lot of timelapse projects out there using this board, but none of them really have the features I’m looking for. Espressif even has an official “webcam” codebase that others have packaged up into cool projects. But here are my requirements:

  • A web interface to control capture / timing parameters
  • Serving up images over the web interface to check that those parameters are good
  • Saving images to SD card
  • Nonvolatile storage of the parameters, along with the current snapshot number, in order to gracefully recover from power failure
  • SD card images available to download over the web interface
  • Over-the-air updating
  • Reasonably well-laid out codebase that’s easy to hack on

Essentially, I want to be able to plug this into a hard-to-reach closet and not have to ever physically touch it again. Lots of projects have a subset of these features, but nothing has hit it all, that I have seen.

One of the other ideas I had to improve upon the typical timelapse design was to get the ESP32 periodically grabbing the real-world time from NTP servers. It’s set to run every half an hour, which is probably too often to make a difference that overcome the latency from hitting the NTP server. Regardless, it should keep average timelapse interval perfect over a long period of time.

So I hacked something together. Originally I used PlatformIO with the Arduino framework, because it’s quicker to get a project off the ground than the official Espressif ESP-IDF. The branch is still there, but I abandoned it after running into issues with partitioning, OTA updating, and the additional PSRAM hardware all working together. The main branch uses the ESP-IDF now.

It’s essentially a webserver that controls the camera. You can open up a page and modify settings, including timelapse intervals:

 

You can also get existing parameters:

 

And snap takes a one-off photo to check your setup without touching anything. That made this super easy to tweak with one hand, while holding a laptop with the other.

When a sequence is done, it’s easiest to grab the SD card and plug it into a computer to copy over the files. For longer sequences, maybe to check progress, it is totally possible to grab the images over the web interface. Just slow.

To stitch together all the images, initially I used this command:

ffmpeg -r 30 -start_number 1 -i %06d.jpg -vcodec mpeg4 -vf "transpose=1" -y movie.mp4

That results in a pixelated and honestly pretty crummy output. It’s fast, though.

This got much better results:

ffmpeg -start_number 1 -r:v "480/1" -i %06d.jpg -pix_fmt yuv420p -c:v libx264 -preset slow -vf "transpose=1" -y -f mp4 movie.mp4

ffmpeg is a little inscrutable, so the parameters that require tweaking warrant an explanation. Order matters, too – Some of the parameters affect the input, some affect the output, depending on position.

-r:v is the input frame rate, relative to the base (25 FPS) framerate. So a 250 frame video with -r:v 25/1 would be 10 seconds, while setting it to -r:v 50/1 would result in a 5 second video.

The -vf transpose option rotates the video. The ESP32-Cam’s camera is mounted sideways, but that’s a minor irritation.

To mount the device, tripods are the obvious choice. I created a quick, minimalist enclosure that allows access to the GPIO pins, SD card, reset button, and fits a 1/4″-20 nut that is compatible with most tripods. A Gorillapod, in my case.

 

For the video posted at the top of the page, here is the setup:

 

It was done with a picture taken every 40 seconds, 8 second exposure, low gain and brightness.

ffmpeg -start_number 1 -r:v "120/1" -i %06d.jpg -c:v libx264 -preset slow -vf "transpose=1" -y -t 00:00:08 -f mp4 movie.mp4

 

The -t option sets the end-time, there was a lot of “content plant” at the end that wasn’t moving much.

Future goals might include shoving the whole mess into a closet, along with timed control of the lights and a watering pump, and leaving it for a month.

POV Globe – Electronics

 

This is a fairly old project that I just wanted to document to current-state and provide a conclusion. See here for the old logs.

Some of the original design goals for this project were ease of design, and manufacturabilty. Ideally, the design would be clean and turnkey enough for me to be able to at least sell the populated PCB as part of a kit. I also didn’t want to spend a lot of time doing anything cutting edge enough to turn into a time consuming side project, as some of my designs are wont to do.

So here is where I started.

The board is 7cm in diameter with 0805 side-mount LEDs all around the perimeter, green on one side, blue on the other. The LEDs were too easy to see individually (right), so I used hot glue to create a diffusion layer (left).

In the centre, I decided to go the easy route and make the board battery powered. The cutout can hold three LR44 batteries in series.

After some hemming and hawing about how to mount them exactly, I found an acrylic tube with a 12mm ID (just barely larger than the batteries), cut a slope into one side so that it can be inserted into the slot and then rotated to lock in. On the PCB, there is battery spring on one side, and some copper braid on the other to hold the batteries tight and make electrical contact. This solution works better than it has any right to, it is fantastic but blows my “manufacturable” requirement right out of the water.

For driving my LEDs – twenty per semicircle – I used a TLC5947. It’s a constant current, 24 channel PWM LED driver, controlled over SPI(a requirement for speed). There are two of them, and they seemed to work well, with one caveat that I’ll get into in a bit.

There is an interesting power section that I never ended up populating. The goal with it was to have a switch mode power supply attempting to boost the battery voltage to 4 or 4.5v from whatever voltage the batteries sag to. The idea being that with fresh batteries, it wouldn’t be doing much of anything, but as the battery runs down (internal resistance gets higher), the power stage attempts to pull more and more current to keep the output rail steady. The circuit ended up working fine with all of that jumpered over and direct from the battery, but it was an option in case that hadn’t turned out.

I also had a clever system on there to ensure proper polarity to my circuit regardless of how the batteries were hooked up, but again, didn’t matter enough for this version to use.

The TLC5947 has an SPI output pin to allow chaining multiple chips together, but naturally, it would halve the refresh rate I’d be able to get. I ran a trace between the two chips, just in case, but I was also able to avoid using that. The dual effective SPI ports I managed to get working(written about in a previous log) saved me from that.

Early tests were promising – I quickly got a recognisable image of the world showing.

Introducing blue turned it into an unrecognizable mess, though. All further testing stuck to green, for now. The problem is that my hot glue light diffusion is too good, and allows light to be directed back through the sphere. Some sort of baffle on the inner side of the LEDs is needed.

An additional problem that I hinted at in the last logs is that my vertical resolution isn’t really high enough. The world map is recognisable, if you know what you’re looking for, but it isn’t fantastic.

And the final problem, the real deal killer: the TLC5947 blanks its output before displaying the next value. That is, a channel displaying 255 (full on) when a new value is sent to it, even if the new value is the same. It will go 255->0->255. That’s why you can see vertical gaps in all the images I’ve posted. This is mentioned nowhere in the documentation, and is just poor design. So future version will have to rethink this portion, too.

 

For the mechanicals, due to an unfortunate move, the old system got a little bit damaged and I 3D printed a replacement. This one also uses a direct drive brushless DC motor instead of the old brushed motor and DC motor. Again, just for fewer components and faster to put together.

 

It worked well, other than some harmonics causing a lot of vibrations on some narrow bands of frequency. Future versions would also have a proper magnet holder, my hand is not a permanent solution.

A Matter of Time

I’m on another clock kick. More of a wristwatch this time.

The dream is to have a couple metal bars floating in oil, and when a button is pressed, they float to the appropriate hour and minute positions.

For an initial version, I’m paring this way down to just a single indicator hand.

On the mechanical side, I start with some preliminary sketches.

There were many more, with very little polish in any of them. They’re just to get the mechanicals down and direct the overall thrust of the design.

Watch crystals are quite inexpensive from China, so I picked up a selection of sizes, and while waiting for shipping, I modeled and 3D printed some tests for the three most likely candidates. Shown here are cases I designed for sizes 30mm, 34mm, and 38mm faceplates, but you really can’t tell that they’re different sizes in pictures. The 38mm one seemed to fit best on my wrist, so that’s what I went with.

Rolling my sketches into the CAD, I came up with this:

The main body is just a shell with internal threads, and inside there’s a stack-up consisting of:

  • 1.2mm crystal face
  • 37mm OD x 1.5mm o-ring
  • Double sided o-ring retainer
  • Another o-ring
  • 15x3x1mm neodymium magnet
  • Faceplate PCB
  • Control PCB
  • Coin cell battery
  • Threaded cap

Dimensionally, it’s a very tight system. It doesn’t really fit with the battery, so stuff will have to be moved around. The o-rings are there to seal in the oil, which is kinda fun.

Jumping to the electrical side, I need some electromagnets.

A guy named Carl Bugeja has designed coils drawn out in PCB traces to make a PCB motor. He shows off the design a lot here.

Included, naturally, are a set of gerbers which were worth ordering to play around with.

I tossed a magnet on there and was able make it jump around the coils using a small bench power supply. The resistance at each phase was about 12 ohm, the same value that Carl Bugeja measured. Each phase does go through three entire coils, however, so assume 4 ohms per coil.

The coil pattern is illustrated quite well with Carl’s coloured gerber export:

Application of the right hand rule shows that as current goes in a clockwise spiral direction (curl your right-hand fingers in that direction), your thumb will point in the direction of the magnetic field, out of the screen. Interestingly, the ordering of the coils on the layers isn’t from top to bottom. Carl ordered it from layer 1(top)->layer 3->layer 2->layer 4(bottom). Probably to (very very slightly) increase the length of the current path and therefore the resistance of the coil.

To drive a coil with any polarity we like, we need a standard H-bridge circuit. A future version might do some interesting stuff with that, so the fine control that an H-bridge provides is kinda cool. Generally an H-bridge consists of a couple matched pairs of transistors of opposite substrate. Poking around, there’s a single chip MOSFET solution that looks suitable, the VT6M1.

So here’s a quick PCB layout of how that would work:

But of course, just dropping that into a board is boring! We’re going to make a pretty PCB, we might as well go all the way! I’ve spoken before about PCBModE. Using my tool to convert the above PCB into a compatible format, I pull it into PCBModE, cleaned it up, added some electromagnetic spirals, and a little bit of flair. There are solder pads to hook this PCB up to another PCB, containing all the brains.

Figuring out a compact way to drive all those connections is somewhat challenging. With six coils around the perimeter and one in the centre, a “drive high” and “drive low” connection for each side, there are 28 signals, plus power and ground. All of those need to be transferred out to a “controller” PCB, so I added those green teardrop solder pads. The idea being that pins are to be soldered onto them, and then pushed into through-holes on the controller PCB.

For the controller, after all of the through-holes that connect to the above-mentioned solder pads are placed, space is very tight! Investigation of various shift registers and their sizing yields no encouraging results. NXP has a cool line of miniature 74HC series logic, but even those don’t fit in my given space.

Fortunately, there is a nice STM32 part I was able to squeeze in.

Despite actually being designed in ECAD software, I think it turned out quite beautiful in its own way.

Some first revision woes:

In retrospect, this was a terrible way to design the electronics. By putting the MOSFETs on the faceplate PCB, I maximised connections needing to cross to the other PCB, and minimised space on the controller by filling it up with through-holes. By crossing with the coil connections directly, I would have needed only two wires per coil, instead of the six that the H-bridge is requiring (plus grounds).

An unregulated coin cell is just about the worst possible power supply for a miniature, portable, long-running device that can’t be opened easily, and leaks oil when it does get opened.

Additionally, I was rushed to get PCBs out and forgot to add a button to activate the watch face.

Next version, with more time, will include improvements for all of the above, as well as a proper external RTC, and LiPo battery circuitry.

Jumping back into the mechanical side:

Everything was 3D printed to test fit. Surprisingly enough, threads worked pretty well. There was a ton of stringing in the internal threads, though.

Initially, I was using a knife to clean those up, but that got old quick. Additionally, oozing from the print of the outer threads made it a little tough to mate for the first few cycles. So I printed a tap. You can see the taper on the leading threads, and the notch to clear out the chips.

That worked great! Passing it through the system a couple times made the threads work easily.

Here all the non-electrical components:

 

 

Here is the faceplate PCB:

 

And, assembled:

Testing the coils directly with a benchtop power supply once again made the magnets jump around.

And then adding the H bridge transistors and testing with a low current signal to control the direction of the magnetic field.

Status: super cool. Listen to that click!

For prototyping, everything is 3D printed. The goal would to mill it all out of aluminum and then anodise it dark blue.

The o-ring holder needs to be lathed or otherwise made out of a solid material, too. 3D printed parts are going to have a bad time if I try to use them to seal an oil filled cavity with porous plastic.

 

I got the endorphin hit I needed out of this for now, though – Some interesting concepts have been demonstrated, and perhaps I’ll come back to it another day to add polish.