Part 2: The J1 Powertrain

[ze_shark]

There is a PEAK torque increase of 5-10% at low speeds.
However, the Taycan 4S at e.g. 85kph has 50% more torque and 50% more horsepower than stock in normal mode.

85kph would be 5100 rpm right ?
So based on your chart (suggestion btw: a stock vs what-i-am-selling chart would make this convo a lot simpler, at least to a seemingly IQ challenged person like me), stock torque at 5100 is 427 Nm ?

There is no warranty risk with a replacement controller.

So here is a hypothetical case.

Car breaks down on the road, that happens on some Taycans, unfortunately.
Call Porsche assistance, car is bricked, gets towed to dealership.
How does one swap the ASG before the dealer tech undertakes to root cause the problem ?
Or does that become the first thing one does road side if the car breaks down ? Is it a trivial operation ?

Sponsored

 

[BjörnfromHamburg]

It´s quite trivial.
A 15 Min. task in the trunk with 3 small tools and a light needed.

 

[Rik_CT4s]

It´s quite trivial.
A 15 Min. task in the trunk with 3 small tools and a light needed.

But can it be done in any state (of the car) without the magic swap being detected?
I remember a short instruction video of HGP turbo (tuner in Germany) where they stated the exchange of ASG needs to be done when the car is "asleep"....any idea if this still applies or it can be swapped at any given time in any state?
If the latter, great! No issues.

 

[BjörnfromHamburg]

The latter!
Should be asleep mainly so the 12 V battery won't drain.
The swap produces error-codes, but that proves nothing.

 

[prj]

85kph would be 5100 rpm right ?
So based on your chart (suggestion btw: a stock vs what-i-am-selling chart would make this convo a lot simpler, at least to a seemingly IQ challenged person like me), stock torque at 5100 is 427 Nm ?

This chart is in second gear to show the total performance of the motors over the rev range, but the car has also a first gear.
From factory the shiftpoints are different for every mode, and especially on the 4S you have to alter them a lot. So a full apples to apples comparison through the rev range can not easily be done.

However - a 0-100kph (60mph) power chart could be useful to add in first gear for each model. This would show when you reach the maximum power.

By the way - I am the first one to provide any charts. All the companies selling until now just made random claims without having any data to back them up! But I love data, and more data is always good.

I think it is a great idea. I will work on these charts and add them. It will take some work.

So here is a hypothetical case.

Car breaks down on the road, that happens on some Taycans, unfortunately.
Call Porsche assistance, car is bricked, gets towed to dealership.
How does one swap the ASG before the dealer tech undertakes to root cause the problem ?
Or does that become the first thing one does road side if the car breaks down ? Is it a trivial operation ?

I will upload a video soon. If push comes to shove and you have some basic tools then you could even do it while waiting for the tow. Or you could do it in the dealer parking lot, they're not going to take the car in immediately most likely - remember, the dealer is not out to get you.
It takes about 10 minutes on a sedan, and about 25 minutes on the CT and ST variants.

That said, right now Porsche does not flag modified ASG's on the backend for warranty purposes.

But can it be done in any state (of the car) without the magic swap being detected?
I remember a short instruction video of HGP turbo (tuner in Germany) where they stated the exchange of ASG needs to be done when the car is "asleep"....any idea if this still applies or it can be swapped at any given time in any state?
If the latter, great! No issues.

It does not matter if you do it when asleep or not. When you plug in the middle connector to the new ASG, which needs to be done first due to interference between the connectors, it gets power and wakes up, and then realizes it has nothing connected to it, and gets a load of errors. Then you either plug in the gray one and it has no Flexray, and wakes everything up on CAN and loads all the modules full of comms errors, or you plug in the blue one and it has no CAN, wakes up everything up on flexray and again loads all the modules full of comms errors.

But - as said already before, having comm errors in the fault memory does not mean anything. Certainly that does not affect the warranty in any way.

 

[ct14garage]

The swap produces error-codes, but that proves nothing.

Ideally you would delete the codes before going to Porsche, because many Porsche dealer techs are fairly inexperienced and the codes may confuse them into thinking something else is wrong with the car.
They may even claim something is bad and try to change it due to the fault codes in extreme cases.

But even this, they will never ever find out about the remap. So warranty is not a concern at all!

 

[Porsche-Guru]

A quick question:

Does changing the ASG in anyway change any parameter coding done on other modules?

For.. eg. I have changed a few parameters in BCM1, BCM2, ZFAS, ESP for some simple changes.
For instance, Enable Rear lights as DayLight Running Lights, Increasing Indicator/Blinker count to 5, Increasing Remote Boot Opening button press time, Enabling 3D view in parking Surround mode, etc.... mainly cosmetic stuff.

e.g. Module BCM2 (Body Control Module 2) [0x46] > Flasher_light_control > Motorway_flashing_flashing_cycles : Changed value to 05 from default of 03

All these changes have been done using PIWIS in Developer Mode.


I presume swapping the ASG module does not affect any of the aforesaid changes or will I need to code these again?

 

[ct14garage]

A quick question:

