EU/UK: Ongoing navigation issues

[ovonrein]

The challenges occur when active route guidance is running but no data can be loaded from the map database. This happens because another function temporarily blocks access to the data.

While this explanation jibes with my personal impressions, it is a truly weird explanation from a software architecture POV. All modern software is structured in layers. The application layer - here the map functions - SHOULD NOT get involved with the network layer. The network layer, on the other hand, should have no idea whose traffic to prioritize - here supposedly at the expense of all else.

It takes A LOT of effort to teach your internet router, to give an example, that is should prioritize VOIP.

It sounds really strange. Of course, it is possible for the application layer - here the navigation - to suspend the navigation thread until some data thread completes. But even allowing that this may have been done, I find it hard to understand what terrible things should happen if one removes these semaphores. Fine - the navigation will work off stale data. Better, I had thought, than not working at all.

Mind you, the above presumes that the PCM is multi-threaded (can run multiple tasks in parallel). Perhaps I am too optimistic.

EDIT: On reflection, I can jump from Navigation to Settings and the navigation continues, so there is strong evidence that the PCM is multi-threaded.

Sponsored

 

[Swiss Danny]

But hey, without having looked at their code, what do I know, right?

I suspect the code is distinctly ungermanic... more italian as in spaghetti...

 

[smoothound]

FWIW - A customer in the UK was told this by his OPC.... (ref Facebook Group) ....

"OPC told me that there is now a recall in progress which should hopefully resolve this issue.

but I will hold my breath until I try its for myself later today"

Recall? .... I only know of the 12V sensor recall that gets done at the same time as the 3885... could be this I suppose? and of course....

A) It's just an OPC's statement;
B) They don't sound confident being just 'hopeful'; and,
C) It may refer to the 3885 fix that doesn't seem to be very effective....

Cheers

 

[Jasper4S]

It could be a recall since Innodrive crashes too, and that is a safety risk and worth a recall + letter to customers.

 

[chun]

You guys should look into how maps work before making assumptions of ram and multithreaded or not.

Porsche is loading into cache map tile data from google’s sdk and other sources, to be able to access it even if you lose signal.

The api that send all that data doesn’t make distinction between old navigation package (pcm 3885) and new one (pcm 4360+).

It’s not ram, it’s just cache managment issues. They are sending more data, because newer navigation package manages it differently. The old one can’t cope with it.

So they either update all cars to newer navigation package (and regression test it with pcm 3885), or update everyone to pcm 4360/4405; or they update the API to make distinction between old and new navigation packages.

I do have this info from the people working on it, and have already posted it. Not sure why extra conspiracy theories are needed.

 

[chun]

It could be a recall since Innodrive crashes too, and that is a safety risk and worth a recall + letter to customers.

My own recall filling/complaint has been under investigation for a few months already, so maybe things are finally moving.

 

[ferdiaz]

You guys should look into how maps work before making assumptions of ram and multithreaded or not.

Both hypotheses aren't mutually exclusive. A caching issue could be caused by, or could even lead to, incorrect management of a common resource across multiple processes.

Even though you got the info on the API mismatch, which could very well be legitimate, the message from Mr. Sajjad Khan also states:

"The challenges arise when active route guidance is running but no data can be loaded from the map database. This happens because another function temporarily blocks the data. This blockage lasts a few seconds and happens, for example, when the map is being updated or when charging stations are being checked."

Based on the above, it is a legitimate interpretation to assume mutex management issues. Otherwise, how else does the data get "blocked"? But as I said, without looking into their code and understanding their architecture, all I can state is that "it looks as if".

Ultimately though, this is just another case of us (me in this case) overanalysing and guessing off of hearsay, which is very much what all the 50 pages in this thread are about Truth is, however, none of us have conclusive information coming from official channels about the root cause of this issue.

 

[ovonrein]

Porsche is loading into cache map tile data from google’s sdk and other sources, to be able to access it even if you lose signal.

While that stands to reason, there is precious little evidence to that effect. All evidence points to the contrary, eg the fact that the navigation freezes in LTE dark spots, the fact that the car pulls down map updates en route, etc. The German post contents that a loss of signal is catastrophic for the current implementation. (Which is weird because I would have assumed that when this code was originally designed, network access would have been patchier than it is today. Conversely, it is possible that the US experience is generally better because their mobile network has better coverage. Not sure, though, that this can really be said about the middle of the Nevada desert.)

 

[Scandinavian]

