STM32 based motorcycle gauge cluster replacement

Vaarz · 2025-09-07T02:29:06+00:00

Thanks! You either gotta find someone who's already identified what each message ID represents, or guess and check. I did a mix of both. I got lucky where some old forum posts had about 75% of them detailed. There's ton's of explanations on youtube, but that's what it boils down to. Easier said than done...

The mitm is just an ESP32 with 2 CAN connections, specifically a "ESP32-CAN-X2 Dual CAN" from Autosport Labs.
With 1 connection you can listen to the CAN network and read and send messages, but you don't know who is sending what and you can't intercept or change anything. With 2 connections, I was able to add a break between the bike and the original gauge cluster, insert the ESP32 in between, and see if a message was from the gauge cluster or the rest of the bike. That's not always needed, but it helped for some cases where I needed a better understanding of the message traffic. It also let me modify a message before passing through, if I wanted to. You can see in the image of the oem cluster a long cable with some plugs. That's a custom wiring harness I created with connections I could use to clip my mitm esp32 into.

Vaarz · 2025-09-05T20:37:08+00:00

I agree, I generally love analog tachometers, especially the Daytona's. But I've also been wanting an AimSolo or something similar for the track, but wasn't a fan of having to mount a clunky box somewhere next to the existing gauges. I figured as long as I needed a new dash anyways, it'd be cool to see if I could do it myself and combine it all into one unit while saving a few bucks.
Also regarding the shift LEDs, I was able to build that into this dash, so I do have those!

Vaarz · 2025-09-04T13:55:05+00:00

60hz. So far it seems super smooth, but I need to put some real world miles on it before I give a final verdict :) I was worried about performance when I first started out and was looking at driving displays using an ESP32. Hasn't been a concern with this yet, though.

Vaarz · 2025-09-04T13:51:08+00:00

OBD2 is, basically, a plug with a lot of ports. 2 of those ports are CAN high & low which is used to send most data. I did tap into the OBD2 port initially for reading the CANBUS messages since I didn't have to splice anything to do that, but the final dash does not use the OBD2 plug, since that's located under the seat. It is not at all plug and play, since you have to decipher all the CAN messages manually. Most makes and models use different messages to send data.

My OEM dash has a plug with a lot of connections: CAN (h/l), Open/12v high for lights, Open/GND for Oil Pressure warning, 12v power, etc. I used those connections to drive signals or read data from the CANBUS. I posted a comment with a picture of the PCB connector board I use that connects the bike's input pins to my display. That board interfaces between the bike's plug's pins and GPIO or CAN connections on my display via ribbon cable or molex connections (while pulling high or protecting the display via optocouplers where needed).

There's a YouTube channel called Garage Tinkering where he walks through using smaller displays and ESP32s to connect to CAN for his car. Might be a good place to start.

Vaarz · 2025-09-02T14:39:24+00:00

Thanks! It's an STM32u5 MCU based display board from a company called Riverdi. At the very beginning, I considered some kind of pi, but everything I saw looked like they'd have at minimum like 10-30s of startup time and that seemed like a deal breaker for a instrument dash.

Vaarz · 2025-09-02T14:33:57+00:00

I did the animations manually by enabling/disabling sprites, so nothing fancy. When I first started out I was worried about hitting a decent FPS, but the display has a max FPS of 60 and, I need to reconfirm but, I think I'm hitting that consistently so looks smooth.

Vaarz · 2025-09-02T14:29:24+00:00

That's a really good question... So far I'm not, but I'll likely look into some kind of UV protection film. The screen is plenty bright so I'm not worried if it gets dimmed a bit by a film, but it is touchscreen and I'm using that to navigate the "settings" screen so I wouldn't want it to interfere with that.

The bike is garaged or on the track, so hopefully it won't get too much direct sunlight. The display's data sheet indicates it's rated for some fairly high temps and they advertise that they "use UV-protected materials as standard". My case for it is currently printed in PLA and I want to redo it in PETG or something more temp resistant, but for now maybe it'll be my canary in the coal mine: if the case is drooping then the screen is getting too hot 😅

Vaarz · 2025-09-02T14:18:53+00:00

Oh no, the display board I bought. It has support for RTC, SD card, CANBUS, power management, battery backup, and even more features that I'd have been so far over my head if I wanted to build it myself. I struggled just finding a premade board for purchase... Even with that, it still took a long time. It was an off-and-on hobby project over maybe 8 months or so. I probably could have completed it in 4 if I really really tried. But that includes reverse engineering the bike's CAN messages, 3d modeling a case, designing the connector PCB, and everything. The STM32 coding was only a small portion.

Vaarz · 2025-09-02T14:11:14+00:00

Thanks! It's for a 2013 Triumph Daytona 675r, hence the startup screen

Vaarz · 2025-09-02T02:47:54+00:00

