OBDX Development - Developer Tools and Suggestions

[Tazzi]

300 unsoldered OBDX GTs sitting on the floor... 300 unsoldered OBDX GTs... you take one down.. solder around... 299 unsoldered OBDX GTs sitting on the floor.

over 1500leds later, 600 screws, 300+ relays/gmlan chips/stickers and cases later... we have our next batch of GTs on the way to Pete. I have kept 10pcs here within Australia, the rest are off to the states.

For anyone that does quite a bit of soldering, to put into perspective just how much I have done.. I have used an entire 1kg roll of 0.71mm solder to do all of those pieces

We still have several hundreds of units to solder as they come in until our main manufacture can take over and do the complete thing. We do have our cases being currently designed/created at our main manufacture now to help consolidate everything into one place instead of multiple.
Little steps but its getting there!

[Tazzi]

Woohoo! Progress!
J2534 GT drivers are now completed and installing correctly, these will be uploaded to the website shortly.

I also have the programmers reference manual being finalized before being uploaded also. There is ALOT of new content in there compared to the OBDX VT, so any devs watching this, please so take your time going through it all. I would also recommend to stick to only ELM or only DVI, trying to become familiar with all commands on both protocols will confuse you.

I also need to update some coding in pcmhammers obdx library since the change to async tasks results in the "thread.sleep" functions to not be respected every time, and need to be moved to task.delay instead. This is important during the initialize routine where sleep is used while waiting for the tool to reset/reboot.

[Tazzi]

Drivers on the website are fixed, I had a naming error for the J2534 API for the GT installer!

Reference manual will be up hopefully tonight for those eager beavers. I have had a few questions regarding ALDL which I will post here also:
1) The OBDX GT ALDL protocol does not have a 'passthrough' mode that makes it work like currently known ALDL cables. The tool processes every received frame and will validate the integrity, check filters ect. This means any current ALDL based programs will need the OBDX ELM or DVI command set implemented.
2) The GT's pinout for ALDL is on pin 9 (Bottom left of OBD2 connector). Vehicles with secondary ALDL pins (like VR/VS) would have to make an adaptor to use on other modules like ABS/SRS.
3) The GT is only suitable for 5v ALDL, it is not suitable to use with 12v ALDL systems. Typically the 12v systems run at 160baud which is also not supported.
4) The GT does not come with the OBD1 12pin OBD connector. If wanting to connect to such vehicle, you will need to make a OBD1 to OBD2 harness. DO NOT use the elcheapo ones found online without modifications as they are pinned out incorrectly and will not work.


For making a harness, only need a couple things:
1) One of the cheap OBD1 to OBD2 harnesses, can get it from Ebay/Amazon or aliexpress (https://www.aliexpress.com/item/1005004433861079.html)
2) Either repin the OBD2 side of the connector IF it has wires (likely dont).. otherwise recommended is to buy a female OBD2 connector (https://www.aliexpress.com/item/32678512660.html)

The OBDX uses the following pins on the OBD2 connector: 4/5 for ground, 16 for power and 9 for ALDL.
This then lines up with the 12pin OBD connector with pin A for ground, pin M/L/E for ALDL (My Tech2 adaptor has these all linked together). For power, this could be run to a 12v source such as a 12v socket. I have read some people using 12v that comes out one of the OBD1 pins (B) but its likely not designed to supply much current, alternatively you can just power the OBDX tool via USB. (Please note I have not tested this harness, just posting the information here for a future news post).

ALDL obd1 obd2.PNG (80.05 KiB) Viewed 3076 times

And just for future reference, the OBD1 DLC connector is 12020043, mouser link to the OBD1 ALDL DLC is: https://www.mouser.com/ProductDetail/Ap ... iSYw%3D%3D


Next, for those asking about Fords, it will work on a Ford but only using the normal HS CAN connection (pin 6 and 14). It will not work on MS CAN as the internal pins do not connect to pins 3/11 for MSCAN. You can however make an adaptor to connect up to those pins using something like this: https://www.aliexpress.com/item/1005001287088693.html

[Tazzi]

Some more ALDL answers for the OBDX GT:

Q) Do I just send mode 1 request on the ALDL protocol and it will respond like OBD2?
A) Yes and No. The GT will automatically try to identify a small zone of silence before transmitting a frame. This does not mean its an ideal time to transmit, the cable is just doing its best to automatically identify an area if it has not been told to look for a heartbeat. It will then search for a response frame with the desired frame ID.

