Two days ago we wrote that the screens in the rig are getting rebuilt. Since then the tools we use to build them put out a new release, and it contains the one thing that has slowed this kind of work down since we started: you can now run a whole screen, your own code and all, on a laptop, before a single board is plugged in. Here is what that changes, the new parts of the drawing library heading into a module we are starting on now, and a complete working project you can take.
What actually changed
EEZ Studio is the drawing board for our screens. You lay a panel out in it, place the gauges and the buttons, set the colours, and it produces the code that runs on the display. It is free and open source, made by a small team at Envox, and we gave it a full tour back in June.
It has always had a Run button. What that button did was show you a picture of your screen. You could see where things sat and what colour they were, and that was the end of it. Press a button on the preview and nothing happened, because the part that decides what a button does is code, and the preview never ran any.
The new release runs it. Your own code, your own buttons, your own readings, compiled and executed on the desktop. Press the theme toggle in the simulator and the screen actually goes dark, because the same function that would run on the board just ran on the laptop.
That sounds like a small distinction. It is the difference between checking that a screen looks right and checking that a screen works.
Why this matters to anyone building anything
Before this, judging a screen meant building the firmware, flashing it onto a physical display, and walking over to look. Several minutes a go. Do that thirty times in an evening and you have spent most of the evening waiting.
The real damage is not the waiting. It is that you stop making changes. When every nudge of a button costs three minutes, you talk yourself out of the nudge. Screens end up shipping with the small wrong things still in them, not because nobody noticed, but because noticing was cheap and fixing was not.
A few seconds instead of a few minutes changes what gets fixed. That is the whole benefit, and it lands on the person looking at the panel in their rig rather than on us.
There is a second benefit that costs us nothing. Anyone can now open one of our screens and press play without owning any of our hardware. If you have been curious about what is actually on these displays but not curious enough to order a board, that is a short detour now instead of a project.
Being straight about what it does not do
It is a simulator, not the rig. Two things it will not tell you, and both of them cost time in the making of this.
The first is anything about the hardware itself. A screen that runs perfectly on a laptop can still sit frozen on the board because of one missing timing call that the desktop version supplies for you. That happened here, and no amount of simulator work would have caught it.
The second is the network. Getting the wireless side of this particular board talking ate an afternoon on its own, and the simulator was cheerfully unaware that any of it was going wrong.
So the board still gets plugged in. It just gets plugged in later, with the screen already known good, and with the remaining problems narrowed down to the ones that are genuinely about hardware.
New parts, and where they are going
The other half of this is LVGL, the library that does the actual drawing on the chip. We wrote about moving to version 9 two days ago. The drawing board has now caught up with enough of it to use the interesting parts.
The gauges are the visible one. Here are two of them, straight out of the simulator.
Look at the battery ring on the left. The outer band runs red at the bottom of the range, amber through the middle, and green once the bank is healthy, and there are real tick marks around the edge rather than a smooth arc with nothing to read against. That colour banding is a setting now. Previously it meant stacking rings on top of each other and hoping. The number in the middle sits with its unit at a smaller size beside it, which is one widget rather than two labels nudged into alignment.
The solar card does the other new trick. How far that amber arc sweeps is worked out from the watts coming in, rather than being pinned in place when the screen was drawn, and the labelled scale underneath gives you somewhere to read 408 against without squinting at a number.
Every gauge in the rig is going to look like this. Milepost on the wall, Fireside in the living space, Spotter up front in the tow vehicle, and a newcomer we have not named yet. That one is still a surprise. More on the hardware and what its interface does when there is something worth showing.
Underneath that there is a layout system that describes a screen as rows and columns instead of pixel positions. Nothing on this dashboard is placed by hand. Change the display size in the project settings and the whole thing reflows to fit, instead of stranding half the widgets off the edge. That is the part that decides whether a screen we build for the wall panel can also run on the small display in the tow vehicle without being drawn a second time.
There are quieter ones too. A single widget that draws a number and its unit together at different sizes, so 46% reads as one thing instead of two labels nudged into place. Fonts that merge an icon set into the text font so a battery symbol and a word can sit in the same line. Text that never changes now says so, which keeps it out of the work the chip does every frame.
There are several devices sitting on the bench for that unnamed one, and this is the toolkit it gets built with. That work starts shortly. For now the pieces are proven, and the sample they were proven in is public.
The sample, and what it is
The project in the video is a real thing, not a slideshow. It is an off-grid power dashboard: battery state and voltage, solar coming in, fresh and grey tank levels, arriving over the same messaging the rest of the system uses. It runs on a seven inch Waveshare ESP32-P4 display, and the same code builds and runs in the simulator.
It ships with a synthetic feed switched on, so a freshly flashed board shows moving gauges straight away with nothing else connected. One setting turns that off and hands you the place to wire your own readings in.
Everything is in there. The project file the screen is drawn from, the hand written code behind it, the fonts, and a build document that lists the four things that cost us the most time, including a version mismatch that produces errors pointing at entirely the wrong place. We would rather you skipped those.
One caution: this dashboard reads a battery bank and switches nothing. It is demonstration code, published to teach the tools rather than to be bolted into a vehicle. Much of it was written by an AI agent and reviewed line by line by a person, which is how we work and is said out loud rather than buried.
Take the whole project here. MIT licensed, same as everything else we make.
The Waveshare link above carries our affiliate tag. It costs you nothing extra and sends a small cut back to the project. If you would rather it did not, strip ?&aff_id=Trailcurrent off the URL and buy it clean. We would still rather you had the information.
The instructions we give the agent, updated too
We build screens with an AI agent doing the repetitive part, the hundreds of small placements and settings that make up a screen file, and then a person opens the drawing board and looks at the result with their own eyes before any of it goes near a display. The editor stays where humans make the calls.
That only works because the agent is given a long written brief on how to behave itself, including a list of the specific ways it tends to produce something that looks fine in the editor and wrong on the device. That brief has been updated for everything above: the simulator, where hand written code is allowed to live so the simulator can find it, and the new widgets. It is published on our GitHub with everything else, and there is a post about why we give it away if that side of it interests you.
Thank you, and why we bother posting this
TrailCurrent has three goals. Build a real open source Software Defined Vehicle platform. Give it away. Teach other makers how to do the same thing with their own ideas. This post is the third one.
The simulator is not ours. It is the work of the people at Envox who make EEZ Studio and give it away, and it sits on top of LVGL, which is behind an enormous number of screens you have touched without knowing it. Neither has ever asked us for anything. Every tool we use to build TrailCurrent is open source, top to bottom, and this is a good week to say so.
If you build things with screens in them, both are worth your evening. Start with the sample, press play, and see the thing run before you have bought anything.
More of this goes up on the open source channel, and the module these parts are heading into will get its own post here when it is ready to be seen.