The more electronics, the more "gremlins" you are going to see.

 

Technically, or perhaps I mean linguistically, this isn't what we call a gremlin. The system is doing exactly what it was designed to do. It was just a stupid thing to design it to do.

G

 

"OK, here's a good one for you:
I have a brand new GTS Cab with about 1400 miles, and I've picked up on a very interesting pattern.
The radio tuner has a tendency to turn itself on spontaneously when passing under a bridge, or when around fairly tall buldings. I live in Santa Fe, so there aren't any hi-rises, but when I drive downtown, and am around 3 or 4 story buildings, the tuner turns itself on repeatedly.
What the hell?"

Designed to do that ^?

 

check the settings in the PCM for "Traffic Information" or "Traffic Alerts" i can't recall what the exact language is. I found my radio spontaneously changing stations and this was the culprit. The radio senses that a traffic alert is coming out on some station and fires over to that for your benefit. Once I disabled this feature the radio returned to normal operation for me. I have a 997.1 so it may be different than yours.

 

Hahaha. That's awesome!

 

Yep. I didn't say it was a decision I would make personally, just an intentional choice that turns out to be annoying. Happens when the designer has too little experience or too little imagination. In this case, the thought process goes something like this: "Okay, when the ignition is turned on, the radio should turn on. Right? Good. Now, we'll do that even if it was muted when turned off. Seems fair. People might mute it when they're tired, but they'll want it on again when they start the next drive. Aren't I insightful to think of that? We'll call that 'initiation' and I can get that coded this Thursday. Did you order the Spätzle for dinner?"

Then, later on the actions must be coded for transition between the sources, that is the Bluetooth phone connection, or the USB or CD drive or one of the tuners. Without thinking about that earlier decision (it's Tuesday by now), the designer pictures using the Bluetooth or one of those other devices as the exception, as of course it is for phone calls. When the device activity completes, when you hang up the call or eject the CD, he pictures the PCM falling back to a default state and in order for it to work properly, he needs to 'initiate' that state, so he calls the same routine.

It may seem unlikely, but the most advanced technology groups fall into the trap of putting their top people on the 'important' jobs, designing the separate subsystems in this case. When it comes to making them work together, they picture that as "a simple matter of programming" and let one of their hotshot interns take on the job: "Call Rolf for this. He took a course in Visual Basic last year."

The study of state transitions, especially the unplanned ones like an interruption in reception, is crucial in complex systems, so we refined it greatly in the space program. Like most of our technology, that trickled down to North American industry. But we worked at it so hard because we went through our own phase like that in U.S. design back in the seventies. Even here, residual pockets still suffer the fallacy. From what I've seen of creations like iDrive and our PCM interface, I suspect that German industry either didn't catch up or they suffered a reversion to that mode when they had to absorb the previously East German professionals. I know Soviet bloc designs were notorious for this failing, so it's not unlikely, though I really don't know.

At least no one will die of a poorly programmed PCM. Well, not unless it happens because they spent a crucial few seconds trying to mute a really irritating station.

Gary