Skip to main content
All CollectionsKnowledge Articles (Internal base)Car sharing
Ride Share doors lock/unlock issue (troubleshooting on the spot)
Ride Share doors lock/unlock issue (troubleshooting on the spot)
Albert Basiul avatar
Written by Albert Basiul
Updated over 7 months ago

The article is still in progress!

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.

Note: The troubleshooting steps provided here are generalized for all vehicle models. More detailed information regarding specific models is provided in the follow-up articles.

Troubleshooting steps:

1. Check the behavior of the DOUTs and CAN door lock state around the time of the malfunction. Take note that in Raw data report, time is displayed in local time, while in SupportMode and DCS commands list, data is displayed in UTC time.

Note: In these examples, data values are color-coded in Excel for clarity purposes.

The normal behavior should look like this:

mceclip3.png
mceclip5.png

The doors are open (example: "LCV hatch=1") while doors are unlocked ("CAN door lock state=0"):

mceclip0.png

--------

Abnormal behavior can look like this:

mceclip4.png
mceclip6.png
mceclip1.png

4. Attempt to send LOCK_BLOCK and UNLOCK_UNBLOCK commands on our own and check at changes in DOUT statuses and CAN door lock state.

In case the behavior is normal, the issue most likely has been resolved for now (the issue could not be reproduced). Try sending commands a few more times to make sure it works as specified.

In case the error shows that doors are open, ask the technician to re-close them and try sending commands again.

5. In case there is abnormal behavior, and there is a technician at the site with a physical key, ask to lock/unlock the vehicle slowly three times (must be unlocked at the end).

6. Send LOCK_BLOCK and UNLOCK_UNBLOCK commands several times. After every command, check DCS commands and raw data report. In a typical scenario, the problem resolves itself at this point.

7. If the commands are not working (abnormal behavior continues), reset the device (SMS command "cspsm reset");

8. Check that the solution has worked:

If the technician is near the car, repeat steps 5 and 6; if the technician is not in close proximity to the vehicle, repeat step 6 only.

9) [Not relevant]

10) Repeat step 8. If it works, the issue is resolved.

11) In case the issue persists, apply known Workarounds (i.e. the DIFF file for VW e-UP and Škoda CityGo cars) if needed; more information for every model here;

12) Repeat step 8.

13) If the problem persists, register the incident for further investigation;

14) if you cannot lock the doors or you are not sure it was locked (the "CAN door lock state" remains "0" or "255"), block the engine for safety reasons (send command BLOCK via Jenkins platform);

15) If the problem is repetitive for that particular vehicle and/or there is reason to suspect a connection problem, we shall register the repair (in Lithuania) or inform the customer that physical checkup of the device is required (in Bulgaria and Romania).

16. In case the problem is more serious and a significant part of the fleet is affected, or under a request of the client, consult with Tier 2 supporter. An FWP consultation/incident to JIRA for further analysis may be needed.

Did this answer your question?