Initial conditions

A while ago one of my house’s lamp dimmer switch died, which meant I had an excuse to dabble in electronics again, yaye!

Opening up reveals an interesting circuit:

And quickly our attention turns to a likely failure point: a BTB600. Is it a mosfet? It’s not!

The triac

A quick look at this component’s datasheet reveals it’s a triac.

It’s a really fun component:

• It’s a thyristor:
  • It will conduct when current is applied to its gate
  • Unlike the transitor, it will keep conducting if current is removed from the gate – shutting it down requires stopping the current flow between its anodes.
• It’s a double thyristor, made to work in alternating current, so its inputs are named Terminal (or Anode) 1 and 2.

As a thyristor, it’s easy to test out:

The gate is the right-most pin: when connected, the LED lights up, and will stay on even if we disconnect the gate.

With this simple setup we test a freshly-bought triac against the one extracted from our device: the latter does not work, so it’s our failure point.

Simplified dimmer circuit

The principle of a traditional light dimmer is that on each rise of the AC sinusoidal, a delayed trigger will start conducting out of phase, limiting the amount of total power sent to the lamp.

Note: this goes to show why such dimmers cannot work on LED bulbs as-is: while a lamp will absorb the on/off periods and simply shine less bright the smaller the triac’s on-time is, an LED transfomer will not magically reduce current based on the form of its input’s wave form. Thankfully, there exists LED bulbs that do work on such dimmers, requiring more circuitry.

Such a typical circuit looks like this (simplified):

This introduces a new component: the diac. It’s an AC diode that starts conducting at large-ish breakdown voltages like 30 V.

Hence the above circuit makes sense:

1. When the sinusoidal starts rising, the triac is off.
2. Current flows through C1 limited by R + R1: the voltage across C1 rises at a rate that depends on R1.
3. The voltage across C1 eventually reaches the diac’s breakdown voltage: C1 discharges rapidly in the triac’s gate and triggers it on.
4. For the rest of the half-period, the triac stays on, and virtually no current passes through C1 anymore.
5. the sinusoidal reaches 0v, the triac turns off, and the cycle repeats.

And how much of the period is cut off depends on the variable resistance’s value. Neato! You can see the circuit in action over at falstad.com: select “Circuits” / “Misc Devices” / “DIAC TRIAC Dimmer”.

Something feels weird though: what happens when T2 is lower than T1 (respectively -120 and 0 V)? What is the potential of the gate? If it was related to T2, you would immediately get a large potential across the diac (from -120 V to 0 V at the start, since C1 starts with a voltage drop of 0), triggering the diac instantly, so that can’t be it.

Instead, my understanding is that the gate’s potential is always related to T1, hence why the capacitor + diac group is across the gate and T1, and it can trigger with either a negative of positive potiential. So a triac is not exactly the same as two thyristors glued together, and T1 and T2 are not interchageable. In our case, when T2 < T1, we enter what is called quadrant 3, because the gate is also < T1.

Dimmer’s actual circuit

Note we’ve looked at a simplified circuit. In the photo above we see at least one large inductor and two capacitors. The basic intention is apparently to filter the circuit, with these additions:

I reversed the actual circuit, which gave me something like this:

We see:

• The filtered dimmer circuit above
• A fuse F1
• TS1 which I believe is a thermal switch or thermal fuse of some kind - it is glued to the coil.
• An LED indicator (2mA with its 120 K resistor)

The repair

Anyhow, replacing the triac with a newly-ordered one fixed the circuit – success!

Initial conditions

A while ago I started looking into Bluetooth earbuds. It was more out of necessity than anything, due to the recent industry trend of removing perfectly useful jack headphone ports from devices — see below for my thoughts on the whole thing.

Looking at the second-hand market, I happened to find an offer for interesting model but selling them for parts as they appeared dead and refused to charge. Looking around, it looked possible to open them up and force a charge to the battery to revive it. They were cheap enough to justify the risk, so I went for it. The model in question is Seinnheiser’s Momentum True Wireless 3.

Opening them up was surprisingly easy — just heat them up with a hair dryer and cut through the glue.

Then gently pry them open, the cover comes off easily revealing the electronics and the tightly packaged battery.

And as expected, the battery shows a very very low voltage.

In this condition, the earbud can’t even power up enough to accept a charge, and so they are dead, ready to live the rest of their long, long after-life in a pretty landfill.

Manual charging

Thankfully, now that we have direct access to the battery, we can attempt a manual charge and see if it revives the earbuds. Because of the deep discharge, it’s possible the battery has suffered heavy damage, so it’s a bit of a gamble here.

The charging profile of a lithium-ion is a classic CC-CV profile:

• First, charge with a Constant Current, and let the voltage ramp up to its target value.
• Then, limit the voltage, and let the current drop to a low threshold, at which point the charging is over.

It looks like this:

It’s easy to emulate with a bench power supply: set a limit to both voltage & current, and connect it. You can also use straight batteries, as they will probably limit the current to a safe-ish value for the small duration.

Note that I should have set a voltage limit to something closer to 4.2V instead of 3.7V. Not that it matters too much in my case, because I’m not going for a full charge: I only want to revive them so that the case can detect the earbuds and take over. For this reason I limited the current to 300 mA to ensure the kick start stays gentle.

With this set up, connect the battery to the power supply for about 30 seconds to a minute, put the earbud back into its case, and voilà!

Results

I’ve been using this pair for about 2 weeks now, and they work like a charm. They last about 75% of their advertised duration on a single charge, which is good enough for 30 €.

Old man yell at cloud

What did I learn in the end?

Well, I don’t deny that I enjoy having cable-less earphones, they’re great and very comfortable in many situations. But I just love love love the idea that with almost only Bluetooth at my disposal, now I get to worry about price, battery life, codec compatibility and latency! Because, yeah, most of these things have like a 250-ms latency (compensated for media, not so much for anything real-time), which is roughly the time it takes to ping the other end of the planet. The experience of satellite phones, right in your pocket!

But the best thing of all is that most of these aren’t repairable at all and that you can’t even change the battery, because those landfills aren’t gonna fill themselves!

Note that some manufacturers do manage to keep theirs earphones at least semi-repairable — Fairphone’s are, of course, but apparently so are Samsung’s including their latest models… relatively speaking for their tiny tiny size of course.

Or, you know, I could buy yet-another adapter to replace the once-ubiquitous port that was everywhere and made plugging stuff so simple. And that gives me the option to choose which DAC is the best! Don’t we love having non-choices forced down our throats?

Anyway, hurray for stuff you can at least minimally maintain.

In this article I’ll describe the details of the project: the design choices and questions to be solved.

First design ideas

I wanted the timer to have:

• A button that provides a satisfying click, nothing mushy
• A blinking light
• Some logo or simple image that would show when lit up.

I also had multi-material printing with a single extruder and manual filament changes in mind: I had tried before with PrusaSlicer but the results weren’t great without a prime tower. I recently switched to OrcaSlicer, and wondered if what would work.

I also knew I could make the circuit simply based on 555 timers, and I had purchased a few a while back but never got to play with them yet.

In the end, while it is a very simple object on the surface, it provided just enough depth with fun questions to solve at every corner, making for a very satisfying project I could complete in a few week-ends.

The 3D model

With that in mind, time to open up FreeCAD. If there’s anything I’ve learned about 3D-printing your own stuff is that you have to test absolutely every detail you solve.

The front panel

As mentioned above, I wanted to use multi-material because it’s fun. I started with the following print:

I had 2 issues:

1. The prime tower was huge!
2. The printer made awfully big blobs on the prime tower, which would get in the way in later layers and would risk damaging the printer.

The prime tower size was solved with limiting flushing volumes:

I resolved the second issue by writing a crude post-processing script (available here on github) to identify suspicious extrusion value and reduce them to 0.

With that out of the way, and a few other prints to get the first layer just right (had to re-calibrate recently), we’re good to go:

The ligthing

Next up is testing the lighting with some LEDs.

Putting the LEDs right behind the white, .4 mm-height disk doesn’t look pleasing: the light isn’t well distributed and too sharp.

Instead, I tried printing some form of diffuser, and hold it at about one centimeter from the front panel.

The result is dimmer, but nicer - this is what we can see in the picture at the top of the article.

Using screws

We need two sets of screws: one to hold the PCB, and the other to close the box. For the former, I decided to use simple M2 screws I had lying around, and screw them directly into the plastic. For the box though, I wanted to be able to open and close the lid easily, so I resorted to using screw inserts.

Again, instead of printing the whole model and getting it certainly wrong, I opted to print a minimal test, and fix issues there.

The back panel

I wondered how I would hold the batteries. I have a few battery holders for 2 AAs, and decided to use them directly as-is instead of designing my own and wasting time there. Still, they represent most of the box’s weight, so they must be fixed and ideally close to the bottom.

As a first simple solution, I tried to print a cradle and see how well that would hold:

And it fits perfectly, is easy to remove but still holds well. Perfect!

