heinzboehmer's 2002 Topaz 6MT Coupe

[heinzboehmer]

My apologies - I somehow managed to completely miss this and thought it was just the files shared in the Google Drive.

Oh, the link was a very recent silent addition

Was always intending on sharing, but didn't want to do so before landing on a final design. Figured it would be easy for people to make copies of it and end up referencing an out of date file.

[t3ddftw]

Feature works great and t3ddftw's codebase is a breath of fresh air compared to some of the stuff I get to interact with on a day to day basis. I've said it before and I'll say it again, the BlueBus is by far the most polished product I've ever installed on my car. Love it.

Thanks for the kind words, Heinz! Software is my background, so that has helped with the code quality, haha. I really do need to sit down and break out a lot of these huge files (handler(s) / ibus.c) into their own files, though, because they are absolutely unwieldy,

One man, maybe two man, show. As you well know the less people that touch a codebase the better, and more consistent, its going to be (well in most cases).

One Man, but I have had contributions to the code! I am a bit of an ass about it as I will accept the code, but then refactor it until it follows the same paradigms as the rest of the code base before merging it in.

And he's a true enthusiast who is building a full conversion M3 touring. 😎

That project is so stalled right now. I think I am going to take a couple days off work and just strip it to a bare shell so I can finally get the ball rolling. Your CF roof is sitting in my basement still

Totally fair. The BlueBus has (2) limitations IMO, and neither of those are Ted's fault.

1. The factory mic is just not great, so phone calls just aren't as good as aftermarket systems (even with aftermarket mics in the factory location).
2. CarPlay/Android Auto, if you need/want that feature you have no option but to look at something else, but I thought I recalled seeing him post that he is working on a CP option?

1. I honestly need to do more work to dial in the microphone quality. Interestingly the G-series Mic (84108794736) is a plug and play replacement in terms of wiring, and it performs pretty well on calls while at speed (using a 7dB Mic Gain value). The only problem is it doesn't directly slot in place, so I need to design an adapter plate.

2. Yes, I am working on this, but it would be for factory Nav cars. At this time, the hardware WAS done, but then Texas Instruments EOL'd a part of the BOM. I need to rework this part of the circuit and then lay out the PCB once and for all.

I did, however, recently come upon some screens that could be used to replace the really crappy 16:9 TFT, so maybeeeeeeeeee I could start selling 16:9 retrofit kits with upgraded screens, Carplay / AA, Bluetooth, etc.

Now, Claude is all over me now days and I can't get that bastard to shut up

My boss at my day job is all over us to embrace the slop and I can't bring myself to use it for anything other than debugging or writing one-time-use scripts that I know I will never need to debug. Yuck.
I have toyed around with the idea (which was suggested to me by someone else) of having Claude write unit tests for the BlueBus firmware.. Certainly some tests will be better than none.

T
Anyway, the real question is what to do with this newfound capability. I'm thinking that displaying the current gear might be a good starting point. My Gauge.S already calculates that, so just need to figure out how to get the info from it to the BlueBus and should be good to go.

Do you have access to the Gauge.S source code? Sorek and I spoke about forwarding Gauge.S values to the BlueBus by emulating factory diagnostics. Essentially, the Gauge.S would send a D-Bus packet to a module on the I-Bus (such as Japanese Nav; 0xBB) and that packet would contain data for the BlueBus to be able to display to the user. I haven't had the time to make this materialize though

Thanks!
-Ted

[George Hill]

That project is so stalled right now. I think I am going to take a couple days off work and just strip it to a bare shell so I can finally get the ball rolling. Your CF roof is sitting in my basement still

I feel that, such is life sometimes.

1. I honestly need to do more work to dial in the microphone quality. Interestingly the G-series Mic (84108794736) is a plug and play replacement in terms of wiring, and it performs pretty well on calls while at speed (using a 7dB Mic Gain value). The only problem is it doesn't directly slot in place, so I need to design an adapter plate.

I'll track one of these down and try it out.

2. Yes, I am working on this, but it would be for factory Nav cars. At this time, the hardware WAS done, but then Texas Instruments EOL'd a part of the BOM. I need to rework this part of the circuit and then lay out the PCB once and for all.

I did, however, recently come upon some screens that could be used to replace the really crappy 16:9 TFT, so maybeeeeeeeeee I could start selling 16:9 retrofit kits with upgraded screens, Carplay / AA, Bluetooth, etc.

I'm game!

[Bry5on]

High res factory nav replacement would be so choice. If you get there, I may pick up the effort to pack the head unit internals behind the screen to avoid the full nav harness run to the trunk. That is, if the iDrive retrofit effort stalls.

