Battery Protection Limit

[CrowSysE243]

After clearing the DTCs it definitely seems to help for a while when the weather was cold - it first reappeared when I got a notification on my phone about battery protection being active - at this point I was driving the car at 70MPH and there was absolutely no issue in the car. Without the app - there would have been no issue.

I have never received a notification from the MySkoda app about the battery protection limit and all the available notifications listed in the app are switched on so there is something different about your set up and mine. The app version has varied over time and I do not have records. The phone was running Android 14 when I experienced Battery Protection Limit activation (without notification) and is during the recent test had been updated to Android 15 and MySkoda (for Android) version 7.8.0 beta. During this test I did not get indication of a battery protection limit activation shown in the app but got a new message that Remote car control was near battery limit when the 12V SoC percentage was in the low 50s shortly before the car started charging the 12V battery from the HV battery. Other details in the message were similar to those given if drilling down from one of the battery protection limit statements I have had previously leading me to think that Skoda may be changing how the battery protection limit information is conveyed to the user.

It seems harder to record the data for extended periods in the 85 with 4.0 software. Leaving it unlocked uses more power it seems - but locking it or letting it lock itself after a period of being unlocked without being opened - always results in either the communication stopping or the alarm going off. Any tips CrowSysE243?

I have not taken long duration measurements with the car unlocked but after reading your post I will add that to my list of things to try. I have noticed that if the phone is taken out of Bluetooth range while the CarScanner app is showing that there is a connection to the ECU the app will generally try and reconnect when the phone is brought back into range, unless there has been a very long gap. If the car is locked then the alarm goes off at this time. My guess is that this may be a mechonism that has been implimented to counter attempts to access the car through the CAN bus connection to externally accessible modules such as lights, etc. When I am undertaking long term recording I either use an old phone or tablet in the car or leave the phone on a windowsill inside the house but within Bluetooth range of the car so that I can leave it locked. When taking spot measurements I unlock the car while in Bluetooth range but do not open the door so that the car will autolock, connect the app before the door autolocks, take the measurement, then disconnect the app before I walk out of range. There have been a few times I forgot to disconnect the app resulting in the alarm going off when coming back into range. In this case I use the key fob to cancel the alarm and then disconnect the app.

What I have noticed is that I have never seen a SOC below 85 - yet the notification is present - and the SOC doesn’t increase as rapidly (as it’s more charged already).

I had noticed that recently I have not seen many very low 12V battery SoC, however the time that I last had the battery protection limit issue, identified when investigating the Octopus report of being unable to control the car, and checked while it was still shown as present the level was low.

Some screenshots - with 12V battery temp varying between 3 and 9 degrees).

I am interested to see that the 12V battery current in most of the screenshots is mostly about +0.2 A suggesting that there is a small trickle charge happening. I have never seen this behaviour. It may be due to the differences between an 80 with SW 3.5 and and 85 with SW 4.x. Have you looked at the inverter current and the HV battery current at the same time?

I’m starting to think a few different things…
1. Battery protection is actually the HV battery stopping itself from charging the 12V when the SOC drops and not a 12V issue directly - ie ‘the HV battery is cold and to extend range in the cold we are going to disable the 12V charging by reducing the 12v load’. This could also explain why charging the 12v directly appears to do nothing for GD2? This could be why it’s fine when the HV is charging also. Or

I do not think that it is due to a mechanism where, because the 12V battery SoC is low, the HV battery/inverter control is deciding to stop charging the 12V battery. It would not be a logical design decision and is not supported by the data I have seen. It might be due to a low HV battery SoC, however my tests suggest that LV battery charging is being carried out when HV battery SoC is below 20% and with lowish ambient temperature. More testing is required, so has been included on my list of things to do. If, for any reason, the HV battery/inverter charging of the 12V battery did fail to kick in when the 12V battery SoC drops then it would be expected to result in a battery protection limit activation or, as observed near 50% SoC during my test, a lockout of remote control.

3. It’s led from the servers… as in the cars are reporting temperatures and other properties back to Škoda - Škoda are then enabling this in the car intentionally - telling the car to go into this mode to stop the 12V going flat and saving millions in warranty costs. Or

