Art Project Completion: Lighted Up Birch Books

The first Birch Books scene

I started talking about my quarantine (or, well, lockdown) art project at the end of March, with a plan. I did manage to (mostly) complete it by the end of April, while the lockdown (and my sabbatical) are still in full swing.

I have shared some work in progress pictures over on Twitter, including a 2-minutes video (shot on my phone by hand, so not very high-quality) showing the full set of scenes (before the latest “firmware revision”). As you can see from all those pictures, the cables are still pretty much in the way and very visible. That’s not something I have addressed yet, but I’m waiting for the PCBs to arrive before doing that.

At the end, the result is that throughout the building there are 12 bright white LEDs, connected via Dupont connectors to a harness that then goes into the breadboard — that’s so that the harness can disappear the moment I have the PCBs.

For the PCBs, I think I made a rookie mistake. I ordered them from PCBWay (affiliate link), as I heard good about them on the tubes, and they seemed to have a good price point even for assembly of the SMD versions. That was not the mistake. The mistake was to send a single order with both the SMT and the through-hole PCBs, to save on shipping. I’m now having to wait until the end of this month to receive the boards, and hope I didn’t make any more mistakes on them.

I’m also sure that there will be changes I’ll need to make. These are literally the first printed circuit boards that I design, and beside obvious stylistic mistakes (such as not marking the value of components), I’m sure there’s more mistakes than that. So I expect I’ll have to update the designs later on. Hopefully it won’t get a mess of bodge wires when I try to use it properly.

I think it might be dinner time.

I have to figure out how to fit all of this into a box, eventually. Probably a Lego box of some kind. And I’ll probably have to make sure that the USB plug is fit properly. Soldering a microUSB connector on a PCB is… not easy and not something I’m looking forward to. That’s why I added a 5-pin header on the design, so I can use one of the cheap breakout boards you can find all over on AliExpress or eBay.

The 8051 based firmware is available on the same GitHub repository, and it includes a full 16-scenes (although not unique scene) schedule that now runs in about one minute.

I also changed the “boot test” mode in the second “firmware revision”: instead of trying to turn on each LED one by one, it turns on each room one by one. The reason why I did that, is that I have hooked up multiple Darlington gates through a joint to provide more current for a couple of rooms that have three LEDs on the same room. This might have been a bit of a mistake and I should probably rewire those rooms to just use multiple LEDs, but that’s not going to happen any day now.

Also, with a bit of a hindsight, I should probably have just left the current-limiting resistors off the actuator board altogether. While the resistor networks are great to simplify the design, I could have just as easily soldered the resistors inline on the cable and wrapped them with heatshrink. I know because I did exactly that on another Lego set, when I realised that powering it directly from a 5V supply was significantly overheating one of the two LEDs.

This is, by the way, another “trick” learnt while watching bigclive on YouTube. Probably not something that would be worth a complete video on, and maybe something that felt fairly natural and not required to explain to him but… something I’m very happy to have learnt. Which is why I love rambling on about small choices in my thought process, as it’s very possible that something that is natural and obvious to me, is not for someone else reading me. And why I do welcome comments asking for clarification on points I may be glossing over.

Also, both my wife and my mother have been pushing me to figure out what the next Lego model I will be adding lights to is going to be. I don’t honestly know, right now. But I guess the lessons learnt with this model should allow me to step up to something a bit more complicated next time. For sure, it would be a cheaper and easier job, since I procured a lot of tools for it anyway.

I think that the things I will consider changing for next time are not just the place the current-limiting resistors are connected (which I can probably retro-fit on the current PCBs), but also the type of wiring I use for the LEDs. I used equipment wire for this build, and it turns out to be fairly stiff and unwieldy. If I were to re-do this, or do it to another model, I would probably use the equipment wire only within the rooms themselves (that way I can push it out of the way), and then solder it just outside the model with a stranded, softer wire.

I think this will probably be the end of the regularly scheduled updates on my art project, at least until the PCBs arrive. I did intend to draw some documentation with a tool like Fritzing, which is used by Adafruit for their documentation, but I’m having quite a few headaches even figuring out how to set it up. None of the components I need are part of their parts libraries, and the documentation is out of date regarding the parts editor, so don’t hold your breath.

Birch Books Controller and Actuation Boards

Now that I’m free from my previous employer’s open source releasing processes, I’ve finally decided to put ideas to the computer and figure out how to actually build the controller board, and its firmware. It does help that I’m still missing the crimping tool to add connectors to the LEDs so I can test them, and that I had to think things through a bit more before ordering chips.

