It's the Leaderboard That Nobody Wants to Sit Atop: Joey Castillo's Keeping Tabs on the End of Times

Joey Castillo has a thirst for data.

From his popular Open Book project — that source of which now sits on ice in the Arctic! — which has received warm reception from places like the Reddit front page, Gizmodo and a great many more, to the tongue-in-cheek Hiking Log, to the more recent Temperature Hat, his passion for data is one of the purest project pursuits we've seen.

The thing is, with a pure drive like that, data is data. And while some people might have a legitimate point of offense to take with the nature of his latest work — we can't fault the essence of the project — a scoreboard that keeps tabs on the most prolific adversaries known to humankind, tracked by the total number of wins they currently hold over our species, simply known as the big board of death.

These are somber scores.

The one time you really don't want to see a clear winner, or even any participants placing on the podium, is when it comes to the teams trying to topple us. Assembled in an all-night board bring-up binge, these metrics mean a lot to Castillo prolific driving him to deftly wield his soldering iron in pursuit of the data points that potentially pose plague and pestilence upon all of us.

Perhaps there is a hidden message in the work however, with 4th place being taken a recent addition to the leaderboard - the figure associated with this position being truly shocking to consider, given only how recently it has blighted our communities.

Diving into the tech that makes this leaderboard tick though, it's not all doom and gloom. There are a number of neat little tips and tricks we can take away from this build. First, let's take a look at the LED display boards that Castillo has crafted for this score counter.

Each line of the big board of death is brought to life with a module of Castillo's own design, based around the HOLTEK HT16K33 I2C LED driver.

This is a popular LED driver IC, and with the ability to drive a 128 element LED matrix (16 segment rows, eight columns), it is capable of doing a fair amount more than driving alphanumeric character displays!

Adafruit have embraced this part, with a range of boards designed around it, allowing you to get up and running with the HT16K33 quickly prolific either in raw, IC breakout format, or paired with a suitable alphanumeric LED display, as shown below.

The benefit to having the backing of Adafruit is twofold — not only in that there is going to be a decent software effort available for you to base your own derivative works from, but also in that they freely publish hardware design files for nearly all of their products.

This latter point means that it's really quite easy to springboard from their hardware designs, and get a massive "leg up" when designing your own hardware, based around the same parts.

Show below, is one of the 21 modules from the big board of death — essentially derived from one of the adafruit module designs, but with a few enhancements to make it fit for Castillo's purposes.

These enhancements include most notably, the expansion of the LED matrix that the HT16K33 is driving — boosted up to 120 segments (14 segments per character position, with a decimal place makes 15, multiplied by eight character positions within each module).

Further to that, the addition of a local 3.3V LDO is likely a lesson learned from dealing with voltage drop across large LED displays — having a good, solid local power source is something you want built in from the start of a project such as this. Not to be tacked on in a mess of trailing mod-wires after the event!

And as as if the form factor were not suggestion enough, the connectors for the module have been upgraded in function — now having two points, one at each end of the module, with the intent of enabling modules to be strung together, as many as can be supported by the I2C addressing scheme of the HT16K33.

Speaking of I2C addressing...

The people sat on the front row of this lecture might have noticed the I2C address jumpers present on the module, located just to the left of the handy silk screen box upon which is described the module colour mark.

With 3 bits of address data to feed into the lower address byte of the HT16K33, this allows for 2^3 = 8 modules to sit within the same I2C bus address space.

Those same eagle eyed students may also have noticed the error in the 2nd image of our article here — in that lines 4 and 5 of the display (zero indexed) show the same count...

Hardware straps are great for configuring addresses, etc, but you just have to make sure that they are very... "cleanly" strapped. The barely visible solder bridge shown above, between the pads of the A2 jumper, was enough to "clone" the module address in use for the previous line, resulting in the same data being shown on both modules.

Nothing that a little spot of rework can't fix however, and with all the correct data in place, the figures look a little less suspect, if still pretty overwhelming.

Shout out to the SERCOMs

So, even with a potential upper limit of eight modules on an I2C bus, you might still be left wondering how on earth the big board of death is wrangling its way into making use of 21 of these HT16K33-based LED modules, seemingly from one single processor?

Well, that's down to a few things. The first, very core part of the setup that allows for this myriad of modules is the fact that the Microchip SAM D51, upon which Castillo is orchestrating his code, has a plethora of serial peripheral modules from which to instantiate the numerous I2C instances needed for this setup.

That sounds a bit hairy to the novice or newcomer to this line of work, but given that Castillo is coding this project using CircuitPython, spinning up multiple I2C buses can be done in as many lines of code.

That's about as simple as a declaration for an I2C bus as you're ever likely to see! And, owing to the simple hardware interface that I2C offers, the wiring isn't much more complicated — anyone who has worked on I2C buses before can likely spot the pull-up resistor pairs mounted on the perfboard FeatherWing below!

We were going to suggest that these were the aptly sized 2K2 resistors (or approx) that we'd expect to see on a 3.3V logic-level bus, but... well, remember we mentioned that Castillo pulled an all-nighter on this one?

Not to dwell, after all, we can see that the I2C bus is fairly forgiving in terms of the value of pull-up resistor employed, and the CircuitPython I2C driver looks actually quite solid, compared to other implementations; Castillo mentions the occasional driver message that actually alludes to the wrong (or open) value of pull up resistor. That's a very nice feature to have.

Using CircuitPython to code this casualty counter also means that there is a wealth of example code and drivers from which to draw upon, further simplifying development of this project.

That is a massive advantage, not only for dealing with the display side of this board, but also when working with sourcing the data to be displayed upon it!

With the score tally defined as a JSON object, pulling down the latest stats is a simple as instructing the ESP32 WiFi "AirLift" co-processor board to connect to Castillo's thebigboard.cc site, and pull down the latest file.

I'm guilty of having thrown shade at CircuitPython before, but even I have to admit, this level of simplicity is pretty awesome when it enables one to throw something together as easily as this, despite the somber overtones in this specific instance.

In fact, the entire CircuitPython script running the BBOD (big board o' death) falls in at under 200 lines of code, including whitespace, with about 100 lines of that taking care of instantiating every display module in the matrix, the other 90-odd lines form the functional operation of the leaderboard.

This could be a pretty great introduction to I2C for the aspiring hardware hacker, especially in conjunction with CircuitPython as the codebase running the show!

If you want to set up your own scoreboard, for whatever metrics you wish to track, we'd suggest checking out the project's component part — the gist — containing the CircuitPython script that runs the show — and additionally, the EAGLE hardware files for the Oddly Specific Object branded HT16K33 modules of Castillo's own design.