Fitting it all with the PCB

As I experimented with the PCB, I realized I wasn’t too sure where I could place the components. Moreover, to print the LED diffuser or PCB mounts, I must know the exact placement of components with regard to each other.

What I ended up doing was creating a sketch with holes spaced by 2.54 mm (.1 inch). I printed it on paper for reference, and fixed the dimensions until they fit the real object I had.

Then, using this sketch as reference throughout the design, I could place my elements properly and make sure I would get a fit on the first print.

Final design

This was my most complicated object with FreeCAD yet: a combination of Sketches, Part Design workbench, and Part workbench for boolean operations where needed.

It might be interesting to talk a bit about FreeCAD here: I’m incredibly grateful this wonderful piece of open-source software exists, I feel I can learn it and rely on it in the years to come, which is worth a bit of a learning curve.

That being said, there are some annoying bits that just hurt the workflow:

• Editing the PCB sketch, with its thousands of constraints, was super slow (think 20-30s per operation). However, once closed, it didn’t slow down anything anymore, so FreeCAD was smart there.
• I created a first sketch for the front plate, which I then used as a reference for later sketches. Going back to the first one and adding fillets wrecked havoc on the references, and I had start from scratch. Fillets are a pain to reference, to, so it might be smart to wait until the end and apply them in the Part workbench instead.
• Reusing sketches for multiple shapes is sketchy (pun intended): you can’t select part of the sketch for the operation, so you have to create a new sketch, reproduce a similar shape referencing the source sketch manually, then use that.
• When using a sketch as reference for further shapes — which as we’ve seen with the previous item, you end up doing a lot — there are multiple ways to combine references (“the circle here is centered on that circle in the reference sketch”) and local constraints (“and it touches this line that already exists”) to make a viable sketch. However, some are better than others: you might end up with partially redundant constraints, or suddenly with redundant constraints which aren’t obviously solvable unless you go a completely different route. I think this is where I spent most of my time in the tool, finding new and minimalist ways to use the reference sketch, and use local constraints as much as possible.
• Finally, it did crash a few times, which doesn’t feel nice, but usually recovery takes you but a few steps back so that was fine.

In the end: I save often, I save copies, I learn along the way, I’m grateful of what it enables me to do. But I probably would not use it in a professional capacity.

Anyway now we can print it all, and look at the circuit.

The circuit

Nothing too fancy here:

• A pre-built DC-DC boost converted to reach 5V from 2 AA batteries.
• A 1st 555 timer in monostable configuration to count up to 2 minutes.
• A 2nd 555 timer in astable configuration to flash the LEDs.
• A button to trigger the whole thing up.
• 4 LEDs & their current-limiting resistor.

The 555s are used in cascade, with the output of the first being the second’s VCC. That incurred a noticeable voltage drop, but wasn’t a problem in the end.

The 555 circuits look like the following:

I won’t dwell on how these work, these circuits as extremely common and there are far better resources than my poor explanations, starting with the Wikipedia links above.

Being an analog circuit, the values of resistors and capacitors depend on the desired behavior. The formulas aren’t too hard, but you can also use a calculator such as this one. Still, I found that the values are just a starting point: you need flexibility to change values in your circuit to properly set it to your desired values.

I built the circuit in stages and checked it along the way. That was a good idea, as I messed up the monostable part and it took me a bit to realize I had mounted the 555 backward… Ahem. Also, I had to change the resistor values I used as the timing I got where different on the protoboard than they were on the breadboard, and I wanted it to be just right.

Moreover, I had to mind the depth of my assembly, and wanted to minimize it: for this reason I located both large capacitors in a corner of the PCB, where they wouldn’t get in the way of the battery holder.

An hour or so of soldering and tinkering later, and we have a functioning circuit:

Final assembly

And now for the big moment!

During testing, I noticed quite a lot of light leakage to I added a bit of aluminum foil to the light cover:

Note the protrusion under the plate’s button to make it reach the actual button on the PCB. The result feels right, with very little space between the two, and a light press immediately produces a nice click.

The assembly went well and the first print fit well! 2 small issues:

• I must have forgotten to update the holes for PCB screws in the PCB mounts, and had to drill them to size.
• The space between these mounts was ever so slightly too large (by about .5-1mm): it did fit but barely. Maybe my (paper) printer’s scale isn’t perfect, and the adjustments I made weren’t necessary after all. I’ll have to check that next time.

I’m really happy at how the project turned out: fun questions to solve, learned a few things along the way, didn’t drag out for months on end, and the final customer got its tooth-brushing-time timer delivered swiftly!

There might be more on this subject later on, as I ordered a bunch of ATtiny85…

What’s the excuse this time?

A while ago I stumbled upon Makedo, which offers awesome kits of screws & tools for children to create stuff with cardboard: a safe saw, big chunky screws, a key and a pointy bit to punch holes. Simple enough, yet a fairly cool activity for my kids to do, either with us or in autonomy.

But first I will have a bit of fun of my own, as this is a very good excuse to do some CAD, so let’s warm up the 3D printer and see if there already exists some open models we can tweak. I found a few things, and settled on this set as a starting point.

Because here we start with a mesh from the STL file, I won’t use FreeCAD as I’m vaguely used to, but I will try using Blender directly.

First things first, the add-on

Because we’ll want to produce valid STL, we must use the appropriate 3D‑printing add-on to check our files, otherwise the slicer will produce garbage. Fortunately, that add-on is shipped with Blender directly, so all we have to do is go to “Edit” -> “Preferences” -> “Add-ons”, search for “print” and check “3D‑Print Toolbox”. We can close the window.

However, the toolbox is really hidden… Look for a small arrow at the top right corner of the viewport:

Click & drag left to reveal a toolbox (magic!), then select the “3D‑Print” tab.

We’ll use that “Check all” button after each complex step to fix our model along the way.

A few guidelines to follow

During this project I did quite a bit of experimenting which I won’t detail entirely. In the following sections you’ll find a summary of a few interesting steps. However, here I compiled a few guidelines that I found useful:

• Don’t trust Blender to keep your model valid, it won’t! Check it regularly, clean it as you go¹.
  • Temporarily keeping non-manifold edges resulting in missing faces is OK or even desirable, if you do so to avoid later intersections.
  • Non-flat faces are simply solved with “Triangulate Faces” when necessary. Use within reason.
  • Bad Continuous Edges seems to have to do with normals. Select all, then go to “Mesh” -> “Normals” -> “Recalculate Outside”, this gets rid of the problem.
  • Other issues are either solved with automatic vertex merging (see below), or with manual editing of the geometry to make your model one single solid again.
• Manual cleaning is often necessary. Make sure your model stays simple, remove spurious edges or vertices.
• Use vertex merging when possible to keep the model simple. Use the “By distance” merge to automatically clean up some obvious issues, check the bottom status bar to see how many vertices are affected.
• Because we work with meshes directly, it’s not always trivial to edit parameters after the fact. For example, making something bigger might completely mess up connected edges. In these cases, it’s way less painful to roll back and do again.
• Because of the above point, save often and keep your history! You’ll be glad to be able come back to a clean version, especially as the history in Blender doesn’t go that deep by default.

Do note that I use Cura, which requires clean models to start from. It seems other slicers might be more tolerant of some types errors — I’ve notably had errors in the past with overlapping volumes which are fine elsewhere, but still an issue in Cura as seen in this Github issue.

Shortening the screw: bisect

The first issue I want to solve is that the screw in the 3D model is longer than is necessary to assemble 2 pieces of cardboard, so I want to make it shorter.

Let’s open the STL file in Blender: simply create a new empty project, delete the default cube, then “File” -> “Import” -> “Stl” and select the scren file.

At the top left of the viewport, change “Object mode” into “Edit mode”, so we can work on the mesh.

We can cut the screw halfway using the Bisect tool:

At this point we could recreate the top cone.

Fixing the screw: boolean intersect

However, further testing of the screws reveals that the tip of the thread is too large and requires a lot of force or twisting around to properly get in the cardboard. Normal screws avoid that with a cone-like shape, so instead we’ll cut a shape in our screw to both make it shorter & more conical at the same time. To do so we’ll use a boolean operation on the objects with “Intersect”, to instruct Blender to cut our mesh so it stays inside another mesh.

First, let’s create our bounding meshes with a cone and a cylinder, as separate objects. Go back to object mode, then “Add”, “Mesh”, “Cone” or “Cylinder”. You’ll end up with something like this:

Then, merge these 2 new objects into one with a first boolean operation:

1. Select the cone.
2. In the “Properties” panel, find the “Modifier” tabs.
3. Click on “Add Modifier”, “Generate”, “Boolean”.
4. Select “Union”, then in the object field enter your cylinder.
5. Apply with Ctrl+A (the “Apply” action is, again, hidden in the combo-box menu right above the “Intersect / Union / Difference” selection buttons).

Note: it might do to simply join the two meshes, but I’m not sure the later Intersect operation would work properly.