It is possible that the servers are involved. It would not be necessary for the servers to enable it in the car as the server acts as the communications gateway for all attempts to control the car. As the API has not been published I do not know whether all the necessary information is reported by the car to allow the servers to make the decision. I think that I would design it so that the car impliments the protection and reports the fact to the servers. I do think that the limitation on the car being woken up when the app is opened is likely to be implimented in the server as it is still possible to force wakeup by using a control but the status information is not updated to the "time now" values.

Either way… I’m predicting a software based issue and won’t be bothering with getting the 12V looked at.

I would not be surprised if software in the car or the servers contributes to the problem. I have often been told that the probablity of failure of software is 100%!!

[Enyaqandy24]

After clearing the DTCs it definitely seems to help for a while when the weather was cold - it first reappeared when I got a notification on my phone about battery protection being active - at this point I was driving the car at 70MPH and there was absolutely no issue in the car. Without the app - there would have been no issue.

I have never received a notification from the MySkoda app about the battery protection limit and all the available notifications listed in the app are switched on so there is something different about your set up and mine. The app version has varied over time and I do not have records. The phone was running Android 14 when I experienced Battery Protection Limit activation (without notification) and is during the recent test had been updated to Android 15 and MySkoda (for Android) version 7.8.0 beta. During this test I did not get indication of a battery protection limit activation shown in the app but got a new message that Remote car control was near battery limit when the 12V SoC percentage was in the low 50s shortly before the car started charging the 12V battery from the HV battery. Other details in the message were similar to those given if drilling down from one of the battery protection limit statements I have had previously leading me to think that Skoda may be changing how the battery protection limit information is conveyed to the user.

It seems harder to record the data for extended periods in the 85 with 4.0 software. Leaving it unlocked uses more power it seems - but locking it or letting it lock itself after a period of being unlocked without being opened - always results in either the communication stopping or the alarm going off. Any tips CrowSysE243?

I have not taken long duration measurements with the car unlocked but after reading your post I will add that to my list of things to try. I have noticed that if the phone is taken out of Bluetooth range while the CarScanner app is showing that there is a connection to the ECU the app will generally try and reconnect when the phone is brought back into range, unless there has been a very long gap. If the car is locked then the alarm goes off at this time. My guess is that this may be a mechonism that has been implimented to counter attempts to access the car through the CAN bus connection to externally accessible modules such as lights, etc. When I am undertaking long term recording I either use an old phone or tablet in the car or leave the phone on a windowsill inside the house but within Bluetooth range of the car so that I can leave it locked. When taking spot measurements I unlock the car while in Bluetooth range but do not open the door so that the car will autolock, connect the app before the door autolocks, take the measurement, then disconnect the app before I walk out of range. There have been a few times I forgot to disconnect the app resulting in the alarm going off when coming back into range. In this case I use the key fob to cancel the alarm and then disconnect the app.

What I have noticed is that I have never seen a SOC below 85 - yet the notification is present - and the SOC doesn’t increase as rapidly (as it’s more charged already).

I had noticed that recently I have not seen many very low 12V battery SoC, however the time that I last had the battery protection limit issue, identified when investigating the Octopus report of being unable to control the car, and checked while it was still shown as present the level was low.

Some screenshots - with 12V battery temp varying between 3 and 9 degrees).

I am interested to see that the 12V battery current in most of the screenshots is mostly about +0.2 A suggesting that there is a small trickle charge happening. I have never seen this behaviour. It may be due to the differences between an 80 with SW 3.5 and and 85 with SW 4.x. Have you looked at the inverter current and the HV battery current at the same time?

I’m starting to think a few different things…
1. Battery protection is actually the HV battery stopping itself from charging the 12V when the SOC drops and not a 12V issue directly - ie ‘the HV battery is cold and to extend range in the cold we are going to disable the 12V charging by reducing the 12v load’. This could also explain why charging the 12v directly appears to do nothing for GD2? This could be why it’s fine when the HV is charging also. Or

