What Tomtom does when you "submit anonymous data"

[gatorguy]

OK, did a short test. Opt-out had been my choice on the 930. File had a three, just like the other opt-out devices. Changed it to opt-in, checked the file again and it was now a one. Disconnected, did a short trip. When I came back I disabled my web connection. Sure enough, a dated trip log was in the statdata directory. A very small data file BTW as would be expected. And the number in the statdata/allowtrip file changed to a two.

Mike Alder is correct (as usual) that a trip-log file is generated and stored in the statdata directory. We just never see it as a rule since it transmits to Tomtom as soon as the Home connection is made and then erased. I know because I watched it happen.

As another test to see if the number relates to transmission of the trip log, perhaps a couple of us could go in the AllowTrip and change the number to a "3", then do a quick trip around the block, or the yard if it's big enough. Then connect to home and see if the trip-log is sent to TT or stays on the device.

 

[sageuvagony]

OK, did a short test. Opt-out had been my choice on the 930. File had a three, just like the other opt-out devices. Changed it to opt-in, checked the file again and it was now a one. Disconnected, did a short trip. When I came back I disabled my web connection. Sure enough, a dated trip log was in the statdata directory. A very small data file BTW as would be expected. And the number in the statdata/allowtrip file changed to a two.

Mike Alder is correct (as usual) that a trip-log file is generated and stored in the statdata directory. We just never see it as a rule since it transmits to Tomtom as soon as the Home connection is made and then erased. I know because I watched it happen.

As another test to see if the number relates to transmission of the trip log, perhaps a couple of us could go in the AllowTrip and change the number to a "3", then do a quick trip around the block, or the yard if it's big enough. Then connect to home and see if the trip-log is sent to TT or stays on the device.

This is completely correct. I went through my backups and found one backup that had a logfile in there. I copied it to my unit, opened up Home, and as SOON as I selected "memory card" as my device, TomTom Home stole the file from me and sent it to their servers I didn't even have to hit "Update my device"

Edit : I tried a few more tests. After TomTom Home ate my file, I went and copied it back into the folder again. It didn't eat the file. I then hit "update my device" and the file still was there. I then tried changing device to "internal" then back to "memory card" and the file was STILL there, even after hitting "update my device" one more time.

I went and closed Home, reopened it, selected my device as "memory card" once again, and TomTom Home ate the file. So at least we know for sure now EXACTLY when it looks for this file. Only when first opening up Home after selecting your memory device (If you use an SD card)

Edit again: I went even further by copying the file a bunch of times over and over. I didn't think Home would recognize the copied files since their name format changed, but it did! Home went and uploaded EVERY copy of the tripdata file.

 

[mvl]

What's interesting, to me anyway, is the timestamp. It shows 8:03 pm. Since I'm typing this at 6:12 pm Eastern, I can only surmise that the time may be based on the European servers.

The triplog is written by the application on the tomtom. Judging from other application-based files like mapsettings.cfg and ttgo.bif, I think the tomtom Linux OS runs on UTC time, even if the application shows all it's screens in local time.

 

[canderson]

Try killing the home process and service, then plugging in the tomtom. I'm not at home now, I would have otherwise tried myself. I doubt you even need to drive anywhere, just walk around your yard.

That's what I did when I got back from that run at noon today. Killed Home from the systray and just fired up the TomTom and explored it for contents of that folder. Nothing new had been added or appended to. Home never got a chance to touch it. How's come I got no dat file? I'm feeling neglected. Would like to get my hands on a short one for "evaluation purposes". Need to generate one of my own so I have very precise info on what *should* be there.

 

[sageuvagony]

That's what I did when I got back from that run at noon today. Killed Home from the systray and just fired up the TomTom and explored it for contents of that folder. Nothing new had been added or appended to. Home never got a chance to touch it. How's come I got no dat file? I'm feeling neglected. Would like to get my hands on a short one for "evaluation purposes". Need to generate one of my own so I have very precise info on what *should* be there.

Nothing special (to us at least)

 

[canderson]

Realized I had not looked since I got home this evening.