First, I needed to figure out what interactions I would get. As I said in the previous post, the plan is to have a single pin pair per driven LED, even when LEDs would always switched on and off together. It just makes the layout much cleaner, particularly as then there’s no need to encode knowledge of the final layout into the electronics. The final count of LEDs I’m looking at is 13, and as I’m going to use two Darlington arrays (ULN2003), I rounded that up to 14. And just to have some extra, I decided to add a straight +5V pin on the final connector, just in case I decide to do something else with it later.

As the target micro (STC89C32/AT89S52 and similar chips) comes with four 8-bit ports, this means that using two ports only, I can add an additional two inputs, which fits with my needs: a button to toggle turning on all the LEDs at once (useful to take detailed photos), and one to “fast forward” — so that instead of waiting for X minutes to change scene, it would wait X/Y (numbers and timing still to be defined).

Choosing the ports turned out to be a bit more complicated than I would have expected. The reason for that is that I also wanted to keep track of how to flash the micros. While I do have a “programmer” board (which is actually an overall test board) for the STC micros, I wasn’t sure how it would look like once completed, and didn’t really feel like unsocketing the chip every time I wanted to make a change.

According to the two datasheets (STC89Cxx, AT89S52), both chips include “In-System Programming”, but they do it quite differently. The STC uses the UART (serial) line that is standard on the 8051 chips and forms part of P3. This is what stcgal uses to program the chips, and I have tested that it works with any serial adapter connected to the right pins. The Microchip version uses I²C instead, using the three upper lines of P1.

This means that, to keep the board as simple as I can, without using the same pin for two functions, I’m better off using the P0 and P2 ports — these are used for address and data busses, when using external memory with the 8051, but that’s not something I need, so they are easily dedicated to drive the I/O of the controller board. Annoyingly, in the 40-DIP version of the 8051 and compatible chips, P0 and P2 are, yes, on the same side of the chip, but also “bookended”: pin 32 is P0.7 (highest bit of P0), and pin 28 is P2.7, which means that to keep the outputs linear you either need to reverse them in software, or in hardware. I went for hardware, since EAGLE’s Autorouter can do that faster than I can do it in software.

I also got bitten by a quirk of the 8051: P0 is the only port that needs pull-up resistors! The I/O lines on P0 are tristate (On, Off, NC) and floating by default. I didn’t notice that before because obviously the devboard I’ve been using has them already. Thankfully, before ordering anything I wanted to try the whole set of components on a breadboard (pictured right), and found that out pretty quickly. There was a hint of this in the heart-shaped circuit I keep going back to: the LEDs on that board are all wired with common-anode, which effectively turn their resistor into the pull-up. I totally missed it, but I was in time to fix the board, and to order some resistor networks so that I don’t have to end up soldering 16 extra legs, but just 9.

Now as I was preparing this I also figured out that, if I do provide the ISP connectors for both AT and STC chips on the board itself (and at least it appears that the STC programming works the same way for other chips, including the STC12C5A60S2), I don’t need to limit myself to DIP chips — I can use a socket PLCC, or a surface-mount LQFP, and just program it on the board. So I tried to figure out how different would an SMD board would be — and realised that there’s effectively two parts to the board as I had been picturing it it in my mind: the controller, with the microUSB plug, the micro and its paraphernalia (crystal, RC net, etc.), and the ISP headers — and the actuator, which receive the signals to turn on and off the LEDs, and sends the button presses, and then translate those in the actual powering up via the Darlington arrays.

So what I ended up doing was designing two separate boards, connected with a straight 1×20 pin header, carrying the 16 I/O signals, and a few extras. In addition to the +5V and the ground, it carries an RST signal (which can be either consider the 17th I/O, or just wired straight into the micro’s reset line, like I did), allowing the whole board to be reset, without having to powercycle it, and it also carries a Vcc line.

Why the extra Vcc line? Well, as I’ll explain in a post next week (hopefully with more positive information rather than just the rant it would be now), I’ve been considering alternative MCUs as well, for the controller. Not least because the 8051 is a very strange thing to program. One of the chips I was considering was the ESP32, which is fairly cheap and easy to find in the market, since nearly anything “IoT” is using it, as it supports WiFi and Bluetooth out of the box, and can be used as a “co processor” as well. It turns out to have enough GPIO pins to not require a multiplexer, but it also uses 3.3V CMOS levels rather than the 5V TTL levels that I’ve been thinking in, for the 8051 version. And for that reason, I need to distinguish, in the actuation board, the supply used to power the LEDs on, and the logical High for the inputs.