I do not think that it is due to a mechanism where, because the 12V battery SoC is low, the HV battery/inverter control is deciding to stop charging the 12V battery. It would not be a logical design decision and is not supported by the data I have seen. It might be due to a low HV battery SoC, however my tests suggest that LV battery charging is being carried out when HV battery SoC is below 20% and with lowish ambient temperature. More testing is required, so has been included on my list of things to do. If, for any reason, the HV battery/inverter charging of the 12V battery did fail to kick in when the 12V battery SoC drops then it would be expected to result in a battery protection limit activation or, as observed near 50% SoC during my test, a lockout of remote control.

3. It’s led from the servers… as in the cars are reporting temperatures and other properties back to Škoda - Škoda are then enabling this in the car intentionally - telling the car to go into this mode to stop the 12V going flat and saving millions in warranty costs. Or

It is possible that the servers are involved. It would not be necessary for the servers to enable it in the car as the server acts as the communications gateway for all attempts to control the car. As the API has not been published I do not know whether all the necessary information is reported by the car to allow the servers to make the decision. I think that I would design it so that the car impliments the protection and reports the fact to the servers. I do think that the limitation on the car being woken up when the app is opened is likely to be implimented in the server as it is still possible to force wakeup by using a control but the status information is not updated to the "time now" values.

Either way… I’m predicting a software based issue and won’t be bothering with getting the 12V looked at.

I would not be surprised if software in the car or the servers contributes to the problem. I have often been told that the probablity of failure of software is 100%!!

You say you take long term measurements with the phone (or tablet) in or near the car, with it locked. How do you stop the alarm going off?

I can’t get to measure the DCDC with the car off… and on is obviously charging. (Screenshot is below - they don’t coincide) .

I think you misunderstood my point ‘1’ of what could be causing it. I’m not suggesting it’s caused by the 12V - but caused by a cold HV battery. To get out as much range as possible - the charging of the 12v from HV is disabled (so HV power isn’t used) - and then the extra loads are switched off to allow the 12V to last. I don’t see this making sense as the impact on HV must be small.

I mention about it being driven from the servers as a possibility- as I have had a couple occasions where the app reports various messages (and status within), the car touch sensors to unlock stop working - the approach lights stop working etc - but checking the SoC as quickly as I can after this is still above 85%. So there is no obvious causing this directly in the car.

[CrowSysE243]

You say you take long term measurements with the phone (or tablet) in or near the car, with it locked. How do you stop the alarm going off?

It may be different with your car/software, however with mine the alarm is only triggered when the connection to the ECU starts to be established while the doors are locked and the alarm enabled. I am using a Veepeak OBDCheck BLE Bluetooth OBD 2 scanner and the Car Scanner Pro Android app. To get the connection without triggering the alarm I ensure that I am within Bluetooth range of the car and unlock it using the key fob. There is a reasonable area inside the house near the front door that works for me. At this stage there is no connection from Car Scanner to the car.

When I start the connection process the app initially starts connecting over Bluetooth to the ELM32 compatible dongle in the car.

.
Once the app has established the connection to the dongle, the app starts establishing a connection via the dongle to the ECU in the car. It is at this point that the alarm is triggered if the car is locked and the alarm active. It the car is unlocked and the alarm inactive there is no problem.

The connection to the ECU has always been established before the car auto-locks because no door has been opened.

The alarm does not get triggered once the connection to the ECU has been established and the car has been locked provided that the device running the Car Scanner software remains within Bluetooth range of the car so that the ELM connection remains reliable. Unfortunately there appears to be a longish timeout before the app shows that ELM/ECU are disconnected but I have found that if I see the Bluetooth symbol on the phone flicker while I move around then moving back towards the locked car will trigger the alarm, although this can be cancelled using the key fob. I suspect that the app keeps trying to re-establish the links several times before it shows that they are shown as disconnected. I have seen that if I keep away long enough and then return the app shows that it has given up trying and asks whether I want to start trying again. In this case the alarm is only triggered if I select the option to re-establish the conneciton. My long term measurements have been taken by leaving the phone in the car or in the house close to the car, rather than carrying it around with me.

I can’t get to measure the DCDC with the car off… and on is obviously charging. (Screenshot is below - they don’t coincide) .

