ECU module programming guide using FDRS

[jperry5835]

Looks like things are getting figured out, the question I have is what is the prefered adapter now? It looks like there is 4 different adapters mentioned through this thread. VX3, Mongoose, Nano, and the expensive Ford Adapter.

Sponsored

 

[Bob_Mac]

Looks like things are getting figured out, the question I have is what is the prefered adapter now? It looks like there is 4 different adapters mentioned through this thread. VX3, Mongoose, Nano, and the expensive Ford Adapter.

The preferred one if you can afford it is the Mongoose however, the NANO still works fine but there's caution that needs to be followed regarding the "Network Test" or more commonly referred to as the "Network Scan". The Mongoose does not have the corruption issue when the scan is run and that makes it the better option. The choice is yours....

 

[Snakebitten]

I have a question regarding the "Avoid Network Scan" routine in FDRS.....

I noticed that the FIRST download from the mothership presented the download progress bar and it visible represented a steady progression until complete.

All subsequent requests to download the same data behaved as if it was cached and FDRS didn't actually get a fresh reading. Or put another way, the progress bar would begin to show a little progress (probably the establishing of handshake and request) and then all at once rapidly progress to 100%.

If I choose a new vehicle with a new VIN, the same experience..... First download is all fresh (of course because it would have to be) but all subsequent requests appear to be rapid and I suspect some kind of caching is leveraged.

Is there anything we can do with FDRS to clear it of any history of a specific VIN that would force it to behave like it's never looked that VIN up previously?

I dug around in the local file directories and the VIN has footprints in a lot of places. I was hoping one of you gurus already figured out what is what?

Thanks regardless!

 

[Bob_Mac]

I have a question regarding the "Avoid Network Scan" routine in FDRS.....

I noticed that the FIRST download from the mothership presented the download progress bar and it visible represented a steady progression until complete.

All subsequent requests to download the same data behaved as if it was cached and FDRS didn't actually get a fresh reading. Or put another way, the progress bar would begin to show a little progress (probably the establishing of handshake and request) and then all at once rapidly progress to 100%.

If I choose a new vehicle with a new VIN, the same experience..... First download is all fresh (of course because it would have to be) but all subsequent requests appear to be rapid and I suspect some kind of caching is leveraged.

Is there anything we can do with FDRS to clear it of any history of a specific VIN that would force it to behave like it's never looked that VIN up previously?

I dug around in the local file directories and the VIN has footprints in a lot of places. I was hoping one of you gurus already figured out what is what?

Thanks regardless!

Good question and I haven't tested it yet. Here's one thing you can do if you want to try, when in FDRS there's a checkbox for the profile and when selected a trash can displays allowing you to delete it. See if that removes the traces and report back.

 

[iceman77]

I have a question regarding the "Avoid Network Scan" routine in FDRS.....

I noticed that the FIRST download from the mothership presented the download progress bar and it visible represented a steady progression until complete.

All subsequent requests to download the same data behaved as if it was cached and FDRS didn't actually get a fresh reading. Or put another way, the progress bar would begin to show a little progress (probably the establishing of handshake and request) and then all at once rapidly progress to 100%.

If I choose a new vehicle with a new VIN, the same experience..... First download is all fresh (of course because it would have to be) but all subsequent requests appear to be rapid and I suspect some kind of caching is leveraged.

Is there anything we can do with FDRS to clear it of any history of a specific VIN that would force it to behave like it's never looked that VIN up previously?

I dug around in the local file directories and the VIN has footprints in a lot of places. I was hoping one of you gurus already figured out what is what?

Thanks regardless!

As long as you are "online" and connected to Ford servers, the tool will download the freshest version of your vehicle data. The progress bar duration should not deceive you

 

[JEB]

Looks like things are getting figured out, the question I have is what is the prefered adapter now? It looks like there is 4 different adapters mentioned through this thread. VX3, Mongoose, Nano, and the expensive Ford Adapter.

The VCM3 is the “Ford” adapter. It’s actually manufactured by Bosch, if I recall correctly. It is the gold standard and can perform all dealer-level diagnostics and programming. But it costs $1500 and is in very short supply because of the chip shortage. If you are an enthusiast, or you have money to burn, this is the very best programmer there is. Many dealers don’t even have it.

The second is the Mongoose Plus for Ford. It is manufactured by OPUS IVS. It is unclear what it’s limitations are relative to the VCM3, but so far it’s done everything I’ve needed it to do as far as FDRS programming goes and will actually clear up corruptions in the back up as-built data if there are any. Consider it the lowest tier of dealer-quality equipment. It sells for $695 for the Bluetooth version, $495 for the wired. You can buy it on Amazon but supplies are dwindling. Opus indicated it is no longer shipping the Bluetooth version as of 2/15 because of chip shortages.

The last is the VXDIAG VCX Nano for IDS. It is a solid programmer that works on FDRS and retails on Amazon for about $109. It is rock solid as a programmer and plays well with FORScan. But it does exhibit some issues with FDRS network scanning—when data is backed up from the truck to the Ford servers, it does introduce some corruptions. Locally, the truck is perfect, however, and the corruptions should eventually sort themselves out as the truck self-reports to the Ford servers over time. But best practice is to follow @iceman77 ’s instructions and avoid FDRS network scanning until a solution is available. If you’re on a budget, the Nano is a solid choice if you understand and appreciate its limitations.

EDIT: Please read this thread in its entirety—well beyond this point. With Ford’s release of updates to modules relating to the activation of BlueCruise in mid-March 2022, particularly the cruise control module (CCM), I can no longer recommend use of the VCX Nano. The Nano cannot program the CCM properly and avoiding this module is difficult or impossible becaue the update is chained to the update of other modules.

 

