When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
I am wondering about the time stamp if on MB original Xentry, because I want to know how the MB error code algorithm works....for knowledge sake.
This may help us troubleshoot in the future when using 3rd party scanner like what I use.
I notice how the car built-in troubleshooting or error code algorithm seems to be quite smart. If only there is a time stamp on it, we can understand the algo better.
1,2 & 3 is 1 problem MB algo found and then stability control deactivated icon showed on the dashboard.
The algo decided that LEFT FRONT wheel rotational speed is correct and decided to declare , all 3 other wheels rotational speed as WRONG.
I do not believe this algo decision is based on yaw sensor, as yaw sensor can detect directional change but a constant state is not Yaw sensor strong point.
I am guessing it is the steering angle sensor which triggers the algo to verify the 4 wheels rotational speed.
As to why LEFT FRONT wheel is not declared as having "unreasonable" wheel speed is because the steering is indeed off axis to the left at near 45 degrees,
So algo believed that the steering angle sensor is accurate ( not defective ), hence it started checking all 3 other wheels speed.
The question now is, item 4 showed steering angle sensor as faulty too....but when was this conclusion reached by the algo ?
If there is a time stamp, we can discover if my assumption is correct... which means that the MB algo is not bad, quite smart and kinda dynamic and knows technical problem hierachy.
Why I say it is not bad is because, at some point in time, when I was on a straight line long enough, the MB algo would have detected that all 4 wheels sensor got the same speed, but why the heck
steering angle sensor is detecting approx 45 degrees to the left So it keeps cross checking like a hard working engineer.
So it then there decided to declare that steering angle sensor is faullty, item #4 C045B00 and this is declared as CURRENT.
The error on all 3 wheels ( U140C&B&A00 ) then declared as HISTORIC.
Wow, self correcting algo.
If only I have a time stamp data, I can estimate when the algo decided to shift fault code to steering angle sensor ( CURRENT ) and removed error codes for 3 wheel sensors ( HISTORIC).
How many meters of straight line driving is needed to change the algo decision ?
Imagine if the mechanic does not know enough of the car available sensors and how mechanically they all interact to produced error code/s, the dude may end up changing so many
parts simply by trusting a 100% what his Xentry declared as faulty. Perhaps this is what's happening when a forum member reported a problem on his car which is not solved even though
the car is handled by MB authorized workshop many times and many parts have been replaced ?
I seen this kind of behaviour shift of technician in 1996 when my friend got the first V6 DDEC detroit diesel in the country. It was 6V92TA DDEC x 2 on a 48 footer sportfish. https://www.sae.org/publications/tec...c=2010-32-0118
This engine series was decent when at under <535HP as a pure non electronic engine, but when the full electronic version introduced and also using electronic triggered injectors and push it to 565HP, it is a JUNK within 500 hours of use.
What I witnessed was, a regular team of techy who have decent mechanical knowledge , suddenly place their faith a 100% on the troubleshooting software of this 2 stroke oil-eater piece of NOW-IS-A-JUNK-AT-565HP.
They treated their laptop with the diagnostic software like God given never-can-be-wrong smart machine
I pity them, because in the end they realized the traditional full mechanical inspection 101 should never to be forgotten.
Few years later when the senior techy manager quit from Detroit Diesel, he told me, YES, you are right, this engine is a JUNK at that power level.
They got tons of problems with this engine at this power level.
.
Not to my experience, but with today's technology what was yesterday - usually doesn't apply today,.
It was quite common in the past that when I was scanning the car for purchase, it would come with 40 or so codes.
Most of them from low voltage when "battery died 3 years ago".
Than there is a limit how far I want to dig in history. I clear the codes, take it for test drive and see if anything comes back.
For a current code, freeze frame data may yield some info about drive cycle parameters when the CEL was commanded on by the ECU. I don't remember specifically about date/time though.
This caster/camber thingy is the 2nd time I have to use icarsoft MB v2.0 to clear error code.
First time was when I done on-car wheel balancing and needed to apply the brake to speed up wheel stopping. I forgot that day if I had the car key on ACC2 (ready to crank ) or ACC1 when I was applying the brake,
surely I need to have the gear in neutral and did have to be at ACC2 when placing gear in neutral. Engine was always OFF.
Car will reset itself though after a short drive, even without the scanner.
Since the on-car balancing is done one wheel at a time, the computer starts throwing code ( upon engine start ) because it was detecting 1 wheel spinning while all other 3 not spinning.
I even lost electric power steering assist , I wonder why.
I did not bother to go to the Electric Steering section on the scanner.
Why would the computer throw all these codes without engine running ? Let's assume key was on ACC2 when I pressed the brake. I mean why not engine-must-run as part of the algo equation ?
Dang, I wished I tried to look into the Electric Power Steering menu and see if the algo declared it as mailfunction too during above event.
According to the balancer techy, if I do not press the brake, the car wont throw the codes. They do lots of MB on-car wheel balance.
In fact prior to this on-car wheel balance of that day for the new tires, I did also got on-car wheel balance 2 weeks prior on the old tires ( after track use ) and no brake pressing = no codes.
All 4 wheels lifted off the ground when on-car wheel balancing was done.
BTW, in MB 7 speed-plus gearbox document called : 7G-TRONIC/7G-TRONIC PLUS (722.9) in the Workshop | Tips und Tricks
does not allow the 4 matic to use on-car wheel balancing ( aside from special towing requirement, both axles off the ground) https://f01.justanswer.com/73bbchevy...and_tricks.pdf
Page 64, bottom right : Balancing the vehicle wheels directly on the vehicle is also impermissible.
I also asked Quaife Engineering, whose ATB LSD I am using, they don't really recommend on-car wheel balancing, unless both wheels spinning at the same time.
Well, worst case I can always engaged gear to spin the wheel instead of the on-car wheel balancer doing it for my wheel ( need to bet at Dyno Mode ).
That was what they did in the days when the balancer roller was low power and can't spin fast enough a big wheel.
Just something that came to mind reading your description of the fickle nature of the codes....
Consider checking wire and CANBUS harness and connectors in the circuits that apply to wheel and steering sensors. Tedious I know. But a chafed wire or loose connector pin can yield the on and off trouble codes if part of the system loses power, communication, reference voltage etc.
Entirely different car but I worked on a civic a couple of years ago. Engine rebuild, all was good except for intermittent idle and misfire code that would come and go. Drove me to madness until I found a loose pin connector at the ECU.
09-12-2020, 10:02 AM
So it keeps cross checking like a hard working engineer.