Once applied, the result is stored in the current object, but the cylinder object still exists and overlaps: delete it.

Next, we’ll do the intersect:

1. Select the screw object.
2. Similarly, create a boolean modifier with “Intersect”.
3. Select the bounding object (called “Cone” even if it’s not a cone anymore).
4. Before applying, if you want to check the results, you should hide the Cone object.
5. Apply, delete the cone object, and voilà!

Use the 3D‑print toolbox’s “Check all” to make sure there are no issues (overhang faces are usually OK, your slicer will be a better judge of that), but it should be OK as we only removed geometry.

Finally, save your model for future reference, export it as STL, and print away!

The key

Similarly the key isn’t perfect:

• I find the punching tool too blunt, which is good for safety, but it requires too much force. It is also too thin, and the resulting hole is too small to fit the screw.
• The 90° edges make it a bit uncomfortable to hold.
• I don’t see the point in having through holes, they probably make printing slower and again, 90° edges.

Cleaning up the pointy side of the key

First, let’s clean that side:

Using the selection in vertices mode, I removed everything but what is stricly necessary to make the edge again:

If we use “Check all” at this stage, we’ll have a few non-manifold edges: our model isn’t solid anymore. Don’t create the missing face! if you do, it’ll intersect with the rest of the model and you’ll have to remove it afterwards.

Spin: extruding a round side

Now we’ll extrude a half circle. First we must define the center of the spining extrusion:

1. Select the 8 vertices in view.
2. Shift-S: “Cursor to selected” to place the cursor at the center of the selection.

Now for the extrusion:

1. Now select only 4 vertices from one side
2. Select the Spin tool
3. Make the angle 180°

At this point, let’s check our model with “Check All”. 3 intersect faces! What? Manual cleaning is required:

1. Select all vertices with “A”.
2. Select “Mesh” -> “Merge” (“M”), then “By distance”.
3. On this model, a distance of 0.1m is necessary.
4. The status bar should indicate that a few vertices are merged.

Check the model again: the issues are solved. Phew, we dodged a bullet here.

Our model isn’t air-tight yet. Select all vertices in the hole above and press “F” (“New face from vertices”). Do the same with the bottom hole.

“Check All”: all good!

Bevels

A simple way to make the edges less sharp is to use the Bevel Edges tool.

Use the edge selection mode (see the 3 icons at top of the viewport, next to the “Edit mode” combox box to change between selection modes) to select the edges on one side of the key side.

Use the bevel tool, and select the desired width:

Check your model again. Horror! Again, merge vertices by distance, this solves most issues. Non-flat faces are simply fixed by selecting them (click on the “Non-Flat Faces button”) & triangulating (“Ctrl+T”)

Boolean union: cleaning up required

As we did before, we can add back a pointy bit by creating a separate object and merging it with a union boolean modifier.

However, I found that this operation often resulted in redundant geometry or faces, creating problems with the model. Sometimes cleaning up is as simple as automatic vertices merge, or deleting a few faces, but oftentimes simplifying the geometry manually is required.

Thankfully, at least when working with low-poly models, that’s not too hard. Let’s take the example below where we have a redundant vertex we want to remove.

We could simply delete the vertex & recreate the face from the vertices around, but it is usually less cumbersome to manuall merge the vertex with another one. Let’s say we need to merge it with the vertex at the lower left corner. We have to:

1. Select the destination vertex.
2. Move the cursor there with Shift+S then 2 (“Set cursor to selected”).
3. Select both vertices, press M to merge, and select “At cursor”.

Rince and repeat as necessary.

Separating part of the mesh into a new object

One final thing I learned was while trying to edit the resulting form, specifically the pointy bit I had merged was too thin. If you’ve read my guidelines above, you know I should have restored a previous version and started from scratch but I persisted.

Notably, at one point it looked like this:

Everything we see here belongs to the same mesh. Must we merge all these vertices by hand? Thankfully, no. Instead, we can:

1. Select all faces from our disconnected pointy bit as seen above.
2. Press P and use “Selection” to separate the bit into a separate mesh.
3. Make both models solid by adding the missing faces.
4. Use a Union boolean modifier again to merge the objects properly.

Phew!

The results

I found that after a slight learning curve Blender was perfectly usable in this context, at least on low-poly models since much manual editing is required. It’s also entirely possible that there are more effective ways to do what I did. In any case, the software certainly went a long way since its early days, and I remember a very different experience with its UI years ago.

In the end, I created 3 new objects:

• I made the pointy bit into its own tool to have two sides with different sizes.
• The key doesn’t need a pointy bit anymore, and it feels better in the hand like this.
• I created a saw that is somewhat good enough for cardboard, time will tell if it is really useful.

The set can be found on Printables.

• I created a simple tool to download the apache logs of a web-hosting OVH account available on github.
• I analyzed the logs of my low-traffic blog to reveal a more accurate count of total readers.

As of 2023, this blog is hosted on a OVH web-hosting instance. This comes with simple analytics tools, which aren’t really satisfying: they do not successfully filter out all bot noise, and bogus malicious queries tend to drown out legitimate user traffic. Moreover, I do not use any JS analytics engine, as I want to keep this mostly tracking-free. As a result, it’s impossible to currently evaluate the readership, especially in a very low-volume website such as this one.

Because of this, I was drawn to taking a look at the raw Apache logs, and try to build a quick ad-hoc filter to get a more realistic estimate of the readership. This article is the result of this attempt.

OVH apache logs

OVH allows direct access to the hosting logs via its web interface. While this is a good starting point, there is no batch option - and there’s no way I’m manually triggering hundreds of downloads.

Fortunately, it’s easy to automate. A quick search didn’t reveal existing tooling for this specific use case, so let’s build our own.

The URL for a daily log looks like this:

https://logs.clusterXXX.hosting.ovh.net/partiallogin.clusterXXX.hosting.ovh.net/logs/logs-08-2023/partiallogin.clusterXXX.hosting.ovh.net-26-08-2023.log.gz

The partiallogin appears to be similar to the FTP username, while clusterXXX is probably a physical instance somewhere. It’s apparently the only two parameters to locate the logs, along with the current date.

On the other hand, the current day’s partial log is not compressed and is stored in a different location:

https://logs.clusterXXX.hosting.ovh.net/partiallogin.clusterXXX.hosting.ovh.net/osl/partiallogin.clusterXXX.hosting.ovh.net-27-08-2023.log

Finally, these URLs are protected behind a Basic HTTP auth. When using the web interface the mechanism is unclear - it seems like accessing the log site will generate a temporary access credential? In any case, the Web UI gives us the option to create a specific account for log viewing - this is a more secure way to access these.

I started experimenting in python, but in the end decided it would be a good way to start using some rust again and properly publish a tool others might genuinly find useful. The repo is available on github.

Using existing tools

There are multiple tools that we can feed these logs into. I tried two of them:

• awstats
• GoAccess

Both provide a nice view into the daily activity and various reports, but it was obvious the noise from bots was still drowning actual user traffic, and I couldn’t trust the total visitor count to be an actual human count. Moreover, I couldn’t easily select a user session to verify it, follow it, see which pages were accessed, etc.

Custom report

Instead I started filtering the logs manually. Removing most of the noise from bots is not too hard, as their user agent is pretty explicit. I assume the tools mentionned above do so as well.

bots_keys = ["bot", "spider", "crawler", "dataprovider", "anthropic-ai", "googleother", 
             "nbertaupete95", "github-camo", "facebookexternalhit"]

Now, most of the noise came from multiple sources, mainly:

• Obviously malicious queries such as queries ending in ?variables=complexquery. These usually end up as 404, so they’re pretty easy to filter
• Regular accesses to feed.xml get a special mention - those get counted separately to figure out the RSS readers
• Access to key files, that tools or websites are likely to do themselves: sitemap.xml, favicons, the avatar, .map files, this kind of things.
• Accesses with, surprisingly, an empty User Agent.

Moreover, strangely I had to ignore visitors doing only a single queries - I’ve seen what I assume are bots (but which don’t advertise themselves as such) slowly but surely scraping the site, one query after another, using different IPs, in the span of days. Very strange.

Finally, I found that quite a few visits did query the links from the main page but not their resources (article’s images, etc.). I’m not sure what this is but I suspect browsers preemptively query urls in various situations, so I don’t count them as a proper human visit either.

Final results

Once this is all filtered out, I can:

• Look at the human-readable results and monitor individual visits to the website
• Pipe the filtered raw results into one of the tools above, and actually get meaningful reports:

It seems we’ve had about 100 readers so far. This sounds way more reasonable than the ~700 generally reported by GoAccess and others, even when ignoring bots crawlers as much as possible.

Note: if you’re curious you can find the resulting notebook (in a .py form) here but be warned that it is very bespoke to this site, and probably not very reusable.

It is time to make our instrument a bit more permanent than letting it sit on a breadboard. Moreover, I want to max out the Arduino’s pins and connect it to 4 chips together.

