Strictly Normal goes PI


One thing that has been itching me for some time now was to take my strictly normal line and manifest it as something less static and more dynamic.

I did this in one manner a few months ago (or to be more precise, it felt like only a few months ago, but it was closer to six months ago) in Sequent 14 — obligatory video snippet:

Today, I finally got around to doing it in another manner — pretty obvious from the video at the top of this page — as an embedded-able LED-based installation — thanks to some suitable parts coming onto the market recently.

Parts Required

Some parts required

Rather than using a Raspberry PI, I decided to use the PI Zero. This seemed perfectly perfect for this kind of project — not only is it exceedingly tiny (and therefore exhibits a high “cuteness” factor), it has the benefit of being extremely cheap, and comes BTO with built-in WiFi and Bluetooth (the PI Zero W model).

A LED HAT. There are two available… a new model with 7 x 17 LEDs which are individually adjustable vis-a-vis brightness… and an older model with 5 x 15 LEDs, unadjustable brightness (and, according to the reviews, very bright). Of course, the new model was unavailable — sold out, apparently, and unavailable from all the distributors I looked at — so I had to content myself with the previous generation.


Some soldering required. Can I find my soldering iron? No. Cue a trip to DIY store to get one. And so, there we go, after 5 minutes it is assembled (just the 40 PIN header to attach).


The driver for the LED HAT was really nice, and it didn’t take too long to integrate it with my existing strictly normal code.

One slight oddity was that the line itself didn’t appear to be strictly strict. After some head-scratching the issue turned out to be a small bug in my code… due to a division operation switching implicitly from float to integer, which introduced some rounding errors. Forcing float fixed it.


The Strictly Pi One installation, as I’m calling it, has been running for a few days now… no crashes, no hiccups, it just runs… updating the display every 500ms or so. Its quite mesmerising having it running. Long exposure to it has brought up an issue: the display is too small! At 5 x 11 pixels the number of potential strictly normal lines that can be generated is small, so after too short a period repetition sets in… this itself isn’t bad, but its happening often enough to be perhaps too noticeable. The solution is to use a bigger LED matrix, but for that the current supply restriction is the bottleneck. One way to circumvent this is to use an alternative display system such as WS2811 or WS2812 the newer WS2813 strips… and that implies a substantial increase in size (as each strip would be about 1m long!) and cost (the minimum number of strips is 7).

Update bis

Looking back, I like the slower pace of _Strictly Pi One compared to the frantic pace of Sequent 14. One thing I wanted to introduce is the aspect of time… on one hand, the time taken to generate each iteration is never fixed but slightly variable (due to the underlying math)… and on the other hand, hybridity and melding in the cultural world is itself slow and should this similarly be reflected in the pack of my visual world? I suspect that when I change the size of the display I will need to adjust the update delay… something that can’t really be predicted until its built and operating.

Update bis bis

Building and running Strictly Pi One has been such a fun experience. I should have done this months ago!

Yes, another update

Q: How many unique strictly normal lines are displayed?

A: 2,835.

Q: How many iterations are required to show all 2,835?

A: 24,778 iterations.

Q: How long will that take?

A: About 3 hours 45 minutes.

Q: Will those numbers change?

A: No and yes. The number of uniques is fixed; there are a finite number of possibilities. However, the order in which they are shown, and hence the number of iterations that must be shown before all have been displayed, depend on pseudo-random number generation; the seed for the pseudo-random number generation affects this.

comments powered by Disqus