This exercise was useful to also figure out that I was completely wrong in the board files I pushed originally! I had not paid enough attention to the ULN2003, and assumed it was a standard PNP transistor, but Darlingon arrays are NPN transistors. So LEDs will have to share the supply cable, and use multiple ground connections going through the Darlington. Again, this would lead to a common-anode design.

So now the boards are in the repository, even though they are probably terrible. There’s some basic documentation as well explaining the pin connections. There are two versions of the actuator board, one using SMD components and one using through-hole (PTH) — the reason is that I’m likely going to buy the prints from PCBWay (note: affiliate link, just in case), and they can manufacture the SMD version fully — but it will take 40 to 50 days. So I’m planning on having that manufactured for later, but in the meantime I wanted something I could prototype on — so the through-hole came later, as you can tell by the fact I realised I could put resistor networks between supply and anode, rather than between cathode and Darlington.

Once the designs are finalized and proven, in addition to having the EAGLE files out there, I will probably make the boards available for purchase on PCBWay’s Share&Sell — and any other sensible platform for that, if anyone is interested. I don’t really care for any revenue out of it, but I guess it would be the easiest way to make them available to the public at large.

Birch Books: Access Points

I already introduced my quarantine art project, and as I promised here comes the second blog post on the topic, just to keep my own running notes around.

First of all, I decided to at least (partially) follow the advice from Adam Savage in his biography, about making lists and planning carefully. Indeed, I decided to write on paper as much running notes as I could and I could make sense, particularly since, as I said in the previous post, I’m not really at ease with electronics and I’m just lost at most of the things that are needed for this project, truth be told. So shout out to my friend Srdjan for helping me keep an eye on the things that are required!

My picture trying to figure out where to access the model to get wires through.

One of the things I clearly needed to solve was the access point for the wires themselves. The cable I have at home (without me going and buying more) is “equipment wire” (I got this a couple of years back because it’s single-core and made my protyping on the breadboard easier), and it is 0.6mm in diameter. I’m sure I can probably look for thinner wire, like wire-wrapping wire, and it’ll be perfectly fine to run 5V/50mA. But unless I deem it’s going to be impossible to keep hidden the wire I already have, I don’t think I’ll be buying more wire just yet.

Because of the nature of the model, the easiest way to modify the set without it being too noticeable it’s on the sides — Birch Books is designed to fit together with other Creator kits, and can be connected together through the base. Indeed, the kit itself is composed of two buildings that are connected at the base, and otherwise perfectly independent. This would be a problem if I decided to buy more sets of Creators, but then again, let’s cross this when it comes.

I also want to make sure that I don’t have to modify the pieces coming from the original kit. While I’m sure all of those are replaceable, it’s easier to keep them aside, and modify other pieces. I bought myself a box of assorted bricks, and I was lucky to find a few pieces that were already the right colour and shape for what I need.

I have then started dividing the set into rooms, and then for each rooms figured out how many LEDs I want (and where) and how many independent control lines I want. My current design involves bringing either one or two wires in each room: where multiple LEDs are needed in a room, I can connect them in parallel, and where a room has multiple control lines, I can share the ground connection between them.

There’s another question that I needed answering and that would be what the interface between microcontroller and the LEDs would be. I settled for simple pin headers, similar to motherboard front-panel connections, and using Dupont connectors. I’m still uncertain on whether to follow the motherboard option of using pins on the board, and female headers on the LEDs, or go the more theoretical approach of using female headers on the side with actual power going through.

Awesome video by bigclive on crimping tools.

Also as an aside. If you ever decide, like me, to start crimping your own Dupont style connectors, don’t just get the first random crimping tool that Amazon Prime will deliver to you, like I did. Watch the awesome video by bigclive, and go for a better tool. I have been fighting with the one I bought for a whole day, until I watched the video, and the one I’ve been trying to use was one of those he dismissed immediately without even going into details for. I ordered the same IWISS he was using at the end. Your mileage may vary, but it’s worth considering that.

I’m still not sure what the final controller board will look like, but to make things easier for myself, my current design assumes that there’s going to be a single pin pair per LED, connected to a 47Ω resistor. This means that even for rooms with a single control line and three LEDs, I would end up crimping them into a 3×2 connector, wiring the three VCC lines together — as long as the GPIO lines are kept at the same state, this should mean that the current is provided and limited in the right amount I need for those LEDs.

