OBDX Development - Developer Tools and Suggestions

[Gampy]

Others may want to look so it might be a good idea to post them together.

However I do recommend doing back to back reads without powering down and making that a point.
Like I've stated, if you must power down in between (use of different VCI for example), please disconnect the battery without turning off the ignition.

-Enjoy

[DethRattles]

droidgrandamse.bin

(512 KiB) Downloaded 41 times

grandamseoriginal.bin

(512 KiB) Downloaded 44 times

Ok but it was a bench reading on both weeks apart. If you want me to do them both again with pcmhammer and lsdroid i can. Maybe things are different now with droid. I remember lsdroid couldn't read it and i had to run to support on facebook. They needed the serial number and vin which i took from pcmhammer. They gave out an update,,weird thing is that i got a Code P0480 Pontiac Description fan circuit one... or something like that,,,the code is related to fans but i don't have codes for a 2004 Pontiac Grand Am GT on tech2. With obdx i get a C0480 power steering motor??? I told support but they said their manuals are correct

[Gampy]

You need to hire another coding expert but now i see why you have your hands full. Right now i'm waiting on support as to why my bins are different from pcm hammer to droid. At first my 2004 grand am se pcm couldnt be read by droid. Support on facebook asked for the vin etc and they gave obdx an update. I was happy to that lsdroid was able to read the bin file but they said the bins don't match?!? and thats all they wrote.

EDIT Ahhh, now i understand why they say the bins are different,,, i get 588 tables from pcmhammer but only 4 tables from droid when i pop it into pcm hammer. I never looked at the droid one, just figured since it read it gave me the tables. so what the hell?

They appear to be the same to me except for what I believe is the parameter sections!

Thus, I have no clue what you are talking about ... Please explain ??

-Enjoy

[Tazzi]

I told support but they said their manuals are correct

Considering I am support... and I created the program...

Unless you can hook up tech2win or something else to read the fault and show otherwise. The fault code comes up as correct to me when simulating to tech2.

[kur4o]

droidgrandamse.bin

grandamseoriginal.bin

Ok but it was a bench reading on both weeks apart. If you want me to do them both again with pcmhammer and lsdroid i can. Maybe things are different now with droid. I remember lsdroid couldn't read it and i had to run to support on facebook. They needed the serial number and vin which i took from pcmhammer. They gave out an update,,weird thing is that i got a Code P0480 Pontiac Description fan circuit one... or something like that,,,the code is related to fans but i don't have codes for a 2004 Pontiac Grand Am GT on tech2. With obdx i get a C0480 power steering motor??? I told support but they said their manuals are correct

No difference is found in the 2 bins, other than an area that is used as long term RAM area, and cpu stores some data there, like permanent codes or fuel trims. It is still good there is no live ram being included in the bin like older obd1 stuff, Than you will get different read on each attempt, and like render the program useless.

