Weird ForScan behavior
Senior User
Joined: Apr 2016
Posts: 306
Likes: 2
From: Maine
I just had another thought. On my 2011 the OBDII adapter would cause some glitchy truck behavior just by itself. I can't remember the details exactly but when that particular adapter was installed I would have weirdish things happen like what you describe. I read once somewhere that even the OBDII readers (if they are monitoring a ton of PIDs) can create enough demand on the bus that it can conflict with truck communication traffic. It isn't a stretch to think that a bad or adapter could cause problems all by itself. I eventually replaced that adapter with another one for a different reason and didn't see those glitches again. One more option in addition to the suggestions just given is to simply yank the adapter right after the next glitch and see if the erratic behavior goes away?
That said, yanking the adapter after the next glitch might not tell you anything... the erratic behavior would continue until some kinda state-clearing happens, which I'm speculating is very quick, but it might require the vehicle be power-cycled, so don't assume that "I yanked the adapter out and the problems didn't go away" means that the OBD adapter is off the hook.
Good thought: that could easily be what's happening.
Thread Starter
|
Hotshot
Joined: Apr 2013
Posts: 10,120
Likes: 652
From: NH
I just had another thought. On my 2011 the OBDII adapter would cause some glitchy truck behavior just by itself. I can't remember the details exactly but when that particular adapter was installed I would have weirdish things happen like what you describe. I read once somewhere that even the OBDII readers (if they are monitoring a ton of PIDs) can create enough demand on the bus that it can conflict with truck communication traffic. It isn't a stretch to think that a bad or adapter could cause problems all by itself. I eventually replaced that adapter with another one for a different reason and didn't see those glitches again. One more option in addition to the suggestions just given is to simply yank the adapter right after the next glitch and see if the erratic behavior goes away?
Thread Starter
|
Hotshot
Joined: Apr 2013
Posts: 10,120
Likes: 652
From: NH
I _believe_ they are stored on the BdyCM module. That's interesting, though, my experience is with GM, Ford, and Toyota, and I don't think any of them have used sub systems like that. I know Ford does for the radio and climate control, but the BdyCM still is the master even for HVAC, afaik. I'm going to see if I can't sniff the various CANs and get a better idea of the layout maybe this weekend.
The registry analogy isn't wrong, but the usage is quite different. (The following is speculation by me) There doesn't appear to be an operating system involved, the BdyCM code is running directly on the hardware, and the registry is stored in ROM-like CMOS, which the whole system trusts inherently because only the IDS tool is supposed to set those values, and can set them knowing the impacts. So, where Windows will be like "Hey I need to know what is in this value, so I can use it to set parameters for this other piece of software" on the BdyCM, there's no "other piece of software" so it says "I am reading these values from these locations so that I know what to do next." It will then do whatever it's told to, based on the values in the current register, and the result of the calculation of the value from the CMOS-like registry and the known locations of next routines to run. ("0x00 is in registry, we are at 0x00FB, we know that we are going to the next instruction, so set next register to 0x00FC" vs "0x01 is in registry, we are at 0x00FB, we need to advance to the next instruction and add the value from registry, so set next register to 0x00FD")
So if it loads a bad value from its "registry" at some point, all instructions after that point will behave erratically (running whatever is in RAM at that address (or L2, or processor cache.... dunno the architecture)). This continues until some condition says "Set next register to <known address>" where <known address> is known and valid.
Essentially, Windows gets a few chances to look at the value and say "That ain't right." The truck has no such luxuries, it accepts whatever values are given to it, and instead handles bad values by resetting state after the fact. Bad values should be rare, IDS should never give them, so they'd only happen as a result of hardware degradation, bad external commands, or noise in the system.
The registry analogy isn't wrong, but the usage is quite different. (The following is speculation by me) There doesn't appear to be an operating system involved, the BdyCM code is running directly on the hardware, and the registry is stored in ROM-like CMOS, which the whole system trusts inherently because only the IDS tool is supposed to set those values, and can set them knowing the impacts. So, where Windows will be like "Hey I need to know what is in this value, so I can use it to set parameters for this other piece of software" on the BdyCM, there's no "other piece of software" so it says "I am reading these values from these locations so that I know what to do next." It will then do whatever it's told to, based on the values in the current register, and the result of the calculation of the value from the CMOS-like registry and the known locations of next routines to run. ("0x00 is in registry, we are at 0x00FB, we know that we are going to the next instruction, so set next register to 0x00FC" vs "0x01 is in registry, we are at 0x00FB, we need to advance to the next instruction and add the value from registry, so set next register to 0x00FD")
So if it loads a bad value from its "registry" at some point, all instructions after that point will behave erratically (running whatever is in RAM at that address (or L2, or processor cache.... dunno the architecture)). This continues until some condition says "Set next register to <known address>" where <known address> is known and valid.
Essentially, Windows gets a few chances to look at the value and say "That ain't right." The truck has no such luxuries, it accepts whatever values are given to it, and instead handles bad values by resetting state after the fact. Bad values should be rare, IDS should never give them, so they'd only happen as a result of hardware degradation, bad external commands, or noise in the system.
Tuned
Joined: Apr 2006
Posts: 451
Likes: 41
From: Carstairs Alberta Canada
I just had another thought. On my 2011 the OBDII adapter would cause some glitchy truck behavior just by itself. I can't remember the details exactly but when that particular adapter was installed I would have weirdish things happen like what you describe. I read once somewhere that even the OBDII readers (if they are monitoring a ton of PIDs) can create enough demand on the bus that it can conflict with truck communication traffic. It isn't a stretch to think that a bad or adapter could cause problems all by itself. I eventually replaced that adapter with another one for a different reason and didn't see those glitches again. One more option in addition to the suggestions just given is to simply yank the adapter right after the next glitch and see if the erratic behavior goes away?
I also had odd problems on my 2012 F350 when the adapter was plugged in and on my 2015 it was so infrequent I almost never unplugged it. With the 2012 I would have to unplug it shut the truck off then restart it and everything would be fine. The 2015 I would also have to unplug and restart. Funny thing is the same adapter has not caused a problem on my Honda. It is an MX.
Thread Starter
|
Hotshot
Joined: Apr 2013
Posts: 10,120
Likes: 652
From: NH
So here's a quick follow up about a week later. No further issues at all. Double Honk remains off, and the sunroof seems to be working properly (have tried a few times); ambient lighting is normal, not being locked out, no key recognizing problems, and no traction control surprises.
Thread Starter
|
Hotshot
Joined: Apr 2013
Posts: 10,120
Likes: 652
From: NH
I left everything alone to just see if the issues would go away. It appears they have gone away completely.
Prolocutor
Joined: Jan 2009
Posts: 13,618
Likes: 1,245
From: Western MA
Huh, must be gremlins. Drop a french fry under the seat from time to time to keep them happy and all should remain well... 
FTE Stories
Ford Trucks for Ford Truck Enthusiasts
Rezvani's Latest Post-Apocalytic Monster Is a Ford F-150 Raptor Underneath
Verdad Gallardo
Top 10 Most Expensive Ford Trucks Ever Sold on Bring a Trailer
Joe Kucinski
2027 Ford Super Duty Buyer's Guide (Every Model, Engine, & Package)
Brett Foote
Top 10 Ford Truck Tragedies
Joe Kucinski
AEV FXL Super Duty - the Super Duty Raptor Ford Doesn't Make
Brett Foote
Lobo Vs Lobo: Proof the F-150 Lobo Should Be Even Lower!
Michael S. Palmer
Ford's 2001 Explorer Sportsman Concept Looks For a New Home
Verdad Gallardo
10 Best Ford Truck Engines We Miss the Most!
Joe Kucinski
2026 Shelby F-150 Off-Road: Better Than a Raptor R?
Brett Foote
Thread Starter
|
Hotshot
Joined: Apr 2013
Posts: 10,120
Likes: 652
From: NH
Haha - I generally don't allow any food or drinks to be consumed in my vehicles, except water. Helps keep the inside a lot cleaner from unintentional spills!
Thread
Thread Starter
Forum
Replies
Last Post
gglover24
1961 - 1966 F-100 & Larger F-Series Trucks
2
Feb 14, 2018 10:20 AM
FAST-FORD
1967 - 1972 F-100 & Larger F-Series Trucks
5
Mar 22, 2008 01:44 PM