We have a comprehensive guide on how to map CAN-enabled devices to channels on RaceCapture:
https://wiki.autosportlabs.com/CAN_Bus_Integration
Read this first when you're ready to take on mapping a device that isn't already supported in one of our pre-set CAN integrations.
You're welcome to post here to talk about new integrations you're working on, questions on things we haven't covered in the guide, or anything else relevant to CAN mapping technologies!
Thank you,
Read first: CAN Mapping integration guide
-
- Posts: 138
- Joined: Fri Apr 07, 2017 3:47 pm
- Location: Oakland, CA
Yes! Great sub forum!
Brent, any way you can provide packet filtering in the future?
I feel the RCP3 is already capable of reading can data. A method of filtering packets to only show what is changing, and at what position would go along way in helping the rest of us map the can bus for different cars.
I'm not against buying extra hardware to use some of the software already available, but I feel it is a bit redundant.
I wish I could program something to make this work, like you previously mentioned, but I'm out of my depth.
Brent, any way you can provide packet filtering in the future?
I feel the RCP3 is already capable of reading can data. A method of filtering packets to only show what is changing, and at what position would go along way in helping the rest of us map the can bus for different cars.
I'm not against buying extra hardware to use some of the software already available, but I feel it is a bit redundant.
I wish I could program something to make this work, like you previously mentioned, but I'm out of my depth.
That's great. Ok here's the spreadsheet!
Coming next. Thanks Brett!!!
There doesn't seem to be one that is deifnitive for the gen iv Prius (aka 2016. Aka zwx50)
By there is one for the previous gen iii (aka zwx35) so we can start with that https://priuschat.com/threads/geniii-pr ... app.98693/
And here is the csv that shows the decoding https://docs.google.com/spreadsheet/ccc ... LcHc#gid=4
Not all these pids work but steering angle is a key one as is the speed. I can send u a list.
By there is one for the previous gen iii (aka zwx35) so we can start with that https://priuschat.com/threads/geniii-pr ... app.98693/
And here is the csv that shows the decoding https://docs.google.com/spreadsheet/ccc ... LcHc#gid=4
Not all these pids work but steering angle is a key one as is the speed. I can send u a list.
-
- Posts: 3
- Joined: Tue Jan 03, 2017 11:28 am
- Location: Virginia Beach, VA USA
- Contact:
Are there any plans for a more robust ability to create a formula for a CAN mapping in a future release. The standard raw x a / b + c is great but doesn't cover all use cases. For example, on my 370Z, the formula for steering angle needs to be -> if raw>32,767 then -(65535-raw/10) else raw/10
I haven't purchased a system yet, still investigating but I'd prefer the RaceCapture/Track model instead of the RaceCapture/Pro model and as I understand it. I'd need the Lua scripting support which from what I can tell isn't on the RaceCapture/Track model.
Thanks,
Tim
I haven't purchased a system yet, still investigating but I'd prefer the RaceCapture/Track model instead of the RaceCapture/Pro model and as I understand it. I'd need the Lua scripting support which from what I can tell isn't on the RaceCapture/Track model.
Thanks,
Tim
Hi,
Good question. Actually, it looks like your 370 uses a sign-magnitude approach for the steering angle, similar to the BMW E46. In sign magnitude, the highest bit represents the sign of the number. https://en.wikipedia.org/wiki/Signed_nu ... esentation
Fortunately, we already have that covered already in the sign-magnitude data type, where the raw value is converted to a +/- value for that data type; *then* the formula is applied, so it just works with the existing CAN mapping capabilities.
Happily, nearly everything seen in the industry is covered by the conventional formula. For anything that actually needs complex logic for mapping, there's the Lua scripting supported by RaceCapture/Pro and RaceCapture/Apex.
We talk about both approaches extensively here:
https://www.autosportlabs.com/racecaptu ... -released/
Good question. Actually, it looks like your 370 uses a sign-magnitude approach for the steering angle, similar to the BMW E46. In sign magnitude, the highest bit represents the sign of the number. https://en.wikipedia.org/wiki/Signed_nu ... esentation
Fortunately, we already have that covered already in the sign-magnitude data type, where the raw value is converted to a +/- value for that data type; *then* the formula is applied, so it just works with the existing CAN mapping capabilities.
Happily, nearly everything seen in the industry is covered by the conventional formula. For anything that actually needs complex logic for mapping, there's the Lua scripting supported by RaceCapture/Pro and RaceCapture/Apex.
We talk about both approaches extensively here:
https://www.autosportlabs.com/racecaptu ... -released/
- Attachments
-
- RaceCapture_can_mapping_sign_magnitude.png (75.12 KiB) Viewed 13628 times
Hi Brent, I never saw boggie's comment addressed so I wanted to add another voice wishing for something similar. I luckily have access to a PCAN device, and have used that to find channels prior to buying RC, now that I have my RCT2 installed and wiring squared away I would rather use RC as the interface to further map the buses.boggie1688 wrote:Yes! Great sub forum!
Brent, any way you can provide packet filtering in the future?
I feel the RCP3 is already capable of reading can data. A method of filtering packets to only show what is changing, and at what position would go along way in helping the rest of us map the can bus for different cars.
I'm not against buying extra hardware to use some of the software already available, but I feel it is a bit redundant.
I wish I could program something to make this work, like you previously mentioned, but I'm out of my depth.
Even without filtering, a simple GUI to hold each ID as a single line item and watch for changing bytes in real time (how PCAN View does it) would be great. Displaying the refresh rate on the bus would also help inform smarter RC sample rates (no sense in sampling at 50Hz if the bus only gives 10Hz).
Anyway, thanks for your consideration. I think it will accelerate mapping undocumented factory CAN data and feed further presets -> value of RC.