While that stands to reason, there is precious little evidence to that effect. All evidence points to the contrary, eg the fact that the navigation freezes in LTE dark spots, the fact that the car pulls down map updates en route, etc. The German post contents that a loss of signal is catastrophic for the current implementation. (Which is weird because I would have assumed that when this code was originally designed, network access would have been patchier than it is today. Conversely, it is possible that the US experience is generally better because their mobile network has better coverage. Not sure, though, that this can really be said about the middle of the Nevada desert.)

From experience you should not compare network coverage between the UK and other countries.

Speaking from own experience the networks in the UK are likely the worst ones of west Europe. Especially 4G and 5G. And that is along major A roads! Countryside it gets even worse

 

[chun]

While that stands to reason, there is precious little evidence to that effect.

The evidence is literarly that that’s how all maps work in cars; per Google sdk documentation - as an example; unless you expect me to leak the info on my university colegue working at porsche in Cluj on the infotainment

But sure

 

[E500]

Both hypotheses aren't mutually exclusive. A caching issue could be caused by, or could even lead to, incorrect management of a common resource across multiple processes.

Even though you got the info on the API mismatch, which could very well be legitimate, the message from Mr. Sajjad Khan also states:

"The challenges arise when active route guidance is running but no data can be loaded from the map database. This happens because another function temporarily blocks the data. This blockage lasts a few seconds and happens, for example, when the map is being updated or when charging stations are being checked."

Based on the above, it is a legitimate interpretation to assume mutex management issues. Otherwise, how else does the data get "blocked"? But as I said, without looking into their code and understanding their architecture, all I can state is that "it looks as if".

Ultimately though, this is just another case of us (me in this case) overanalysing and guessing off of hearsay, which is very much what all the 50 pages in this thread are about Truth is, however, none of us have conclusive information coming from official channels about the root cause of this issue.

Guessing is fun!

I bet it’s a null pointer. Something returns null (after a timeout?) when it’s busy instead of handling it gracefully. At least it’s not deadlocking

that’d be a very easy fix though so it’s probably not that simple.

The most complex and difficult to solve issues I’ve dealt with are always seemingly random memory corruption in (very) multithreaded processes.

edit: I agree with the point i think you’re making though. The use of ‘blocked’ is odd; either a bad translation or some sort of mutex thing as you say

 

[Jasper4S]

/s I guess it has to be a Jasper Exception.

OK, enough internet for me today. See you tomorrow!

 

[ferdiaz]

Guessing is fun!

I bet it’s a null pointer. Something returns null (after a timeout?) when it’s busy instead of handling it gracefully. At least it’s not deadlocking

that’d be a very easy fix though so it’s probably not that simple.

The most complex and difficult to solve issues I’ve dealt with are always seemingly random memory corruption in (very) multithreaded processes.

edit: I agree with the point i think you’re making though. The use of ‘blocked’ is odd; either a bad translation or some sort of mutex thing as you say

In the end, chasing bugs in Taycanforum isn't to dissimilar to chasing them at work. The amount of provided information is usually about the same ;p

 

[Murph7355]

Does the issue happen on

While that stands to reason, there is precious little evidence to that effect. All evidence points to the contrary, eg the fact that the navigation freezes in LTE dark spots, the fact that the car pulls down map updates en route, etc. The German post contents that a loss of signal is catastrophic for the current implementation. (Which is weird because I would have assumed that when this code was originally designed, network access would have been patchier than it is today. Conversely, it is possible that the US experience is generally better because their mobile network has better coverage. Not sure, though, that this can really be said about the middle of the Nevada desert.)

Does the issue happen on J1.2 cars?

What they should do - upgrade to the latest s/w throughout. Good customer publicity, fixes the issue, shows legacy product is supported.

What they are more likely to do is ignore it, hoping people will move to J1.2 or kludge it with branched API calls.

 

[chun]

Does the issue happen on

Does the issue happen on J1.2 cars?

What they should do - upgrade to the latest s/w throughout. Good customer publicity, fixes the issue, shows legacy product is supported.

What they are more likely to do is ignore it, hoping people will move to J1.2 or kludge it with branched API calls.

Doesn't happen on PCM 4360 / j1.2, no.

The update is 6h minimum. They won't do 500$ - 600$ an hour (standard porsche service rate) for 150.000 cars, 6 hours each. They can't afford to anymore, it's 540,000,000$; and that's assuming no part breaks and that services don't claim more hours than 6 worked.

Sponsored