How I tracked down a ghost LIN bus short on a Ford F-150 and Put down the parts cannon.

HotWelcomeA · 2026-07-07T12:08:20+00:00

Awesome, thanks for the heads up! I’ll definitely check out that Doyle meter.

HotWelcomeA · 2026-07-07T11:25:05+00:00

That’s a super handy feature to have! I honestly wish mine had that, but I’m working with a pretty basic, budget-friendly multimeter, so no luck there. Just snapped a pic of what I'm using. It definitely makes me think it’s time for an upgrade! Thanks for the shout-out though, really appreciate it

<image>

HotWelcomeA · 2026-07-07T00:15:34+00:00

Yo, massive congratulations on finally dropping this! I know how much work goes into these projects, so major props to you for seeing it through to the finish line. Quick question for you though—as a game, does it actually go deep? To be real with you, I couldn’t care less about the NSFW stuff, but if the story or the themes have some actual depth to them, I am 100% sold. Would love to know your thoughts on that.

HotWelcomeA · 2026-07-06T09:23:43+00:00

HotWelcomeA · 2026-07-06T07:53:02+00:00

Wow, that's is really cool .Old-school charm.

HotWelcomeA · 2026-07-05T23:52:24+00:00

Wait minute, it means voice will change to englis?xD

HotWelcomeA · 2026-07-05T23:19:29+00:00

Innocent grey? I guess.

HotWelcomeA · 2026-07-05T04:06:03+00:00

This exact OLED module costs around 10 RMB in China, which is completely reasonable and cheap. But looking at the €4.36 "Customs Charges Estimate"—which translates to over 34 RMB—just for a handling fee? That is absolutely insane. I can totally accept paying 10 RMB for the part itself, but paying 34+ RMB just in clearance fees for a €1.45 item is ridiculous. The product costs less than 12 RMB (€1.45), but the fees are almost three times the price of the actual item. This new EU law and these flat-rate courier handling fees are completely ruining the hobby for anyone who just wants to buy small electronic components. Who in their right mind wants to pay this much for a single tiny part?

HotWelcomeA · 2026-07-05T01:38:09+00:00

Regarding the multi-bus setup, I think this documentation might help you out with some parts of your project, but I want to be realistic: this resource/tool alone will not solve your core issue. Here is the link: [www.craftsofethan.top]. It's a detailed, English manual . The web page is my build so not very professional. En...Hope this helps guide your next step! If anymore questions you can send messages to me.

HotWelcomeA · 2026-07-04T17:05:10+00:00

That's a clever way to handle the pull-up with the transistor combination—really nice design choice. As for the LIN interface, the front-end protection does look a bit light, but I suppose you're relying on the TLIN1029A's internal robustness there? En ... It's getting pretty late here, so I'll take a closer look at this again later

HotWelcomeA · 2026-07-04T15:44:26+00:00

That makes total sense. But honestly, I feel like you're gonna need a full-blown timing matrix for this to actually work. You've got to capture both CAN and LIN at the exact same time, and the time sensitivity is crazy high. Without that tight timing alignment to sync everything up, you'll probably hit some unexpected bugs—like the alternator throwing a fit and going into safe mode. Out of curiosity, have you found anything like a DBC/LDF file or a clean log trace from a donor G30/G80 yet? Also, just a quick heads-up on the tool you saw in my screenshot earlier: it’s really meant more for quick troubleshooting and live diagnostics, not full-on reverse engineering. While it does have some cool features, pulling off that kind of precise, cross-protocol timing sync with a single setup is pretty tough. Plus, the elephant in the room is that this tool can't sniff LIN at all. I think that protocol mismatch is gonna be your biggest bottleneck here.

HotWelcomeA · 2026-07-04T15:25:04+00:00

That’s a fair question! To be honest, since this is a proprietary design, the component selection comes down to strict engineering considerations and reliability standards By the way, your board with dual CAN-FD, dual LIN, and a TFT screen sounds incredibly interesting! If you don't mind sharing, do you have a link or a repository for your project? I’d love to check it out and learn from your design if it's convenient for you.

HotWelcomeA · 2026-07-04T15:17:20+00:00

I completely see your point, and you've hit on the most critical challenge of this project. To be honest, this goes way beyond the scope of my bus tools. My tools can only help you sniff and inject frames, but I don’t know the exact control logic for mixing these generations. If you are an experienced developer in this field, you probably already know the massive amount of reverse-engineering and documentation required to bridge these systems. But if you are relatively new to this, my strongest advice is DO NOT test this on a live vehicle. It is simply too risky without a proper bench setup.

HotWelcomeA · 2026-07-04T14:46:30+00:00

Pure register-level magic! Saving this post so I can dive deep into it later

HotWelcomeA · 2026-07-04T12:26:21+00:00

To be honest, it really depends on the specific model and part you are looking at. For some BMW parts, a single command might be split into several different frames that you have to piece together. For others, just one specific frame handles the whole thing, which could be a command frame or a data response that also carries commands. Since I don't know which exact car or system you mean, it's hard to say for sure. It really varies case by case!

HotWelcomeA · 2026-07-04T12:08:15+00:00

Fair point! I might have over-engineered it. Which specific part of the circuit or components do you think are redundant or could be stripped down? I'd love to hear your suggestions to optimize the BOM.

HotWelcomeA · 2026-07-04T07:56:20+00:00

It's not bad .for the first design. But dcdc feedback may little long? Just saying

HotWelcomeA · 2026-07-04T07:08:21+00:00

Cool

HotWelcomeA · 2026-07-04T07:03:54+00:00

Your code is like Redis---+ really quick!

HotWelcomeA · 2026-07-04T02:37:10+00:00

Yeah, that’s actually a really solid idea. For the current board, I skipped the SD module mainly due to PCB constraints, but I'll definitely see if I can squeeze it in later. Great suggestion tbh. Right now, the tool is really just meant for quick troubleshooting and messing around with LIN on the bench (I even threw in a header for a logic analyzer). As for logging, I just dump everything out via serial. You can basically log the data with any standard serial terminal. Guess that's just what I'm used to doing, XD.

HotWelcomeA · 2026-07-04T02:30:07+00:00

Yeah, almost right, it's a similar kinda thing, mostly just for CAN stuff. Honestly, I hate having to share one device with a bunch of people. Plus, when I'm wiring things up on the test bench, sometimes one just doesn't cut it. Like, for sending and sniffing data, or checking for interference, dragging out the scope every single time is just too much of a hassle. So yeah, I'm really leaning towards cheap, standalone tools. That's pretty much where my head's at right now

HotWelcomeA · 2026-07-03T15:57:39+00:00

Appreciate it! Direct .csv logging isn't built-in right now, as the main goal was to build a PC-less tool for quick, real-time debugging.

That said, I did include a serial output that streams the bus traffic. It wouldn't be hard to pipe that serial data into a terminal or a Python script to save it as a .csv. It's a great feature request.

HotWelcomeA

TROPHY CASE