UDS polling rate with OBDLink MX+

easytelemetry

Hi everyone,

I'm experimenting with custom UDS PIDs in RaceChrono Pro and would like to understand whether the polling rate I'm seeing is limited by RaceChrono itself or by the OBDLink MX+ . Car is a 2014 BMW F20 M135i (N55, MEVD17 DME) and adapter is OBDLink MX+ (firmware 5.12.4)

I'm reading proprietary BMW UDS Data Identifiers (service 0x22) through the standard OBD-II connector.

Initialization string is as follows:
ATZ
ATE0
ATL0
ATS0
ATH1
ATSP6
ATCAF1
ATCFC1
ATSH7E0
ATCRA7E8

The custom PIDs are working correctly, however, the maximum device acquisition rate reported by RaceChrono is consistently around 20 Hz. I have also verified that Request delay is set to 0 ms.

Questions

Is this 20 Hz device rate a limitation imposed by RaceChrono's UDS polling scheduler, or is it simply the maximum throughput of the OBDLink MX+ / STN11xx hardware?
Has anyone managed to achieve a higher UDS polling rate with the MX+ using custom BMW UDS PIDs?
Would switching from UDS polling to CAN Bus mode be the recommended solution for higher acquisition rates? If so, are there any tutorials or documentation explaining how to configure RaceChrono and the OBDLink MX+ to log data directly from the CAN bus?

Thanks

aol

easytelemetry 1. RaceChrono does not impose any rate limit on OBD-II data, it polls as quickly as it can. 3. Well potentially, but there's some problems with the raw CAN-BUS over MX+, some users are reporting connections that "get stuck". Also you need to know the raw CAN-BUS packet formats, in order to configure the channels in RaceChrono.

easytelemetry

aol

Thank you very much for your response. I'll give it a go with the CAN mode and then report back. Regarding CAN packets identification, I've found this link that has the Identifiers:

https://thesecretingredient.neocities.org/bmw/#two

Cali_Chuck

Hey @easytelemetry - haven't owned a bimmer in years but am part of an active CAN back-engineering group over in Porsche land. While our signals may not be identical, you asked about the general process of how to set up RaceChrono to use CAN. For that, please see my extended writeup https://www.718forum.com/threads/successfully-hacked-my-718-gts-can-bus-for-racechrono-data.31918/.

Also @webkris has a nice writeup about his work (also Porsche but the process is universal) here - https://planetkris.com/

There's also a bunch of writeups by bimmer owners on this you can easily Google - here's one from an M3 owner with the whole tapping & scanning & racechrono process - https://g80.bimmerpost.com/forums/showthread.php?p=29397382

What I've discovered in chasing CAN signals under the Volkswagen umbrella is that there's a huge amount of commonality across brands you wouldn't think share anything - because the number of ECU makers is actually pretty small. BMW is obviously more of a standalone entity that may not apply as much. But if you can identify a common ECU vendor shared between your target car and some more mainstream brand for which CAN signals have already been recovered, there is a decent chance that those signals would apply to your ECU. Then all you have to do is some back-engineering to isolate the particular signals of interest that don't show up in other documentation.

There's an active OpenDBC project over on Github with CAN definitions (called .dbc files because that's the format) for over 15 manufacturers (not BMW however) but would be a place for a coder to start to see some code for reading/writing the bus.

Also... I've been surprised just how much manufacturer docs have leaked onto the open internet in various fora like these from interested parties. For instance, a quick search turns up this site with DBCs for an E90 and E39 - https://github.com/nberlette/bmw-dbc.

easytelemetry

@Cali_Chuck , thank you very much for your hints. I went through all of this links before I strated my project, and none ofd them was really helpful to find out PID IDs. What ended up saving the day was this website:

https://thesecretingredient.neocities.org/bmw/can/g29/

Almost every of these PIDs worked for me, except the steering angle.

Made a log couple of hours ago and everything worked beautifully, all signals are recorded at 20 Hz and connection is stable.

Cali_Chuck

easytelemetry that is a very nice list, glad to see other car brand enthusiasts going down this road.

easytelemetry

And it worked out beautifully on the track. Thanks for everyone that supports the the enthusiasts and for @aol for this great piece of software. I didn't have enough time to setup my video rendering software yet, but I managed to acquire all cars accelerometers, the gyroscope, ABS and TC signals. With these and some extra time, I'll build a ovesteer/understeer gauge! For now, I made this video with the result:

https://youtu.be/8G_VeAz4hmg?is=xmAsw7Mskt32PvRL

Cali_Chuck

OK, coming back to this thread but now on the topic of OBD/UDS. Also tagging @TriB and @easytelemetry for help.

I've now installed a 3rd OBDLink MX+ in my vehicle into RaceChrono. 2 of them as noted in other threads are CAN-only. The new one is OBD only for some channels that I just can't yet locate on CAN bus.

I know all about getting mode $01 PIDs, that works fine with normal RC setup.

But I have a list of mode $22 RDBI DIDs that has very useful stuff in it. Writing because for the life of me I cannot get RC formula to produce a non-zero output with any variant of a formula.

I am issuing mode $22 DIDs no problem - and verified with simultaneous OBD packet sniffing. Responses are coming in as expected with no errors.

In RC when I enable Live Data Test, it even shows me the realtime results correctly. But no version of any formula I try produces anything but a zero.

Here is one of many such screenshots

https://www.dropbox.com/scl/fi/qg8mlpinux8dmt7e1l0f6/RC-RDBI-channel-definition-showing-valid-live-data-but-zero-formula-result.jpg?rlkey=ammjfmh1ijjifbl1ymecdwgeq&st=xrw2lxc0&dl=0)

I've tried both bytestoUInt(raw,X,Y) and bitstoUInt(raw,X,Y) same result. Going by bytes I have stepped through all integers from 0 to 15 with no change. Same on bits.

I believe I have the custom channel setup correctly because it's returning data. I have 0x7E0 as "Header" and 0x07E8 as Response Prefix".

Anyone see an obvious mistake in my channel config? Has there been some regression in the code regarding processing mode $22 RDBI query responses?