Please DethRattles, pay some respect to the hobbyists, developing FREE stuff in their free time, and don`t demand auto tuning and fixing software, before you do your homework.

[Tazzi]

I have had a J2534 dev for Ford modules get back to me with some interesting results!

So we have two things to fix up in the J2534 API:

1) The OBDX Pro FT was faster then a Ford TCM could handle. Basically it sent the data so fast, that the TCM actually responded with the following flow control message:
7E9 32 00 00
Now a break down of a flow control message is basically 0x30 = flow control, and then the low 4 bits (0-F) provide a status for the flow control message
The break down of this flow status is:
0 = continue
1 = wait
2 = overflow

Overflow means cancel the transmit, since the ECU has either missed information, or does not yet have room to process new information.
This is the first time I have EVER seen a 0x32 byte in a flow control, I have only ever seen 0x30. The tool is currently designed to only proceed when it receives a 0x30 byte, so it returns failed if it doesn't which is also what it should do in this instance.
Even though the TCM is reporting to send the data as fast as possible, its actually not keeping up to how fast the OBDX Pro can send CAN frames.

In a recent update, the time between frames (STmin) was reduced from about 500micros to 10microseconds. Its quite a large jump in speed, about 50x, which makes a significant impact on the transfer times. Modules are suppose to report if they need a slower chunk of data sent, but it does appear some modules assume a scantool cannot sent that fast.


2) The J2535 software is setting a timeout value that is smaller then it takes to send the CAN data and receive a response back. Basically the J2534 software has set a timeout of around 15ms, and the response back is 16-18ms, which is resulting in a failure. Previously this was hardcoded to actually always use a much higher timeout (multiple seconds) which was done for this exact reason, so I believe I may adjust this and basically anything less then 1second will be forced to 1second to ensure this scenario doesnt occur.
I can confirm other scantools do not comply to this exactly since when timing the J2534 write command shows its longer then when allocated very very small timeframes, so they also hardcode a "minimum" into them too.

The above will also apply to the OBDX Pro GT, so I will have to apply the same changes there incase devs have made tolerances way too small!

[DethRattles]

I told support but they said their manuals are correct

Considering I am support... and I created the program...

Unless you can hook up tech2win or something else to read the fault and show otherwise. The fault code comes up as correct to me when simulating to tech2.

I cannot simulate the fault now that i cleared the codes. I was jumpering the radiator fan relays and obdx caught the code. And kuro, I promise i'm not trying to shit on anything anyone has done, these are just my observations. Please don't take it that way. I'm an uninformed hobbyist compared to a developer. I've been told the two bins by two different products are not the same by droids tech support. And was given a fault code that doesn't exist for my car is all. Why i'm being told to stfu about the two when i'm just observing differences isn't right in my book. Support responds to me in the same way. If i'm incorrect then show me why two things are different rather than blast me and say im shitting on the product from a developers point of view rather than a hobbyist. I know the engine codes for instance for my vehicle and now being told i don't is frustrating. This is nothing to bash the company or developers, its just the issues i'm running into. Why am i being told by droids facebook support that the two bins are different. No explanation from them as to why. Why am i seeing only maf and de in the parameters or table listing with droid bin and 2 sets of stock codes when opened in UP and something completely different than what my pcmhammer read? I thought that i could somewhat tune the 558 things in the bins read with pcm hammer , all i get is the maf and ve table when i use the droid read. So i'd say their much different. They might look the same in ghidra but not in universal patcher that a novice like me uses to tune. Im not shitting on this ,,,i'm just trying to let you know from my point of you. I was strongly advised against trying to flash this pcm because my grand am se osid was never found on any record according to droids tech support.

[DethRattles]

droidgrandamse.bin

grandamseoriginal.bin

Ok but it was a bench reading on both weeks apart. If you want me to do them both again with pcmhammer and lsdroid i can. Maybe things are different now with droid. I remember lsdroid couldn't read it and i had to run to support on facebook. They needed the serial number and vin which i took from pcmhammer. They gave out an update,,weird thing is that i got a Code P0480 Pontiac Description fan circuit one... or something like that,,,the code is related to fans but i don't have codes for a 2004 Pontiac Grand Am GT on tech2. With obdx i get a C0480 power steering motor??? I told support but they said their manuals are correct

No difference is found in the 2 bins, other than an area that is used as long term RAM area, and cpu stores some data there, like permanent codes or fuel trims. It is still good there is no live ram being included in the bin like older obd1 stuff, Than you will get different read on each attempt, and like render the program useless.

Please DethRattles, pay some respect to the hobbyists, developing FREE stuff in their free time, and don`t demand auto tuning and fixing software, before you do your homework.

I apologize kur4o , i thought i'd had the newest UP with my vin added but clearly i did not. That's where the confusion lies. I finally able to see the extra parameters/tables now. I in no means want to tarnish myself or anyone else on here. I made the mistake.

[Tazzi]

I am so close to getting this damn iOS WIFI library sorted! Its now just a version controlling issue.

When compiling using MAC Visual Studio to create the actual DLL, the Microsoft.iOS SDK DLL used is v16.2.46, whereas the Windows Visual Studio using v16.2.34.
For the life of me, I cannot figure out how to manually edit or update this dll in the MAC, so I am relying on hearing back on the issue to (finally) get this resolved!!!!!!

[Tazzi]

Have managed to replicate an error which I had not come across previously for J2534!

Basically when using the PassThruWrite command on two separate threads at the same time. This can result in 'second' write to time out depending how long its taking to process the first write request.
Technically the J2534 standard indicates only 1 J2534 command should be processed at a time, whereby its meaning is an application should only request one J2534 command and receive the response before processing the next request.

Buuuuuuutttt, it appears some tools are more flexible on this. Where I assume they are using a queue based system inside the J2534 DLL to basically waiting for the first command to complete before even starting the second one. The reason I say this is some J2534 scantools will throw an error when trying to use the command as the same time on different threads, and others do not as they try to actually do both requests in order of which was received first.

I have also had another developer contact regarding ISO14229 based Ford PCMs indicating that the initial connection with Forscan seems to hang. Logs indicate its only taking about 20seconds for it to do its full sweep of the engine computer, but then after that, it hangs for another 3minutes before proceeding (Odd!). Ill need to get the J2534 logging re-implemented as a configurable option to narrow the issue down. The logging was removed initially as it had huge impact on large read/write routines (Such as tuning software), but can now be reintroduced since all writing routines have been optimized.

Couple things to fix, but its great to see developers and end users providing really helpful input!!!!