987.1 Can Bus Mapping

[boggie1688]

Brent,

I recorded the following data. All of this was done on the same "short track".

Test with the script unmodified from above:
https://drive.google.com/open?id=1BRtit ... cNnLQA29Z4

Test with the script having removed the gopro function call from onTick():
https://drive.google.com/open?id=1EvR7V ... jNTkJwiyTc

Test with the simple can logger script, data has been parsed for only the steering can id, then my steering formula applied to the last column:
https://drive.google.com/open?id=1Zpyyv ... Vwa-ekTXZk


There is appears to be a difference between the raw can data vs what is being logged via the LUA script. The can data has slight gaps when the wheel is moved VERY quickly, but it still has a higher resolution than the LUA script version. It appears the GoPro script had no affect on the logging rate. Additional, the can script used had the default tick rate.

[brentp]

Overall, the direct CAN mapping will always be faster than Lua, correct.

However, if you're not setting the tick rate, then it'll default to 1Hz. To clarify, the latest script you were testing with - did you set the tickRate in there?

[boggie1688]

Set @ 50hz.

It is what it is. I think the angle sensor is a bit on the slow side to begin with. Coupled with the slight difference between the can and lua, and there is a 4 second differential between when I turn the wheel from 0 to 90 degrees and hold, to when it changes on the app.

[brentp]

4 seconds is absolutely huge. Is that with the direct CAN mapping? It could be that whatever on the car that is outputting that CAN data might be creating the delay.

What I would do is try the CAN logging script and observe all the messages. observe the responsiveness of a different channel, like RPM - you can probably see the raw numbers changing (like Neo in the Matrix) as you blip throttle. Compare that responsiveness with the steering angle changes.

[boggie1688]

Brent

4 seconds is huge and not very useful. This is with lua scripting.

The docs previously attached show that at a can level, the steering sensor is quick. It skips angle if the steering wheel moves too fast, but otherwise there is pretty good resolution.

Please take a peek at the sheet and let me know.

I guess alternatively, I can change the can logger script to only show message ID 194 and see how responsive it is. Maybe I'll try that tonight if I have time.

[boggie1688]

Brent, it has been awhile. Autox season hit full swing, and side projects to up my free weekends. Funny enough, my post about decoding the 987 can caught some attention on other forums. I've had a few people reach out to me.

One guy even manage to decode steering. Much like me, he figure out the can ID and which bytes contained what data. In fact, he has provided a log from his can bus.

Both of these logs are 987.1. He has a homebrewed can logger, but the data is good.

My car:
https://docs.google.com/spreadsheets/d/ ... sp=sharing

Another members car:
https://docs.google.com/spreadsheets/d/ ... sp=sharing

The can data is there, and its quick enough.

For whatever reason, after my LUA script or during, the data has holes. Any ideas what I can do here?

[brentp]

Thanks for the update. I'm guessing your data, the first 9 columns is the CAN bus data.

What are the K and L columns exactly?

I remember the conversion formula was the tricky part. What did the formula end up being?

[boggie1688]

Data in byte 0, 1

If byte 1 is >= 128 then steering is positive.
If byte 1 is < 128 then steering is negative.

I got lazy and just calculated some of the negative portions because that happened to be the direction the other data went first.

K is the hex shift, because the data is contained in two bytes. So Data[2]*256+Data[1]=steeringangle. Then L applies my multiplier to get the final angle (*.0436). I applied this formula to the other data set as well. You just gotta scroll way over.

[boggie1688]

This was the final version of the formula or code to deal with steering angle.

steerId = addChannel("Steering", 50, 0, -450, 450, "Deg.")

function getSteering(chan)
id, ext, data = rxCAN(chan,100)
if id == 194 then
processSteering(data)
end
end

function processSteering(data)
local steer = 0
if data[2] < 128 then
steer = -1*((data[2]*256)+data[1])
else
steer = (((data[2]-128)*256)+data[1])
end
setChannel(steerId, (steer*.0436))
end

[brentp]

It sounds like the steering angle is very similar to how the E46 steering angle works. Can you try the direct CAN mapping using the 'sign magnitude' data type?

https://wiki.autosportlabs.com/CAN_Bus_ ... he_mapping

[boggie1688]

Brent,

I finally had a chance to come back to this.

It worked!!!

I still need to drive the car to make sure it is picking up the angle fast enough, but in the garage it seems perfect!!

[brentp]

That's great. Can you switch all of your remaining mappings from Lua to the direct CAN?

[boggie1688]

That was actually the only LUA mapping.

I'm kinda surprised how much faster it is seems to be. Still TBD, but initial impressions are that the lag is completely gone.

[brentp]

Right on! Yes, the native CAN mapping is lightning fast.

[VPD]

Boggie are you still working on this? Somehow I never discovered RaceCapture until recently, but over the last year I've been off and on sniffing CAN bus channels manually on my 2007 987.1, preparing to make an Arduino CAN solution that would output OBD protocol, but now I'm going to go the RaceCapture/Track MK2 route I think.

It's hard to find good info on Porsches so here is what I've figured out in general (aside from specific CAN channels).

The CAN bus is actually wired to the OBD2 port, but it is not active in the normal sense because a gateway controls their output, and even when active they don't follow a standard CAN protocol. The secret handshake and protocol is what Durametric figures out, and why the data over Durametric is way faster, because it's using the CAN bus and not the K line that OBD2 uses.

There are 3 separate CAN buses on the car, and not all of them have the same data. The gateway collects all 3 and makes everything available on the OBD2 port CAN wires if you know the protocol. Assuming none of us do (if we did Brent, could RaceCapture accommodate it?) we have to make physical connections to all 3. I've sniffed 2 buses so far, and if you only tap the commonly referenced Drive (ECU) bus (like AIM says to do), you miss additional channels...like brake pressure (whereas only brake on/off is on the Drive bus).

From what I read RC/T can handle 2 CAN buses, so if we don't use the OBD connection, we can tap both the Drive and Display CAN buses and get most (if not all) channels any track rat wants.

I've not yet mapped or figured out the scaling for the channels I've identified, but I was hoping we could trade notes. Earlier in the thread Brent hinted at including these in the presets, but has that been done for some Porsche models? I downloaded the app but without RC hardware yet I can't see a list.

Long ago I installed a full electric sweep oil pressure gauge in the car and want to feed the 0-5V signal into RC/T, Boggie did you ever try this? It looks possible using the AnalogX board, but it isn't clear to me if that would take up 1 of the 2 CAN inputs, or if it can be injected into one of the CAN bus streams so I can tap 2 buses.