Microtron Design History, Part 2: Making a Real Product
In this post, I’d like to walk you through the design choices I made when developing the Microtron. As I mentioned in Part 1, part of the reason for these posts is to convince you that this is a legitimate product worth your hard-earned cash, despite being from a manufacturer you’ve likely never heard of. However, this post has another benefit to you, which is that you’ll get a good enough idea of how the Microtron is made such that you could, if you are technically inclined, build one yourself. I’d prefer you buy one from me (and also, as you’ll see, I’m not giving away the REAL secret sauce, which is all the software that powers it), but should you want a high quality, low-res LED display, well, you’ll know enough to build your own. As with the first post, I’m going to write this for a broad audience, but include a reasonable amount of technical detail in case you’re technologically inclined. If you have any questions, don’t hesitate to email us at info@themicrotron.com Alright, let’s begin!
A Quick Recap
You may want to start with Part 1 for the full context, but the important bits for this post are the challenges presented by the original proto-Microtron, aka Voigt Vision:
It ran mains AC power into a wooden box, which is not NOT a fire hazard.
The box itself was hard to build, complicated, and not particularly tight with tolerances.
It was powered by a Raspberry Pi, which is basically a full blown computer running an operating system, and the user experience of having a full computer in the box wasn’t good (it takes time to boot up, you have to be careful turning it off, etc).
Updating the software was going to be a huge pain, because again, it’s a full computer but without any keyboard/mouse/usable screen hooked up to it.
Even with these constraints in mind, I posted a picture of Voigt Vision showing the Red Sox on opening day, and had enough people ask me if they could buy one that I figured I’d at least try to solve these issues. Let’s take each of them in turn.
Let’s Not Run Wall AC Current Into A Wooden Box
This was actually pretty straightforward to solve. While a lot of “wall wart” power adapters don’t put out enough current, it turns out slightly beefier power supplies designed for laptops put out plenty. I tested a few different options, and used a Kill-A-Watt to measure the current draw from the Microtron showing a bright white screen. Bright white is the most energy intense color to show because of how the LED panels work. Each pixel is actually made up of 3 tiny LEDs: a red, green, and blue one. You get colors by turning on the LEDs to varying power levels (e.g. yellow comes from the red and green pixels being on), you get white by turning them all on, and you get bright white by turning them all on to maximum power. So with all 4 panels showing white on every pixel, I could roughly approximate the maximum load I’d ever encounter. I was bracing for the worst, which would be around 25 watts/panel (5V panels x 5A rating), or 100 watts total, but in practice, it never went much above 25 watts total at maximum draw. So, instead of needing 30 amp internal power supply that the Voigt Vision used, I could go with an 8 amp external laptop supply, which is what the Microtron Ships with. Problem 1 Solved.
Let’s Make A Simpler Box
The second issue with the original design was the box itself. It had mitered corners, complicated internal bracing, the mounting for the panels was two strips of metal that they attached to via magnets, and the Raspberry Pi mount was a pain to construct. I decided to try out a rabbeted corner joint to see how it would look in comparison, and it looks really nice! It's also slightly stronger than a mitered joint, so I didn't really need to worry about having additional internal support structure. I suppose all things being equal, a mitered corner would be slightly more ideal, but the rabbeted joint looks 90% as good and has 10% of the complexity, so it's a pretty big win overall.
Rabbeted corner on a Microtron prototype box. The Prototypes were made out of pine because it’s cheap, and pinned together with nails (you can see the holes on the top). The production Microtrons have no such holes.
For all the mounting, the key thing I did here was invest in a 3D printer, so that I could make my own brackets. There are two brackets for the panels: a "single" bracket that goes on the outer edge of the leftmost and rightmost panel, and a "double" bracket that connects the rest of the panels together. The new computer board also attaches to a 3D printed bracket, and the switch plate for the power switch and power input jack is 3D printed as well. I designed them using TinkerCAD, which is effectively CAD (Computer Aided Design) for children, but it had all the complexity I needed, plus it was free. Printing a full set of hardware for a microtron takes about 4 hours.
The 3D model for the full hardware set for a Microtron. The switch plate up top is face-down. This lets me print a bit of detail on the face, and have the face be super smooth as well.
The last major change is that the Microtron boxes are made out of actual hardwoods (we offer Maple, Oak, Walnut, and Mahogany). Voigt Vision was a pine box that I stained and finished with polyurethane, which is fine but isn't particularly high quality. Pine is soft and can dent, and having to stain it adds and extra step to the process and never looks 100% natural. The Microtron is made out of actual premium hardwoods, and finished with Danish Oil, which gives it a rich, natural color without making it look plastic-y the way a poly finish can. Anyway, here are some pictures of the guts/first production run as it was being built:
Computing In The Cloud
Here is where I need to give credit to my friend Guy Dupont. He's a wizard with electronics projects, from making a clock radio that plays Bonnaroo sets to putting Spotify into an iPod. And so, needing some advice on how to ditch the Raspberry Pi, I met up with him and laid out the problems I had. His suggestion was to instead switch from Client-Side Rendering to Server-Side Rendering using an ESP-32 chip instead of a Raspberry Pi. The difference here is crucial, so I'll explain it in layman's terms. "Rendering" is the process of taking raw data, e.g. sports statistics, and turning that data into pixels which can be shown on the screen. Whatever computer does the rendering needs to be able to process incoming raw data, and then draw the shapes and text required. The basic steps are:
1. Fetch data from a sports score data source
2. Pull out the bits of data I care about (e.g. I don't care about the league leaders in batting average, because that's not something I display during a game)
3. Draw the scoreboard, filling it with the correct data
4. Repeat every 30 seconds or so to make sure everything is up to date
Here are the pitfalls:
1. The data source can disappear. MLB or ESPN or whoever could shut down their data pipe, and I'd have to find another one (there are plenty out there, so long term it's not a concern, but switching data sources would be less than pleasant in the short term).
2. The data format could change. The data comes in what is called "JSON" (“JavaScript Object Notation”… don’t worry about it) which is a human and computer readable format. For example, here's a bit of team data:
"team": {
"id": "152",
"uid": "s:20~l:23~t:152",
"location": "NC State",
"name": "Wolfpack",
"abbreviation": "NCST",
"displayName": "NC State Wolfpack",
"shortDisplayName": "Wolfpack",
"color": "EF1216",
"alternateColor": "231f20",
"isActive": true,
"venue": {
"id": "3670"
}
}When I want to fetch the team name to show on a Microtron, I look up what's listed under "shortDisplayName". However, if my data source decided it wouldn't send down something for "shortDisplayName", I'd have an error when I went to look for it. The exact layout of the data matters when you're having a computer try to pull it apart.
3. I could decide I want to show something different (e.g. maybe I do want to show league leaders), or show the same thing in a different way.
4. I might not want to update every 30 seconds. I might want to update every hour if there's no game on, or every 15 seconds if it's a more time sensitive sport.
Voigt Vision used client side rendering, where all the steps above were done by the Raspberry Pi. It pulled down data, it parsed it, it decided how often it would fetch fresh data. This meant that if anything broke, I'd have to push out a software update to each and every box or it would be broken, which is a huge pain.
The Microtron, on the other hand, uses “Server Side Rendering”, where all the Microtron does is fetch an image that's generated by the server, and show that image. If anything goes haywire with the data, or I want to change the layout of a scoreboard, or add more sports, I just make changes on the server side, and all Microtrons are instantly updated. All the Microtron is responsible for is repeatedly asking the server “hey what image should I show, and when should I call you back?”
The ESP-32 chip itself is far dumber than a Raspberry Pi. It has no operating system, and very little memory and processing power. However, it boots up instantly, can be shut down at any time, and has built in wifi. Overall, it's a far better setup than a Raspberry Pi. At this point, there's only one challenge with this setup, and that is that animation is impossible in the current configuration. The Microtrons are only fetching one image every few seconds, and animation requires them fetching several frames at once. The low low power and memory of the ESP-32 currently prevents that from being possible, however there are some solutions I may try in the future. If I do wind up upgrading the hardware, all existing Microtrons will be eligible for an upgrade at a reasonable price, and the current hardware will continue to work in perpetuity anyway (it's pretty good as is!).
The ESP-32 also needs to be mounted on a board that has the connector for the LED panels. Once again, I turned to Guy, who designed a custom Microtron circuit board and got them printed up. All of the components are then soldered onto it:
And that’s pretty much it! A bit of wiring and Quality Assurance testing, and a Microtron is complete. The production model of the Microtron is sturdy, reliable, and not a fire hazard! There’s some stuff I picked up along the way about the way to produce these consistently and reliably, and a bunch I learned about doing image processing in the cloud, but I’ll save those for another time. Thanks for reading, and like I said at the start, if you have any questions, feel free to email me at info@themicrotron.com.