Description of the issue: the customer Ride Share (also known as Spark) reported that the vehicle does not react to lock/unlock commands properly, the car cannot be locked or unlocked. The system on the customer's side shows ATH_FAIL or similar error.
This article is applicable for vehicles that use ATH_INV installation method using 2 DOUTs to control Lock/unlock commands +1 DOUT for ATH (Ignition blocking). This includes but is not limited to:
VW e-Up / Škoda CityGo
Hyundai Ioniq
Hyundai Kona
VW Golf (installation manual version 1.0, older one)
BMW i3
Common causes:
User mistake (Open doors/hood/hatch);
Incorrect LCV door state is received ("open doors");
Delayed or incorrect reception of "CAN door lock state";
Physical connection issue;
Faulty CAN communication (rare case, needs to be investigated individually)
Troubleshooting steps:
2. Check the operation of UNLOCK commands. Filter out "DOUT2" state "1" in the Excel file:
The list should look like this (abnormal behavior is marked in yellow):
Note: DOUT2 state "1" and CAN door lock state "1" (locked) does not necessarily mean that there is an unlocking issue, a more in-depth analysis is needed in order to make a conclusion.
3. Check the operation of LOCK commands. Filter out "DOUT1" state "1" in the Excel file:
Note: DOUT2 state "1" and CAN door lock state "0" (unlocked) does not necessarily mean that there is an locking issue, a more in-depth analysis is needed in order to make a conclusion.
4. Remove all the filters and evaluate the execution of the commands.
Normal operation looks like this:
Abnormal execution looks like this (marked in red; correct execution in green):
In this case, most likely "CAN door lock state" validation does not come through (state does not change), therefore the device returns an error after trying 3 times in a row.
5. Check whether CAN data is being received correctly (it is not getting stuck);
In case there are a lot of records where "Speed (wheel)" is stuck on "0" while vehicle is moving normally (more than 20 km/h), there may be an issue with CANbus data reading:
6. In this case, you have several options:
Register a repair (for Lithuania) -- it is recommended to replace the EasyCAN adapter. Leave a comment to the UVS team among these lines: "CAN data is getting stuck, client cannot unlock/lock the car. The issue is repeating and persisting, check-up of EasyCAN is recommended".
Recommend the client to perform a physical check-up (for Bulgaria and Romania) -- it is recommended to replace the EasyCAN adapter and check the connection of DOUTs as well.
Try using workarounds (next step).
Note: in case CAN data is not getting stuck, register a query and evaluate the need for repair/physical check-up:
In case the issue is not repetitive, additional testing (observation) is recommended for the time being (1-2 weeks).
Repetitive issues for the same car usually require physical check-up.
Repetitive issues for the same model of vehicle (different cars are affected) may require deeper investigation -- consult with EU Global support in case of doubt.
7. As a temporary solution, you can apply approved workarounds, specified in the Confluence page.
In most cases, turning off the "CAN door lock state validation" helps (commands will be displayed as SUCCESS and DOUT triggers for both locking/unlocking+blocking/unblocking will be sent in all cases).
The following DIFF file shall be uploaded:
root_door_state_validation_OFF.fz5d
Take note that it increases security risks: the diagnostics would become more complicated, as DOUT triggers will be sent only once and without correct "CAN door lock state", it may be impossible to tell whether the door was locked/unlocked for real using raw data. Therefore, a physical check-up is always a preferred option. In case the issue of incorrectly working doors is repetitive and DIFF file is already uploaded, the only solution would be a physical check-up.
8. After repair (physical check-up) is done, please upload the default configuration file!
The configuration details are described in the Confluence page.