Q) Does OBDX GT support ALDL with the ELM? So I can use a serial terminal?
A) The ELM protocol does support ALDL. It will automatically handle the length frame and checksum when using the default commands. Its recommended to turn on headers to see the whole response.

Q) Can I use the OBDX GT with Tech2win?
A) The GT does not yet have the DPDU API support to use with Tech2win. This is on my todo list once I recover from the trauma that API caused me on the VT last time.

[Tazzi]

OBDX reference manual is back up. I somehow managed to completely remove the CAN section of the document so now its back in it (After a full rewrite of it!).

I have also added some basic examples for DVI in the example section, this shows how to open the desired protocol, set a filter and send a message which are the core features anyone really needs to start.

Currently working on a couple examples in visual studio to demonstrate communicating with the ELM and also DVI protocols, these will hopefully be templates for people to work with for future applications.

[The1]

i havn't had time to read your thread yet mate but it looks awesome so far.

[Tazzi]

i havn't had time to read your thread yet mate but it looks awesome so far.

Slowly but surely! Majority is just my ramblings and thoughts so I have something to look back at when developing

Its good to see multiple early bird GT owners successfully using the J2534 API with GMs SPS, great to see!

[Tazzi]

After having to write down every single command in the canbus section, I have noticed a couple commands missing which need to be implemented.
The current round of v1.0.0.0 OBDX GT scantools will have an update available in the coming weeks to implement:

1) Command to control whether ISO15765 7F 78 responses are automatically handled by the scantool or not. By default this is enabled when auto processing is enabled. The only downfall with this is when modules have HUGE processing times, this can sometimes take upwards of 30-40seconds before the module would return with its response. Turning this off means auto processing is still available, but all 7F 78 responses are reported to the programmer to deal with manually.

2) Enable RTR capability into read/write frames. This will add an additional byte into the read/write frames to allow identifying and writing RTR for CANbus

3) Enable extended byte into read/write frames. This will allow specifically identifying and writing CAN frames for if they are 11bit or 29bit (Currently automatically calculated).

I do have to be extremely vary of the flash limits. I did compress it down a little previously, so these edits must be as small as possible.

Majority of the above should not affect the average person though, its just being picky to ensuring all possible capabilities are available.

[Tazzi]

The J2534 API seems to be working nicely for a bunch of people, we have not had anyone indicate any issues so far. This is not to say there hasn't, but no-one has been unable to use Techline for GMs or using any J2534 applications.

Next things being worked on are:
1) Continue development for the custom programming/flash app for Envyous
2) Implementation of J2534 5.0 (Only a few commands to add)
3) DPDU API (Tech2win) for the GT so it works with ALDL and CANBus.

Im genuinely dreading working on the DPDU api from how many sleepless nights that protocol caused. Technically it should be fine now since the issue was timing between messages sent/received and the callbacks between. This has now been resolved so it should be fairly straight forward (fingers crossed).

So might just work on that to get it out of the way, then move to the J2534 5.0, and finally the envyous app.

[DavidBraley]

Just wanted to thank you Tazzi and Pete for all your hard work.

I just purchased your latest new OBDX Pro GT device this morning and I'm looking forward to trying it out. When the GT arrives, I will download the OBDXplorer software and do some testing.

I also own two of your VT devices. Hope these purchases help!

David