MyT app not recording longer trips correctly

[nlee]

First time for a while I've done a few longer journeys. Have mentioned this before but not had it for a while due to mainly short trips.

Thursday drove from North Wales to Norfolk non-stop. Trip data cuts off somewhere between Grantham and Boston at 163.4 miles and 3 hours 9 mins.

Sunday, drove back from Norfolk to North Wales and trip data cuts off near Rugby, 132.8 miles and 2 hours 41 mins.

On both trips, the text description of the real start and finish location is correct but the map trail and stats cut short. It's like there is not enough buffer available to store the details of a longer trip prior to uploading to the server.

Anyone had any success with recording longer journeys, say over 3 hours?

 

 

[Roy124]

Actually, now you mentioned it, I had a similar issue, 3 hours 11 minutes and the tracking stopped on the M25 just before we went on to the M23 for Gatwick. 

[ernieb]

Sorry, Nigel any longer trips have usually involved a break/stop at some point so they have generally been OK.

I’ve rarely lost a recording just a couple since I’ve had the car. The ones your missing has it been likely that the single has been lost to the SIM?

[Roy124]

Ernie, signal loss might be possible but the 3 hour point is a consistent point among many users. 

[nlee]

26 minutes ago, ernieb said:

Sorry, Nigel any longer trips have usually involved a break/stop at some point so they have generally been OK.

I’ve rarely lost a recording just a couple since I’ve had the car. The ones your missing has it been likely that the single has been lost to the SIM?

I haven't lost any complete trips for a while, maybe a few delayed but that area seems to have improved.

I doubt it is network coverage related as there are many other rural "blackspots" where this would occur and be more random. It always seems to be longer trips which leads me to think it only uploads at the end of the journey and it is running out of storage memory after about 2.5-3 hours of the journey, depending on complexity of the route and data points.

[Roy124]

Nlee, that makes sense.  If you try and track the car when it is moving then it reports the car as moving. 

I wonder if it requires the car to be switched off before the upload. 

I checked back over last year and found a second journey that ended prematurely after exactly the same 3hr 17 min.  That rules out comms blacks spots. 

[Nick72]

On 3/28/2022 at 1:18 PM, nlee said:

First time for a while I've done a few longer journeys. Have mentioned this before but not had it for a while due to mainly short trips.

Thursday drove from North Wales to Norfolk non-stop. Trip data cuts off somewhere between Grantham and Boston at 163.4 miles and 3 hours 9 mins.

Sunday, drove back from Norfolk to North Wales and trip data cuts off near Rugby, 132.8 miles and 2 hours 41 mins.

On both trips, the text description of the real start and finish location is correct but the map trail and stats cut short. It's like there is not enough buffer available to store the details of a longer trip prior to uploading to the server.

Anyone had any success with recording longer journeys, say over 3 hours?

 

 

Many regular long business trips. Doesn't always record them. Have given up as a reliable source of defining distance and hence my fuel mileage claims. Now use odometer. 

I think there is an issue with when that data gets uploaded to the Toyota server from the car. I assume when you switch off the car it bursts an upload via the car GSM sim to Toyota. But, if in a low or zero signal environment I think this is when it goes wrong. Now, I would have expected that the trip is held in a buffer until proper handshake and txfer with the Toyota server at which point the trip record can be deleted off the car. But, I think what happens is the next trip overwrites the former. Easily fixed by having a last trip and new trip separate buffers or arrays. Then when on the new trip the car is continuing to make contact with Toyota so it can get the last trip buffer uploaded.

 

Guessing.

[ernieb]

24 minutes ago, Nick72 said:

Many regular long business trips. Doesn't always record them. Have given up as a reliable source of defining distance and hence my fuel mileage claims. Now use odometer. 

I think there is an issue with when that data gets uploaded to the Toyota server from the car. I assume when you switch off the car it bursts an upload via the car GSM sim to Toyota. But, if in a low or zero signal environment I think this is when it goes wrong. Now, I would have expected that the trip is held in a buffer until proper handshake and txfer with the Toyota server at which point the trip record can be deleted off the car. But, I think what happens is the next trip overwrites the former. Easily fixed by having a last trip and new trip separate buffers or arrays. Then when on the new trip the car is continuing to make contact with Toyota so it can get the last trip buffer uploaded.

 

Guessing.

Totally agree with your analysis of how it works it’s sooooo very sad that what essentially is a potentially good app is screwed by not buffering the data effectively. I’ve previously reported that I’ve missed the first part of a trip when I’ve stopped part way, the app only reporting the second part. So somehow the car was transported 100 miles from it’s last reported know position without the car using any energy, EV or ICE?

It must be really frustrating that the use of the business trip function can not be used in the app reliably?

[Hayzee]

Has anyone reported the problem via the MyT app?

I notice that the developers do respond to comments/problems. Contact at MyTapp@toyota-europe.com

By the way, does it happen on Android and IOS?

Is it the same on the MyT pages on PC browser?

Edited March 31, 2022 by Hayzee

[nlee]

11 minutes ago, Hayzee said:

Is it the same on the MyT pages on PC browser?

It's exactly the same on My Toyota as it is on the MyT App so unlikely anything to do with different operating systems.

Good shout on contacting the app team at Toyota, I'll try that.

[ernieb]

Already contacted the team about the app some time ago, no comment.

[Hayzee]

1 hour ago, ernieb said:

Already contacted the team about the app some time ago, no comment.

Ernie....did you make the comment on the app or just email them? Worth highlighting as a comment first to get their attention....though you may have done this already.

[ernieb]

Comment on the app initially.

[Roy124]

On 3/31/2022 at 10:07 AM, ernieb said:

Already contacted the team about the app some time ago, no comment.

I did too.  I told them of the last two instances.  They came back today and asked for the journey dates. 