Speaking of GPIO lines — part of the reason why I decided to stick to the STC89C32 that I had at hand was also because they come with quite a few GPIO lines. Indeed, the AT89S52 from Microchip also comes with 32 easily accessible GPIO lines, which is plenty for this project. Unfortunately, they don’t have particularly useful maximum current draw. The LEDs that I got here are fairly bright at 35mA, but not particularly so at less than 3mA that they are getting from the GPIO line as is, and even I/O expanders such as the MCP23016 have a limit of 25mA per line. So instead, I settled for adding transistors, or to be precise to add two ULN2003 Darlington arrays, giving me space to drive 14 LEDs (I only expect 13 of them to be used).

In addition to the time-scheduled updates, I expect to want a button to “fast forward”, which allows me to show off the effects without having to stand around the kit for an hour — and a “full on” that works both as a way to test that everything is working, and as a way for me to take pictures easily.

I don’t have anything remotely sharable about that part of the work just yet. But hopefully soon I’ll be able to get drawings, pictures, or anything at all useful, and start sharing. Because if I didn’t think this horribly wrong, the board itself should be usable for many other configurations, just by programming something different on the micro using the same base software. And as I said previously, I think I’ll try turning around a number of different designs, just for the sake of it.

Quarantine Project: Birch Books Smart Home

By now, everybody knows we’ll be spending a few more weeks closed up in our houses, flats, or rooms. And so everybody is looking for new ways to keep busy. While I do have a significant number of incomplete open source projects to dedicate my time to, I also felt I needed something that was just for myself. So I decided to start what could be described as an “art project”.

A few months ago, I have bought for myself a Birch Books Lego set. It’s a lovely set, and I have a particular place in my heart for bookstores in general (despite having switched to ebooks many years ago). I wanted to take good pictures of it, particularly since I have a few macro lenses that should do it justice, but to do so I felt the need for lighting it up.

Now, you can buy light kits on Amazon for it (and for most other kits out there), but I wanted to do something. So I ended up buying a bunch of battery holders, white LEDs, and a box of assorted lego bricks for me to take a look at, for modifications. I also got lucky, and found a number of bricks the right color for the set.

And since I’m a geek and I love overkill solutions, I started thinking “can I make wire this to a microcontroller, and have it control the lights over time?” — Originally I considered keeping it aligned to the wallclock (as in, the time in the real world) but it turned out that it’s not that interesting to change so slowly — and it’s actually much harder. Having it cycle at a fixed speed is much easier, and with a couple of button controls you can do pretty much all you need.

As it turned out, I had most of the stuff I needed at home already: for Valentine’s Day, I ordered three heart-shaped LED kits on eBay (three because that’s how many they sold it as), that came with a microcontroller — a STC89C51, which are Intel 8051 compatible micros with 35 I/O ports. Back then I also decided I would like to try programming one for custom patterns, and bought a programmer/development board as well, and it came with another micro. While this seemed like a fairly niche micro, it made prototyping easy, since it’s a DIP micro, which I can just put on a breadboard.

The first problem I had with this was figuring out how to flash anything on the micro. What I found online suggested using a set of Windows tools that are only in Chinese. I then found another page, that suggests to just use SDCC and a tool called stcgal, which is Python command line tool that allows one-command programming of the micro. This worked great — the Special Function Registers are described in the datasheet, so it shouldn’t be hard to describe in a header.

So I turned to EAGLE first, and KiCad second, trying to figure out how I would layout what I need on a board, and couldn’t find the STC anywhere. And then I started thinking that maybe this is a clone of something else. A few Google searches later, I found the AT89S52 — which turns out to be exactly the same pinout and most likely the same registers as well. The STC89C51 is (mostly) a clone of the AT89S52. It does not appear to share the same programming protocol, and it actually appears to provide a list of additional capabilities and registers that the Microchip MCU does not have, but it does mean I can just write the code targeting the AT89S52, and be done with it.

Now let me remind you that I’m not particularly versed with electronics, so I’ll probably be making tons of mistakes throughout this experience. But I’ll also be trying to provide regular updates on how the project is going and, assuming I do make it to get it to work, I’ll be publishing all the source code, and any schematics I might end up drawing for the project.

I’m actually happy of having found out that the chip is just a Microchip/Atmel chip instead — because this increases not just the usefulness of me talking about the design, and opening up the sources, but also for myself as I would rather play with something that I can reuse later, rather than with some specific micro I just happen to have at home.

Also, I might end up designing a few alternatives for this anyway. The original draft of this blog post was written when I just started thinking this around, but I’m now putting a few more edits on it while having fleshed out some of my intentions for the project, and it might just be I’ll run with a number of different options around. We’ll see.

The relaxing method failure