[iceman77]

Excellent writeup @JEB! I will be updating the guide this weekend and will include your post above, as this is yet the best description of tools of choice

 

[Snakebitten]

Good question and I haven't tested it yet. Here's one thing you can do if you want to try, when in FDRS there's a checkbox for the profile and when selected a trash can displays allowing you to delete it. See if that removes the traces and report back.

Thanks Bob,
But I tried that first because it just made sense. But amazingly, when you enter the VIN , it appears that the moment FDRS handshakes with the server, they both agree that there's something on the local harddrive already so no reason to download the whole dataset.

The real reason I want to know how to do this is because my sweet Sync update to the LATEST build rendered a very comforting piece of information when I first saw it:
(Note the NO-Scan greyscale of the View CMDTCs column)

However, as excited as I was to see ALL modules listed without erroneous spaces in the P/N's, my very next No-Scan request for information was one of those FAST "cached" feeling downloads and the APIM data was then different:

WAIT A MINUTE........while preparing this post and doing a new FDRS NO-Scan download to show the abbreviated "ML3T" value for the APIM software P/N, I JUST NOW got an unexpected different result!

I SWEAR that yesterday and last night that other than the first pic above, the APIM P/N was gimped to "ML3T". But just now it has the value you see above as FFF1-14D358-FF

Also note that it is even more surprising that it is a different value now because of exactly what I was mentioning about the "cached" feeling about the download. This download was one of those kind.......The progress bar barely had a tiny blue moment and then without any hesitation it went to 100%. Yet obviously, it rendered new results!

So nevermind on my assumption that the NO-Scan multiple downloads are NOT full comparisons every time.

I'm kinda relieved but now even more confused. LOL
I have no idea what that new value even means for the APIM.
I do know the truck is now the latest version of Sync and I don't see anything that appears to be a problem.

 

[TJSparky]

Snakebitten, my APIM also shows the same version as yours. I think this is correct for the sync 21281 rev 244
FFF1-14D358-FF

 

[Snakebitten]

Snakebitten, my APIM also shows the same version as yours. I think this is correct for the sync 21281 rev 244
FFF1-14D358-FF

Thanks Sparky!

But I'm no longer 21281 ?????
I'm in the latest and greatest cool cats club
(that'd be a $900 FDRS co$ver charge)

 

[Bob_Mac]

Excellent writeup @JEB! I will be updating the guide this weekend and will include your post above, as this is yet the best description of tools of choice

Agreed! Well written...

 

[TJSparky]

Thanks Sparky!

But I'm no longer 21281 ?????
I'm in the latest and greatest cool cats club
(that'd be a $900 FDRS co$ver charge)

We’ll that’s weird… I show the same in FDRS but still 21281 Rev244 on the sync screen???

 

[TJSparky]

We’ll that’s weird… I show the same in FDRS but still 21281 Rev244 on the sync screen???

Disregard…. I guess it changed over the last week since I grabbed the original screenshot


Today

Week ago

 

[JScaro]

First thing I did was NOT run a scan and download my truck records from the sky.
Sure enough, the IPC had a space in the software part number. When I clicked SW Updates, there was only the GSM and ABS, but when I clicked on the IPC module specifically the right hand side of the screen automatically chooses "All"

In the list for All is an IPC Update!

It is not listed under the updates tab.

I chose download and run, just as you normally would. Sure enough there was a USB portion (but only 2 files for the Powerboost VS the 5.0)
Applied them the traditional USB method. Did not get into a restart loop! Said Yes in FDRS and sure enough a canbus second routine ran for a while.

All without ever doing a network scan.
As soon as it updated the database, I shut down FDRS, again no scan, downloaded the truck records and the IPC was uncorrupted and new values.

And get this....... After the IPC update and the fresh session with the sky, I got a new GWM and APIM update in SWupdates. Again, without a Network scan.

Some great tips here and I found these were many that I used.

USB install and the shut down FDRS and than re-connect after 15min seemed to provide the best results.

 

[Snakebitten]

We’ll that’s weird… I show the same in FDRS but still 21281 Rev244 on the sync screen???

Yea, just one more fact that proves I know just enough about what I'm doing to be dangerous. ?

I can prove that I don't REALLY know what is going on or what all the moving pieces are...

Think about this: There's a Ford server in the invisible cloud. There's a Ford truck in my yard.
Now the truck CAN actually communicate DIRECTLY with the server in the cloud. Ford designed it to and actually intends it to.

Because THAT isn't working the way it should, we grab a laptop with a software program and deliberately insert ourselves as a middle man.

So as the middle man, I ask the server "hey, you got a package for the truck?"
It responds to me (middle man) "As a matter of fact I do. Here, can you deliver this FOR me. I admit I'm having difficulty doing it myself"

So I do. Package delivered successfully!

I even notify the server with a legitimate receipt signed by the truck! The server confirms it received the receipt by showing the middle man the P/N

MU5T-14G676-EJ

A few minutes later, the middle man asks for another copy of the P/N and the server says "no problem, here ya go :

Ml-13T

What? That's not what you said 5 minutes ago? Lol

The next day I, the middle man, call the server to ask again," hey, I just wanna make sure you sent me the right copy of the receipt yesterday. Can you send it one more time?"

Server says sure, here ya go:

FFF1-14D358-FF

?????

So seriously, at least as seriously as I can muster, WTH? Whatever is editing data on the server it can't just be what the middle man is providing to the server. Either the server has instructions to do things independently, or the truck IS corresponding with the server and talking behind the middle man's back. Just to mess with him? ?

Sponsored