OBDX Development - Developer Tools and Suggestions

[Tazzi]

Always exciting when working with a new generation of tools, since I can add in even more custom capabilities.

Something that I have wanted to add but was unsure if it was worth while doing, was the ability to have two (or more) CAN protocols running at the same time on the tool.

An example would be having HSCAN and GMLAN running at the same time, or HSCAN and MSCAN. Alternatively, it could be used as a "man in the middle" device if both HSCAN/MSCAN CAN lines where hooked up in-between a vehicle and module, which would be very handy for R&D.

So far I have not found any dealership softwares that request and use two at the same time, but I would imagine it would be helpful for anyone doing CAN network analysis/R&D.

With that said, the OBDX command set will need updating to be able to support this ability, including an option to select which CAN line to write from, and also identifying which CAN line it is reading from, along with being able to set all filters/settings separately between the two/three CAN channels.

This leads me into one of my two wish list items to implement:
1) Allow passthrough mode where CAN1 and CAN2 pass messages through each other.
2) Allow live CAN frame manipulation. Basically, allow searching for a specific CAN ID, and manipulate a CAN byte or entire frame which is all done inside the tool for speed.

I use the above quite extensively on a little custom triple CAN board I have, but this would be something that allows commands to control and manipulate instead of uploading a whole new firmware everytime.

[antus]

That is quite interesting.

My suggestion would be to make it a different device. Something that can sit under a dash or inside an engine bay and perform a task. If you were to put dual protocols in the interface the added complexity in the firmware might be a pain. Though I am sure you could handle it. But you might be better off implementing it on the J2534 side as the protocol allows this and factory interfaces like MDI support it. I have used dual protocol while debugging things with universal patcher's logger which supports it.

[Tazzi]

Ah yes, it could be implemented with J2534 to allow dual protocols at the same time.
This would basically just be implementing the multiple CAN functionality built into the firmware at that point.. so.. might as well add it if its capable of doing so.

[Tazzi]

There has been a couple interesting finds recently.

First one is being able to send data faster then a module can keep up with.
This seems to have only impacted much older engine computers such as early Ford BA ECMs where if a data chunk is sent too fast, then the ECM actually misses the response and sends back an error saying "Oh damn I missed something". I believe this occurs due to the RTOS in some of these ECUs not being able to keep up with the CAN data being received, which results in a CAN buffer overflow internally.

This is a fairly easy fix, where the tool can search for an error response, then apply a small delay automatically for the next attempt performed by the software. Or alternatively, apply a few microsecond delay between frames being sent by default so that the ECM can keep up straight away.

The next one is when using the latest version of Forscan, when trying to read the "Module Configuration (AS BUILT format)", some ECUs were not able to complete the data read.
After some investigation, I found my MDI2 and Peak devices could not read the data either, but it did work with an MDI1 and VCM2.
So.. what gives? Well, when forscan requests to read a J2534 message, it uses a 100ms timeout and repeats this another 5 times before giving up (total of 6 attempts).
This makes a total of 600millis of wait time before it errors, yet the ECU response takes a total of 1.2seconds to complete!

So, why does the MDI1 and VCM2 work, yet the other don't? Great question! The devil is in the details on this one.
The MDI1 and VCM2 J2534 dlls do something a little different, as soon as they see the flow control request from the ECM, it results in the "PassThruReadMsgs" being held hostage since the message begun being received while still in the function. Even though the timeout is 100ms, the routine will hang for 1.3seconds as it waits for the rest of the message to come in!
Whereas, when using an MDI2, PeakCAN or OBDX, these all hit the timeout since they don't hold the PassThruReadMsgs function hostage while waiting for a message to process completely.

Anyways, the above is a simple fix on my end which will be applied to the next firmware/software updates.

[AngelMarc]

I guess this could also move onto monitoring external sensor readings as well, just have a simple 0-5v analog reading using some screw headers on the side also.

A logger that prioritizes external sensors. And piggyback existing sensors, especially something simple as temp sensors. More universal with less work. Yeah, user has to splice some wires, big deal.

[Tazzi]

A logger that prioritizes external sensors. And piggyback existing sensors, especially something simple as temp sensors. More universal with less work. Yeah, user has to splice some wires, big deal.

I think an external tool which allows adjusting the priority of live data being returned would be the way to go there.

[AngelMarc]

How cheap and universal can you do it? I know you know OEM software routines more than I do.

[Tazzi]

Depends what you call universal?
Since everything I create follows a specific command set which is publicly posted, although this still requires someone to be making software to integrate with.

[AngelMarc]

Depends what you call universal?
...requires someone to be making software to integrate with.

Respect the work, but I'm sure some would appreciate not needing software configering of any kind, even if it means fabricating. But I'm probably way out of touch.