[heinzboehmer]

1. I honestly need to do more work to dial in the microphone quality. Interestingly the G-series Mic (84108794736) is a plug and play replacement in terms of wiring, and it performs pretty well on calls while at speed (using a 7dB Mic Gain value). The only problem is it doesn't directly slot in place, so I need to design an adapter plate.

Any pics of the G series mic? More than happy to help out with the design/testing for this if you need extra hands. Also recently bought a 3D scanner if you need any scans of the part or chassis

2. Yes, I am working on this, but it would be for factory Nav cars. At this time, the hardware WAS done, but then Texas Instruments EOL'd a part of the BOM. I need to rework this part of the circuit and then lay out the PCB once and for all.

I did, however, recently come upon some screens that could be used to replace the really crappy 16:9 TFT, so maybeeeeeeeeee I could start selling 16:9 retrofit kits with upgraded screens, Carplay / AA, Bluetooth, etc.

Have you seen this effort? https://nam3forum.com/forums/forum/m...onnected-drive

There is some iDrive screen out of a Mini that packages nicely in the dash with a custom bezel. I helped YoitsTmac print out a prototype of the bezel, but looks like I didn't take any pictures of it with the screen installed. Maybe he'll chime in with some.

Don't know if that screen will be easier or harder to interface with, but it might be nice to base the product around HW that was mass manufactured by BMW (and can be scavenged out of any junkyard), instead of something that could get EOL'd in the future.

My boss at my day job is all over us to embrace the slop and I can't bring myself to use it for anything other than debugging or writing one-time-use scripts that I know I will never need to debug. Yuck.

Oh man, same. I've found some success using these technologies for what they're good for, which is processing large amounts of data. Distilling down docs, trying to make sense of convoluted code paths, that kinda thing.

Think more people should treat them as tools instead of full on engineering replacements.

Do you have access to the Gauge.S source code? Sorek and I spoke about forwarding Gauge.S values to the BlueBus by emulating factory diagnostics. Essentially, the Gauge.S would send a D-Bus packet to a module on the I-Bus (such as Japanese Nav; 0xBB) and that packet would contain data for the BlueBus to be able to display to the user.

I don't have access, no I've tried asking for it, but have gotten nowhere.

My plan is similar. I'm pretty sure I can use it to send arbitrary D Bus frames, so emulating the diagnostics is doable in theory.

Functionality isn't super well documented, but there's some mention of the extended D Bus stuff here: https://github.com/handmade0octopus/...ig#fundatajson

I've managed to get brake pressure data from the MK60 like this:

{
  "funData": [
    {
      "name": "Kline req 2",
      "frequency": 2, // every 0.5 seconds
      "values8": ["0xB8", "0x29", "0xF1", "0x02", "0x21", "0x06", "0x45"], // MK60
      "expr": [
        "obtainKline('Kline req 2', 0x11)" // KWP protocol
      ]
    }
  ]
}

It seems like the approach could be extended to just spit out data on the bus. We'll see.

[oceansize]

Oh man, same. I've found some success using these technologies for what they're good for, which is processing large amounts of data. Distilling down docs, trying to make sense of convoluted code paths, that kinda thing.

Think more people should treat them as tools instead of full on engineering replacements.

Agree. Its ludicrous the amount of hype that is being generated. I code every single day. Its what I do all day every day and I attempt to heavily use AI. It is not a replacement. I use it for generating small code samples when I'm unfamiliar with a language, API, or framework. Its shines in helping me get started and being productive fast. Text summarization is also one of the large benefits. As of late, its gotten pretty good at updating a legacy code base with technical debt to a more modern version. Still can't trust it which is problematic on a large project, which is a much bigger problem than bosses want to believe.

[heinzboehmer]

Still can't trust it which is problematic on a large project, which is a much bigger problem than bosses want to believe.

100%. The amount of code I've looked at that is clearly written by these tools with zero review by an engineer is staggering.

Seems like a lot of the people (usually without engineering backgrounds) that are calling for mass adoption keep forgetting that the tools have no critical thinking skills.

Calculators help speed up arithmetic operations, but you still need someone who knows what they're doing to feed the correct numbers into them. Same story with the new gen tooling.

[YoitsTmac]

High res factory nav replacement would be so choice. If you get there, I may pick up the effort to pack the head unit internals behind the screen to avoid the full nav harness run to the trunk. That is, if the iDrive retrofit effort stalls.

Not stalled! Working with a PCB designer finalizing designs. I have otherwise been working on this all day because I want to get this out soon. For iDrive, my only holdup right now is my PCB designer messed up the original design and I had to hire another designer to make sure the first designer is staying...within the design scoped .

