Shortly after I revamped the site, I realized that I had a problem. There’s a nice feedback mechanism, but no way to tell if anyone uses it unless I go and look. It’s far too easy to miss incoming feedback.
Sure, I could just make it email me or something, but I really don’t want to do that. My phone is forever notifying me of various things, and important notifications have a tendency to get lost in the chaos. Plus, 99% of the feedback I get… is spam.
Yes, some ass with way too much time on their hands has written code that finds – and submits spam to – feedback forms on the web. Do NOT get me started!
In the mean time, what to do? I want a way to be made aware of waiting feedback, but I don’t want it to be intrusive. I spent a lot of time thinking about this, but it just wouldn’t come to me – and then I got bored and built a display toy out of 14-segment displays…
The Plan
As amusing as my little internet signpost is, it’s not quite right for what I have in mind here. For one thing, a Raspberry Pi is overkill; I only used it in that project because it was there and it was easy. I’m willing to spend a bit more time on this project, though, and that means not wasting an expensive, hard-to-source computer on each incarnation.
It’s also far too large, and not nearly portable enough – and I wouldn’t want to deprive you of the toy you enjoy sending messages to!
Instead I’m thinking a little smaller. Probably twelve characters like the signpost, but in a much more compact form. An ESP8266 or ESP32 can provide the connectivity, and there will possibly (probably?) be another small microcontroller dedicated to handling the actual display work.
I can set up a nifty protocol for identifying and sending messages to these things, and then build a bunch of them and sprinkle them around the house. One of those messages – frequently updated, of course – can be the number of messages waiting in my feedback queue.
Problem solved!
Or at least, it will be…
Potential Pitfalls
The biggest issue that will likely present itself is the fact that I want to be able to conveniently pick these things up and move them around, and that means that they need to be battery powered. This wouldn’t be as much of an issue if they were LCD-based with no WiFi, but… they’re going to be LED-based, and have WiFi.
Both of which are power hogs!
So that’s going to require some design. I have a few ideas on keeping the power requirements modest; if I can get a week out of a power supply, that would be ideal, but I’ll settle for a couple of days. Also, I want them to have USB inputs so I can plug them in where it’s convenient as well. Flexibility will be the key.
Of course, that leads to issues surrounding the processor.
The ESP series are cheap and work great for WiFi connectivity, but anything involving WiFi is going to chew through batteries. I’m going to have to do some research and planning to see what can be done here. My current thought is to dedicate something like a low-power STM32 to the display and keep the wireless powered down most of the time.
Of course, that leads to the question of udpate rate; right now I’m thinking once per minute, but we’ll see.
Another issue I’m going to have to research is ESD protection. That’s what killed my last TuneConsole: I accidentally zapped it with static electricity, and it no longer works. I don’t want to see that happen here (or with my future TuneConsole replacement!), so I need to learn about how to protect portable devices from that sort of thing.
Candidate Parts
The displays that I used in the signpost were fairly cheap when I bought them a couple of years ago, but now they’re pricey – $4.36 USD in small but workable quanitities, which means more than $25 for a single 12-character display. That’s… a little pricier than I would like, so I did some looking around.
SparkFun is selling some nifty displays (purchased via DigiKey in this case) that are actually reasonable candidates. Originally I was digging for 7-segment displays, but these are 14’s, and they’re a mere $2.50 a pop, and they’re four-character units! That’s a fraction of what the others cost, so that’s a win – plus, they come in nifty colors!
I ordered some. The image on this post is one of them. I like them so far, though I have yet to power one up…
I also popped for a Nucleo board with the STM32G031 on it. Somewhere in my lab is an old Feather with an ESP8266 on it, so I can play with that as well. For testing and tinkering, that should be enough to get started.
The Long Haul
Unlike the Boredom project, I’m actually angling for something a bit more polished here. That means that I’m going to have to put a bit more effort into it. How, you ask?
A proper case, for one.
If I’m going to drag these things around the house – or even just leave them lying around – they need to look good. I’ll have to find a good CAD package and whip something up, and probably will hit up my brother-in-law to 3D-print them (I don’t want to invest in my own 3D printer just yet, though that day will probably come eventually). That’s about all I have on that score so far…
It also means that I’ll have an excuse to have some PCB’s made. I do enjoy tinkering in KiCad!
But where to have them made? I’m not sure yet. OSHPark is a candidate, but so is JLCPCB over in China. The latter has the advantage that they’ll do assembly, and that is admittedly attractive if the price is right. And those are just two of many; lots to think about there.
Off To The Races!
The way I figure it, this project will have a few distinct elements:
Tinkering: Figure out what we can do power-wise with the displays. They’re going to be the number-one energy consumer. That and consider options with respect to WiFi power management.
Design: Yes, this one will actually have a design phase! I’m going to mostly know what I’m building, before I’m done building it!
The Build: And then we get to build the hardware! Yay!
Packaging: Figuring out how to package it. I expect this to be a rabbit hole all its own because I’m not very well versed in CAD and the like.
Firmware & Software: This one will have a fair bit of code involved, and I’m not even sure what language I want to write the firmware in. I’m thinking that I might use the Arduino IDE, or maybe just straight-up C/C++, but we’ll see. TinyGo is a fun thought, but I don’t think it’s going to be viable for this. It’s just not mature enough, especially where the ESP line is concerned. I expect that rust will have the same issue, and I don’t much care for what I’ve seen of rust syntactically anyway…
Some of this will overlap based on stalls and things, and I’ll post here as progress continues. Note that I don’t have a schedule for this, per se; this still really falls under the “art” category. I’m doing it for me, and as I have an interest.
Don’t forget the reason for the name of this site…
I will, of course, document things on the project page and in various posts as I go. That way, you can point and laugh as I bumble my way through the process…
Enjoy!