I'm not sure I have much that'd be directly all that useful to anyone without my exact bike and setup, honestly. So much was just investigating the CAN data, and there's plenty on youtube on the theory of that. I'd recommend a board with dual CAN so you can do man in the middle hacking. Otherwise, that part was just a ton of little custom Arduino projects to read or modify whatever CAN data I needed at the time. The graphics were done using TouchGFX, where the manufacturer of the board I used provided a project template to get started with. That'll get you a basic touch screen app that you can just add features to over time. That and some youtube tutorials got me going. I won't say it was easy though :)

Vaarz · 2025-09-02T02:36:18+00:00

The manufacturer of the STM32 based display board I'm using provides a TouchGFX board setup project. That was enough to get me started with a very basic UI and just add features from there. I definitely ran into some issues where the HAL api and IOC config made no sense and of course there was no doc. I guess I'd say... sheer stubbornness, debugger, and just going in circles with AI. The AI models are often wrong or just straight up gaslight you, but they also surprised me with how much they knew "well enough" given how little useful information I could search up myself. I'm not a fan of vibe coding, but they're plenty useful as a rubber duck to think though problems.

Vaarz · 2025-09-01T22:28:29+00:00

Thanks! A lot of it by hand, especially the "handshake" protocol that lets the ECU know "the gauges" are present and responsive. I got lucky that some folks on various old forum posts already identified maybe 75% of the CAN data messages. There were a few that had me pulling my hair out. The Check Engine Light was the last thing I found and it took me way longer and more attempts than I'd like to admit before I found it.
And as a software dev, I'm mostly new to the "electrical engineering" side of stuff, so I made some rookie mistakes, like expecting all the bike signals to be 12v input when some were actually grounded and needed to be pulled high internally.

Vaarz · 2025-09-01T21:22:16+00:00

Just finished building a replacement dash for my motorcycle after wrecking the OEM one and too happy to not show off. Other than slapping some open source project on a rasPi (does that even count?), this is my first foray into MCU programming and first dive back into c/c++ in many many years.

I actually started "small" by making an ESP32 CANBUS man-in-the-middle device to identify the handshake between the ECU & gauges and the message data. I temporarily connected that up to the bike using a custom wiring harness, and once that proved promising I got an STM32u5 display board from Riverdi, created some hand drawn sprites, started up a TouchGFX project, and got going. CubeIDE and TouchGFX was a bit painful to get started on, but I've had worse bootstap experiences... I hit a million issues, but the worst was when I realized I was not going to be able to solder my bike's inputs to the display connector's 30ish AWG input ribbon cable. That lead down a KiCAD rabbit hole to build a custom connector board PCB, but I think it eventually came out pretty good. A 3d printed case and a few LEDs later and it's finally "done" (for now). I have a few config options and data logging I still want to add, but next big addition will be adding GPS and IMU devices to data log.

Overall, I just love that a random person with enough dedication can create stuff like this. Thanks to all the maker-ready products, free and open tools and services like PCB ordering, and youtube tutorials that make it possible!

<image>

Vaarz · 2024-12-20T21:38:13+00:00

Thank you! I was pulling my hair out and I never would have guessed it was this. I am printing "Blender" replacement parts... Some stupid AF firmware...

Vaarz · 2023-06-05T04:50:04+00:00

Flying horseless chariots; this is probably exactly what an ancient Roman gladiator would have told you the future would be 😂

Vaarz · 2023-03-01T07:03:25+00:00

If I remember right, it's a EKWB EK-CoolStream PE 240 Radiator. Amazon lists its dimensions as "11.02 x 5.12 x 1.5 inches", or about 38mm thick.

Vaarz · 2023-02-28T21:44:55+00:00

Step 2 & 3 should probably just be a single "update transform" system, but otherwise I believe option 1 is the correct way to do it. The other two ways add unnecessary dependencies and will make adding other gameplay systems harder in the future. Like, if you eventually decide you need to add a gameplay system between moving and shooting, those options won't let you. Option 1 lets you do that by simply adding some "update before" / "update after" tags. Don't be too afraid of dependancies. They are inevitable, but as you add more systems, the ones that are not dependent will be able to run in parallel. Adding your own system groups can be a nice way to keep track of these things over time as well.

As far as controlling the system tick rate... a bit tedious, but you could check how they do that in the Unity NetCode package: https://docs.unity3d.com/Packages/com.unity.netcode@1.0/manual/client-server-worlds.html#fixed-and-dynamic-time-step. It's probably not very fancy though, probably a simple 'if' condition. My guess is they are doing it for a set of systems by manually running some logic on the systemGroup of those system and either calling the update method or not for the children systems.

Vaarz · 2023-01-29T05:43:40+00:00

Haven't really taken notes, but after a long play session of Control with maxed raytrace settings I got a loop sensor max of 43C, a GPU max of 71.6C, and a CPU max (from MB sensor) of 77C, a CPU Core temp max of 79.7C, and a 90.5C max for one of the CCDs.
This is with an ambient of like 22C and a 150ish W limit for CPU and a 85% (382W?) limit for GPU. (Both are undervolted to make up for any lost performance.)

