Custom PIDs?

[Drewster]

I noticed in the "hacking" guide, we're essentially left with a list of PIDs and told "don't use anything else, it'll just get ignored"

Is there any plan for implementing custom PIDs? I would love to just use my Arduino to pull brake pressure (for example) off of CAN, and then send that data as a custom PID.

As a hardware guy, it's a little frustrating to have access to loads of data (limited only to what you can pull off the CAN bus), access to a brilliant app that can merge and overlay everything, but no way to take the data I really *want* and merge it into the app.

[Harry]

Yes, custom PIDs are planed. There are actually several things to do:

1. Enhance the database scheme to support missing engine parameters / channels (like brake pressure).
2. Use these fields in displays and functionality (like overlay or real time displays).
3. Probably provide some fallback to calculate these channels in case they are not provided (like neg. longitudinal acceleration for brake pressure).
4. Provide access to non standard sources (like custom PIDs).
5. And map these sources into the enhanced set of channels.

The reason I didn't start the custom PID item for v20 has actually been trivial. I'm lacking a test environment. I do not know about any custom PID for my 997.

As solutions become available providing brake pressure out of the box (like Autosport Labs' RaceCapture devices), I will probably start with 1, 2, 3. Btw. you may mimic ASL's protocol instead of using ELM lingo too. ASL's protocol is open source. Let me know if you want to dive into something like this and I will provide the missing glue to recognize an Arduino as RCP.

- Harry

[Harry]

P.S: In case you have some full ELM conversation on any custom PID request and the reply received for a specific car, please make it available. It will allow me to create a test case I can use. I have some samples collected already, but they are incomplete and there is nobody I can ask to verify on byte level.

[Drewster]

I would LOVE to dive into this. I've got an e46 M3 so most of the arb ID's etc. have been figured out. Where would you like me to post progress, etc.?

[Harry]

Post it here or send it to Harry@gps-laptimer.de.

Harry

[salvodrago]

Hello Harry,

I'm also interested in custom PIDs to get data from a ducati.
So far I've managed to use HLT with a ducati by using a custom HW bridge to convert the proprietary into OBDII PIDs.
However if HLT would allow to define custom PIDs i can get rid of the additional HW, decreasing latency.

Is already something on the radar for custom PIDs or it is considered low prio?

Cheers,
Salvo

[Harry]

Lots of requests, but people are mostly not aware they need knowledge on the actual PIDs provided by individual cars. So priority is probably higher than it should be

Harry

[Drewster]

I've finally had a chance to come back to this after taking care of some work stuff, and over my vacation I plan to tinker with the following setup:

[ELM327 + Venus GPS] -> [Rasberry Pi] -> [HLT] with the goal of using something better than an ELM later down the road.

After my last track day I really wanted more PIDs (brake pressure, namely), and much much higher GPS resolution. After doing some basic numbers, a basic Arduino can't really hack the high GPS rates, and the data rates would probably require Wi-Fi as well.. making the add-ons on a Mega pretty expensive at the end of the day. The Pi's Broadcom chip doesn't have any CAN IP, but I figure I'll use SparkFun's ELM breakout until I get around to doing something much more cost-efficient of my own.

Honestly a more embedded environment like an Automotive Freescale/NXP chip would be more comfortable to me, but I'd really like to move forward with something that's easy to replicate for people.

I know it's kind of a long way to say "I made some changes to the plan and bought some stuff but haven't really gone anywhere", but I figured I'd update my direction, just in-case someone's like "oh here's a perfect Python library to communicate with HLT over TCP/ Wi-Fi"

[gplracerx]

I've been logging engine data on my Mustang for chassis dyno pulls using an SCT tuner as the interface between the OBD port and a laptop. I noticed in the list that some functions are listed as OBD and PID. If you select on OBD function instead of the PID equivalent, you get a warning that datalogging may drastically slow down. I'm currently logging 22 different items at reasonable rates. So there must be some fast protocol available.

[Drewster]

I've been logging engine data on my Mustang for chassis dyno pulls using an SCT tuner as the interface between the OBD port and a laptop. I noticed in the list that some functions are listed as OBD and PID. If you select on OBD function instead of the PID equivalent, you get a warning that datalogging may drastically slow down. I'm currently logging 22 different items at reasonable rates. So there must be some fast protocol available.

I'm not familiar with how SCT does their datalogging, but I would suspect that one refers to a textbook SAE J1979 request/ response (which all 1998+ cars must comply to in the US) and the other is a listen only or manufacturer specific query (there's a lot of stuff the different manufacturers do to their own liking beyond J1979)

The main thing I'm trying to do is listen on the CAN bus for brake pedal pressure, translate, store it, and when HLT requests [custom PID def], the module on the bus will send it out just as if it were a standard PID