Page 50 of 95
Re: OBDX Development - Developer Tools and Suggestions
Posted: Thu Feb 23, 2023 1:25 pm
by Tazzi
With the OBDX Pro FT now done (Just waiting on stickers), along with the OBDX Pro VX, I finally have little bit of time to push further with CAN FD.
Our OBDX Pro FT has quite alot of free memory space, so I will be able to easily fit FD CAN protocol on this. I don't believe I will be able to make it fit on the GT, but, we will know more after I add it to the FT to see how much space it will actually take.
Technically, the main difference between CAN 2.0 (normal CAN) and CAN FD is:
1) The data block and arbitration header can be at two different speeds (Stupid, yes... I know).
2) CAN FD supports MUCH faster speeds
3) CAN FD support data blocks larger then 8bytes.
It shouldn't be too bad to implement. Especially after having a CAN FD scantool to monitor API calls with also, this will make it possible to verify responses.
Re: OBDX Development - Developer Tools and Suggestions
Posted: Thu Feb 23, 2023 1:41 pm
by In-Tech
Tazzi wrote:hink if I simulate to IDS a 'valid' response for the mode 31 message, it might just proceed forward and seed a seed/key request. Ill have to update my R&D software to accommodate for PWM. That way I should be able to then intercept calls made by IDS into the DLL.
This would all be so much easier if I could just get IDS to work.

Can you help me with the acronym's, IDS and IFR. I have read of both but don't know what either one means. Sry
The 7f response doesn't seem to mean the same thing in Ford vs GM

Re: OBDX Development - Developer Tools and Suggestions
Posted: Thu Feb 23, 2023 2:04 pm
by Tazzi
In-Tech wrote:Tazzi wrote:hink if I simulate to IDS a 'valid' response for the mode 31 message, it might just proceed forward and seed a seed/key request. Ill have to update my R&D software to accommodate for PWM. That way I should be able to then intercept calls made by IDS into the DLL.
This would all be so much easier if I could just get IDS to work.

Can you help me with the acronym's, IDS and IFR. I have read of both but don't know what either one means. Sry
The 7f response doesn't seem to mean the same thing in Ford vs GM

Im pretty sure 7F is actually a negative response, so the ECU is actually basically saying "Im not happy".
But your software is just progressing regardless
OK so, Fords dealership software is called IDS:
https://www.fordtechservice.dealerconne ... Latest.asp
They also have another newer sofwtare called FJDS and FDRS which both work with generic J2534 tools. Whereas Ford IDS only works with Fords factory VCM2.
Fords IDS V96.01 can work with other J2534 devices by swapping out DLLs for the scantools, after that version they hardcoded it to only work with VCM2 tools. Technically... could make any tool work with it by make a little DLL hack, but that walks in the realm of pissing off Ford.

Re: OBDX Development - Developer Tools and Suggestions
Posted: Thu Feb 23, 2023 10:30 pm
by In-Tech
Thank you for the explanation. So, it sounds like we really need to log an IDS transaction to see if we're missing the holy grail. Shoot, that's $149 for 2 days

hmmmm I have a ford vcm
Re: OBDX Development - Developer Tools and Suggestions
Posted: Fri Feb 24, 2023 2:41 am
by Cincinnatus
It's only $50 for fjds for two days InTech. Tazzi, do you know if a nano supports feps? I've got a suspect pcm on an 07 explorer and need to program a replacement. Vci manager from ford doesn't like 64 bit Java, and I haven't sorted it yet to attempt with my nano, but would like to have a good j2534 to attempt it. I found a few different ford spec jboxes (STIC svci, VNCI, and vcm2 clones)to consider, but haven't ever programmed ford to know what works.
Re: OBDX Development - Developer Tools and Suggestions
Posted: Fri Feb 24, 2023 3:24 am
by In-Tech
Cincinnatus wrote:It's only $50 for fjds for two days InTech. Tazzi, do you know if a nano supports feps? I've got a suspect pcm on an 07 explorer and need to program a replacement. Vci manager from ford doesn't like 64 bit Java, and I haven't sorted it yet to attempt with my nano, but would like to have a good j2534 to attempt it. I found a few different ford spec jboxes (STIC, JVCI, and vcm2 clones)to consider, but haven't ever programmed ford to know what works.
I appreciate the reply. I have a VCM but not a VCMII. I'm new to this Ford stuff too. The website seems to say I would have to use IDS since I have a VCM and not VCMII. Shoot, I am still contemplating my next move. First, I need to make sure PuTTY has a large enough buffer to do a download or upload and not crash
I have an acquaintance that works at the Ford dealership and said I could do whatever I want there, the only suck is that dealership is an hour away.
Re: OBDX Development - Developer Tools and Suggestions
Posted: Fri Feb 24, 2023 4:20 am
by kur4o
In-tech you can try to sniff data with MDI unit, not sure it supports high speed, but at normal should be fine and no buffer issue.
Re: OBDX Development - Developer Tools and Suggestions
Posted: Fri Feb 24, 2023 5:00 am
by In-Tech
kur4o wrote:In-tech you can try to sniff data with MDI unit, not sure it supports high speed, but at normal should be fine and no buffer issue.
Hiya kur4o,
I thought I remember Taz saying that the mdi cannot support the FEPS. I would bet it would support standard scanner stuff but not support any "enhanced" functions. I am not sure how I would log packets with the mdi. The buffer problem I was describing I think was a hyperterminal buffer limit. I don't think it had anything to do with the elm, especially since the packets are so small. I would bet the AVT terminal would work as well, I haven't played with it yet either.
At this point I am going to keep dumping and playing with different settings in the modes. If we can get a handle on the seed/key issue, maybe I can write something simple in VB for testing block and full 256k reads. Then grow from there, ya know, like full file checksum so no bricky, lol. I dunno, just been having a bit of fun with this unknown(to me) Ford crapola
Suggestions, tips, etc always welcomed. It's always cool to work with others that may not have a test bench station but have good ideas
The tazzmanian doesn't need my help, I just like to give more info if I can. A second opinion or approach can never hurt.
Re: OBDX Development - Developer Tools and Suggestions
Posted: Fri Feb 24, 2023 5:35 am
by kur4o
For logging you don`t need FEPS support. I guess you can always apply it externally with your custom PS unit.
To log anything with MDI you can use universal patcher. Get latest version at github.
utilities->logger->j-console tab
select j-device for logging.->J1850PWM->select baudrate->connect
It should log anything on the bus-> you can also send custom commands
Also you can set custom filters and other variables and make simple scripts with predefined messages.
Re: OBDX Development - Developer Tools and Suggestions
Posted: Fri Feb 24, 2023 6:23 am
by In-Tech
Wow, Shoot, I need to keep better track of your stuff. I will check it out tonight. That is way cool stuff. Should I use a standard 115500 baud rate or will I need to play with it? Is there anything else you guys would like me to do/try?
Yes, I shouldn't need any FEPS 18v but I will check.
Thank You