dump canbus data

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.

thanks

Comments

  • I have decided to grab a PiCan2 hat and a ODB-2 cable, which in the end, will probably make reverse engineering easier with can-utils and wireshark to help process the messages.
  • @dirtyfreebooter There's deliberately no reverse engineering functionality in RaceChrono, but I guess it could show the CAN-Bus PIDs it sees. Although the message format is the important one, which needs to be reverse engineered. I think I should purchase a similar reverse engineering setup too...
  • edited August 2022
    yea, totally. having cansniff and candump and the ability to replay can dumps will end up really being much nicer to reverse engineer stuff in the long run anyways.

    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
  • edited August 2022
    Notice the DIY CAN-Bus API will be able to do ~100 messages per second due to Bluetooth LE bandwidth constraints, the rest are just trashed. The OBDLink MX+ (as it's based on Bluetooth Serial Protocol) will be able to do more, but I don't know how much more.
  • edited August 2022
    yea, but the BMW OBD-2 CAN-BUS pins don't actually provide any real data or CAN-BUS "stream" with the G series BMW, if you read that bimmerfest link, you'll see that BMW has some sort of request/reply protocol in place, so instead of a constant stream of messages.

    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"
  • edited August 2022
    @dirtyfreebooter "BMW has some sort of request/reply protocol" yes, and this is called OBD-II :smile: You're just seeing OBD-II request/reply on CAN-Bus packet level.

    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

  • this is my PiCAN2 setup
    https://photos.app.goo.gl/75sTkNCbMBEJRYGe9

    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.

    https://copperhilltech.com/pican2-can-interface-for-raspberry-pi-with-smps/
  • FWIW if you have already made an Arduino-based DIY BLE device for RaceChrono, it might be easier to reverse engineer the protocol using that device connected to a laptop.
    Here's a good starting point:
    https://github.com/timurrrr/arduino-CAN/blob/master/examples/CanBusMonitor/CanBusMonitor.ino

    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.
  • honestly, this PiCAN2 setup is working great, candump and cansniff, especially cansniff's color output + filtering is incredibly helpful at identifying PIDs. I have basically been doing this:
    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:
    1) rpm
    2) throttle
    3) gear
    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. :smile:
  • hey @dirtyfreebooter, I am looking into PT-CAN as well trying to communicate with Mini F60 instrument cluster. Would you share your findings anywhere (esspecially about the PT-can frames? are they any similar to the frames shared by http://www.loopybunny.co.uk/CarPC/filter.php?filter=flag_KCAN2 )?
  • @ogonzuhnina i posted a detailed write-up over on bimmerpost, which includes a link to a google spreadsheet of all the PIDs i have decoded so far https://g80.bimmerpost.com/forums/showthread.php?p=29397382
  • edited July 2023
    BMW OBD ports are connected to the ZGW (Gateway) and the canbus wires terminated at the OBD connector do not expose the raw canbus frames as you see on the PT-CAN. You can decode the prg files from ediabas for the particular engine code which will give you all the extended BMW OBD sensors, PIDs and associated formulas however each of these calls are still over OBDII. On the F8x I find the request/reply limited to a minimum of 20ms for each poll. Don't get excited as there appears to be no relationship between the decoded prg file and the raw canbus frames. Not that I have found anyway.

    Ideally you want to probe the bus via Ethernet via the OBD port which will be super-fast but I have never seen an arduino library for this and well above my skill level. For example BM3 can log many channels at a very fast rate.

    Otherwise, as you have concluded, tap into the PT-CAN via the FEM and manipulate the raw frames.
Sign In or Register to comment.