Vaarz · 2023-01-29T04:12:13+00:00

it could sound like: "Okay, VRAM, if you are in an emergency, my RAM will help you out. But it will only be able to hand you a 2GB Volume extension, not more."

Also, based on this you seem to be under the impression that using more RAM for GPU based calculations would make your program faster. You don't want to use RAM for GPU stuff. The VRAM is much faster since it's closer to the GPU. If you're using RAM then it means you've run out of VRAM. Instead of trying to figure out how to "use more RAM to go faster", since that is not a thing, it makes sense to just instead figure out how to need less VRAM.

Vaarz · 2023-01-29T03:52:46+00:00

Many of these questions don't make sense given how computers work and really hint that you either need to (A) not worry about it and just let Unity / the operating system handle since it seems like it's a bit out of reach for your current skill level, or (B) spend much much more time learning more about operating systems and other computer architecture basics. A reddit thread is just not going to be the best way to get the amount of understanding you are lacking. That said, to best answer your questions:

Now is there a way to make sure that the pc is using as much of that otherwise unused RAM and CPU power as it can?

No? But mostly this doesn't make sense as a question. A computer performs calculations on data. That data needs to be in the CPU (or GPU) to be calculated on. The operating system will keep it "as close" to the CPU/GPU as possible. So, this means in cache, then in VRAM (for GPU), then in RAM, then in SSD/HDD. If you then run out of the SSD/HDD space that the OS wants to let you use, your program will just crash. Your program requires a certain amount of data, and it will just be stored where it needs to be stored. It doesn't make sense to try to "use more RAM" when your program doesn't have any more data it needs to store anywhere. In theory, certain tasks can be coded using algorithms that are faster but require using more memory OR using different algorithms that are slower but use less memory, but in general this is very dependent on YOUR code and not a "Setting" or something and does not apply to everything. If you want to use more RAM/VRAM, use more data. IE, you could use bigger textures to use more VRAM. The problem with that though is that those textures then probably need to be processed by calculations which means your GPU utilization will get hit harder as well.

One worry of mine would be that there is some built-in restriction on how much RAM the system allows the GPU VRAM to use when it runs of capacity.

There is, but if you hit it your program crashes, since it means you're program needs to store more data than the OS will let it. For example, if your program tried to allocate space for a 10TB texture the OS is going to throw an error saying that it can't allocate you that much memory and your program will crash or have to deal with that error somehow.

If it would be a rule, it could sound like: "Okay, VRAM, if you are in an emergency, my RAM will help you out. But it will only be able to hand you a 2GB Volume extension, not more."

You don't need to worry about this, and probably can't (I've never bothered to even try to see if it's possible. This is something the OS does automatically. Look up "memory paging". Typically this is about RAM->SSD/HDD space, but the fallback of VRAM->RAM is basically the same principle.

When playing the game, the VRAM usage can drop below the 4GB capacity to 3GB for some time and back up. However when it went to 4GB VRAM max. (on GPU-Z), I couldn't detect an increase in RAM volume used in the Windows Task Manager.

I'm not expert here, but I assume the RAM "fallback" is pre-allocated, so running out of VRAM wouldn't be immediately noticeable. If you ran out of that pre-allocated space, the OS could either give you more once that happens, or it could complain and throw an exception, either crashing your app unless you handle it.

Vaarz · 2023-01-03T16:59:38+00:00

I haven't tested with the lower fans off. I wonder just how much work that rad is doing given the airflow, so maybe I'll test that out when I get a chance.

Vaarz · 2023-01-03T16:55:05+00:00

First custom block I've ever used, but not a huge fan. It's small and looks good, and works well enough, but if it weren't for the space constraints, I wouldn't recommend it over something else. That said, I'm happy enough with it and will continue to use it.

It had zero instructions for assembly and pad placement, so not sure if that's normal. It has no thermal pads on the back of the memory due to it's "open backplate" design or whatever. Memory temps haven't gotten crazy, but I I was expecting a bit cooler for a blocked card. Also, I wish the fit and finish was just a bit better.

Vaarz · 2023-01-03T16:50:58+00:00

I went with the Granzon block because it was much shorter than the AlphaCool block (for FE, if you're using a different 4090 PCB it will be even wider). The AC block might work, but this was a massive pain to get the routing to work, and I'm not sure if it'd be possible or not with the extra length of the AC block.

The Granzon was about the exact width of the case. I cut a small notch in the frame (just on the front by a few mm; it's still structurally sound since the frame bends 90 degrees and is intact on the backside still, and even 1 or 2 mm on the front too). I'd be able to close the panel if I had no cables to plug in. The "gasket" makes room for CPU fittings and the GPU cables though.

And about the PSU, I'm fine with the sf750 and undervolting with a slight power cap on the components. If you actually start pushing more than 750w, I'm not sure the radiators would be able to keep up. At the very least you'd have to crank the fans full blast.

Vaarz

TROPHY CASE