heinzboehmer's 2002 Topaz 6MT Coupe

[Bry5on]

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

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

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

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

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

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]

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]

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.

[Flow]

Good luck having carphonics answer to any type of communication.
I've written multiple emails and tried the website's contact form to no avail.

[Slideways]

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.

Would you use Siri to input navigation instructions?

[t3ddftw]

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:

I emailed you about this, but for the sake of the forum at large, I believe BMW is using binary coded decimals rather than converting the byte to decimal.

Would you use Siri to input navigation instructions?

You can do that with the BlueBus today, so yes .

[karter16]

I emailed you about this, but for the sake of the forum at large, I believe BMW is using binary coded decimals rather than converting the byte to decimal.

Just curious - if that was the case wouldn't it mean that the max value you can get from a byte is 99? whereas Heinz is managing to get to 165?


Edit: actually I think what you're saying is that the cluster assumes BCD but its assuming it's going to get the right value and its actual implementation is looser and allows you to overdrive it in slightly weird ways.

[t3ddftw]

Just curious - if that was the case wouldn't it mean that the max value you can get from a byte is 99? whereas Heinz is managing to get to 165?


Edit: actually I think what you're saying is that the cluster assumes BCD but its assuming it's going to get the right value and its actual implementation is looser and allows you to overdrive it in slightly weird ways.

Yes, input validation is not something these engineers really cared about.

I think 0xFF is translating to decimal 165 because of an overflow —

0xF = 15

So, 1515, but somewhere in the logic the 15 and 1 are being added to the same register.

[karter16]

Yes, input validation is not something these engineers really cared about.

I think 0xFF is translating to decimal 165 because of an overflow —

0xF = 15

So, 1515, but somewhere in the logic the 15 and 1 are being added to the same register.

Love it - that makes complete sense!

[heinzboehmer]

Yep! Think Ted cracked the code. BCD makes total sense.

Funky implementation though. I know these are tiny (in terms of compute) embedded devices operating in a very constrained and well defined environment, but the complete lack of validation for most of the stuff on this bus is wild to me.