The latter is rather trivial to do: the next 3 chips can share most of the Arduino’s output pins already used for the first one. The only pin that must be separately controlled is CE (Chip Enable): by pulling only one to true at a time, we can make sure only one chip listens to its input at any given time. Alternatively, we can also pull them all to true to send the same command to all 4 chips in one go, for instance to quickly turn them off.

I did a layout on paper which has since been lost to time, dusted off my cheapo soldering iron and went on for a long and quiet evening:

Please disregard the sub-optimal soldering job I did there. Note I used 30 AWG (0.25 mm) wire to solder the common data pins, otherwise I don’t see how I could have crammed it all to the same small protoboard. I opted for regular wire for the rest: first, to make it easier to distinguish what is going on; second, so there isn’t too much resistance for the Vcc and ground; finally and most importantly, because the thin wires are very easy to break.

Designing the mixing circuit

Now that we have 4 chips we have 4 outputs, and we need a way to mix them together. Since the signal is a variation of voltage, what we need is effectively a voltage adder.

The simplest circuit we could use is a passive resistor network, where the output voltage $V_o$ is composed of equal proportions of the input voltages $V_{ix}$. For N inputs, all connected to the same resistance value $R_i$, we have:

This works well enough for testing purposes, however I see two issues:

1. Obviously, the voltage of each input to our mixing circuit is divided by the number of inputs, so this will require more amplification on the output which will generate unnecessary noise.
2. This provides the same impedance on the input & output side. My crude understanding here is that we want stages to be high-enough input impedance (so as not to require too much power from the previous stage, in our case the TI chips) and low output impedance (so we can drive lowish impedance loads if necessary).

The solution I settled on is, again, certainly very obvious to anyone with any knowledge of electronics - I used an active mixing circuit based on operational amplifiers.

In theory it looks like this:

I’m not going to go over the usage of an op-amp here, because there are many resources on the subject. The important points here are:

• The op-amp inputs sink virtually no current.
• The op-amp will keep both of its inputs at the same voltage, as long as possible, by varying the voltage on its output.
• This makes our inverting input a virtual ground (albeit one that sits at 2.5V, because I don’t have a negative rail so I want my signal to oscillate around mid-voltage, not 0V). Because of this:
  • The resistor network to the left does not act as a voltage divider anymore.
  • On the other hand, there is a voltage divider between each input and the resistor across the op-amp, and since both $Ri$ and $R3$ are identical, $V_1 = -V_i$ (again, not really, it’s actually mirrored around 2.5V, stay with me here). Note we could vary the resistor values to multiply the voltage by a different factor than 1.

On the impedance side of things¹, I think we have an input impedance of $R_{in} = R_1$ and and an output $R_{out} = R_{op-out} = 125\Omega$².

Building the circuit

Now that we have our circuit in theory, we can start testing it on the breadboard.

A bit about tooling

When I started experimenting a bit on the breadboard, I realized how absolutely necessary it is to be able to measure things up, otherwise you’re just shooting in the dark. As a complete beginner I lacked all basic equipment: all I had was a multimeter.

Still I couldn’t justify to invest too much at this stage, so I bought an EspoTek board:

We already used it in back part 1-B of this series to do various measurements. It provides a variable voltage source, a signal generator and a digital oscilloscope all in one single board. Of course, due to its accessible price, it comes with significant compromises:

• The voltage source cannot source a lot of current — still, it was enough for my needs.
• The oscilloscope’s measured frequency ceiling is the in hundreds of Khz — again, enough for measuring sound frequencies.
• The voltage resolution is quite poor, even if you can effectively double it up by cheating a little bit. I think this is the most problematic item on the list, and one that will probably justify going with more expensive equipment in the future.

Noise, noise and more noise

During testing, I realized how much noise there was on my chip’s outputs. It was so loud I was afraid it was going to make the whole thing unusable for actual recordings. Unfortunately, looking at the signal didn’t really make obvious what the frequency was, nor did poking around reveal the source.

So I tried to make a filter to block it out: I tried simple RC filters and made multiple unfruitful attempts. Then I started trying semi-random things, and of course nothing worked until magically, putting a small cap on the op-amp’s feedback significantly reduced the noise. Hurray! Not the most formal approach, but hey it worked.

Still, it’s not all gone. Connecting that thing to my desktop results in a different, but again very present noise. For this reason, I’m quite sure the source of the noise was and still is the power supply: the chips are getting their juice from the Arduino, which is itself powered from USB… And if you look closely (not), you may notice a subtle bit of hot glue. What?

Well, the micro USB connector on these Arduino clone boards is absolute garbage, and despite my carefulness, broke loose after about 3 manipulations. What you see is my heavy-handed attempt at securing the even worse repair job I did by soldering a USB cable’s wire directly to the surface-mounted component next to the connector. However, in my desperate surgery, I had to solder after the component - I believe I may have bypassed some crucial filtering there… I could always replace the Arduino, but hey, where’s the fun in that.

In the meantime, any proper recording from this finished instrument will have to be made from my laptop where the USB bus is very quiet to get a nice and quiet recording.

Keeping options open

Now let’s skip the various other digressions that I went through³, and jump straight to the end. This is what the final circuit looks like:

Note there are 2 outputs, and more than 4 inputs in total. The reason for this is that I wanted to keep a bit of adaptability: I have an external sound card that can capture two inputs, so maybe I’ll apply different filters to different voices in the DAW. But I’m not sure which voice I want to send to either output: do I want 1 chip optimized for bass sounds and the rest flat? Do I want two chips with reverb and two without? Do I want simple left / right channels? With the configuration above, I can do 4/0, 3/1 or 2/2, so I’ve got all the options covered.

Here is what it looks like now:

Putting it all in a box

Nothing fancy here — I grabbed a cheapo plastic electrical box, a few spacers, some black paint and forgot that varnish was even a thing. I drilled a few holes and voilà:

I don’t care, I absolutely love it. Beauty is in the eye of the beholder.

… OK but now what? We’re done?

The quest for color

Oh no we aren’t, because now we can sorta make chip music with it! And I’m really keen on experimenting with what sort of sounds we can get out of this thing. That also means improving the software in the Arduino following what we need.

I’ve said it before, I have no illusion about my composing skills. Besides, I want to focus on testing and playing with the instrument, and the frustration of (failing at) trying to compose a track would just get in the way.

For this reason, I started working on covering tracks I loved (or should we call that “porting”?), and I had to implement the following:

Fast arpeggios

This is the definitive signature sound of chip music: instead of playing chords, which require many simultaneous voices, we play the chord’s notes sequentially, on a single voice, very fast. This provides harmony at no cost.

They sound like this:

And I have found them sometimes used to provide some rythmic background as well:

I didn’t have to do anything to implement arpeggios as Bitwig supports them already (and keeps them correctly in tempo).

Vibrato

Vibrato is a small variation in the note’s pitch, like on a violin. This is a cheap way to bring expression. I sneaked an example in the previous’ article:

And it’s easy enough to implement: just vary the channel frequency of a small percentage towards the next or previous note. We control this variation with a dedicated MIDI channel.

Careful readers will remember that we have little precision on high notes: the vibrato won’t work well (or at all) there.

Tremolo

On the other hand, we can vary the channel’s volume to bring a similar type of expression. Similar implementation, and it sounds like this:

Interestingly, I found that introducing a fast tremolo also provided some texture to the voice, almost like distortion, which I quite liked in certain situations:

Portamento

Finally, the portamento is a glissando from one note to another. It’s generally triggered in MIDI by starting the next note prior to releasing the previous one (similarly for legato), and the glissando speed is controlled by a separate MIDI channel.

Putting it all together

Here is a typical screen of Bitwig:

With 4 chips, I have quite a few voices at my disposal. In my typical setup, I ended up mirroring voices on the left & right channels, allowing for some stereo separation, that I mixed it a bit more in the center in Bitwig so it’s not 100% left or 100% right. On each side, I get:

• 1 polyphonic channel with up to 2 voices (so I can play 2 notes at the same time).
• 2 monophonic channel2 which I can use for simple voices or arpeggios.
• 1 polyphonic drum channel with up to 2 voices, and each drum voice also eats up 1 regular oscillator voice as we’ve seen before.

That’s a total of 8 oscillator voices & 4 drums simultaneously. It is really cheating at this point, compared to what these chips are originally intended for. But it’s plenty of fun!

Conclusion

So far I ported 3 tracks, and it was a really interesting exercise. You can find them on Bandcamp or in the embedded player below. Maybe I’ll port other tracks if I feel like it, but no constraints.

And with this, our little series ends! We dabbed in electronics, theory and practice, and also into chip music & DAWs! It was quite a fun project, that lasted for more than a year.

At this point in the project, we have reliable communication with one SN76489 chip on the breadboard and some form of sound output. In this article, we’ll make it play its first note, control it from a computer, and start improving its musicality.

Playing notes

First we need to solve a detail we’ve overlooked in part 1: how do we specify a note’s pitch?