As I now have a specific case number we could be in business. 

[nlee]

7 hours ago, Roy124 said:

I did too.  I told them of the last two instances.  They came back today and asked for the journey dates. 

As I now have a specific case number we could be in business. 

They came back to me today also, asking for VIN and trip dates. Interestingly, they said they hadn't heard of this issue from anyone before. Well at least we know they've had two!

As it happens, I drove from North to South Wales this morning and the trip cut off around Hereford, after only 99 miles and 2h 17m, which is much shorter than I've had before. Again actual start and finish addresses were correct.

[Spo2]

I had the same issues so just reported in the app and email. 

[Roy124]

I guess we might see something in a few months 

[Roy124]

Definitive answer:

I have been advised there is a limitation of the module fitted (which is known as a DCM (Data Communication Module) in our cars. The DCM while having a trip capture a lot of data. Each data is stored as an event and at the end of the trip all events are stitched and sent to us as a trip. The DCM cannot store more than 2000 events. Once it reaches 2000 events, after that only the end location is captured. The events can be anything, like the driver behaviour which is not good for hybrid score, threshold breaches like speed, accelerations and breaks. During longer trips, we usually see this issue.

We have gone through the trip that you have mentioned for 27th October and 4th March. There were total 2000 events captured for both the trips. After that DCM could not load more events. Thus no further locations could be captured and we only got the last location after that.

[philip42h]

I tend to take a break every couple of hours or so and I have never had this problem - I may do many 'trips' in a day but they are all less than 2000 events.

Still it's good to have an explanation and maybe there will be an update / fix one day ...

[ernieb]

42 minutes ago, Roy124 said:

Definitive answer:

I have been advised there is a limitation of the module fitted (which is known as a DCM (Data Communication Module) in our cars. The DCM while having a trip capture a lot of data. Each data is stored as an event and at the end of the trip all events are stitched and sent to us as a trip. The DCM cannot store more than 2000 events. Once it reaches 2000 events, after that only the end location is captured. The events can be anything, like the driver behaviour which is not good for hybrid score, threshold breaches like speed, accelerations and breaks. During longer trips, we usually see this issue.

We have gone through the trip that you have mentioned for 27th October and 4th March. There were total 2000 events captured for both the trips. After that DCM could not load more events. Thus no further locations could be captured and we only got the last location after that.

Great info Roy, but it does sound pretty pathetic reason and does account for the problem with longer trips. However, I’ve lost trips that were split into two parts with a stop mid way. Strangely it was the first part of the trip that was lost. As I’ve done this route many times and it has recorded perfectly there must have been another reason,  maybe the SIM not connecting? 

[Stopeter44]

16 minutes ago, ernieb said:

Strangely it was the first part of the trip that was lost. As I’ve done this route many times and it has recorded perfectly there must have been another reason,  maybe the SIM not connecting? 

Certainly, sounds reasonable. I can only recall one lost trip, and it was very short. The other day, I thought a trip would be lost because I parked about two floors below sea level (!), or rather at level -4 of an underground parking.

There were no worries trip was recorded. The trip recording is handy, too, for retracing a Satnav route on a map, to see just exactly the route taken, especially when you don't exactly know where the Satnav has taken you.

[Roy124]

I went back with a supplementary question ; will this also apply to Smart Connect. 

[nlee]

Thanks for the update @Roy124. I haven't had a response yet but was expecting something along similar lines. It's a bit poor really that it can only store that much data but it doesn't sound like it is something than can be fixed by software, it sounds like a larger capacity module would be required.

2000 events sounds very low. They haven't made it completely clear what an event consists of and I guess my assumption is probably incorrect that each event is a GPS coordinate. If it was, then the track resolution would be very poor. On the basis it seems to stop recording around the 3 hour point, or 150 miles, that would equate to an average of one reading every 5-6 sec, or every 120 metres if using distance. You would probably find many cut corners or going straight over roundabouts. If you zoom into the map, you see a pretty good trace so it must be more complex data wrapped up into each event.

[philip42h]

1 hour ago, nlee said:

Thanks for the update @Roy124. I haven't had a response yet but was expecting something along similar lines. It's a bit poor really that it can only store that much data but it doesn't sound like it is something than can be fixed by software, it sounds like a larger capacity module would be required.

2000 events sounds very low. They haven't made it completely clear what an event consists of and I guess my assumption is probably incorrect that each event is a GPS coordinate. If it was, then the track resolution would be very poor. On the basis it seems to stop recording around the 3 hour point, or 150 miles, that would equate to an average of one reading every 5-6 sec, or every 120 metres if using distance. You would probably find many cut corners or going straight over roundabouts. If you zoom into the map, you see a pretty good trace so it must be more complex data wrapped up into each event.

Picking on a trip from last week - exactly 1 hour driving - I noted that it recorded 7 driving events (2 hard accelerations and 5 hard brakings). It was a quietish day so relatively easy-going - a typical hour's driving might well contain rather more events than that.

In order to have an exact track of the route all it need record are the turn waypoints - it can (and does) assume that you follow the road and uses the same map as available to the sat nav to determine the route. So if your journey is relatively straightforward it can be recorded with relatively few data points; if it is complex with many junctions and turns it will require many more data points.

Using your estimates, a data point every 5-6 seconds / 120 metres seems an excessive number  - one every few minutes or every few miles seems more reasonable - so it does seem to be recording rather more than perhaps it needs to.

A software fix sounds relatively easy to me - add code to the effect that when the2000 event buffer is 'full', upload the buffer (as if you had just stopped), flush the buffer and start again ... but it is probably a little more complicated than that. 😉 

[ernieb]

If they were able to do a software fix to upload the data more regularly then this would effectively give a version of real time tracking.