[CAN/UDS] Homebrew Exhaust Valve Controller using Carloop+Particle

[packet.pilot]

I've begun a project that I hadn't expected traction on rather quickly, but alas it's working to a basic degree, and I figured I'd start a thread about it and hopefully inspire other tinkerers to play with a rather neat and cheap toy and, potentially, help build on my code.

The Intent
For pretengineers like myself to do cool things with their car relatively easily, no expertise in programming nor electrical engineering required.
(I'm in no way affiliated with, nor receiving free goods from, anyone involved with the hardware/software etc.)

The Hardware
I purchased a Carloop Pro ($150) from store.carloop.io, which includes a Particle (formerly spark) Electron development board and GPS receiver (GP 735).
It comes with a micro-SIM that I've discarded, instead opting to use a Google Project Fi (Data-Only) SIM.

It's worth noting that the Carloop Basic is only $55, so if you'd like to play around without GPS/3G connectivity, the barrier to entry is pretty low, not only on a technical expertise front.






more photos here

The Code
Using a saleae logic analyzer and an OTS OBDII-connected EVC, I've been able to reverse the CAN messages for overriding the exhaust valve behavior. The 'force open' signal is in the two 8-byte CAN messages sent in the following code (also on github), which is my first take on EVC with the Carloop.

To be clear, this is the only code (aside from imported open-source libraries) that turns a Carloop into a rather dumb "force my valves open" EVC.

Of course, I hope to incorporate other logic into this project (e.g. close valves whenever in 6th gear, and whenever I'm close to home), but here's what I've got working for now:

// This #include statement was automatically added by the Particle IDE.
#include <carloop.h>

#include "application.h"
#include "carloop/carloop.h"

// Don't block the main program while connecting to WiFi/cellular.
// This way the main program runs on the Carloop even outside of WiFi range.
SYSTEM_THREAD(ENABLED);
STARTUP(cellular_credentials_set("h2g2", "", "", NULL));
SYSTEM_MODE(SEMI_AUTOMATIC);

// Tell the program which revision of Carloop you are using.
Carloop<CarloopRevision2> carloop;

// Send a message at a regular time interval
void sendMessage() {
  static uint32_t lastTransmitTime = 0;
  uint32_t transmitInterval = 5000; /* ms */
  uint32_t now = millis();
  if (now - lastTransmitTime > transmitInterval) {
    CANMessage message;

    // A CAN message has an ID that identifies the content inside
    message.id = 0x6F1;

    // It can have from 0 to 8 data bytes
    message.len = 8;

    // Pass the data to be transmitted in the data array
    message.data[0] = 0x12;
    message.data[1] = 0x10;
    message.data[2] = 0x08;
    message.data[3] = 0x2F;
    message.data[4] = 0x60;
    message.data[5] = 0xFD;
    message.data[6] = 0x03;
    message.data[7] = 0x19;

    // Send the message on the bus!
    carloop.can().transmit(message);
    
    // Pass the data to be transmitted in the data array
    message.data[0] = 0x12;
    message.data[1] = 0x21;
    message.data[2] = 0x99;
    message.data[3] = 0x0A;
    message.data[4] = 0xFF;
    message.data[5] = 0x58;
    message.data[6] = 0x00;
    message.data[7] = 0x00;

    // Send the message on the bus!
    carloop.can().transmit(message);

    lastTransmitTime = now;
  }
}

void setup() {
  // Configure the CAN bus speed for 500 kbps, the standard speed for the OBD-II port.
  // Other common speeds are 250 kbps and 1 Mbps.
  // If you don't call setCANSpeed, 500 kbps is used.
  carloop.setCANSpeed(500000);

  // Connect to the CAN bus
  carloop.begin();
}

void loop() {
  sendMessage();
}

[packet.pilot]

Audio's not super loud on the valves actuating, but here's a video showing how long it takes to power up and activate.

[aboulfad]

Not sure if you realize from the above snipplet that using 0x2F 03 60FD (UDS InputOutputControlByIdentifier), BMW has set a default timeout SW_TO_EAGK of 20s, and a max of 510s ... Maybe test your script again, and wait and see if the valves close again after 20s or not!

Given I care less about driving and controlling my valves in open state, I've never tested to see if the DME overrides this diag setting when it needs to control the exhaust valves.

[elmerzasty]

From the code I gather that you resend the message every 5 sec. Isn't it likely that the valves will constantly be closing and opening with the DME interfering?

[packet.pilot]

Originally Posted by elmerzasty

From the code I gather that you resend the message every 5 sec. Isn't it likely that the valves will constantly be closing and opening with the DME interfering?

I've gone up to 15s as of last night and the valves always stay open, irrespective of gear and throttle mode etc.

As you can see in the video posted, it takes about 20s after removal of the device for the valves to go back to their normal state.

[elmerzasty]

That's awesome

Looking forward to further development.

[NorCal f80]

if cost is 100$ that would be awesome but if not why not just get cg precision valve controller

[aboulfad]

Originally Posted by NorCal f80

if cost is 100$ that would be awesome but if not why not just get cg precision valve controller

What if it cost $50 or less one thing as I eluded to above, using that means to control it can only keep it open for a max of 510s at a time...

[packet.pilot]

Originally Posted by NorCal f80

if cost is 100$ that would be awesome but if not why not just get cg precision valve controller

Firstly, because I see hijacking the electrical signal to the actuators as at the very least inelegant, and at most, cheating.

Secondly, that involves wiring, and only does two of three modes afaik (out of three: override open, override closed, passthrough).

Thirdly, because my intent here is not to build an exhaust valve controller, but rather to use EVC as a 'hello world' for this platform, which I'm new to, and wish to do more things with (both in cars and not in cars).

...and the CG Precision unit is not going to help me do IoT development.

Also, as stated, cost is $55 (at the low-end), so it's nearly twice as awesome as you'd hoped.

[psedog]

If only something like this could play well with the JB4. I just want the valves to close in 6th gear. Every other gear it should be open.

[aboulfad]

Originally Posted by psedog

If only something like this could play well with the JB4. I just want the valves to close in 6th gear. Every other gear it should be open.

You can message the DME using another protocol than the one JB4 uses (see above), however it isn't known regardless of JB4, how does such backdoor EVC play with the DME during runtime. In order to do what you asked, you also need to know which gear you are in, that also can be read and you need to permanently keep the valves open, but it seems there is a maximum timeout... but I am curious, why do you want the valves open in all gears and closed in sixth? (Seven for DCT), i guess for cruising purposes?

[aboulfad]

@packet pilot , IoT + car is super fun a very important aspect of IoT is power consumption and the Broadcom WICE used in the photon has nice power saving features. However I found out that that you need to pay attention to how our car handles devices attached to the OBD port, especially with ignition off. When you get to that stage, you can either rig your gizmo with tap in cable for an ampmeter and/or use ISTA's closed circuit monitoring to get some info.

[firedown31]

Originally Posted by aboulfad

but I am curious, why do you want the valves open in all gears and closed in sixth? (Seven for DCT), i guess for cruising purposes?

For me it's exactly the point you mentioned. I would love for my valves to stay open in gears 1-5 and then close for 6 and 7 (DCT here). Give the car a little extra noise as you're accelerating away, instead of going into quiet mode the instant you hit 3rd.

[NorCal f80]

Originally Posted by aboulfad

What if it cost $50 or less one thing as I eluded to above, using that means to control it can only keep it open for a max of 510s at a time...

50$ would be awesome

youre saying the other evc on the market it will close after 8-9 minutes ?

[aboulfad]

Originally Posted by NorCal f80

50$ would be awesome

youre saying the other evc on the market it will close after 8-9 minutes ?

I am saying that using the above UDS msgs over CAN or ENET have a timeout as per the above info. Don't know what 3rd party EVC's do. Don't have one so I can't check but I think packet pilot sniffed the msgs from his using a logic analyzer. I think he confirmed that the valve closes after 20s which is the default as per the above info I put.

The ones that mechanically control the valves obviously don't timeout... $50 is the basic carloop wifi model or my home made gizmo which costs much less.

[packet.pilot]

But your gizmo needs some computer at the other 'end' of it, no? My brusband (the embedded engineer) and I are focusing on CAN for now but are keeping Ethernet-capable packages in mind for the future.

A project to do all this sans Photon on our own board is underway. We've already got tick-timing ticking the OS and nearly have an RTOS running on it. We'll have an STM32f205 dev board with JTAG bright out to facilitate progress.

I have a feeling one day there'll be an initial package offering BTLE and WiFi and doing two things:
1. EVC with user-configurable logic (over CAN/UDS)
2. Touchiness drive-off mode (throttle/steering/EDC/TC), also user-configurable.

So, one old thing with new tweak capabilities, one new thing people have been asking for left and right, which would theoretically come free with the companion app.

Other cool stuff developed could be offered with in-app purchases.

Just spitballing here, no hard plans, clearly in R&D and I'm not selling anything... just sharing thoughts and ideas, which I think is still allowed 'round these parts...

[aboulfad]

My gizmo is a self running openwrt, that you build and run whatever you want on it your option 2 above is a like the search for the holy grail! trust me CAN is trouble, ENET opens up the world for realtime streaming and everything else we can do ... if your goal is to develop something for BMW, ENET is a unique way, CAN is supported on all vehicle makes...

[packet.pilot]

Unfortunately one of the constraints I have with my 'engineering staff' at present is no Ethernet (yet) because dayjob, flying cars, yada yada.

I do have two of those travel gizmos in the box collecting dust as of months ago, too, one torn apart and the other still sealed. A dayjob is only a problem for one of us, "thankfully"... so maybe I'll get to playing around with that.

[aboulfad]

Hahaha, I am up for hire and I am cheap: $ CDN btw, carpool is an IoT device, my home made gizmo isn't, its lowest power consumption is 80mA and doesn't support sleep or deep sleep.

[packet.pilot]

SocketCAN_serial on carloop and can-utils in Linux are working. Here's an example with a message that is bigger than it needs to be...

[psedog]

Originally Posted by aboulfad

You can message the DME using another protocol than the one JB4 uses (see above), however it isn't known regardless of JB4, how does such backdoor EVC play with the DME during runtime. In order to do what you asked, you also need to know which gear you are in, that also can be read and you need to permanently keep the valves open, but it seems there is a maximum timeout... but I am curious, why do you want the valves open in all gears and closed in sixth? (Seven for DCT), i guess for cruising purposes?

Exactly. That's the only time that the drone matters. By throttle position would have been the best option, but we know can messages don't poll frequently enough to facilitate that. It boggles the mind why BMW didn't set it up this way out of the gate. By speed is stupid.

[packet.pilot]

Originally Posted by psedog

Exactly. That's the only time that the drone matters. By throttle position would have been the best option, but we know can messages don't poll frequently enough to facilitate that. It boggles the mind why BMW didn't set it up this way out of the gate. By speed is stupid.

Default behavior, at least on 61.1, is by pedal position in some gears (3rd I believe but not 4th+, then it becomes RPM-dependent, in my 6MT at least). The can bus is plenty fast for this.