Killed Home in the systray. Fired up unit on USB. Windows wanted to know what to do with it. Told it "nothing". statdata folder in internal memory still contains nothing but the 1 byte allowtrip.dat file containing the number 2 -- a 32h if you will. Ah... file was created on 3/12/2009 and shows no signs of modification since that date. Hmmm...

Looked over on SD card. First, understand that my OS and application park on the internal. Maps are on the SD. ALSO has a statdata directory. Best guess is that it is following the currently used map folder in terms of which partition it's on. I was mistakenly assuming such folders would reside closer to the OS than the map set. This one DOES have .dat logs in statdata. FYI, from my perspective, the time/date stamps are in GMT, and the stamp occurs at the START of the trip.

I have some pretty solid idea of the coordinate data that would be associated with the shorter of the two files. As time permits, I'm going to take this bad boy apart byte by byte. Providing TomTom hasn't used some strange coordinate system, and has instead stuck with normal latitude/longitude for their reporting, the truth will be squeezed out of it one way or another.

We've been screwing around with ISO audits this week, so I'm going to be a bit jammed for time, but will get back to this and a couple of other projects soon.

 

[mvl]

One of my longer files had lots of repetition. I think it was logging the same coordinates when I was stuck at a stop light, so it may not require any motion to do anything.

When you decode it, try a stationary test far enough from a road so that it doesn't snap. Then you could record the GPS coordinates and compare it to the log's repetition. Since the log is being used to move roads, it should be the unsnapped data you've been begging for.

Edit: I forgot - the tomtom won't snap to road if you mapshare erase (2-way block) all the roads near you.

 

[sageuvagony]

Sadly this could be cause for mallicious attempts at screwing up a road. Here's how someone could possibly screw up a piece of road. I could simply go out for a drive, drive back and forth a few times in a parking lot of a plaza that is parallel to the road, go home, hook up my TomTom to my PC, make a copy of the file 8,000 times, then open TomTom Home, then have it upload all of the files. I wouldn't do such a thing, but I think with enough reports of me driving parralel to the road, TomTom may curve the road in a future map update. I tried copying the file over and over 8,192 times. When I opened Home, it uploaded them ALL. I didn't drive parallel to the road though, so I don't screw anything up. Hopefully each log file NORMALLY has a unique ID number as to prevent doing what I just explained. Weird that TomTom Home accepts all my files though.

Here's a link to the screen shot I just took. I didn't embed the picture because the picture might be a little to large for these forums. When you click the link, click on the pic to fully enlarge it and take a look at the lower left corner. You will see the same file 8,192 times (1 of the files is the one that tells Home to Opt in or out which is why I'm not saying 8,193) What do you guys think of my theory?

http://i19.photobucket.com/albums/b197/sageuvagonyx/muchotripdata.jpg

 

[gatorguy]

You don't have anything to worry about. TA does not add a road only based on tracklogs from anonymous data, tho perhaps that's the impression they they wanted to give. That data is just a part of the "discovery" process. It gives them a heads-up that there might me an area of travel that needs further investigation. Satellite photos of the area might be looked at, a physical visit might be required. While sharing of the data with TT/TA has the potential to make them aware of road changes and additions faster than ever before, other verification is still needed before that new development makes it into a map near you.

 

[sageuvagony]

You don't have anything to worry about. TA does not add a road only based on tracklogs from anonymous data, tho perhaps that's the impression they they wanted to give. That data is just a part of the "discovery" process. It gives them a heads-up that there might me an area of travel that needs further investigation. Satellite photos of the area might be looked at, a physical visit might be required. While sharing of the data with TT/TA has the potential to make them aware of road changes and additions faster than ever before, other verification is still needed before that new development makes it into a map near you.

So my plan to take over the world won't work!?!? Darn!

 

[mvl]

I haven't seen complaints about Alberta since map 830. I'm curious if this process actually fixed it. Do you know anyone who still has these problems?

The Trans-Canada highway looks like it is spot on now on Google maps satellite view through most of Alberta. So I suspect this anonymous data process fixed it. There are some spots in the middle of national parks where it's waaaay off, but I suspect that was due to insufficient data points. Wouldn't be surprised if the entire highway was waaay of in map 825.

I haven't seen any Alberta complaints on this forum since map 830, good sign.