OBDX Development - Developer Tools and Suggestions

[antus]

can you not do both at once? it sounds like that is the way its designed and architected, though my understanding of it is a lot more shallow than yours.

[Tazzi]

can you not do both at once? it sounds like that is the way its designed and architected, though my understanding of it is a lot more shallow than yours.

The OBDX GT has a single CAN controller on it, meaning only 1 physical CAN is used at one time. We use a relay to switch between HSCAN and GMLAN so you cant have both at once with this design.

But it appears I have overcome the issue. The tool is now switching to the correct CAN channel upon request and then proceeding. Its ALOT of stuff going on in the back ground but I can now successfully connect with everything on my bench without any problems

Im honestly not even excited to have finally beat DPDU.. its genuinely traumatizing how over complicated that protocol is. Its probably one of the most over complicated design I have ever had to deal with to date.

But... its done. Anything left may be little fix ups but I should be able to test in my vehicle later today. Final step is completing the DPDU installer for the GT and then itll be ready for some further public testing.

[antus]

Sounds good. Also sounds like D-PDU was designed by committee who didnt know what they were doing yet, and thats why nothing newer uses it anymore!

[Tazzi]

Sounds good. Also sounds like D-PDU was designed by committee who didnt know what they were doing yet, and thats why nothing newer uses it anymore!

Apparently used by some Chrysler software which I think only drewtech has bothered to support it.. so there are people crying out for its support... but you can already guess why only one company has bothered

[Tazzi]

Tested in car.. and the ECU, Radio and BCM are working as expected... but appears the live data on instrument cluster and HVAC didnt show anything. So Ill need to fire those up on the bench and see what the problem there is. Since they clearly communicated when opening that modules menu and reading fault codes, just not live data.

Anyways, it is working, just a bit more refinements needed.

[Tazzi]

Woohoo! All working now!

It took a little bit of forward thinking but its working in car with every module available. So with that now done, I believe that is the end of the Tech2win D-PDU saga! (Or... until adding Kline one day...).

I have finished the installer as well, so this will be uploaded to the website within the next day or so for testing

With this all done, we are now moving forward to either working on the new prototypes or the NVS flasher app for custom programming. Might have a little tinker with the new prototypes to ensure their core functionalities are there, then move onto the app after that.

I have noticed alot of requests regarding a phone app for diagnostics with OBDX pro tools. This will likely be OBDX's next release once I have a strong mobile app foundation from my own developments to work with.

*Edit
Seems to be working nicely in car. I do have a odd occurrence with tech2win saying no communication from ECU when I first try communicate as theres about a 0.5-1second delay on the first every response from the ECU which must be it just changing its priorities to begin searching more actively from can frames from a scantool. Iv confirmed this with an external tool logging. Tech2win only waits around 200ms before it just simply times out and says no response found. A hack method around this is adding a small delay after each frame write to allow time for the ecu to wakeup/respond. This could be made that it only does this delay for the first couple writes it does on a specific protocol (Maybe?)

I also did two further tests which I know use GMLAN and HSCAN, and they werent a happy camper:
1) Module presence check, this only picked up everything on GMLAN. I will need to go through the log and see what it attempted along with the filters it sets so I can understand why it missed all of HSCAN.
2) SDM primary key learn, this also stopped when switching between protocols to check prescence of modules, so again need to check the log.

Other then that, was working beautifully.

[MudDuck514]

Woohoo! All working now!
[snip]

I have noticed alot of requests regarding a phone app for diagnostics with OBDX pro tools. This will likely be OBDX's next release once I have a strong mobile app foundation from my own developments to work with.

Hi all

I know this is probably wishful thinking, but it would be AWESOME if you and Pete could create an Android App to "replace" Tech2Win!
Imagine, having the functionality of the Tech2 on your phone or Tablet!

Mike.

[Tazzi]

Hi all

I know this is probably wishful thinking, but it would be AWESOME if you and Pete could create an Android App to "replace" Tech2Win!
Imagine, having the functionality of the Tech2 on your phone or Tablet!

Mike.

Making that isnt so hard.

The annoying part is reverse engineering every last frame sent to/from tech2win so it can be put into a separate software. This isn't so 'hard', but it is extremely time consuming to do since you have to make a change, see what parameter updates.. make another change.. check again... ect ect. Rinse and repeat until every parameter/Action/option is reverse engineered.

[Gatecrasher]

Hi all

I know this is probably wishful thinking, but it would be AWESOME if you and Pete could create an Android App to "replace" Tech2Win!
Imagine, having the functionality of the Tech2 on your phone or Tablet!

Mike.

Making that isnt so hard.

The annoying part is reverse engineering every last frame sent to/from tech2win so it can be put into a separate software. This isn't so 'hard', but it is extremely time consuming to do since you have to make a change, see what parameter updates.. make another change.. check again... ect ect. Rinse and repeat until every parameter/Action/option is reverse engineered.

It's even worse because they don't seem to use consistent data sets across similar modules. I was recently playing around with some Global A instrument clusters, and I tried building them out in GDS2 as different vehicles to see if I could get any extra parameters. They all seem to request the same set of PIDs, but they pack them into the 2C/AA packets in different orders. It can be overcome, but it's just more hassle and more opportunities to introduce transcription errors.

There's a guy who figured out how to directly translate the Mercedes OEM diagnostic database into an open format. I've wondered what it would take to do that for Tech2Win and GDS2. There could be some legal pitfalls with that too. I don't know.

[Tazzi]

It's even worse because they don't seem to use consistent data sets across similar modules. I was recently playing around with some Global A instrument clusters, and I tried building them out in GDS2 as different vehicles to see if I could get any extra parameters. They all seem to request the same set of PIDs, but they pack them into the 2C/AA packets in different orders. It can be overcome, but it's just more hassle and more opportunities to introduce transcription errors.

There's a guy who figured out how to directly translate the Mercedes OEM diagnostic database into an open format. I've wondered what it would take to do that for Tech2Win and GDS2. There could be some legal pitfalls with that too. I don't know.

Im sure people have done it with GDS2, but maybe not tech2win since that one is difficult to reverse engineer.

Global A does follow a standardized format, so once a PID for a specific module is figured out, it could be used on another global A of the same module type (ie BCM, ECU, ect). Not all modules will support the same PIDs, but once you have a list of them, you can easily just rotate through them all and find which are supported. Its basically what I do for OBDXplorer to build the supported parameters list.