I see what you mean. There appears to be a gap in your 12 V battery current plot where the DC-DC converter current has data and very little DC-DC converter data. I have 5 preconfigured dashboard pages set up to record the data sets that I am interested in for the long term recordings. These pages are set up to update in the background so recording continues while I am looking at other pages. There is some duplication in the data on the pages because I want to be able to see some information as part of more than one set, for example the odometer data appears on 3 pages and the 12V SoC appears on 2. The following shots show the page that I have for viewing the 12V battery investigation data but there is other related information that I recorded simultaneoulsy on other pages, for example the HV battery current.

The pages can be configured using the Dashboard Editor.

I think you misunderstood my point ‘1’ of what could be causing it. I’m not suggesting it’s caused by the 12V - but caused by a cold HV battery. To get out as much range as possible - the charging of the 12v from HV is disabled (so HV power isn’t used) - and then the extra loads are switched off to allow the 12V to last. I don’t see this making sense as the impact on HV must be small.

There might be some justification in conserving HV battery charge if it was very low and the temperature was very low, however I agree that the impact on HV is small. Adding 40 Ah to the 12V battery would use around 0.5% HV battery charge. I do not have good data at very low charge and low temperature but I the battery protection limit problems I had last winter did not occur under the most extreme charge/temperature conditions. I have not seen it when the temperature was below 0 and I have seen it when the HV charge was above 30%.

I mention about it being driven from the servers as a possibility- as I have had a couple occasions where the app reports various messages (and status within), the car touch sensors to unlock stop working - the approach lights stop working etc - but checking the SoC as quickly as I can after this is still above 85%. So there is no obvious causing this directly in the car.

I cannot comment on the behaviour of the door handle touch sensors and the approach light behavior when the battery protection limit is active as I have turned off the approach sensors and normally lock the car with the key and then touch the sensor so that keyless entry is disabled when I am at home. I turned off the approach sensors to prevent the lights coming on everytime I walked into the hall or onto the stairs. I may try an experiment later if I can reliably and reasonably quickly cause a battery protection limit event. I have seen strange reports in the app when there are communicatins problems, or server problems, without the battery protection limit being active, What you report may have been triggered by a battery protection limit activation but I think that the app behaviour is not due to the servers triggering the event but possibly responding to the symptoms. You reported in an early post that there had been a delay in it showing up in the app so it is difficult to be certain about the order that things happened.

[MikeG8]

I've had the 12v battery replaced yesterday. Skoda garage said the battery itself was faulty. We'll see what happens over the next few days/ weeks

[Aragorn]

You'd be better off buying a BM2 type battery monitor/logger rather than trying to use OBD for this. Not least because logging using OBD means your keeping the cars computers awake which isnt really representative of what happens normally.

[Enyaqandy24]

So is everyone else the same, in that this has pretty much gone again now we are back above 4’c?

Today and recently has been 5’c and not one issue with battery protection for me.

When it gets below 4 again I bet this comes back.

Strongly suggests no 12V issues to me as the battery performance is no different at 4’c compared to 5’c.

Let’s see in the coming days… or have others still been getting the issue?

[Doodle24]

I'm getting regular warnings on the app saying:

"Unavailable due to battery protection limit".

And:

"Remote car control — near battery limit. Some remote controls are now disabled — low 12V battery level. The remaining battery energy is needed for vital car functions. You can recharge the 12V battery by driving your car or charging the12V battery."

Yesterday drove 120 miles and then charged 40% to 80% overnight. 12V battery showed 13.2V on my meter when I finished driving it yesterday before charging the car up but down to 11.8V this evening (3 deg C). I would have thought it should be higher than that. The car's only 9 months old.

Waiting for an appointment to take it in to Skoda before I try and drive it to the Alps!

[RichMix]

Mine has been with dealer now since Tuesday (now Thursday PM)

They've juts called to say they are waiting for SKODA Technical to advise. It is however pointing to 12v battery and the fact it is depleating or not charging as it should. Tonight they will disconnect the 12v and see what it reads tomorrow andthen decide

I'll keep you posted

[RichMix]

Still in garage, looking like a defective 12v battery. Will know MOnday

[Skku]

Talked with Skoda today and they have escalated the problem to level 3 (what the he## that means). They couldn't give any feedback on when they tough there would be a solution of the problem...