hi. i have a obdlink mx+ connected to bmw. when i use it via obd-ii mode i can get about 7hz with 3 data fields. add 4 or 5 and it’s around 3hz. so i saw that i can connect it as a canbus device instead. the “test” connection status was showing as connected and showing 225 kbit/s of data. that’s good considering obd-ii was going at like 0.9 kbit/s (tho i realize obd is request/reply and canbus is more of a giant pipe you filter out). also canbus has potentially better info for us track users
anyway the age old problem of canbus ids being guarded secrets, i was wondering if there was a way to dump the data seen by racechrono so i can investigate the data stream.
that being said, when trying to use the DIY Bluetooth LE API, it would be nice to have some sort of way to see what RaceChrono is seeing when trying to debug. Sometimes its unclear as to where the disconnect is happening.
i tried using the OBD-2 CAN-BUS pins on the 2022 BMW G80 M3, but there is nothing but garbage on that as BMW seems to have filtered it pretty heavily, as noted here: https://www.bimmerfest.com/threads/bmw-m235i-f22-can-read-message-reads-only-0x130.927805/
even so, i still tested it and i was able to get 29 can messages per second, which is not great, barely better, if at all, then OBD-2 protocol. i decided to tap into the main nervous system, lol. based on the AIM SOLO2 documentation, using the CAN-BUS wires in the passenger footwell.
as soon as i connected my DIY device, it jumped up to 1700 messages per second with the car off!.
My progress so far: https://photos.app.goo.gl/Wjcwdx6qovqeoQZL7
When I sent the following data on [0x7DF]:
02 01 0D 00 00 00 00 00
1st byte: length=2 bytes
2nd & 3rd bytes: PID=010D (Vehicle Speed)
I received the following data on [0x7E8]:
03 41 0D 00 AA AA AA AA
1st byte: length=3 bytes
3rd byte: SPEED=0 kmph
you need to make a request with pid 0x7DF and get the reply with pid 0x7E8
in my experience with using the OBDLink MX+ with my 2022 G80, RaceChrono sees no pids, except for 0x130, which is just some sort of keepalive *shrug*. i was unable to get any of the pids i see from tapping into the CAN-BUS under the passenger footwell .. but again, its hard to tell, because i don't know what RaceChrono is actually seeing from the MX+, only that i see bandwidth being used when i toggle on the "Test CAN-BUS device"
0x7DF is the standard "OBD-II request header". The 02 is message length, and 01 0D is the OBD-II request for speed.
0x7E8 is the standard "OBD-II response header". The 03 is message length, and 41 0D is the response to 01 0D, and 00 is the payload (speed).
Here's the list of standard OBD-II PIDs: https://en.wikipedia.org/wiki/OBD-II_PIDs
https://github.com/iDoka/awesome-automotive-can-id i think this is really useful data, for @aol_of_RaceChrono and for the users
candump + cansniff (with filtering) is pretty good way to find stuff. writing custom python scripts to process the candump logs to try and tease out the data values.
the anker battery is amazing, powers pi4 for days. the JST connector makes it easy for me to switch between PiCAN2 and my Adafruit DIY device for connecting to RaceChrono.
Here's a good starting point:
That being said, I also wish there was an option in RaceChrono to save raw CAN data as-received, and let the user tinker with equations to extract data after the fact.
1) cansniff + color + filters
2) do something in the car, like press pedal or move steering wheel
3) once i have identified the PID i think is responsible, i switch to candump
4) using candump on that one PID, i try and test all the values, like pedal idle, pedal 50%, pedal 100%
5) using python scripts to tease out the data format in the PID
i am working with BMW PT-CAN bus, so it appears each can frame has some counters and CRCs bytes, most values are using 1 byte or 2 bytes + some formula. so far i have identified:
4) gearbox (p-n-r-d)
5) gearbox shift speed, s1, s2, s3
6) brake pressure front
7) brake pressure rear
currently looking for engine temp, coolant temp, intake temp, steering angle, fuel level
The PiCAN2 setup is nice because i can power it for days with an anker battery, SSH into it control candumb/cansniff.. doing anything with arduino + serial + usb cable is a more of a hassle because i have to have cables connected and laptop in the car, etc.