According to the specification, we must send a 10-bit number to set the frequency. That number won’t be in hertz, but rather a division of the input clock: with $N$ the clock’s frequency, $n$ the 10-bit number passed as “Tone frequency” and $f$ the resulting note’s frequency, we have:

This $n$ being limited to 10 bits means there is a limited range of frequency that will be available to us, and for two reasons:

• First, the ratio between lowest and highest frequency will be 1023
• Second, in the low $n$ region (higher frequencies), the jump between 2 consecutive $n$ values will result in huge jumps in resulting frequencies, making it hard to get a precise pitch. The higher the note, the bigger the step, the more out-of-tune it will be.

To find a good balance, let’s calculate the target $n$ for the entire MIDI notes range. Moreover, we need a measure how out-of-tune notes are. For this, we’ll calculate the error the rounding of $n$ produces by comparing the error in the obtained frequency with the step in frequency from the previous semi-tone.

Remember that in part 1, we assumed the maximum possible clock frequency for the chip, at 4 Mhz. Let’s start from this clock value and see what we get:

This graph outlines the 3 regions we mentionned:

• To the left, the innaccessible low notes where $n > 1023$. The error on the frequency is of course huge.
• In the middle, the valid range with an acceptable error. I arbitrarily set the threshold to 10% of a semitone.
• To the right, the out-of-tune higher pitches. Even though the frequency error is barely visible on the blue frequency curve, the bottom graph shows that it is very hearable.

This balance is not good, because B2 being our lowest note is not very satisfying — going lower would provide much nicer bass sounds. However, if we reach the lowest possible MIDI notes, then the precision error creeps very quickly at ranges we definitely want to use! This 10-bit precision is not very good, and it seems other chips do better in that regard: the AY-3-8910 is a very similar chip, but has a 12-bit divider.

In the end, I settled on E1 being my lowest note. Highs get a little out of tune but that’s bearable. We reach this by applying using a timer step of 5, giving us a clock frequency of 1.33 MHz.

Here are the error graphs for the initial 4 MHz situation, the corrected 1.33 MHz clock, and a 4 MHz but with 12 bits of precision of the AY-3-8910 which we wish we got:

In the middle graph, we see we get about 4 usable octaves, starting in the middle of octave 1 up to the middle of octave 5. Starting octave 4, it will start to sound a tad out of tune, but that should be acceptable.

Setting up MIDI

The simplest way to go about controlling this from a computer is to use the MIDI protocol.

What is MIDI

You’ve probably heard about MIDI at least in the form of .mid files: lightweight files that can be played, and the ouptut is often a very computer-y sound, but quite comprehensive with various instruments available. If you’re old enough, you might even fondly remember the good old 🎵 Canyon.mid!

These .mid files contain MIDI commands such as notes with pitches for instruments, or modulation values. The instrument “patches” (instrument sets) are standardized, and nowadays every system under the sun can generate the appropriate sound for these commands.

These files are now a bit obsolete, because size & compute power is not an issue anymore. However, the protocol itself was initially designed to communicate with external instruments, and that’s where it still lives and thrives.

The protocol even got updated recently with new additions such as MPE (midi polyphonic expression) that basically allows more control over individual notes. You can see an example of Jordan Rudess demoing such a keyboard. I especially love how the vibrato works on this.

MIDI with Arduino

MIDI is well-supported in the Arduino environment, either through the usual MIDI serial connection or via its more modern USB layer. Because I don’t have a USB-MIDI adapter, we’ll go for the USB solution with the library MIDIUSB.

This library does not work on my old trusty Arduino Duelaminove, because it requires control over the actual USB connection (whereas mine is using a USB-serial chip). Instead, we can use an Arduino Micro or one of its clones.

Receiving MIDI events over USB is incredibly easy to setup, with the basic skeleton looking as follows:

#include <Arduino.h>
#include "MIDIUSB.h"

void setup () {}

void loop() {
  midiEventPacket_t rx = MidiUSB.read();

  switch (rx.header) {
    case 0:
      break; //No pending events

    case 0x9:
      noteOn(
        rx.byte1 & 0xF,  //channel
        rx.byte2,        //pitch
        rx.byte3         //velocity
      );
      break;

    // [...]
  }
}

Note how the library is rather low level when it comes to the protocol itself: you have to know byte values and how to extract the message’s content. In reality, there aren’t that many different types of messages, and you can use the MIDI 1.0 specifications for that.

The next step is to connect these noteOn and noteOff functions to the proper output for our SN76489 chip. MIDI provides up to 15 independent channels, so we can easily control our 3 square oscillators separately.

An now we can connect the thing to your computer, fire up VMPK, and you can test individual channels & notes.

At the risk of making this section read a bit like “draw the rest of the owl”, I won’t get into much more details about the plumbing because it is not that interesting to talk about. In any case, the code is in a public repo at midi2sn76489. Note that at some point in the project I switched over to PlatformIO for VSCode, because I don’t really like the vanilla Arduino environment for more than trivial sketches.

A first tune

For the demonstration here, I use a simple setup where aplaymidi will ouptut the commands from a .mid file to the MIDI hardware:

> aplaymidi -l
 Port    Client name                      Port name
 14:0    Midi Through                     Midi Through Port-0
 24:0    SparkFun Pro Micro               SparkFun Pro Micro MIDI 1
128:0    VMPK Input                       in
> aplaymidi -p 24:0 totoro.mid

And the output sounds like this:

That’s one heck of a milestone!

Envelope

Now that we can play notes, the next step we can take to make it sound a bit more natural is to implement an envelope. This is to mimic real-world sounds, where the amplitude (volume) is not constant for the whole note’s duration.

ADSR

A commonly found envelope model is ADSR for Attack, Decay, Sustain, Release:

Sustain is measured as a fraction of the amplitude, while the other parameters are time based.

In this model, a piano note would have a very short attack and decay, a reasonable sustain and a short release when the key is released (assuming no sustain pedal). Note this is an approximation, as a piano note cannot be sustained forever - we would need the sustain phase to be a downward slope but that’s not part of the ADSR envelope.

On the other hand, a bowed instrument played in a mellow fashion has a longer attack, no decay, a high sustain, and a moderate release:

You can also play bowed strings staccato, with much shorter attacks — a drum kick would have a very similar envelope:

As we can see, it’s a simple model but versatile enough for our needs.

Implementation

Again, the plumbing itself isn’t that fascinating: the volume must change with time, following various slopes. Let’s highlight a few notable details though:

To implement the envelope, we must control the volume of the oscillators with the 4-bit register Attenuation — as we’ve seen in part 1, this register goes from 0 (maximum sound amplitude) to 15 (channel is off). This resolution is not great, especially when we’ll want to control quiet sounds, but we’ll have to do with it.

Moreover, we should take a look at the MIDI specification a little closer:

As you see, incoming notes carry their pitch along with a parameter called velocity — this is basically the strength of the note, or quite litteraly the velocity of the keyboard key.

Not knowing any better, I decided to use the velocity paramater as a factor applied to the envelope’s amplitude, so both the attack peak and the sustain are impacted. It works well enough.

Here is the same tune as above, this time with the ADSR envelope and velocity implemented:

Drums

Ah, drums. There we are. The SN76489 is a bit poor when it comes to drums. Where other chips get away with the situation by providing a crude PCM channel, we are limited to one noise channel.

Noise channel

First, we can choose which type of noise we use: either periodic or white noise. Then we are provided with 3 basic input frequencies: $N / 512$, $N / 1024$, $N / 2048$. These options sound like this:

In my tests, I found that I needed to use higher frequencies than what was provided, especially to reproduce something like a hit-hat. Fortunately, the last option is to use the 3rd oscillator’s output as an input frequency to the noise channel. This means we can essentially sacrifice one oscillator output for better noise control. Combining this with envelopes, I got to the following set of sounds:

That’s… let’s go with “charming”? Creative people would probably squeeze way more, but so far that’s the best I managed to find. Here is what it sounds like in context¹:

You might be surprised that I would willingly sacrifice a whole tone channel. However, you’ll see in part 3 that this is an acceptable compromise because we’ll have tone channels to spare.

Kick

But still, can’t we do juuuust a bit more? Famous last words

Looking around I learned that certain games targetting this chip emulated PCM playback². I assume that is how they produced that “SEGA” sound at the start of the console. However, they seem to use a mode where a frequency parameter of 1 would keep the output pin high, which effectively does not work on my version of the chip³. Moreover, while that may be one way to get more diversity, why use the chip at all when the arduino has a few output pins available? I feel that this option would be pushing the project’s boundary a bit too far, so I won’t go that way.

Still, I found that the thing I missed the most was a punchy kick sound.

Here’s what this sound looks like:

Couldn’t we mimick this with a single square wave? We can imagine reproducing this by carefuly controlling one of the oscillators. Before we commit to coding, let’s simulate that first.

