heinzboehmer's 2002 Topaz 6MT Coupe

[George Hill]

you can query it from the MK60 with a DS2 command.

Very interesting, that would be cool for sure!

[heinzboehmer]

Unfortunately I'm pretty sure it doesn't. Anything where the DME needs to know the status of the brakes it's simply evaluating the brake light switch. I'd love to be proven wrong on this, but I haven't found any evidence of the pressure data being available in the DME (and I've specifically looked for it).

That's alright. Maybe it's time to splice into the sensors directly and stop worrying about relaying the data over multiple busses.

All of the track guys for years have been hoping to find brake pressures over the CAN bus, but no luck. AFAIK it isn't broadcast out of the DSC.

Yeah unfortunately the data isn't on CAN, but you can query it from the MK60 with a DS2 command. If the DME knew these values, we could hack its FW up and have it send them out over CAN

karter16 has a proof of concept of sending internal DME data out over CAN somewhere (couldn't find the thread in my five seconds of searching), but hacking it up to both query the MK60 and send out over CAN sounds much harder.

[George Hill]

All of the track guys for years have been hoping to find brake pressures over the CAN bus, but no luck. AFAIK it isn't broadcast out of the DSC.

[karter16]

karter16, any chance the DME has that data? If so, CAN relay in the DME seems like the simplest route.

Unfortunately I'm pretty sure it doesn't. Anything where the DME needs to know the status of the brakes it's simply evaluating the brake light switch. I'd love to be proven wrong on this, but I haven't found any evidence of the pressure data being available in the DME (and I've specifically looked for it).

[heinzboehmer]

Sorek gave me FW that handles the XOR operator correctly, so now I can calculate the checksum without all that overhead.

I also found that I can max out the message sending at ~2 Hz if I get rid of all my other D bus calls in the Gauge.S config. Ideally, I'd like it a little faster, but this will do. At least the frequency is pretty consistent this way.

I'll figure out where to get brake pressures from later (this was my other D bus call). karter16, any chance the DME has that data? If so, CAN relay in the DME seems like the simplest route.

[heinzboehmer]

Also, success!

[104659] DEBUG: IBus: RX[5]: 3F 03 BB 04 83
[105211] DEBUG: IBus: RX[5]: 3F 03 BB 44 C3
[105895] DEBUG: IBus: RX[5]: 3F 03 BB 04 83
[106455] DEBUG: IBus: RX[5]: 3F 03 BB 24 A3
[107133] DEBUG: IBus: RX[5]: 3F 03 BB 04 83
[108372] DEBUG: IBus: RX[5]: 3F 03 BB 84 03
[112635] DEBUG: IBus: RX[5]: 3F 03 BB 84 03
[118273] DEBUG: IBus: RX[5]: 3F 03 BB 44 C3
[118862] DEBUG: IBus: RX[5]: 3F 03 BB 04 83
[119506] DEBUG: IBus: RX[5]: 3F 03 BB 05 82
[120745] DEBUG: IBus: RX[5]: 3F 03 BB 04 83

I mapped the steering wheel cruise control buttons to a singular payload byte for Gauge.S to send out, then clicked on them randomly. The log above is (a parsed down version) of what the BlueBus's I bus logger prints out. You can see the fourth byte react to the button presses and the checksum get updated accordingly. Just a proof of concept, but it does show the full CAN -> Gauge.S -> D bus -> IKE -> I bus -> BlueBus route working correctly.

Worth mentioning that the functionality that the Gauge.S FW has for sending out D bus messages is completely undocumented. The amount of blind guessing and testing I had to do to get this to work was not fun, to say the least.

I also found a few bugs along the way. Most of them were related to JSON parsing (e.g. `^` gets parsed as the exponent operator instead of the XOR operator, so calculating the checksum involves a crazy workaround), but I got there in the end.

The resulting config is convoluted, hard to read, inefficient and just in general pretty ugly. BUT, it does work! It gets nowhere near the 2 Hz send frequency specified, but at least I can continue the BlueBus development with this. Config follows, for posterity.

fundata.json:

