I'm using the OBDLink MX+ Bluetooth reader in an iOS environment and would like to use a third-party OBDII monitoring gauge with RaceChrono.
Therefore, OBDII is connected to a third-party monitor equipment other than RaceChrono to function as Tx for diagnostic request messages(e.g. 0x7E0, 0x7E1, etc.), and RaceChrono and OBDLink MX+ only function as Rx for diagnostic response messages(e.g. 0x7E8, 0x7E9, etc.) floating on the D-CAN bus through a CAN-bus connection for RaceChrono APP Logging.
RaceChrono & OBDLink MX+ cannot connect to OBD-II because it causes a conflict of UDS Request messages as 'Sender'.
Therefore, RaceChrono & OBDLink MX+ only wants to connect to CAN-bus as just 'Reader'.
I would like to designate the only sender of the vehicle system's OBDII D-CAN as a third-party gauge.
However, the problem is that UDS on CAN diagnostic response messages have a multi-frame format because they follow the CAN TP ISO 15765-2 protocol.
If I set the CAN-bus PID to 0x7E8,
RaceChrono & OBDLink MX+ CAN-bus connections recognize only 8 bytes Data Field of each single-frame line in multi-frame in turn.
For example, if the CAN-bus is being received as follows
0.010sec 7E8 10 2D 62 E0 01 9F F7 FE ---> First Frame for Multi Frame. 45 Bytes(2D) datas contained in '62 E0 01' response
0.020sec 7E8 21 00 00 AA 00 00 00 00 ---> Consecutive Frame for First datas in '62 E0 01' response
0.030sec 7E8 22 00 00 00 00 00 00 00 ---> Consecutive Frame for Second datas in '62 E0 01' response
0.040sec 7E8 23 00 00 00 00 00 00 00 ---> Consecutive Frame for Third datas in '62 E0 01' response
0.050sec 7E8 24 ~~~~~~ ---> Consecutive Frame for Fourth datas in '62 E0 01' response
0.080sec 7E8 10 1A 62 E0 04 FF FF 07 ---> First Frame for Multi Frame. 26 Bytes(1A) datas contained in '62 E0 04' response
0.090sec 7E8 21 00 00 00 00 00 00 00 ---> Consecutive Frame for First datas in '62 E0 04' response
0.210sec 7E8 10 2D 62 E0 01 9F F7 FE
0.220sec 7E8 21 00 00 AE 00 00 00 00
What I want is the third byte HEX data of the first data line '21' of the multi-frame among the '62 E0 01' response data of the 0x7E8 PID message received at 5Hz intervals.
AA → AE → ...
However, response over the RaceChrono CAN bus connection is received in order by each single frame of the 0x7E8 PID at a 100 Hz cycle, which is not what I want.
E0 → AA → 00 → 00 → ...
Is there a way to parse data only in the desired response of a multi-frame protocol as I wish?
I've tried this through several PID changes but no data collection has been made.
I need help!
So, as far as I understand this, this is not possible with RaceChrono.
Is there any future plan to add a way to read multi-frame messages in CAN-Bus Reader mode when using OBDLink MX+?
If you allow us to use the 'STCSEGR' ST command for OBDLink, I think multi-frame reading will be possible even in CAN-Bus Reader mode. Like the 'Initialization commands' feature in OBD-II Settings already in RaceChrono.
Currently, there is nothing in RaceChrono's CAN-Bus Settings, so I sincerely hope you can supplement it so that I can use AT Command (ie. ATCAF, etc.) or ST Command (ie. STCSEGR, etc).
According to the 'OBDLink Family Reference and Programming Manual', or 'FRPM', the 'STCSEGR' syntax plays the following roles.
STCSEGR 0|1 : Turn CAN Rx segmentation off*/on
Disable or enable CAN segmentation for received multi-frame messages. Automatically removes multiframe PCI bytes and assembles the data into a single message.
Default is 0 (CAN segmentation disabled).
If RaceChrono can merge Multi-Frame from CAN-Bus, it will be able to record the desired signals with Race by HEADER '0x7E8' and PID '0x62 E0 01' like OBD-II!
I sincerely ask you to forward this proposal to your developers.
If multi-frame parsing is added to RaceChrono's CAN-Bus Reader feature, RaceChrono will achieve an unparalleled achievement for other mobile racing recording tools.
Additionally, as you may have it, I will reply to your email with the FRPM and ELM327 datasheet pdf that was released to the public from OBDLink's www.obdsol.com .
And I agree- it's a great feature and although setup is pretty extensive, it makes logging so much faster and quite impressive for what it is.
Awesome. I commend you for your efforts.
Your method for DPID is an incredible way to speed up logging!
Sadly, however, there is a difference from the environment I want to implement right now.
I make a $22 UDS on CAN request with another equipment (third-party OBD monitor, not RC+OBDLink) on one CAN bus as a transmitter, and RC and OBDlink just have to do the CAN-Bus's receiver. So I cannot use ST Command for CAN-Bus until now.
The RC's Initial Command function exists for OBD-II transmitter/receiver functions, so I do not want RC to interrupt a series of communications Tx by other third-party OBD gauges and marked on the gauge. I want RC to snatch and log only response messages already floating on CAN Bus by another transmitter.
I think the above function will be possible if the RC allows the Initial Command function to be used even in CAN-Bus reader mode. Multi-frames received through ST Command can be recognized as a flow, and the desired $22 response PIDs can be separately snatched from each controller header response.
I hope this idea will be good for RC and for users.
I'm sorry, I just confirmed on my vehicle that OBD-II setting's initial command works the same way in CAN-Bus reader mode!
'STCSEGR1' Command works well, and it is well recognized as Multi-Frame as PCI bytes rather than Single-Frame in 8 bytes.
But there is still a major stumbling block!
If one controller responds to multiple $22 requests, you cannot distinguish between multiple $62 responses.
For example, in CAN bus, multi-frames with different information are floating, such as 0x62 E0 01, 0x62 E0 02, etc. with a CAN ID (header) of 0x7E8. However, RC's CAN-Bus Reader does not have a function to select a prefix or a separate PID (like that of OBD-II Setting) until now. I strongly suggest these features!
I understand your use case, but it is an exotic one, and I doubt there's enough demand to justify doing these changes to the CAN-Bus side too.
I fully sympathize with your concern.
Because if it's not UDS or J1939 on the CAN-Bus, it's usually going to distribute the IDs and divide the data within the size of 8 bytes.
However, there will be some demand (though not much!) for the role of an observer for use with other OBD equipment as a recording device for racing or driving.
Or, Is there any way to use the initial command function(or etc.) in OBD-II mode to accept messages distinguished by set headers and PIDs already floating on the bus without transmitting, as 'Observer'?
It would be great if the proposed function could be added in the distant future, not even immediately. :)
When I was logging the CAN-bus, The 0x7E8 messages was broadcasted on bus.
First GIF is 'STCSEGR0' command.
Second GIF is 'STCSEGR1' command.
Is the response variable in length (sorry if I wasn't paying attention before), or is it losing packets and failing at reassembly randomly?
When the STCSEGR1 command is in operation, the length of the response varies depending on the actual length information contained by raw data.
No data loss or failing at reassembly randomly.
RC and OBDLink MX+ are successfully assembling and representing in accordance with ISO 15765-2, to match the total length of data represented by PCI Bytes in First-Frame.
For example, '62 E0 21' response, '0x10 45 62 E0 21 FE 9F C6' is the RAW Hex data of First-Frame for this Multi-Frame.
'10 45' is PCI bytes, '62 E0 21' is PID of UDS response and 'FE 9F C6' is DATA bytes.
'10' is byte representing the First-Frame of this Multi-Frame.(This is first byte of PCI bytes)
'45' means the total number of bytes of DATA contained in this Multi-Frame.(This is second byte of PCI bytes)
So 45(hex) = 69(dec) is total data length except for additional PCI bytes such as '10', '45', '21', '22', '23', etc.
'FE', '9F', 'C6' are real data bytes from 0x7E8 ECU(Engine) response.
When the STCSEGR1 commanded, OBDLink hides these PCI bytes and prevents them from being seen on the RC.
If you look at the second GIF in the comment above, you can see that 69 bytes of data are well aligned in the actual '62 E0 21' response.
Similarly, other responses are aligned to the data length that PCI bytes means.
Therefore, we only need to add the ability to distinguish between the PIDs(e.g. '62 E0 21', '62 E0 01', '62 E0 04', etc.) we want!
You're welcome! I'll be waiting for your positive feedback. :D
If there's any additional information I need to give you, please feel free to leave a comment!