We’ll iterate through a frequency range going from 150 Hz to 20 Hz. To keep this simple yet smooth, we’ll wait for a full period before changing to the next frequency:

T = 0.25      # Duration of sample, in seconds
samples = []  # List of sample points, that we'll use in the Arduino code

t = 0
while t < T:
    amplitude = curve(1, 0, T, t)
    freq = curve(150, 20, T, t)
    period = 1 / freq
    samples.append((freq, amplitude, period))

    t += period

In the above code, curve is simply a function that will return a value between the first 2 parameters based on t, in a 1/x-type curve.

We can then create the actual PCM data based on this, and output that into matplotlib and IPython.display.Audio:

import IPython.display as ipd
import math

sr = 44100        # sample rate of the output PCM audio data
pcm_samples = []  # List of PCM samples

for freq, amplitude, delay in samples:
    for i in range(int(sr * delay)):
        t = i / sr
        value = math.sin(2*math.pi*freq*(t))
        pcm_samples.append(amplitude * (1 if value > 0 else -1))

ipd.display(ipd.Audio(pcm_samples, rate=sr))
plt.plot(samples)

This made it easy to experiment a bit with various curves and frequency ranges. Below are the results I settled on:

That sounds like a very distorted kick. It’s not exactly was I was going for, but it’s going in a very usable direction, I like it!

At this point the Arduino code is really not suited for this kind of “sample” (or rather, controlled) playback, but hacking the implementation is quite easy:

• We don’t need to update at a rate of 11025 kHz or more like we would if we were playing samples — we simply have to change the oscillator’s frequency & volume periodically. We already have facilities in place for the envelope, we just need special cases.
• We’re already sacrificing oscillator 3 to control the noise channel anyway, so we can use it for playback of this kick sound (and mute the noise channel while doing so).
• We can easily store the data in the Arduino’s flash.

With this new sound under our belt, let’s change our little loop above to use this kick instead:

I’m pretty satisfied with how this sounds.

Some music

With everything we’ve built so far, it’s time to have some fun and make some music! This will also drive new features as we try to make it sound interesting, as there are a few obvious things missing.

I experimented with multiple DAWs & other software, including REAPER and Rosegarden. For now I settled on the 8-track edition of Bitwig:

• It’s quite straightforward to get the live sound output from the hardware instrument back to the DAW and apply filters to it, then output it back to your sound card. Plus, finding out the latency between MIDI & sound input is just a click away.
• The UI is quite easy to discover.
• The separation between individual loops on one side & general sequencer on the other felt like a natural workflow.
• Arpeggiator!
• Finally, it’s the only tool that silently reconnected to my MIDI hardware after each of the numerous firmware updates — every other tool required some manual action after uploading a patch to the Arduino, which was seriously cumbersome.

Starting a cover

I want to start small and have fun quickly, so let’s cover some songs. That, and I don’t know how to make music, so, you know.

For my first dab at this I copied a fun track from the Modern Vintage Gamer channel. Here is a screenshot of the projet:

And it sounds like this:

That’s almost usable now! The timbre of the melody long-held notes sounds a bit flat and boring, while in the original there is a nice filter on top to make it interesting. We’ll make this better⁴.

What’s next

In this article we’ve really brought our project forward, from making random noises up to something usable: we’ve sent the first notes, integrated the MIDI protocol, implemented a basic ADSR envelope and programmed some drums.

Theoretically though, at this point the chip is still sitting on a breadboard. In part 3, we’ll make something more permanent, integrate multiple SN76489 chips together, and build a case for it all. Finally, we’ll implement more features. See you then!

If you’ve read the previous installment, you may have noticed this little aggregation of curious things:

That’s an amplifier, that’s what! Although a pretty bad one. In this article we’ll dive into the design I used here, and start exploring the fascinating, daunting, seemingly-infinite territory of how transistors work.

Note before we start: I’m really out of my depth here, and just trying to have fun. I’ve completely forgotten the little formal training I might have ever had in electronics. I don’t know what I’m talking about, so don’t quote me on anything. You have been warned.

Why an amplifier

The SN76489 chip can output up to 10 mA, which while enough to drive a small load for test purposes, begs for some amplification. Moreover, a few components I had bought or salvaged¹ a while ago were looking at me with begging eyes, so this provided a good excuse to indulge and build an amplifier. However, we only need it for testing and we’ll drop it pretty soon: it does not have to be perfect, and only has to drive my little speaker.

This article will actually be a bit of a time warp: at the time when I actually build the amplifier, I did not have any measurement tools so I couldn’t validate nor understand what this was really doing. This was a bit frustrating. Since then though, I bought a little EspoTek Labrador, so we can now take on the challenge.

Quick & dirty design

I settled on the simplest-looking² amplifier design I could get my hands on³, which you can see below. It’s pretty bad (for multiple reasons), and will damage your speaker if left on for too long. Thankfully this is only for testing, so that’s OK. It looks like this:

What do we have here? From left to right:

• A signal source. We’ll simulate our TI chip here as a 1 KHz sine⁴ wave signal.
• R2: a current-limiting resistor to simulate the limited current.
• C1: coupling capacitor.
• R1: resistor for biasing the transistor. Its exact value isn’t too clear, some use 2 KΩ. We’ll talk about that.
• Q1: transistor to provide the amplification.
• SPKR: either a speaker or a funny hat, you decide. Most speakers are about 4 Ω or 8 Ω, but not mine, no sir. 52 Ω for you.
• And to the right, our voltage source to feed the amplification. It’s only 5 V so I can power it from the Arduino.

Input stage

Let’s look at the input stage first:

I configured the signal generator to output a 2 V amplitude sinewave. Combined with the 5 KΩ resistor, we get a current amplitude of 0.4 mA. That’s small, but since the usual $\beta$ factor for current amplification is around 100, we get a maximum amplitude of 40 mA.

However, just as is the case with the TI chip, the generated signal is not centered on zero but always positive. To remove that positive bias and get a nice AC signal, we must use a coupling capacitor. Now, while this is again super common stuff, I found that notion interesting enough to warrant its own measurement:

On the left is the signal voltage, while on the right we have the voltage at the terminals of R2. The signal looks cut at the bottom, but I think that’s an artifact of my signal generator, or of my setup here.

Note that even without this DC bias from the input source, the coupling capacitor would have been required anyway to block the bias we’ll apply on the transistor’s base.

A word about transistors

Throughout this article, we’ll focus on NPN BJT transistors and ignore the other categories.

An transistor allows a certain current through its collector based on the current flowing through its base (both flow to the emitter). Note I’m talking about current only: this is probably more complicated than that, but transistors are inherently current devices. I found it easier to reason about current first, and introduce voltage only where necessary.

You get $I_c = \beta I_b$, which is why you can amplify a signal: small signal in input, bigger signal in output, mostly constant factor between the two.

There is a minimum $I_c$ for the transistor to turn on. When this threshold is reached, $V_{be}$ is at its maximum (≅0.7 V) and mostly stays there, and the transistor starts allowing current through the collector. In a real circuit, this will result in variations of $V_{ce}$, to respect the above relationship between $I_c$ & $I_b$. However, the transistor only allows current through the collector, it does not create current: if not enough can be provided by whatever source is connected to the collector, $V_{ce}$ reaches a minimum (≅0.3 V) — this condition is called saturation.

It must be noted that $\beta$ varies a lot with operating conditions ($I_b$, temperature, etc.) and with transistors (even within the same model you get different values). It seems common to assume a value of 100, at least for a start. It can easily vary between 50 and 300, so good circuits are designed as to not depend on the exact value too much.

Biasing the transistor’s base

We want to amplify a signal that varies between -1 V and 1 V. When amplifying a signal we must bias the base of the transistor up (meaning, apply a DC voltage) for two reasons:

• First a transistor only works one way, so AC signals are a no-go — we must get a positive signal only. Thanks to our coupling capacitor C1, applying a voltage will not alter the signal: it simply moves it up, exactly how we moved it around 0 in the section above.
• Second, even if our signal is 0-2 V, our transistor will constantly turn off when reaching 0 V and then back on — this would heavily distort the signal. Hence, we want to positively bias the transistor so our lower input value will still keep the transistor on.

This is the reason we have R1, to force a DC voltage at the base. The input signal will then pull or push current at this same point, influencing $I_b$, which in turn will influence $I_c$. Magic!

This is also one of the reason why this particular amplifier design is bad: when on, even without signal, we’ll always have some current running through our speaker. Better designs work around that issue with a different placement of the speaker allowing the use of another coupling capacitor.

Initial current values

We will talk in more details about the exact value and effect of R1 in a section below, because it is a treat. Notably, I’ve seen a value of 2 KΩ used here and there, but at this point we have no idea why.

What we do know is that a value too great will not let enough current through to turn the transistor on. So for a start, let’s choose a big value as a potential maximum and calculate its current in the circuit in normal operation mode, if only to check that there is enough to turn the transistor on in the first place.