I'm software first, so all this hardware stuff I am doing really slowly to make sure everything is handled appropriately. Like I shared with you, I may even outsource the bezel. A little sad given how "close" I am, but I may not have what it takes to make a polished final design. Once the design is back, I'm making 5, quadruple checking and refining firmware, and then some test samples will be sent out.

Have you seen this effort? https://nam3forum.com/forums/forum/m...onnected-drive

There is some iDrive screen out of a Mini that packages nicely in the dash with a custom bezel. I helped YoitsTmac print out a prototype of the bezel, but looks like I didn't take any pictures of it with the screen installed. Maybe he'll chime in with some.

Don't know if that screen will be easier or harder to interface with, but it might be nice to base the product around HW that was mass manufactured by BMW (and can be scavenged out of any junkyard), instead of something that could get EOL'd in the future.

Man, Ted and I haven't talked since before I started learning how to code! I knew Ted was working on a CarPlay headunit. I think back then, it was just growing into something beyond an idea. I'm excited to see where he goes because I'm a HUGE fan of Bluebus. If he executes at the same level of attention and care, I think he'll have the best headunit for E46 available.

My personal allures to iDrive are:
- the screen is top notch in brightness, low reflectivity, responsiveness to touch, viewing angles and resolutions.
- great UI for trips
- the "favorite button" row I feel is damn near the perfect auto UI for infotainment.
- mildly the "OEM+" feeling.

The MINI screen is insanely good. I actually began looking into trying to render my own UI on it myself, but it's WELL beyond my abilities. 10/10 much better off just piggybacking off BMWs HU by spoofing and translating some messages

[heinzboehmer]

The MINI screen is insanely good. I actually began looking into trying to render my own UI on it myself, but it's WELL beyond my abilities. 10/10 much better off just piggybacking off BMWs HU by spoofing and translating some messages

Any idea how it displays images? I vaguely remember there being a bunch of stuff on the board behind the screen. Guessing the input is some digital protocol that talks to the nav computer and then the circuitry behind the screen figures out all the displaying/touching bits?

Edit: Looks like the answer is a protocol called APIX:



First time hearing of this, but it seems pretty powerful. Copy paste from INOVA's website:

The new APIX3 technology supports transmissions of up to 6 Gbps over one shielded twisted pair (STP) cable and up to 12 Gbps over a quad twisted pair (QTP) connection.

APIX3 offers a number of unique features for in-car video, such as:

- Enables the transmission of multiple video channels on one connection (which supports advanced cockpit architectures);
- Supports 100 Mbps Ethernet and other serial interface protocols;
- Provides advanced diagnostic capabilities, including cable monitoring, for preventative detection of cable degradation.

That's impressive. Seems like you could figure out how to package the screen in the dash and then just run a single cable to a controller that can live basically anywhere.

t3ddftw <insert eyes emoji>

[YoitsTmac]

I can send you a photo if you'd like. Personally? No idea. It's like an old clamp down ribbon cable. I think the Switch has connectors that look similar.

The accompanying board takes in APIX. Now, there are “tons of” eBay kits for like aftermarket reverse cameras that override the iDrive view to display their own. Aftermarket iDrive kits for NBT non EVO do this too. So there are cost-effective ways to broadcast to it and receive inputs for touch. I just have my mini board I'm designing and power a high-yes display like that requires way more compute and probably custom drivers than what I'm working on, so that's when I walked away. Sticking to my strength areas with frontend web/mobile design and backend design.

[heinzboehmer]

I can send you a photo if you'd like. Personally? No idea. It's like an old clamp down ribbon cable. I think the Switch has connectors that look similar.

The accompanying board takes in APIX. Now, there are “tons of” eBay kits for like aftermarket reverse cameras that override the iDrive view to display their own. Aftermarket iDrive kits for NBT non EVO do this too. So there are cost-effective ways to broadcast to it and receive inputs for touch. I just have my mini board I'm designing and power a high-yes display like that requires way more compute and probably custom drivers than what I'm working on, so that's when I walked away. Sticking to my strength areas with frontend web/mobile design and backend design.

Yeah, makes sense!

I wonder how feasible it is to reflash one of the million iDrive piggyback controllers with custom FW. Raspberry Pi + some board to do the APIX transceiving is probably still the path of least resistance though.

[heinzboehmer]

This thing looks like it would be fun to mess with: https://engineering.arrk.com/compete...3-converter-ii

Can't find a price anywhere though so probably $$$$

[YoitsTmac]

