Today has been a non-hardware day, estimating the energy usage of the display under the various algorithms. I simply wrote a program to run the math, and found that my answers from yesterday were correct enough to be going on with.

My thinking on this is fairly straightforward: the perceived brightness of the display is directly proportional to the amount of energy it consumes. No amount of scanning trickery will change that. You want more brightness? Apply more power!

Color me surprised.

Not…

The Verdict

As amusing as playing with these algorithms was (and is), I want to move on, and I think we have enough information to make a decision or two. There are other investigations I want to get to (such as the wireless bits!).

The short version: we’re going with the row-scan method.

I did consider doing the multi-mode trick as in the demo (where the current limit can be applied to either anode or cathode depending) just in case I change my mind, but it needs far too many MCU pins – more than the demo used, since we will likely have three display modules (though I’m now debating using two, for an eight-character display).

It works out something like this, including support for dots and colons, sorted by total GPIO requirements¹:

As you can see, it just gets a little ridiculous. Even just going with 8 characters would require a 64-pin MCU at a minimum if we supported both modes! There may be a more clever way to wire it that wouldn’t require that, but all the ways I can think of offhand would require external components.

In the end, it’s not worth it.

Using the row-scan algorithm in combination with PWM dimming will allow us to do whatever we need to do. I’m not entirely thrilled about using the harder-to-implement algorithm, but it’s worth it for the extra bit of brightness. And we can still implement the ultra-low-power one-segment-at-a-time modes; we only lose proper support for digit-at-a-time.

So yeah. The current limits will be on the anodes, which lets us light more of the display at any given moment, for a much brighter future.

I’ll play more with display algorithms later; I have thoughts on that…

What’s Next?

It’s Easter, so the rest of the day is a bust; I’m going to go hang out with family. But tomorrow? Hmmm…

My Nucleo boards arrived, so I have an opportunity to play with the STM32G031, which I’m kinda interested in. It’s a very low-power CPU, and I think it would work well for this application. The bigger looming questions, though, surround WiFi, and the ESP8266 (or maybe ESP32).

Mostly, it’s going to be about power consumption again, but that’s neither here nor there.

Up next:

• Make the ESP8266 work, probably via MQTT, in some kind of “mostly asleep” mode, and see just how far down we can get the power usage. Time to dig up that feather that I have floating around…
• Start looking at power issues. As one example, while I have no illusions about powering this with solar in its entirety, the idea of a couple of small solar panels to extend battery life does hold a certain amount of interest. We’ll see where that thought goes.

So many things to play with, so little time!

And I need to go, because I’m late! We’ll see if I see you tomorrow…