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.
Sharing a data glitch condition.
Lost use of turn signal switch during my approx 2,000 KM journey Jakarta to Surabaya back to Jakarta.
Halfway out of Jakarta to Surabaya, at 40,224 to 40,368 KM, N80 Steering Column Module reported 11 events of B178F00 - SWITCH-TURN SIGNAL has a malfunction.
While E1n9 LEFT HEADLAMP reported 4 events between 40,224 to 40,320 KM , a U021200 - Communication with Steering Module ( N80 ) has a malfunction.
Engine kill and re-start at one of the fuel stop solved the issue, no Xentry or scanner in use.
Scanned the next day at 40,755 KM, I got STORED DTC explained above.
.
No issue whatsoever till I got back to Jakarta 4 days later on 4th Aug at 41,899 KM. So 1,500 KM trouble free ride after that actual loss of use of turn signal on 31st July.
I scanned the car again, and I got a stored code at a supposedly 40,960 KM but I did not recall loosing function of the turn signal.
The weird part is, how could a supposedly STORED DTCs from 2 modules, where at the same mileage of 40,960KM the occurrence was, but the elapsed ignition cycles
during the scanning are reported 19 vs 27 ? It does not make sense.
Both modules should be reporting the same elapsed ignition cycles ... duggh.
The road to Surabaya city from Jakarta, the first 400KM is bad, albeit paid highway. So car was jumpy jumpy at road to bridge joints and poor road surfaces.
So was vibrations causing the DTCs ? Mavbe, but those 2 modules should repeat the problem 1,500 KM later....which it never did.
N80 SCM and LeftHeadlight are not on the same CAN BUS.
They both needed N93 gateway as data transit/conversion device.
N80 is using CAN E1.
Headlights, both are using CAN E2.
So CGW being slow or sloppy could also be the factor.
==================
Have I got other STORED DTC glitch which never actually cause any actual loss of use of the module/s ?
Yes, N62 Parking System is one which very often has STORED DTC, but it always work well.
I do not know if MB designers ever realized that in Jakarta traffic, motorbikes are azz-holes no 1.
In a traffic jam, stop and go, or while waiting at rail road crossing or traffic light, motorbikes will be like swarm of flies buzzing around cars and causing parking/proximity sensors to beep like mad.
See below :
.
Classic Barbaric bikers in a big Tee junction grid lock.
Cyan arrow is the supposed traffic flow. Look at the pink rectangular I made, those are hundreds of bikers running opposite of traffic...LOL
My Toyota Corolla Cross, my driver got so fed up, he kill the proximity sensors ( there is a switch ) because Toyota version is very stupid, compared to MB version.
Stupid in the operational sense. MB version still has some decent algo as such proximity alone will not cause the crazy beep, but it will beep
when proximity to the surrounding changes in a risky way towards the car. Its difficult to explain in details, I must show you guys in real time.
I think the azz-holes motorbikes is how N62 Parking System is no 1 DTC glitch for my car.
==============
One more thing I noticed, the power loss and power come back from battery disconnect and re-connect.
I have disconnected and re-connected my battery like 100+ times.
Often many kind DTCs will be logged as STORED when doing battery disconnect and re-connect.
My hypothesis is this :
Modules are programmed to listen to other modules CAN traffic, as such the active/ON module/s can be the reporting module when other modules are offline/OFF.
Upon battery re-connect, I doubt all modules have equal boot time. So some modules maybe already hit its too-long-waiting time limit towards X and Y modules, thus DTC appeared and then became STORED
by some seconds later when the said modules came ON-LINE/active.
My headlight high beam command for ON, is a 10 signals per second. Same repeated signal 10 times in 1 second.
Imagine if any modules requiring the same data transmission of 10 times in 1 second and 3 out of the 10 transmissions got delayed, what will other listening modules do in terms of reporting a DTC.
I know some mission critical module, a mere 0.1 second signal loss of 1 out of 10 signals, a DTC will be declared.
A good example is N118 fuel computer. See how short the allowance for duration of a fault #1 to #3.
22ms or millisecond is crazy fast, #1
0.9ms is even crazier fast , #3
1 second is 1,000 milliseconds
Master Surya, I am sorry to read your chassis gave you a headache on your way to Surabaya this summer.
This time the turn signal and headlight both reported transient faults with SCModule.
The good thing is we can directly rule out low voltage with your perfect ALT self-control and good main GND strap.
At the end of the day... you are going to work on solderless SCM with a method of your choice: repair or renew or reboot.
The interesting part is how traffic jams are purposely created across CGW by marginal secondary modules.
The HL normal signaling is repeated countless times when in working conditions and crazy when it does not.
CGW is like Jakarta traffic...
Traffic jam cause bottlenecked throughput
When a priority vehicle shows up, the gridlock guarantees latencies.
> CAN limited performance vs. faulty:
-- With normal factory-grade modules, CAN datagrams have a nominal amount of delays they handle mostly well.
-- When too many crazy modules jam the gateway bridge: limited throughput is the result. The more modules soft-crash the bigger the traffic jam. Until power is cycled then functionality is temporarily resumed.
-- this reduced performance scheme is too good so Bosch added distributed gateways. We have more than one network bridge: ZGW!
Some modules act as their own bridge to directly collect data over multiple networks: IC-Display...
-- Now that I've surveyed my whole chassis for troublemakers, I understand there are different class of modules. The VIP vs.
The peripherals modules are used to degrade performance of VIPs that are otherwise honestly robust (ECU/TCU/FSCU/...).
What I evidenced is that the engine injection+spark timings are DIRECTLY AFFECTED BY POOR CAN Performance...
I am not one to complain as I like testing SOLUTIONS!!
MS! we can trace your turn signal wiring or you can get proper timings for full performance of your twin-turbo
Obviously right now your 1st priority is your failing steering column module. While column is out also fix your EIS ignition module...
The worse providers of managed chaos is ESP module!!
Pls give us CAN network map with names so we can make more sense. I do know Bosch ESP is not on Bosch ECU CAN but it has strong negative impact on engine performance from factory -
Impacting core engine timings from unrelated modules... can now be easily turned around better than new.
My M276 "Zero Engine Vibration" achievement is in part thanks to you Master Surya.
++++ FIXING TRAFFIC PRIORITIES:
-- The key to this network chaos is the volume of traffic. We want to order our priorities to remove bugs out of our chassis.
Meaning: a solderless CAN-B door module can not generate as much junk traffic than high-bandwidth CAN-E such as solderless ESP. So fixing ESP brings more performance rewards.
-- Sanitize high-bandwidth networks first as they can readily flood the gateways.
-- Engineered chaos :
CAN-B is in charge of draining BAT while parked
CAN-E is in charge of detuning ECU-TCU timings
Smooth diving made easy.
I recall how surprised I was after soldering my SCM/EIS when it made my tranny shift noticeably better. These 2 modules also made the car drive planted straight instead of unstable around 0° straight.
I also recall you mentioned your tranny and throttle being very responsive... mileage can vary. Dealing with your SCM may well open your eyes to a far greater reality.
++++ Deeper Diving
The network chaos created by poor module connections relies on error-rates to trigger faults.
I don't know that we have access the error-rate counters. Not the useless fault-count but one level below where error rate is accounted to trigger faults.
Different error thresholds affect system performance causing gradual responses.
-- New condition poor performance should not trigger warranty claims until some time later.
-- Medium error rates can be reset simply with Key:ON/OFF/ON cycling.
-- Hard faults are used to protect users from hazardous accidents. Functions are halted in best possible ways to protect road users. (solderless steering rack self-test).
2015 SL400 (M276 Turbo), 2014 C350 Sport (M276 NA), 2004 SL500 (M113), 2004 Audi TT225 (BEA)
Interesting that I also had the same two error codes (U021200 and B178F00) during my last issue with the Check Engine Oil message discussed here: Check Engine Oil At Next Refueling - MBWorld.org Forums. I'm beginning to think the solar flare activity last week or so is now screwing with our cars!
EDIT: I also got a Parktronic error! I hope I didn't catch some kind of virus from you. 🤣
Interesting that I also had the same two error codes (U021200 and B178F00) during my last issue with the Check Engine Oil message discussed here: Check Engine Oil At Next Refueling - MBWorld.org Forums. I'm beginning to think the solar flare activity last week or so is now screwing with our cars!
EDIT: I also got a Parktronic error! I hope I didn't catch some kind of virus from you. 🤣
Yeah, you two are brothers:
turn signal + SCM + HL
Do you have the active ILS LED ?
Your HL spends its time reading the steering angle to aim the HL straight/L-R sideways.
We realize that is a lot of uninterrupted traffic !!!
When traffic is across a narrow bridge with limited bandwidth, it impacts other modules streaming their data such as TCU reading wheel speed from ESP.
That's how SCM chaos gets spread to TCU timings.
When TCU is busy arguing with ESP, ECU traffic gets the shaft only limited by its VIP priority. Bosch designed the CAN protocol, I am nearly sure packets use priority tagging. Our chassis are used to field test the technology licensed to the top brands through Denso partnership.
The best way to cancel this chaos is by fixing high speed modules first.
Hell even with all my previous fixes, soldering couple loose pins on MFK camera is what smoothed my engine perfectly. I did not know this could be possible.
Let me clarify that fixing MFK is NOT going to transform any chassis still loaded AtoZ with standard chaos.
The best bet is to start experimenting with busy high-speed modules for rewarding ECU-TCU transformations.
+++ ADDITIONAL CAN TRAFFIC...
-- I've said a few times that additional OBD traffic is not a good choice outside of troubleshooting sessions.
-- Don't collect ECU-TCU-ESP live data when not necessary knowing that chassis timings are challenged.
++++ QUICK REBOOTS...
You can reduce the power surging of your chassis by using the experimental reboot method I documented there.
There may be better ways used for 18-wheeler 24Volts trucks (connecting through a power resistor??) - Some battery systems work in 48 and 72 volts so the unlimited surge reduction I'm sure has been solved before.
I am not surging my personal gear if I can avoid it!!
2015 SL400 (M276 Turbo), 2014 C350 Sport (M276 NA), 2004 SL500 (M113), 2004 Audi TT225 (BEA)
Originally Posted by CaliBenzDriver
+++ ADDITIONAL CAN TRAFFIC...
-- I've said a few times that additional OBD traffic is not a good choice outside of troubleshooting sessions.
-- Don't collect ECU-TCU-ESP live data when not necessary knowing that chassis timings are challenged.
That reminds me. I did have my BlueDriver module in my OBD port when I started having problems. I had been using to check readiness codes because of my upcoming emissions test, at the time. I no longer have it plugged in, but I'm wondering if the additional traffic it caused led to that Check Engine Oil message, and that it took some sort of ECU reset on pin 13 to clear whatever was wrong.
No, I don't. But I do have Bi-Xenon Headlicht w. Active Curvelight, Code 615.
by looking at various fault reports its interesting to see what modules are consuming traffic bandwidth to stream data.
Your active HL option keep reading SCM steering angle.
HL modules are solderless but are downstream meaning they have nothing else to impact than themselves.... where SCM is an upstream broadcasting node that must handle bandwidth well non-stop
else "no turn-signal" is >> "Sorry could not reproduce!"
That reminds me. I did have my BlueDriver module in my OBD port when I started having problems.
I had been using to check readiness codes because of my upcoming emissions test, at the time. I no longer have it plugged in, but I'm wondering if the additional traffic it caused led to that Check Engine Oil message, and that it took some sort of ECU reset on pin 13 to clear whatever was wrong.
Because this sensor glitch is a false positive with no consequence, you can keep it on the back burner while studying the miltiple ways it was built to dysfunction.
Unreliable warning sensors are aggravating!
Now we have a remote idea why Bosch cancelled the oil pressure sensor...
I can guess this may be a multi-trip reset and IC-Display failed to update???
The best way is to collect clues to figure if this is bad before ECU or after it.
Reproduce the issue to exercise setting its status. While doing all that, SILICONE each and every leaky connector you come nearby... ISM!
As for now I have some traveling to do before I can fix my side front radars to be 100% solderless free!
2015 SL400 (M276 Turbo), 2014 C350 Sport (M276 NA), 2004 SL500 (M113), 2004 Audi TT225 (BEA)
I know this is hijacking Surya's thread, but what did he expect?
I found this interesting. Using XENTRY Simulation, I found six error codes associated with the oil level sensor. I set them all to be CURRENT DTCs and ran the scan. Here are the results.
What this tells me is that the error codes for a malfunctioning oil level sensor can be ignored.
I know this is hijacking Surya's thread, but what did he expect?
I found this interesting. Using XENTRY Simulation, I found six error codes associated with the oil level sensor. I set them all to be CURRENT DTCs and ran the scan. Here are the results.
/-/
What this tells me is that the error codes for a malfunctioning oil level sensor can be ignored.
What are you thinking regarding your SCM + HL ?
chicken or the egg...
which way troubles roll up or down from SCM??
You and MS! should compare your Xentry research because you both have the greatest @BenzNinja systems in top shape, right?
We know handheld scanners are limited unlike Xentry - There should be high odds you two banging on the same issue can discover good fixes for it (besides my soldering tricks).
Today, 11:26 AM
, #3