{
  "funData": [
    {
      // D bus to I bus relay
      "name": "d2i_relay",
      "frequency": 2, // Every 0.5 seconds, can't seem to get it to go faster
      // Don't forget to add more `0xFF` bytes as a pseudo-malloc if array grows.
      // d2i_relay[2] = Gear, d2i_relay[3] = RPM[4:7], d2i_relay[4] = RPM[0:3], d2i_relay[3] = Checksum.
      "values8": ["0xBB", "0x06", "0xFF", "0xFF", "0xFF", "0xFF"],
      "expr": [
        "obtainKline('d2i_relay', 0x01)" // DS2 protocol, arrayIndex 1
      ]
    }
  ]
}​

config.json:

{
    "interDelay": 50,
    "canSpeed": 500,
    "address": ["0xB8", "0x29", "0xF1", "0x02", "0x21", "0x06", "0x45"], // For requesting brake pressure from MK60 over D Bus
    "forceKwp": true, // For requesting brake pressure from MK60 over D Bus
    "ecuparam": [

        ...
        
        // Start D bus to I bus Relay Logic
        {
            "header": "SetD2IDataByte2",
            "expr": "setData('d2i_relay', 2, {Gear})",
            "hidden": true,
            "noLog": true
        },
        {
            "header": "XorD2IDataByte2",
            // 189 (0xBD) is the precomputed XOR result of the first two static bytes of the d2i_relay message (0xBB ^ 0x06)
            // `expr` is equivalent to d2i_relay[0] ^ d2i_relay[1] ^ d2i_relay[2]
            // Use A ^ B = (A & ~B) | (~A & B) since XOR operator is not supported
            "expr": "(189 & (255 - {Gear})) | ((255 - 189) & {Gear})",
            "hidden": true,
            "noLog": true
        },
        {
            "header": "RPMHighBits",
            // Mask bits 4-7 (& 0xF0) and shift
            "x": "RPM",
            "expr": "(x & 240) >> 4",
            "hidden": true,
            "noLog": true
        },
        {
            "header": "SetD2IDataByte3",
            "expr": "setData('d2i_relay', 3, {RPMHighBits})",
            "hidden": true,
            "noLog": true
        },
        {
            "header": "XorD2IDataByte3",
            // `expr` is equivalent to d2i_relay[0] ^ d2i_relay[1] ^ d2i_relay[2] ^ d2i_relay[3]
            // Use A ^ B = (A & ~B) | (~A & B) since XOR operator is not supported
            "expr": "({XorD2IDataByte2} & (255 - {RPMHighBits})) | ((255 - {XorD2IDataByte2}) & {RPMHighBits})",
            "hidden": true,
            "noLog": true
        },
        {
            "header": "RPMLowBits",
            // Mask bits 0-3 (& 0x0F)
            "x": "RPM",
            "expr": "x & 15",
            "hidden": true,
            "noLog": true
        },
        {
            "header": "SetD2IDataByte4",
            "expr": "setData('d2i_relay', 4, {RPMLowBits})",
            "hidden": true,
            "noLog": true
        },
        {
            "header": "XorD2IDataByte4",
            // `expr` is equivalent to d2i_relay[0] ^ d2i_relay[1] ^ d2i_relay[2] ^ d2i_relay[3] ^ d2i_relay[4]
            // Use A ^ B = (A & ~B) | (~A & B) since XOR operator is not supported
            "expr": "({XorD2IDataByte3} & (255 - {RPMLowBits})) | ((255 - {XorD2IDataByte3}) & {RPMLowBits})",
            "hidden": true,
            "noLog": true
        },
        {
            "header": "SetChecksum",
            "expr": "setData('d2i_relay', 5, {XorD2IDataByte4})",
            "hidden": true,
            "noLog": true
        }
        // End D bus to I bus Relay Logic.
    ]
}​​

This is the only valid approach I found, and unless Sorek adds functionality for sending out arbitrary D bus messages, this is how this is staying. If I could choose, I would structure a function that can be called inside `config.json` as follows and does the checksum calculation internally:

sendKline(Gear, RPMHighBits, RPMLowBits)

Should free up some RAM and cut down on the number of cycles needed to prepare the message.

Oh well, this is good enough for now. Time to go back to the C++ comfort zone with the rest of the BlueBus implementation.

