OBDX Development - Developer Tools and Suggestions

[gmtech825]

The more you post the more it makes sense why our dealer equipment is such a cluster fuck

X1000
I'm kinda shocked, today is friday and neither globalconnect nor tldc has crashed all day.. It's still early and I did have a 30 minute radio usb programming crash right at the end earlier so I got to do that twice..

they'll update TLC over the weekend and it will be down on Monday

[Tazzi]

Never a dull day with TLC...

I am just finding it comical that I am ending up with modules being sent in for programming from dealerships since TLC no longer supports any calibrations for the module.
Or.. better yet.. does not support any brand new modules due to a new part number change.

Its a shitstorm honestly.

[Whiteford]

As I was saying, maybe you should contact Firmec to help you with your hardware issue.

[Whiteford]

I'm sure he will debug your hardware issue's for free.

[Tazzi]

I'm sure he will debug your hardware issue's for free.

Haven't had OBDX customers indicate issues with his software.

If there is, Im sure Matt will be happy enough to provide a log for me to resolve.

[Tazzi]

Man does time fly! Been several months since I updated this thread.

There is still plenty going on in the background with development of the next generation of tools, including moving to a larger processor, newer wireless module and the revision of our OBDX case to use the long awaited USB-C connection!

There has also been several additions to OBDX tool firmware, J2534 APIs and libraries over the last few months which will be publicly available in the next coming days.
Alot of these changes have been to add custom options/commands/capabilities for developers, along with various format fixes and changes for the ELM API and also J2534 API.

Something I have noticed over the past couple years, is the increase in requests for a "J2534 to smartphone" library.
I hear the exact same thing from software companies every week, that making the move from a J2534 tool to a Smartphone has been near impossible without creating custom hardware themselves.
With that said, I am going to redo the MAUI examples that I created a few years ago, update them for the latest .net8/9 core and get some more examples out for using OBDX MAUI J2534 library that I had built.

Once I have those examples done, it might be worth while doing a quick youtube video to explain the main steps and functions, so new devs can get a better understanding of how to use them effectively.

[oldtinfords]

There has also been several additions to OBDX tool firmware, J2534 APIs and libraries over the last few months which will be publicly available in the next coming days.
Alot of these changes have been to add custom options/commands/capabilities for developers, along with various format fixes and changes for the ELM API and also J2534 API.

When you upload the new firmware & API's, could you add a release date against each on the website. It would make it easier when checking if there's been an update.

[Tazzi]

When you upload the new firmware & API's, could you add a release date against each on the website. It would make it easier when checking if there's been an update.

Thats certainly something we can look into doing.

[modzer321]

hey Tazzi, what can cause ERR_BUFFER_EMPTY when trying to read the form the vehicle this is only happening with OBDX Pro GT version not mdi1 or mdi2

[Tazzi]

hey Tazzi, what can cause ERR_BUFFER_EMPTY when trying to read the form the vehicle this is only happening with OBDX Pro GT version not mdi1 or mdi2

ERR_BUFFER_EMPTY means there was no message found or return by the tool.

This all depends on what filters are set since they dictate what is allowed to pass or block, along with any flow control messages (If canbus).