OBDX Development - Developer Tools and Suggestions

[Tazzi]

Hi Gampy - Have you had any break throughs on this. I also still can't get commands to work? Monitoring/reading traffic works fine.

We would need to see some logs using Chrysler dealership software or other third party software to start identifying and understanding the diagnostic routines needed for live data ect.

[kur4o]

I think there is some problem with byte padding. The dodge stuff might not like it or need specific format.

Meanwhile here is a full emulated flash of random ngc4 file.

[Tazzi]

I think there is some problem with byte padding. The dodge stuff might not like it or need specific format.

Meanwhile here is a full emulated flash of random ngc4 file.

Code: Select all

TxFlags:                                  ISO15765_FRAME_PAD

This is indicating it wants padding enabled. Default padding for J2534. ISO15765 should be 00, I think the MDI might do AA or 55 from memory? Its been a while since I checked that one, but most tools will pad with 00 unless otherwise told so.

[Gampy]

Hmm, it looks like padding does seem to be an issue ... Now I'm getting some results!

ISO15765_1a_22_read_ngc4-New1-Log.rtf

However, I still get no heavy traffic ...

-Enjoy

[In-Tech]

Hiya,
What vehicles do these ngc3's and 4's come in?(or a couple vins) I'll order one of each and make a bench harness(s) and play along too

[Gampy]

In-Tech,

If you look a few pages back there is a list ... Here

-Enjoy

[acln99]

NGC3 dodge Rams 2004 2005, Caravan - ~2004 - 2006

NGC4 dodge Charger, 300C Magnum - 2005 - 2010 Rams 2007 - ~2010

[kur4o]

Gampy, thanks for the log, it unleashed the simulated flash of 2010 ngc4+trans.

Here is the full log. Feel free to duplicate as you like.

The tcm ids are 07e1<->07e9.

Great logging worked, I will do more test files using raw CAN and will try to fix byte padding commands in script.

I am still fighting with ngc3 trans flash.
I got the point where tcm is polled for something and can`t find the needed response.
If anyone can log it will be great.
here is the message that needs to be logged

34 11 00 00 45 [45=some sum checksum]

[acln99]

Hmm, it looks like padding does seem to be an issue ... Now I'm getting some results!

ISO15765_1a_22_read_ngc4-New1-Log.rtf

However, I still get no heavy traffic ...
-Enjoy

This NGC4 log looks like you are only getting responses to messages you have sent. There should be a continuous string of "broadcast" messages like

(10:42:54.090) 308 00 00 00 02 00 FF FF FF
(10:42:54.090) 210 00 20 00 00 02 00 89 00
(10:42:54.090) 312 26 75 1F FF 06 F4 5C 4B
(10:42:54.090) 212 03 20 85 FF 5C 4B 06 75
(10:42:57.646) 101 00 00 DC DD
(10:42:57.646) 308 00 00 00 02 00 FF FF FF
(10:42:57.646) 239 00 00
(10:42:57.646) 312 26 75 1F FF 06 F4 5C 4B
(10:42:57.646) 3D0 00 00 00 04
(10:42:57.646) 308 00 00 00 42 01 FF FF FF
(10:42:57.646) 210 00 20 00 80 82 00 89 00
(10:42:57.646) 312 46 75 1F FF 06 F4 5C 4B
(10:42:57.646) 212 03 20 85 FF 9C 4B 06 75
(10:42:57.646) 415 91 AC 00 00 00 00 6E
(10:42:57.646) 308 00 00 00 42 01 FF FF FF
(10:42:57.646) 239 00 00
(10:42:57.646) 312 46 75 1F FF 06 F4 5C 4B
(10:42:57.646) 4A0 FF 00 00 00 89 FF 00 AE




My issue is still with ESP32 sending same msg repeatedly as I do not think it is receiving an ACK. So transceiver is simply re-sending continually. Can't find how to turn on ONESHOT mode. Anyone know how ??

[acln99]

I think there is some problem with byte padding. The dodge stuff might not like it or need specific format.

Meanwhile here is a full emulated flash of random ngc4 file.

From what I can tell - looks good - uploads "flash routine" first , then uploads the actual Flash .

What do you need to know ?