Let’s start simple: while the transistor is off, no current flows through the collector so we have both $I_c = 0$ and $I_b = I_{R1} = I_{spkr}$.

In turn, the base current is $I_b = {V_{R1} + V_{spkr} \over {R_1 + R_{spkr}}} = {V_{cc} - V_{be} \over {R_1 + R_{spkr}}}$. The lowest current we can get at the base while the transistor stays off is when $V_{be}$ approaches 0.7 V.

We have $V_{cc} = 5\,\mathrm{V}$. Let’s take a big $R_1 = 10\,\mathrm{K\Omega}$ as a starting point. This also makes $R_{spkr}$ above small enough to ignore.

We get: $I_c = {4.3 \over 10000} = 0.43\,\mathrm{mA}$. This is above $0.1\,\mathrm{mA}$ which the 2N2222A’s datasheet seems to imply as the minimum base current, so we’re good: we can turn the transistor on.

Operating current values

But wait! Now that current is flowing through the collector, a significant portion of $I_{spkr}$ is diverted away from the base, and the whole situation has changed. So the above calculation, while a nice way to get us warmed up, is just not valid — at least not while operating the transistor.

Let’s start again with this new condition and see if we can solve it easily:

We’re trying to determine $I_c$, and we know $V_{cc}$ and some of the resistances so let’s start from there and make $I_b$ pop in every non-constant:

Which gives us now:

Hurray! That’s still above $0.1\,\mathrm{mA}$ with a nice margin.

Before we move on, let’s get a feeling of what the above equation for $I_b$ implies:

• The lower the resistance $R_1$, the greater the base current.
• Similarly, the lower the resistance $R_{spkr}$, the greater the current in the circuit, so the greater the base current.
• Interestingly, the greater the $\beta$, the more diverted current into the collector, so the lower the base current.

In operation without signal

Now that we have our circuit and sort-of understand how this is supposed to work, let’s build it and start measuring. As opposed to the above section, let’s start with a small $R_1$ because at this point, I figure the lower the bias resistor, the greater the base current, the better (spoiler alert: this is wrong).

Will we get the expected results according to the equation above?

Well, close but not exactly.

First measurements

Confounded by the early results, I decided to do measurements with 2 $R_1$ values. Here are the results:

Wow, OK, our assumption of $\beta = 100$ was way off. And this factor does indeed vary a lot. However, if we use the corrected $\beta$ value in the equations above, we do get the correct relationship between $I_b$ and $R_1$ so at least we’re good here.

However something really strange happened: when testing both circuit, I got a clearly stronger amplification with the biggest $R_1$. Why is this?

We see in the table that $\beta$ looks higher with a greater resistance. Could this be the reason (Spoiler alert: nope)? And if so, what is the biggest value we can get?

Exploring Beta

I got all worked up about this $\beta$ thing, so let’s measure it on our transistor.

It’s not too hard to do: with the signal generator, I can create a voltage sweep from 0 V up, and through a fixed resistor create a known $I_b$. Then, supplying a small load at the Collector with a fixed voltage, I can measure the resulting voltage drop across the load and deduce $I_c$.

This looks like this:

Or like this on my breadboard with a nut for, ah, scale:

Note I dropped the speaker for an actual resistor: the speaker was causing too much noise when the transistor suddenly turned on.

Out of this, we get the following voltage measurements:

You can’t see it too well, but $V_{R1}$ starts with a plateau, were most of the voltage drop is (I guess) eaten up by the base’s diode, and very little current is passing through. Then, we get a nice linear-ish relationship, until we approach saturation and $V_{load}$ plateaus again.

What we really want to observe are the currents and resulting $\beta$ values. However the measurements are very noisy: the Espotek’s resolution isn’t too great⁵, so we need to average the heck out of this:

We get similar-looking current curves, and a beta approximation. Again, the spikes at the beginning are probably due to the measurement resolution, which is not sufficient at the start of the graph even when averaged. The low resolution really hurts when the values are small.

While the exact $\beta$ values are not too exploitable, this tells me a great deal about this parameter:

• It does vary, especially (as expected) when nearing saturation.
• A value between 150 and 250 is to be expected at low currents, although huge variations are indistinguishable from measurement errors.
• It seems to drop a little when the base current gets higher, before saturation — although again it’s hard to tell if it’s just the error factor getting lower.

However, this does not tell much about the difference in sound output relative to $R_1$. I suspect the variations we were observing previously are measurement errors that don’t explain the significant difference in power output I was hearing.

We need more measurements while the thing is operating.

In operation with signal

Let’s measure the influence of the input signal on the output, and try to understand it.

Initial assumptions

Let’s be naive for a moment. If we consider the current amplitude of the input signal applied to the base, the amplitude of the output should be relative to $\beta$, right? We apply a $2\,\mathrm{V}$ amplitude to a $R_2 = 4.7\,\mathrm{K\Omega}$ resistance: we expect $I_{ampl_c} = \beta I_{ampl_b} = 200* {2/ 4700} \approx 85\,\mathrm{mA}$ of current amplitude in the output.

To actually measure the output signal, we’ll measure the voltage drop across multiple points, and get the bias & the amplitudes. We’ll repeat the operation with multiple $R_1$ values.

Here is a plot of the output currents. I also added their measured ranges, along with the naively expected ranges and a percentage of the former over the latter:

Note Iload is considered interchangeable with Ic for simplicity in this graph, but this does not change the results too much

This invalidates our naive calculation above, and confirms what I was hearing: while a lower $R_1$ values drives the mean current lower (as expected), the amplitude gets bigger so the sound is louder. Why is that?

Negative feedback

Well, poking around in the circuit, I finally got the answer. It turns out the approach above completely overlooks the fact that the transistors varies the voltage at the collector to regulate the current, which influences R1, and in the end its base current. Let’s see what it looks like:

In the above image, we see the input signal vs. the collector voltage (from which the bias current is derived). Their phases are opposed, ain’t that a treat? The more current must get drawn into the collector, the lower $V_{ce}$ must be, so less voltage drop is available for the biasing resistor. The bias goes against the signal, which dampens the effect of the latter. I guess that this is textbook negative feedback, and that it’s been painfully obvious for a while for the more electronic-savvy of our readers.

I may be completely off the mark with what’s about to follow, but let’s try to calculate all that. Let’s start from $I_{R1}$, dropping the assumption that it is equal to $I_b$:

Let’s assume that $R_1 \gg R_{load}$ so we can gain some clarity without losing too much precision :

This hints at the relationship we observed above: $I_{R1}$ shrinks as $I_b$ grows, by a value inversely proportional to the $R_1$ resistance value.

Let’s now try to see the influence of the signal. At any point in time, we can express $I_b(t)$ as a function of the current pushed (or pulled) by the input signal $I_s(t)$:

Which we can expand as:

Let’s rename the constants to make this readable:

Again, this confirms that the influence of $I_s(t)$ over $I_b(s)$ (and so over $I_c(t)$) is relative to the value of $R_1$ — the greater the $R_1$, the lesser the input signal is dampened (up to no dampening at all when $R_1$ reaches $\infty$), and the greater the output’s current amplitude.

Let’s plot that to compare against our previous measurements:

Not too far off! Again, I have no idea if the calculations above are anything correct but this is encouraging. I’ll consider that good enough for now.

In any case we understand why going with a greater $R_1$ helps: it limits the negative feedback that is dampening the signal’s influence on the output. Also, it reduces the constant current applied to the speaker which, while this whole thing is definitely a bad design anyway, helps a little.

Conclusion

And there we go! We started with a completely unknown amplification circuit diagram and managed not only to make it work, but understand and visualize the use of each of its components. We took a detour to measure the $\beta$ factor of our transistor. We also dug into the negative feedback applied to the transistor’s bias, and managed to find a calculation that reproduces our measurements.

Now this raises some questions:

• Why not connect R1 from the voltage source directly instead of at the collector?
• Could we place the speaker somewhere else so it does not suffer from the constant DC voltage even without signal?

Well, I would guess that’s why an actual Class A amplifier looks the way it does. And no, I’m not going to build one, that’s a rabbit hole for another time. It’s time to go back to our project.

See you in part 2.

This series (see part 1-B, part 2, part 3) will be a sort of idealized recollection of what took place over the past 6 months or so, where I tried to make music with these things. Apologies for the relative lack of pictures — I did not think for a moment that I would actually go anywhere with this.

There is a lot to talk about, so this will be split up: in this part 1, we will concentrate on setting up communication with a common SN76489 chip and getting some sound out of it. In part 2, we will start playing notes and we will set up MIDI control of the various channels. In part 3, we stick multiple chips together, build a mixer circuit and a case for our contraption and add even more features to our synth to make some music with it.

Chip music?

I guess we should start here. My understanding of what is called chip music today is music made at least partly with a set of simple waveforms such as pulse waves (square waves), triangle waves, and noise channels. We can probably throw FM synthesis in the mix as well. This is a legacy from 8-bit-era video games & computer systems: the limited capacity of the machines required the use of programmable sound generators (to which the CPU sends notes). Moreover, the cost constraints meant using few, basic chips. As a result, you get simplistic sounds on very few parallel voices.

