OBD2 Splitter

Hi! I'm trying to use an OBD2 splitter with racechrono and a race dash, but I cant, if I connect the dash before racechrono it doesnt show any data or channels in racechrono, but if I connect first the racechrono app and then the dash both works perfect for like 15 seconds and then racechrono stop recieving data, while obd2 Bluetooth still blinks (showing it is working) and other apps like torque pro or dashcommand works fine with the splitter 🤔

Comments

  • This is an unsupported use case in RaceChrono. I don't think it makes sense. If you use a splitter and two apps polling the ECU for OBD-II PIDs, you're going to get a really bad update rate, and probably unexpected results for the PID requests. Please do not do this.
  • Ok, I asked because any other apps works perfectly with good update rate, even racechrono for the 10seconds it works, aim dash polls 360 pids per second and I could use torque pro at the same time working fine

  • edited April 2021
    Yes I understood. But I have no plans to fix this, as the splitter is not the right way to go. For listening CAN-Bus data its fine, but not for OBD-II as it does active polling. Doing that from two devices at same time does not make sense to me.

    Also I'm fairly sure AIM Dash uses CAN-Bus not OBD-II... :smiley:
  • @aol I believe the use case here is that the "race dash" is not an app on the phone, but a separate hardware device. The OBD protocol is designed in a way that multiple devices should be able to request different PIDs without conflict. However, I agree with you that it will affect the update rate.

    The race dash could theoretically just listen to the data already broadcast over the CAN bus, but I presume they just use the OBD protocol for simplicity and almost universal support. Just as a data point, using my DIY CAN reader in parallel with a OBDLink MX+ in the OBD mode works great for me in RaceChrono. The reason I'm doing that is because unfortunately, some data in my car only seems to be available on request (OBD PIDs) and isn't regularly broadcast (CAN PIDs), or at least I wasn't able to find the right CAN PIDs. I'm planning to add OBD polling to my CAN project and introduce a synthetic CAN PID so that RaceChrono can get that data over the CAN DIY protocol. It might also be useful for RaceChrono add support for OBD requests over CAN DIY protocol.
  • Well, like I said, I'm completely fine with the splitter is one is polling OBD-II and one is listening CAN-Bus. It's not optimal but works.

    BUT I'm not going to change my opinion about two OBD-II devices polling at the same time. Please do not ask for that feature. :lol:

    You could push any data through the DIY "CAN-Bus" API, so not sure if it needs any RaceChrono support to do that. Just create an OBD-II polling cycle on the device, and have special PID numbers to output the data to RaceChrono. It's DIY after all.

    I'd like to do that OBD-II + CAN-Bus with the commercial products like OBDLink, but unfortunately the rigid protocol does not really allow this properly. The update rate would suck on either the CAN-Bus or OBD-II PIDs.
  • > Just create an OBD-II polling cycle on the device, and have special
    > PID numbers to output the data to RaceChrono. It's DIY after all.

    Yeah, that's what I was thinking as a hack for now too.
    But hope some day there is enough demand for this to become part of the API :wink:

    > I'd like to do that OBD-II + CAN-Bus with the commercial products
    > like OBDLink, but unfortunately the rigid protocol does not really allow
    > this properly. The update rate would suck on either the CAN-Bus or OBD-II PIDs.

    Understood... :neutral:

    For channels where I do need high refresh rates I already found most of the CAN PIDs needed.
    But there's a bunch of OBD PIDs that I can't easily find on the CAN bus for a few cars,
    and I don't need them at a high update rate anyways. But oh well.

    Again, I understand the technical limitations, just complaining at the combination of
    - lack of CAN PID standardization or at least documentation
    - inflexibility of the communication protocols
Sign In or Register to comment.