Not sure if you remember, but I’ve started, since a month and a half ago, trying to relax myself by playing with the Nintendo DS. When I bought I also bought Mario Kart DS (provided with the unit itself) and Pokémon Sapphire (for GBA, but that was needed also to protect the GBA card slot, as the pre-Lite version doesn’t have a dustcover for it). I’m the nerd kind of guy who actually like the Pokémon series, and I was pretty happy to play it through the end; I’ve played emulated the previous generations, this was the first time I could afford a game myself, and so I took the chance.

I don’t actually like racing games, I got Mario Kart just because it was sold together with the unit, but I enjoyed it, especially to try out the Nintendo DS graphic which was quite nice. Of course after a while, playing only two games starts to be boring, so when I had the last cold I asked my syster to pick up Lego StarWars II for me.

Nice game, nice graphic, nice ideas… too bad that starting from Episode V (the second of the three movies reproduced in the game), it starts to feel buggy.. there are times when you can end up stuck in a wall, requiring to end the mission and then restart from scratch. The game is nice so even if bugged, I continued playing, till in Episode VI I got stuck in a big bug and I needed to search for the solution of the game to find how to pass that mission… the solution also referred to the bug, so I did a bit of search, and I found that LucasArts admitted that the game, in its DS version, was shipped incomplete and unfinished. Nice one.

Oh well, as I said the game is interesting on its own so I don’t feel like I totally wasted my money (I also got it relatively cheap), still I would have liked if Nintendo paid more attention to the title that are published worldwide, maybe putting a “Notice: might contain annoying bugs” on the package… okay I know it won’t ever happen, but let’s say that this game didn’t relax me that much.

Then finally the game I was expecting was released, Yu-Gi-Oh Championship 2007, a nice game after all, although I don’t play the TCG, I found it quite interesting to play emulated before, so I gone for it as soon as it was available (via Amazon, as the local suppliers don’t carry it), I received it last Saturday and I started playing around. The nice thing about this game is the online challenge, which finally allows me to play against human opponents: playing against the computer becomes just a run to a better deck every time until you can beat the next opponent.

So there I go, I try to get some decent cards and start getting beaten up by human adversaries, I wasn’t expecting anything different, but I wanted to see some more strategies before working out a deck that might work against the computer but not against an human.

The online play is a nice thing, really cool especially since it’s WiFi-based so you don’t have to stay put while playing, and the stylus control in the game is well designed; but then I’ve started feeling bothered by the repeated “communication errors” I started getting during games.

First I thought it was truly random, then I’ve seen it happened mostly when I was leading the game.. I thought of a coincidence, but when it happened after I did win the game, the opponent coming to 0 life points… I was sure the thing was not that random.

Now, of course Konami can’t disallow people from closing their connection, or powering off the DS when they see they are losing, but… they could at least assign you the bonus points for the match, or at least the 10 match points you get for playing online, when the adversary fails to complete the game!

Even if I like the game, I’m tempted to ask Konami my money back, online playing is poorly designed.

I love LEGO®

It’s been a while since I last played with the neat LEGO briks, but I still love them; with such a title this post could talk about Irregular Web Comic or Legostar Galactica two of my favourite webcomics, both of which uses LEGO characters and LEGO scenes (well, IWC only on some themes, but that’s well enough I suppose :) ), but I’m not going to talk about those, I can just say “give them a try”, you won’t be disappointed.

A couple of days ago, I noticed the KLDraw program on KDE-Apps, the screenshot is neat, and I wanted to try it.

Today I found some free time and decided it was worth trying getting an ebuild ready.

The good news is that’s a pretty standard KDE package so I had no trouble to create an ebuild for it, the bad news is that it needs the parts library from the ldraw project that’s not Free Software. I also had a hard time to figure out what the latest version of the parts library was, as it has a lot of “Updates” packages, and a single complete package that’s not versioned at all.

Now, if you get my overlay, you’ll find two ebuilds, one for ldraw-parts and one for kldraw, the first has fetch restriction (you can find the license in the proper licenses/ directory) and will require you to rename the downloaded tarball.

Unfortunately, even after doing this, I had some trouble, as one of the four views does not appear at all, and the 3D thumbnails on the parts selection don’t appear at all, and I get a long series of error coming from Qt/GLX.. I’m not really sure what the problem is, I’ll have to check kldraw on Gentoo/FreeBSD and see if there it works (using the non masked version of mesa and a different video driver).

Who knows, maybe in a couple of years I’ll be able to give to my nephew for his birthday a custom LEGO construction set.