[heinzboehmer]

Just pulled it out doing some other work, no degradation or any issues observed. It probably won't go back in, but I'm going to put it in another car.

Nice! Adds more credibility to the theory that the firewall doesn't actually get all that hot

[George Hill]

Just pulled it out doing some other work, no degradation or any issues observed. It probably won't go back in, but I'm going to put it in another car.

[heinzboehmer]

Sat down and finished up the BlueBus side of the extended OBC project. I've yet to fully figure out the Gauge.S side of things, so am using dummy data for now. Will upload the BlueBus changes to GitHub once the data is real.

Quick demo:

Some things to note:

• The "R/T" steering wheel button is used to put the extended OBC in scroll mode. This allows you to select what data is shown in the extra OBC page.
• For convenience, the BlueBus uses the CD53 display to show when you're in extended OBC scroll mode and what page you've selected.
• The cluster handles the extra page natively. That is, you can set up the data that you want to show and then scroll away from it using the "BC" button. If you want it shown again, just scroll to it with the same button.
• You can update the data on the extra page without causing the cluster to jump to it. This means the page refresh handler can keep writing to it (or even scroll to a different page) in the background. This saves a lot of overhead in the BlueBus FW, since it doesn't have to worry about what page is being actively displayed in the cluster.
• This is not shown in the video, but the feature is configurable in the BlueBus settings. You can fully turn it off and both the BlueBus and cluster will behave like they normally do.

[heinzboehmer]

Swapped in four new strut bar nuts (31316769731) since the printed bracket design uses the stock studs.

Much to no one's surprise, I pulled out the aluminum threads holding one of the timeserts in. I'm pretty sure this was the hole I messed up badly, so it was only a matter of time. No big deal though, I left a tooon of material around those holes, so even with a bigsert (~12mm OD on the exterior threads), there's still ~3mm of wall thickness at the thinnest point. Cross section for reference:



Bigsert install was uneventful:




And, importantly, there's no way to tell that something happened with everything back in its place:



Also, pro tip. M8 bigserts use the same bore and threads as M10 regular timeserts. So, if you love to mess up threads (like me) and have a collection of timesert kits, all you need to buy are the bigsert inserts themselves. Then use the M10 timesert drill/tap/counterbore tools and the M8 timesert install tool.

[heinzboehmer]

I don't have a picture of mine handy, but it's nowhere as bad as that.

Thin film of oil though? Definitely

[Bry5on]

Genuine CSL airbox after about 15k miles with new BMW filter



My guess is that the BMC filter allows more flow, but is worse at filtering fine dust particles. Even the non-CSL paper filter allows some stuff to go through, just not nearly as much.

That’s what mine looked like until I added foam. Now it’s totally sand free with just a thin vapor layer of motor oil from the crank case vent.

[0-60motorsports]

Genuine CSL airbox after about 15k miles with new BMW filter



My guess is that the BMC filter allows more flow, but is worse at filtering fine dust particles. Even the non-CSL paper filter allows some stuff to go through, just not nearly as much.

I just installed the blue ECS one....lets see how that does.

[Slideways]

I can't say for certain, but the fit of the filter is pretty bad along the bottom edge. Sand does collect outside the filter lip on the airbox, but there's no obvious sand inside. Might be worth scanning and printing some TPU inserts to seal up the gaps.

I wonder if your brake duct scoop is making the sand intrusion situation worse.

Genuine CSL airbox after about 15k miles with new BMW filter



My guess is that the BMC filter allows more flow, but is worse at filtering fine dust particles. Even the non-CSL paper filter allows some stuff to go through, just not nearly as much.

[heinzboehmer]

I was doing a remote dyno tune with Epic Motorsports and he noticed something on the dyno graph. He told me to replace those arms. I didn't notice a difference but apparently it is a common thing and can get bad enough to affect power. I don't know if its the tune or replacing the arms but the car does idle much better now. It would hunt a little bit especially when warming up bit I never cared or tried to address it.

Interesting. The difference in play was super minor, but I guess that might be enough to throw idle off on an engine with ITBs. I've heard people have a tough time getting older ITB engines to idle properly, since getting them all in sync is not easy.