The Research and Development Thread!!

[TazzI]

Thanks for the honest opinion Andrew!

I like the *cough*.

That was the original plan, but 3D printing is extremely slow. And 'sometimes' doesnt pan out, due to warped sections, so it has to be redone. I double checked the 3d printing costs, and shipping is also another killer. For what would be essentially 15g of plastic, it would be upwards of 70 per case, this seems to only go down once 100's of cases are bought... which by then the plastic molding could be done!

I don't want to keep holding off, but releasing a product with a sub-par casing is just asking for bad reviews and irritated customers. Iv shown the new cable to a few customers when out doing jobs, and the common response I get is "Is that the case it will come with?". Most people have never seen a 3d printed object, and dont realise that they don't give a perfect seamless finish.

The above does seem silly all this work for a case. But, I know if I bought something for good money, I would expect better.

 

[TazzI]

The J2534 support does seem like the best option for the next step. For those that are curious, think of J2534 as an actual language such as English. English has a specific set of rules and requirements for everyone to understand it and communicate (Such as using the alphabet). So if you speak the language correctly, then you are understood correctly.

So all tools that support and follow the J2534 protocol, will all speak the same language, so the software only needs to understand one language rather than multiple.


So.. what are the Pros and Cons of this situation??

Starting with the Pros:
1) Supporting this diagnostic protocol means that there are HEAPs of tools all supported at once.

2) By supporting J2534, this means a final software solution can be provided (MUCH) faster. Not have to manufacture the custom hardware (Cable) is a massive help.

3) All new tools from all sorts of different manufactures will be supported as they will all follow the J2534 protocol.

4) Getting the software out means that my next focus can be back on the custom envy cable to add its support.

Now for the Cons:
1) J2534 scantools are a little pricey. Some support more diagnostic languages than others which does affect their cost. I will end up stocking a suitable tool that Im happy with as a kit with the software. Otherwise people can purchase a J2534 compliant tool from other places to use with the software. And to check that their tool does work (Plus the supported vehicles), I will have a quick demo/test version that will check over the tool.

2) If bundled with a tool, it will end up more expensive than what I would like. My aim is to provide affordable diagnostics, but the actual J2534 cable is costly part (depending on the cable!)

3) Im technically taking a step backwards in development. As I need to start from scratch to support the J2534 protocol, and begin testing on multiple modules on bench and in car.


Hopefully that gets everyone on the same page! I will be looking into some sort of testing system for people to try out with their tools as I develop. Since Ill need people with older and newer commodores to test their own tool (If you have one).

Im actually really excited for this, been a while since Iv been so eager to wake up and begin programming!

 

[nzv8farmer]

Although a short term step backwards I think that the long term gains could be great if I understand the difference in the diagnostic language as you mentioned, if it’s a language used by many manufacturers, then it maybe opens the door in the long run for easier programming of other makes and a more multi purpose software one day that works ob more makes. I think short term lose long term gain as far as the software side of things go. And as for the Envy cable, I think taking the time to get it right will be worth it long term, you want something that is slick and easy to market as well as easy to use. If it costs a bit more but ends up being a better product it will sell on reputation easily. Don’t know/understand the costs that go into the software side of things, but from the sounds of what’s being planned, I’m happy to pay what it’s worth. Chinese crap is Chinese crap, no point trying to compete with that

I can’t wait to see the developments here, top work so far!!

 

[TazzI]

Iv imprinted 300+pages of technical documents into my head now to understand this new protocol. Its not heaps of pages, but its all interlinked so you have to understand each one for it to all come together.

It does make sense, and will be fine to integrate. Although it is a little vague on communicating to vehicle that uses ALDL.. so thats going to be a bit of a trial/error situation I think.

The next interesting thing, is alot of these tools actually support a wireless connection (Using wifi). So wireless option should still be possible this way.

The next step is to get each diagnostic language functioning in a basic application, so this includes:
- ALDL: Used in all older commodores such as VR,VS,VT,VY
- VPW: Used in all LS1 V8 vehicles for engine/transmission diagnostics
- HSCAN: This is normal CAN, used in VZ,VE,VF for engine/trans and abs modules
- SWCAN: This is single wire CAN, used in VE,VF for body modules
- MSCAN: Used in other manufactures

Connecting and detecting the scantool is all done, its now onto the interesting part of interacting with connected modules!

Ill be looking for testers as soon as I have the above functionality working!

 

[Dirbatua]

Well i got access to VR-VE so both v6 and v8 so if you need any one of those i can do some testing for you.

I've got a J2534 USB cable around here somewhere as well, cant remember what i used it for some toyota or something years ago.

 

[TazzI]

Well i got access to VR-VE so both v6 and v8 so if you need any one of those i can do some testing for you.

I've got a J2534 USB cable around here somewhere as well, cant remember what i used it for some toyota or something years ago.

Perfect, need to start making a list of which cables support what.

Part of the detection process is to work out which protocols the scantool supports. Some support more than others, some only support HSCAN, other support everything physically possible plus more.

This early app testing will indicate which vehicles and modules the tool will support. Hopefully between a few testers and tools, we can come up with a good list.

 

[TazzI]

Always an interesting day when dealing with GM/Holden related R&D.

As always, GMs documentation is (extremely) lacking. The ALDL protocol in the official standardized documents for J2534 literally says the ALDL protocol has no predefined format. My interpretation of this is: "GM has been too lazy to provide us with further info.. so you will need to nut it out yourself".

*Sigh*.. so itll be a bit of a trial and error setup to get it going. Realistically.. all I need it to do is read messages and write messages at a bare minimum. All other 'luxuries' can be ignored till a later date (Such hardware filters) since they can be performed inside the software.

Have read through the documents about a dozen times now, getting to the point I can actually recall page numbers for specific topics

 

[TazzI]

Iv also contacted a coupe dozen J2534 manufacturers. Looks like theres quite a few kits that are(reasonable) prices that support all GM protocols except ALDL, there are a few that claim support but need to ask for further information.

 

[TazzI]

The plot thickens!
Most of the vendors that claim support on ALDL and VPW have absolutely no documentation on how to implement them with their tools.
It seems almost impossible to acknowledge support for something.. without knowing anything about it.. so it does make me wonder if they do infact support the protocols.

A big name vendor which Im keen to support has graciously accepted to help out and track down documentation, this actually means getting their engineers involved to either find documentation, or to begin putting documentation together which explains how to use them. This will save me a huge headache for R&D.

 

[TazzI]

What Iv done so far software wise is:
- Implement entire J2534 protocol to support all GM protocols, plus a few others
- Implement ability to identify any installed J2534 drivers and their connected scantools
- Identify supported vehicles and car modules based off of the scantools supported protocols
- Establish connection to scantool, and test communication to vehicle

The above doesnt sound like too much, but the J2534 has been quite a learning curve, and each of those steps have lots of checks to ensure that everything required for successfully communication is present. Essentially the aim has been to design a bullet proof communication system between software and hardware.

I am able to test and communicate to everything from VZ and newer. Its just the older vehicles with ALDL and VPW that need a bit of a custom touch to get up and running which Im currently working on.

Once those two protocols are sussed out, it will be full throttle for testing in cars and getting some trial versions of this app out there for people to try out.