This thing looks like it would be fun to mess with: https://engineering.arrk.com/compete...3-converter-ii

Can't find a price anywhere though so probably $$$$

ahhhhh yeahhhhh that's about how my venture ended. Probably stumbled on the exacty same product! While you're at it, let me know if you stumble on ways to read and broadcast OABR! 😅

[heinzboehmer]

Brackets and braces dropped off for paint. Hopefully will have them back within a week or so.

I printed out these caps/plugs to try and make the lives of the guys at the bodyshop a little easier:




They're meant to stop the threads from getting painted and, in my mind, are easier than masking tape. The plugs are also hollow to provide a convenient place to hang the parts from.

I'm not the one painting the parts though, so these might be dumb and get thrown out, we'll see.

Also, I noticed something amusing about the unbraced car. My garage floor is not even close to flat and the car's doors are significantly harder to open/close without braces. Cool.


Unfortunately, when parking back in said garage, I noticed a faint oil smell. Popped the hood and immediately saw this:



Mind immediately went to the front main seal (and, naturally, to driving the car off a cliff), but upon closer inspection, the oil trail seems to line up with the water pump pulley, not the harmonic balancer. Quick poke around with a mirror confirms that the balancer is dry. Crisis averted.

But what is leaking then?

Timing chain tensioner is drenched:



The boss on the head that it threads into is drenched as well though, so it seems like the oil is coming from higher up.

The previously problematic corner of the VANOS gasket is dry:



The underside of the VANOS is a bit grimey, but does not look wet (forgot to take a pic of this).

I think there's only a couple suspects left and one of them looks kinda suspicious:



It's really hard to see back there, but it does look wet right under the bolt that holds the top of the chain guide. I'll likely have to pull the intake and investigate more, yay.

I'm starting to wonder if something in the PCV system is clogged and not allowing the positive pressure to vent correctly, which, in turn, is pushing oil past random seals. I replaced the oil separator and cleaned the channel in the valve cover a few years ago, but it might be time for another service.

I don't want to start randomly throwing parts at the problem though, so I'm gonna rig up a pressure tester and grab some data first. Pretty sure I have a spare oil fill cap somewhere, so should just be a matter of drilling and tapping a hole for a pressure gauge. Stay tuned.

[heinzboehmer]

Continued messing with the low OBC in the cluster while I wait for my PCV diag tools to arrive.

Unfortunately, Obioban's mi/km theory didn't work out. I coded my cluster with a bunch of different unit combinations and still got the same weird base10/16 counting strategy. Still haven't figured out why it does this.

I also swept through a couple things I thought might yield results:

1. Entire uint16_t (had the BlueBus send out commands at 200 Hz so I didn't have to sit there all day) for the data value. Same deal, counted to 165 and reset back to 0, regardless of what the high bits held.
2. Entire one hot encoding of a uint64_t while holding the lowest byte static at <some_num>. Was hoping to find hidden flags this way, but again, no change.

So then I turned my attention to the other two bytes in the data field of the message and found something interesting!




I like the "m"! Can use it to represent "money shift". As in, "if you downshift with the revs this high, you'll money shift". Love it.

Here's the low OBC I-Bus message is structured:



where:

• Source ID: ID of module sending the message.
• Length: Data length in bytes + 2 (1 byte for destination ID, 1 byte for checksum).
• Destination ID: ID of module meant to receive message (0x80 for IKE in our case).
• Data[0]: 0x44 tells the cluster to write to the low OBC.
• Data[1]: Tells the cluster how to interpret Data[2]. Encodes multipliers and additional symbols to display. This is the interesting one.
• Data[2]: Data to communicate to the cluster. Bounded to uint8_t.
• Checksum: XOR checksum.

So, basically just structured like a normal I-Bus message, except the first two data bytes tell the cluster what to do with the data and how to interpret it.

Data[1] feels very "flag-like" (for lack of a better term), so I've just been poking around with sending various one hot encoded combinations and seeing how the cluster reacts. Based on my highly scientific messing around, I think the following options exist:

• 1x multiplier
• 10x multiplier
• 100x multiplier
• 1000x multiplier
• Display "m"
• Clear low OBC

For completeness I'm gonna go go through all possibilities for Data[1]. It's a uint8_t, so I think I can sit through the 256 combos and not die of boredom. Wouldn't want to miss some hidden format specifier just because I was impatient. A negative sign would be particularly cool, but not holding out too much hope.

Also worth mentioning that I double checked my cluster's coding and all units are set to imperial. Seems a bit weird that you can trigger an "m" instead of a "ft" symbol like this, but maybe the "m" is the only symbol allowed.