Does changing the ASG in anyway change any parameter coding done on other modules?

For.. eg. I have changed a few parameters in BCM1, BCM2, ZFAS, ESP for some simple changes.
For instance, Enable Rear lights as DayLight Running Lights, Increasing Indicator/Blinker count to 5, Increasing Remote Boot Opening button press time, Enabling 3D view in parking Surround mode, etc.... mainly cosmetic stuff.

e.g. Module BCM2 (Body Control Module 2) [0x46] > Flasher_light_control > Motorway_flashing_flashing_cycles : Changed value to 05 from default of 03

All these changes have been done using PIWIS in Developer Mode.


I presume swapping the ASG module does not affect any of the aforesaid changes or will I need to code these again?

it obviously wont affect

 

[whitex]

The important part is, that when they perform warranty work that the car has a stock ASG.

What about Porsche generating VAL remotely? A number of TSB's mentioned that the VALs would be generated over-the-air and sent for analysis?

And technically right now they don't check on the backend for a tuned ASG (even though the ASG reports the tuning status to the backend).

Why not daisy-chain the two ASG's? The new, modified one does all the work, but passes any HSM interrogation to the old one, so genuine values are reported? Your modified ASG would of course require some customization in hardware, to be able to talk to the original one, but it seems like that would give you the perfect cover.

 

[Porsche-Guru]

it obviously wont affect

I too thought so...

... but the one thing I have learnt over time.

Assumptions are the mother of all F**$-ups.... so always ask an expert.

Thanks for the quick response & assurance.. ?

 

[prj]

What about Porsche generating VAL remotely? A number of TSB's mentioned that the VALs would be generated over-the-air and sent for analysis?

The TD1 status is only read via tester.

Why not daisy-chain the two ASG's? The new, modified one does all the work, but passes any HSM interrogation to the old one, so genuine values are reported? Your modified ASG would of course require some customization in hardware, to be able to talk to the original one, but it seems like that would give you the perfect cover.

Let's just say this is impossible. I could write a page about why that is, but yeah, no. If you knew how everything works, you would also instantly come to the same conclusion.
The way you describe it would be nearly impossible to do even for the factory dev team.

 

[whitex]

The TD1 status is only read via tester.

So not part of the VAL?

Let's just say this is impossible. I could write a page about why that is, but yeah, no. If you knew how everything works, you would also instantly come to the same conclusion.
The way you describe it would be nearly impossible to do even for the factory dev team.

Can it be made impossible, yes it can. However given Porsche software maturity level, they may not have designed it that securely (heck, they haven't even discovered two factor authentication for their online services yet). I also personally reverse engineered one their other ECU's when I was bored during the pandemic, and was able to extract private cryptographic keys, which obviously are supposed to be well protected (granted, physical access to the board was required, which perhaps was out of scope for their security requirements, but still).

 

[prj]

So not part of the VAL?

There is no way to read it that way, it's only readable over diagnostic services, which VAL does not use.

Can it be made impossible, yes it can. However given Porsche software maturity level, they may not have designed it that securely (heck, they haven't even discovered two factor authentication for their online services yet). I also personally reverse engineered one their other ECU's when I was bored during the pandemic, and was able to extract private cryptographic keys, which obviously are supposed to be well protected (granted, physical access to the board was required, which perhaps was out of scope for their security requirements, but still).

What you described is impossible for the aftermarket on the software level because diagnostics are on Flexray and Flexray uses fixed timeslots, you can't just add another device onto the bus, like is the case with CAN.
Adding extra messages is nearly impossible without updating all the controllers etc.

On the hardware level it's impossible as well.

You can hardcode the message, but the message is timestamped and changes all the time. Also you're not dumping anything on the hardware level without using destructive methods on the ASG. And even if you do, good luck with the reverse...

 

[whitex]

There is no way to read it that way, it's only readable over diagnostic services, which VAL does not use.

What you described is impossible for the aftermarket on the software level because diagnostics are on Flexray and Flexray uses fixed timeslots, you can't just add another device onto the bus, like is the case with CAN.
Adding extra messages is nearly impossible without updating all the controllers etc.

On the hardware level it's impossible as well.

You can hardcode the message, but the message is timestamped and changes all the time. Also you're not dumping anything on the hardware level without using destructive methods on the ASG. And even if you do, good luck with the reverse...

What I was thinking is not adding a new device onto flexray, more have 2 flex rays interfaces, and relay messages that do interrogation of firmware, but consume functional messages. That said, I don't know anything how Porsche authenticates this firmware, so might leave it at that.

That does make me think about something else however, would it be possible to design a man-in-the-middle device which would plugin between the ASG and the inverters, and simply scale the requested torque/power? A device like that was possible for Teslas for example.

 

[whitex]

There is no way to read it that way, it's only readable over diagnostic services, which VAL does not use.

The OTA module seems to have all the necessary buses, and an SoC which has enough horsepower to run a PIWIS equivalent which could interrogate other components and send the report back to the mothership. I think this might have been the original intent behind this module, with it flashing new firmwares remotely as needed.

Sponsored