Here are a few examples²:

• 1942’s Main background music (BGM) — or rather ambience made with percussive elements:

• Clean Sweep’s Sound 1 for background sound effects:

• Donkey Kong’s Game start with some triangle wave bass to keep you on your toes:

These constraints, as is often the case, meant that talented people started to work around the limitations to get more and more juice out of these systems. A typical sound started to emerge, a kind of “scene” grew out of isolated silos, and you get gems everywhere you look. It’s fascinating.

• Silver Surfer’s BGM on NES — arpeggios, fast rhythms, tone sweeps, the works:

• Bomb Jack’s on Game Boy — different platform, different sound but similar principles:

Nowadays I guess this sound is 100% associated with old video games. However, chip music is still being made today, sometimes on real hardware³, sometimes more as a reference incorporated into more complex songs. Here are two examples of the former:

• 🎵 Chipzel - Focus on bandcamp — Super Hexagon’s soundtrack

• 🎵 Kommisar - The Maid and the Pocket Watch of Blood on bandcamp.

I just scratched the surface here, and I could not be thorough even if I tried anyway. Hopefully that’s enough to give an idea. If you want to know more about the old days of chip music and its creators on the Japanese side of things, I found the documentary Diggin’ in the Carts to be interesting and approachable.

The SN76489 chip

Let’s get back to business.

This TI chip and its variants were used in various computers & game systems from that era: from arcade games, to the BBC Micro, to the Sega Master System & Game Gear. It has 4 channels: 3 square wave & 1 noise. It it sounds similar to what we’ve listen to above, but even more limited: no sample playback, no triangle wave, 50 % duty cycle pulse wave only.

They are still pretty easy to find today, and on some rainy day I purchased a batch on eBay. I settled on the AN variant, which accepts a 4-MHz clock.

First stages of communication: sending bytes

We need to try to talk to this thing, so let’s take a look at the chip’s datasheet.

Pin layout

This is the chip’s layout:

First, the data bus is made up of pins D0-D7. The chips needs an external clock signal, not only for operation but also as a way to derive the notes frequency — that’s on pin 14. The sound signal is then output on pin 7.

The remaining pins are used for synchronization:

• CE on pin 6 (inverse logic): Chip Enable, unless pulled to ground the chip will ignore what’s happening on the data bus. It’s weirdly spelled OE in the above picture, but later referred to as CE.
• WE on pin 5 (inverse logic): Write Enable, to be pulled to ground when data is ready on the bus.
• READY on pin 4: high when the chip is done reading data.

The inverse logic thing means that the voltage you set is opposed to the logic: pull low for true, and high for false.

Ergo, sending a byte to the chip is a matter of:

1. Setting CE to true to select the chip (this can be wired to ground if there’s only one chip)
2. Putting our data byte on D0 to D7.
3. Setting WE to true to indicate that data is ready.
4. Waiting for READY to be true.

Vague memories from school 15 years ago tells me this is pretty standard stuff. So, time to get the Arduino out?

Data layout

Wait! What should we send?

The chip is controlled by setting its internal registers, which is done by talking a simple protocol on the data bus. There are 8 registers:

• 10-bit registers for channel 0-2’s frequency control.
• a 3-bit register for channel 3 noise type.
• 4-bit registers for each channel’s attenuation (volume).

In order to set a register value, the most significant bit (MSB) is set to 1, the 3 next bits select the register, and the rest is devoted to the register’s content. For the 10-bit registers, data is sent in two stages, and the MSB is set to 0 to indicate the second stage.

Note how D7 is the LSB and D0 the MSB, “big-endian” fashion.

Clock

We also need a clock signal for this whole thing to work. I don’t have a quartz around, and I sure don’t know how to make a proper clock circuit, so I looked for other options.

It turns out⁴ the Arduino’s SoC is quite flexible and you can use it to generate pretty fast signals with counters & interrupts. Let’s get a deeper look at the ATmega328P datasheet to see precisely what we can do.

The ATmega328P has multiple internal timers, with different resolutions and functionalities. They can be configured to trigger interrupts on delays, compare values, generate waves via PWM, at high frequencies (close to the SoC clock) while letting the CPU do something else. Timer 0 is used by regular Arduino functions such as delay, so we must leave it alone. However Timer 1 and 2 are up for grabs.

Timer 1 supports a mode called Clear Timer on Compare Match (CTC). When properly configured, we can get the following behavior:

• The timer increments a counter in TCNT1 at each clock cycle
• When the value reaches a top value stored in OCR1A:
  • The counter TCNT1 is set back to 0.
  • The timer event happens: in our case, we want the output pin OC1A to be toggled.

The maximum output frequency can therefore be obtained by setting OCR1A (the top value) to 0: the output pin gets toggled at each clock cycle, so a full period takes 2 cycles. Hence, the maximum clock we can generate is 8 MHz on our 16 MHz SoC. In our case we want to generate a 4 MHz clock signal: we must set the top value OCR1A to 1 so the timer is reset every other clock cycle.

In the general case, the output signal’s frequency will be $f_{out} = \frac{f_{SoC}}{2(1 + \mathit{OCR1A})}$⁵.

To configure this mode properly, according to the datasheet we need the following parameters:

• WGM1 (4 bits) = 4 = 0b0100 for CTC mode compared against OCR1A⁵
• COM1A1 (1 bit) = 1 for toggling the output on compare match⁵
• Disable the interrupts that could be generated to the CPU⁵ — simply have the signal on the output pin.
• CS1 (3 bits) = 1 = 0b001 to disable the prescaler⁶ that can change the incrementing speed, but is too coarse for our use.

Those values are spread over multiple registers, so we must set bits individually:

• TCCR1A stores COM1A1 and WGM1 bit 0 & 1⁷,
• TCCR1B stores CS1 and WGM1 bit 2 & 3⁸,
• TIMSK1 stores the various interrupt enable flags⁹.

In the end, we need something like the following code:

void setupClock()
{
    // Setup the clock to drive the SN76489
    pinMode(clockOutputPin, OUTPUT);

    // Set Timer 1 CTC mode with no prescaling.  OC1A toggles on compare match

    // WGM1 = 0100: CTC Mode against OCR1A
    // WGM1 bits 1 and 0 are in TCCR1A
    // WGM1 bit 2 and 3 are in TCCR1B

    // COM1A0 sets OC1A (arduino pin 9) to toggle on compare match
    TCCR1A = ( (1 << COM1A0));

    // Set Timer 1  No prescaling
    TCCR1B = ((1 << WGM12) | (1 << CS10));
    // Make sure Compare-match register A interrupt for timer1 is disabled
    TIMSK1 = 0;
    // Counter top value
    OCR1A = 0;
}

Testing setup

Finally, we can get the Arduino out.

Setting up a data bus on a breadboard is easy to get wrong, so at this stage we want to keep things simple to test our setup. We’ll simply set channel 3 to max volume, and then cycle between noise values 0 to 7 with a small delay in-between. This means we’ll send the following commands:

Here is one picture I took of the setup in a flash of clarity of mind:

You can barely make out the pin layout, but it does not matter too much: there are enough pins on a simple Arduino to dedicate one to each chip’s pin. Note I decided to revert the big-endian-looking data bus into little endian on the Arduino side, because my brain is wired that way and the code looks simple to me:

void writeByte(byte value)
{
  for (int i=0; i < 8; ++i) {
    digitalWrite(DATA_BUS_PIN0 + i, (value >> i) & 1); 
  }

  // [...] Wait for write enable

One trivial detail: I pulled CE to ground via a pull-down resistor. I think it was 4.7 KΩ? At 5 V, a value of ~5 K drains an acceptable ~1 mA, and this value seems to work well.

And finally, this is what is sounds like through the feeble speaker you see on the picture:

Our first milestone has been reached!

Mistakes were made

Now, don’t think for a minute that this went smoothly. It did not, and I did a fair share of rookie mistakes.

First, notice how pin 0 & 1 are not wired on the Arduino? That’s because pin 0 & 1 on the Arduino are dedicated to the serial transmission if you set it up (which I did, because logs). So of course, if you wire them up to the chip, you’re going to have a bad time. This is reflected in the actual writeByte code.

A second, big issue I had was with dealing with the READY signal. I could not, for the life of me, see it pull up! It was just… standing there, flapping in the breeze. I’m probably missing something trivial though. I may revisit this in the future, if I put a chip back on the breadboard. In any case, after a while I decided to cut my losses and ignore the signal, use a delay instead, and move on.

Next steps

We’d now be ready to make the chip play some simple tunes on one of the other channels, or do some cool sweep. In part 2, we’ll set up the MIDI side of things so we can control the board from a keyboard or a DAW, and improve from there.

But first, in part 1-B, we’ll dive into the little amplifier you can vaguely see on the picture above.