heinzboehmer's 2002 Topaz 6MT Coupe

[George Hill]

It would also not require a video module, like Baris' solution.

You've already got me, you don't need to oversell it 🤣

But seriously, very cool.

[t3ddftw]

I'm a buyer when you do. I've been holding out for Carphonics, but just can't commit as I'm not 100% sold its as polished as I want. Your solution sounds right up what my alley.

It would basically be a BlueBus with the ability to switch to "mirror" mode when you want to use it for maps. Even in our family Minivan, I prefer the factory UI over CarPlay -- CarPlay looks too cartoonish IMO.

It would also not require a video module, like Baris' solution.

[George Hill]

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

paging thegenius46m

My CarPlay / AA solution is less "headunit" and more of an add-on module for cars that came with Nav. The screen(s) I have been looking at would still drop into the factory BMBT as I lack the tooling to make automotive quality headunits. This might change in the future, especially as I know someone with an injection molding machine, but I want to focus on Nav cars for now, and maybe even develop some retrofit kits for factory Nav that don't suck to install.

I'm a buyer when you do. I've been holding out for Carphonics, but just can't commit as I'm not 100% sold its as polished as I want. Your solution sounds right up what my alley.

[t3ddftw]

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

It's pretty small, hah.

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.

This might actually work! Sorek gave me access to the source code, so I will help out if you are not able to get this approach to work. I was given a free Gauge.S, so I might as well install that and get a bunch more metrics on my Nav screen

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.

Good to hear you've continued down the path of getting the iDrive retrofit working!

My CarPlay / AA solution is less "headunit" and more of an add-on module for cars that came with Nav. The screen(s) I have been looking at would still drop into the factory BMBT as I lack the tooling to make automotive quality headunits. This might change in the future, especially as I know someone with an injection molding machine, but I want to focus on Nav cars for now, and maybe even develop some retrofit kits for factory Nav that don't suck to install.

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

I'm sure the screen is beautiful, and obviously iDrive is very polished, but I don't know how I feel about that level of tech in the E46. Looking forward to seeing what you come up with

Makes sense. There's the "F" used for the temp, but trying to use that in place of "ft" would probably have been very confusing.

Freedom units are missing because the British use yards as their unit of distance (or at least that's what BMW baked into the Navi when coded for GB).

-Ted

[George Hill]

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.

I'm seeing this more and more, somehow the timing chain tensioner starts to leak through the crush washer. I don't understand the physics of it, but I've replaced a bunch of tensioner crush washers recently.

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.

That bolt is a usual offender but it generally doesn't leak enough to drip off the tensioner. Most often it leaks and chases the head gasket back to the transmission, then drips down straight there. If you are feeling lucky you can loosen the (3) thermostat housing bolts and shift it to the side a bit and then reach down with an open ended 13mm and tighten that bolt. In my experience if its loose you can tighten it up and it'll seal.

[heinzboehmer]

Also, finished running through all Data[1] values and only came close to dying of boredom 15 or 20 times.

Anyway, this is how the values are encoded, to the best of my understanding:



Full investigation here if anyone is curious: https://docs.google.com/spreadsheets...it?usp=sharing

Worth noting that there is no x1000 multiplier. I must have sent 10x100 and seen 1000 earlier or something along those lines.

Even with the multipliers applied, the weird base10/16 counting still happens. I'm starting to wonder if this is an undefined-behavior-type bug/oversight. Maybe the mi/km theory has some credence and BMW only ever planned to display max 10mi/16km for each of the multiplier stages.

Regardless, the x100 multiplier still works with the 165 max. Not that I see it being particularly useful, but it's good to know that you can go that high:



And yes, you can display this:



Cute.

Next up is figuring out the D-Bus -> I-Bus diagnostic message relaying. As far as I can tell, all I need to do is tell the cluster to relay the message to I-Bus by sending a specific D-Bus command, but we'll see if it's actually that easy.

I'm planning on doing all processing on Gauge.S and sending a single byte that encodes both the gear and the possibility of a money shift. Hoping to just send out the message on a gear change, but unsure if Gauge.S offers that level of granularity. Not gonna lie, I'm not super excited to interface with the Gauge.S SW again... It seems to be a struggle every time.

[heinzboehmer]

Looks like it's 'm' because there is no freedom units version of short distance:

Makes sense. There's the "F" used for the temp, but trying to use that in place of "ft" would probably have been very confusing.

[Bry5on]

Looks like it's 'm' because there is no freedom units version of short distance:

[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.

[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.

[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]

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 $$$$

[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.

[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]

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>