Hi Everyone,
I'm an owner of a 2007 Cayman S (987.1). I just bought the RaceCapture Pro MK3. I primarily autox the car, and was hoping to use the RCP3 to create cool videos. Secondary to that, I want to analyze my driving run to run and better understand how I can improve my skills as a driver. At some point, the car will make its way to the track but I've already gotten ahead of myself by buying this little toy.
So...going back to the title of this thread: "What did I just buy.....". Seems like the RCP3 is very powerful tool, if you know what you are doing. Admittedly, I don't know what I'm doing. I'm mildly capable of mechanical things, decent with electronics, and can learn new skills given enough time.
Here is what I've managed to piece together while I wait for my new favorite toy.
The 07 987.1 does not have CAN support via OBDII. (YAY!)
From another datalogging product. I discovered the 987.1 does have CAN at the ecu. Pin 36 for CAN High, and Pin 37 for CAN low. Documentation here: http://www.aim-sportline.com/download/e ... 02_eng.pdf
Data that can be "sniffed" seems to be a bit conflicting. My goals are to try to log the following:
Throttle
Steering Angle
Brake Pressure
Oil Temp
Oil Pressure
Plus all the info from the accelerometers, gps, etc etc.
It sounds like sniffing the data from the CAN is manual in the RCP3. Is this the right place to start: https://wiki.autosportlabs.com/CAN_Bus_logger
Has anyone tried to map the CAN for a Porsche 987.1? Or am I going to be the stumbling trail blazer on this?
Also for bonus points:
It appears that brake pressure isn't provided on CAN. At least AIM hasn't figured out how to get this information. However, someone has discovered that brake pressure can be obtained over OBDII using the Porsche OBDII Protocol and Durametric software. Anyone have clues to how you might get this info? https://rennlist.com/forums/data-acquis ... st13028343
What did I just get myself into?!
What did I just buy....
Moderators: JeffC, rdoherty, stieg
-
- Posts: 138
- Joined: Fri Apr 07, 2017 3:47 pm
- Location: Oakland, CA
Hi,
Thanks for the post and thanks for getting an MK3!
Great that your ECU supports CAN. Using the optional OBDII cable you'll have the ability to get standard OBDII data (PIDs) like RPM, throttle position and engine temperature.
OEMs will also have available custom PIDs which are usually secret / unpublished and the community has to figure it out. RaceCapture/Pro has the ability to query those custom PIDs- once you plug those PID values in, RCP will request those PIDs and make them available along side other telemetry channels.
If you can query your Porsche community for a listing of those PIDs we can make them available in the form of a 'pre-set' so another enthusiast with a similar Porsche can just click one button to import everything.
Hope this helps, let us know what you find out!
Thanks for the post and thanks for getting an MK3!
Great that your ECU supports CAN. Using the optional OBDII cable you'll have the ability to get standard OBDII data (PIDs) like RPM, throttle position and engine temperature.
OEMs will also have available custom PIDs which are usually secret / unpublished and the community has to figure it out. RaceCapture/Pro has the ability to query those custom PIDs- once you plug those PID values in, RCP will request those PIDs and make them available along side other telemetry channels.
If you can query your Porsche community for a listing of those PIDs we can make them available in the form of a 'pre-set' so another enthusiast with a similar Porsche can just click one button to import everything.
Hope this helps, let us know what you find out!
-
- Posts: 70
- Joined: Tue Mar 10, 2015 3:31 pm
- Location: Detroit, MI
My suggestions:
For combining data and video: RaceRender (free version works well enough for me) or Solostorm ($$$ but has more perks)
As Brent said, you can log standard OBD2 PIDs without any special info. Start there. Worry about the CAN stuff later. You'll at least be able to get throttle, engine speed, and temps at decent rates (10-30 hz depending on how many you log and how fast your ECM responds).
For steering and brake, you can infer or directly measure in other ways:
For braking, look at the RCP's (negative) lateral acceleration. This'll tell you when you're hitting the brakes and how hard.
For steering, position your video camera where you can see your steering inputs. (inside car or outside on driver's side of car). Lateral accels can also tell you some about what you're doing with the wheel.
For me, the first thing I want to know is WHERE I'm giving up time on a given run or course. This is best accomplished with a speed vs distance plot and comparing two runs.
With RCP, there's a few ways to get that plot:
1. Use 1.9.0 app and upload your .log files to it (start/finish line must be defined before recording your runs!)
2. Upload .log files to Podium (start/finish line must be defined before recording your runs!) after creating a new Podium event.
3. Convert .log files to .stf files using conversion scripts/programs and open in GEMS/AEMData (defining start/finish lines not required, can crop files as needed in GEMS/AEMdata). GEMS/AEMData are free to download and use.
4. Buy Solostorm and connect it to RCP via bluetooth. Use solostorm to record data and set start/finish.
For the past 2 years, I've been using #3. Mostly since #1 and #2 were either not available or I didn't define start/finish ahead of time. I've used Solostorm a few times when co-drivers had it and it's great. It's the $200 easy button for between run auto-x data analysis.
Once you have two runs of speed vs distance plotted on top of each other, you can at least see where you are carrying more speed and possibly improving your time. I say possibly because the other factor is distance. How much distance you drive varies between runs as well. Sometimes this will show up clearly in the speed vs distance plot as an offset to the right or left for the remainder of the plot. Video is also useful in seeing where you saved distance by running a tighter line.
Anyway, once you find a place you are losing time (by looking at where the place in speed vs distance corresponds to on the track map), you can start trying to figure out the why's and how's using all the other data (accels, video, etc).
Finally, sniffing the CAN bus for the other signals can be time intensive and quite difficult if the info you want is not public knowledge. It appears AiM has figured out some signals for your car, but they don't share the actual info you need to log those same signals in RCP (message ID, start byte and bit, length, scaling, and offset).
For combining data and video: RaceRender (free version works well enough for me) or Solostorm ($$$ but has more perks)
As Brent said, you can log standard OBD2 PIDs without any special info. Start there. Worry about the CAN stuff later. You'll at least be able to get throttle, engine speed, and temps at decent rates (10-30 hz depending on how many you log and how fast your ECM responds).
For steering and brake, you can infer or directly measure in other ways:
For braking, look at the RCP's (negative) lateral acceleration. This'll tell you when you're hitting the brakes and how hard.
For steering, position your video camera where you can see your steering inputs. (inside car or outside on driver's side of car). Lateral accels can also tell you some about what you're doing with the wheel.
For me, the first thing I want to know is WHERE I'm giving up time on a given run or course. This is best accomplished with a speed vs distance plot and comparing two runs.
With RCP, there's a few ways to get that plot:
1. Use 1.9.0 app and upload your .log files to it (start/finish line must be defined before recording your runs!)
2. Upload .log files to Podium (start/finish line must be defined before recording your runs!) after creating a new Podium event.
3. Convert .log files to .stf files using conversion scripts/programs and open in GEMS/AEMData (defining start/finish lines not required, can crop files as needed in GEMS/AEMdata). GEMS/AEMData are free to download and use.
4. Buy Solostorm and connect it to RCP via bluetooth. Use solostorm to record data and set start/finish.
For the past 2 years, I've been using #3. Mostly since #1 and #2 were either not available or I didn't define start/finish ahead of time. I've used Solostorm a few times when co-drivers had it and it's great. It's the $200 easy button for between run auto-x data analysis.
Once you have two runs of speed vs distance plotted on top of each other, you can at least see where you are carrying more speed and possibly improving your time. I say possibly because the other factor is distance. How much distance you drive varies between runs as well. Sometimes this will show up clearly in the speed vs distance plot as an offset to the right or left for the remainder of the plot. Video is also useful in seeing where you saved distance by running a tighter line.
Anyway, once you find a place you are losing time (by looking at where the place in speed vs distance corresponds to on the track map), you can start trying to figure out the why's and how's using all the other data (accels, video, etc).
Finally, sniffing the CAN bus for the other signals can be time intensive and quite difficult if the info you want is not public knowledge. It appears AiM has figured out some signals for your car, but they don't share the actual info you need to log those same signals in RCP (message ID, start byte and bit, length, scaling, and offset).
Josh
-
- Posts: 138
- Joined: Fri Apr 07, 2017 3:47 pm
- Location: Oakland, CA
Right before my order shipped, I threw in the OBDII cable.
I tried the OBDII without any success. I enabled my OBDII. I selected a channel, TPS, write to the RCP3 and go to the dashboard. Add the channel to the dashboard, and I'm not getting any data. This is weird because this should be standard. Tried RPM and that didn't work either.
Am I doing something wrong?
I have other questions too.
With regards to the can bus simple logger, I'm assuming all output is already converted to decimal. The first digit set is the can bus ID, and the following sets of 8 is the data. Is this correct?
I think I've found a few channels of data: throttle, rpm, and two temperatures. I'm not 100% sure. For example: I think throttle is ID 578 Offset 5 Length 2. I assumed I'd be getting the decimal value seen in the Lua script output, but this isn't the case. I was expecting seeing a value from 0-255. But this wasn't the case. What exactly am I seeing?
Also, it seems like after putting in two can bus ID into the can mapping area, I'm maxed out. A third input doesn't work. If I delete one, then I get an output. It doesn't matter which one I delete, it seems to have to do with the number of can bus IDs I'm using, capped at 2.
I tried the OBDII without any success. I enabled my OBDII. I selected a channel, TPS, write to the RCP3 and go to the dashboard. Add the channel to the dashboard, and I'm not getting any data. This is weird because this should be standard. Tried RPM and that didn't work either.
Am I doing something wrong?
I have other questions too.
With regards to the can bus simple logger, I'm assuming all output is already converted to decimal. The first digit set is the can bus ID, and the following sets of 8 is the data. Is this correct?
I think I've found a few channels of data: throttle, rpm, and two temperatures. I'm not 100% sure. For example: I think throttle is ID 578 Offset 5 Length 2. I assumed I'd be getting the decimal value seen in the Lua script output, but this isn't the case. I was expecting seeing a value from 0-255. But this wasn't the case. What exactly am I seeing?
Also, it seems like after putting in two can bus ID into the can mapping area, I'm maxed out. A third input doesn't work. If I delete one, then I get an output. It doesn't matter which one I delete, it seems to have to do with the number of can bus IDs I'm using, capped at 2.
-
- Posts: 70
- Joined: Tue Mar 10, 2015 3:31 pm
- Location: Detroit, MI
The CAN data is in binary form. You tell it the length of the signal in the message, then those bits are taken together and turned into an integer. This integer is then scaled and offset.
Example:
Message $197 (hex ID) has the following data in it (4 bytes) :
1101 0110 1010 0001 1110 0111 1010
You tell it to start at byte 0 and the length is 2 bytes, so your data is:
1101 0110 1010 0001
Converted to an integer, this is 54945.
your scaling might be 0.0125 with an offset of 819.1875 to give a range of decimal values of +819.1875 to -819.1875.
I'm logging at least 6 different messages in my lua script, so it's definitely possible to log more than 2.
Something to keep in mind - some OEMs do not parse on even bytes. The first 3 bits of a byte might mean one thing and the next 14 bits might mean another.
Example:
Message $197 (hex ID) has the following data in it (4 bytes) :
1101 0110 1010 0001 1110 0111 1010
You tell it to start at byte 0 and the length is 2 bytes, so your data is:
1101 0110 1010 0001
Converted to an integer, this is 54945.
your scaling might be 0.0125 with an offset of 819.1875 to give a range of decimal values of +819.1875 to -819.1875.
I'm logging at least 6 different messages in my lua script, so it's definitely possible to log more than 2.
Something to keep in mind - some OEMs do not parse on even bytes. The first 3 bits of a byte might mean one thing and the next 14 bits might mean another.
Josh
-
- Posts: 138
- Joined: Fri Apr 07, 2017 3:47 pm
- Location: Oakland, CA
Care to join me here?
viewtopic.php?t=5300
I found rebooting the rcp3 after i add a mapping seems to do the trick.
I appreciate the tip about data potentially starting at an odd byte position.
viewtopic.php?t=5300
I found rebooting the rcp3 after i add a mapping seems to do the trick.
I appreciate the tip about data potentially starting at an odd byte position.