TMC is an independent, primarily volunteer organization that relies on ad revenue to cover its operating costs. Please consider whitelisting TMC on your ad blocker and becoming a Supporting Member. For more info: Support TMC

HW2 Anonymous Snapshot

So today I was able to capture one of the anonymous snapshot/image/video uploads that got pushed out over my home network. The file was uploaded via cleartext HTTP post to Amazon s3, file name of snapshot-cc2ae3b6-b884-42f2-9c18-be531f34cfcf-0000.tgz. It was 40MB in size, ~80MB uncompressed. Some files named like this: "892383829920.img.data.h265", others like this "890192887360.img.data" in a path named img\replay and img\main in that tarball.

So far, only partial success in getting anything useful out of it. One example is below. Seems to be stills, as far as I can tell. Not all files are decoding. There are some files that are larger, but the format is eluding me so far. There was also a snapshot.can file in a path named \var\log\canrx in the tarball, which I suspect is a capture of the CAN bus data for a brief period, but still working on that too. Might need to re-examine the capture, as there were re-transmissions and some out of order packets in the stream. Might be causing some of the problems.

So, not sure if I'll be able to get anywhere else with this, but it was interesting!

This looks like something else other than a random snapshot that are typically bigger and incorporate all cameras (~150-200M compressed).
Did you trigger FCW on that trip? That matches more the footprint you have. There's an archive_info.json file in there that lists the requester and that's how you know what triggered that particular snapshot (FCW for FCW, random for random snapshots and so on).

If I could freakin figure out how to change the title of the thread I would add something like (maybe) to the anonymous part, since it seems suspect at this point.

Click to expand...

btw there's another clue.
If wall-time time is same as monotonic-time (first 10+ digits anyway) - it's an anonymous snapshot, otherwise it's not.

Every time APE turns on it creates a "log snapshot", so if you catch that you can get some interesting info in there too, e.g. in the telemetrypackager logs you can see what requests were pushed to the mothership, how often were they to trigger and such.

To trigger APE start: do the car poweroff thingie from CID display, all screens turn dark, don't touch anything for 70 or so seconds until you hear a loud fan from gloves compartment that dies down after about 2 seconds or so. Now your APE is off. Touch the screen or otherwise wake the car: now APE would wake up and generate the logs snapshot to be sent to the mothership.

Okay, here's the full archive_info. Wall-time and monotonic time are massively different. They seem like different date formats entirely. wall-time is obviously a unix ns timestamp and matches my drive this morning. monotonic and request-trigger are not obvious. Do you know something about the format/reference for them, verygreen?

monotonic-time is ns time since last boot. It's also used in filenames for camera snapshots.
wall-time is unix ns time as you correctly indicated.
request-trigger-time is when it actually triggered (also relative to boot time).
anonymous snapshots masquerade wall-time as truncated monotonic time based on a sample I have. Or actually I might be wrong about it and it was just a coincidence they were close enough and I did not look carefully.

Granted, I guess all request names are pushed from the mothership so they don't need to remain in this same format forever, they can also change what info they request.
But when I was tracking it, they did request every camera and the requests were numbered every time with a probability trigger.
You really need to look into your logs to see what exactly was it requested from your car with what sort of a trigger.

Granted, I guess all request names are pushed from the mothership so they don't need to remain in this same format forever, they can also change what info they request.
But when I was tracking it, they did request every camera and the requests were numbered every time with a probability trigger.
You really need to look into your logs to see what exactly was it requested from your car with what sort of a trigger.

Click to expand...

I've read the disassembly code of snapshot_trigger_client and found it receives some data from Hermes and write it in the /home/telemetry/triggers.json, but I don't think the Hermes could send "FCW_sparse" requester to the trigger because it could not know the FCW was triggered, so I'm confused that who send the "FCW_sparse" requester to snapshot

I've read the disassembly code of snapshot_trigger_client and found it receives some data from Hermes and write it in the /home/telemetry/triggers.json, but I don't think the Hermes could send "FCW_sparse" requester to the trigger because it could not know the FCW was triggered, so I'm confused that who send the "FCW_sparse" requester to snapshot

Click to expand...

triggers.json is stuff from hermes - i.e. from mothership - those are timed, so cannot really be triggered on FCW or other such sporadic events.
In addition snapshots could be requested by other parts of the autopilot code automatically/internally. if you read around you'll see in addition to FCW there's all sort of crash detection that also triggers a snapshot.

Meta

Do you value your experience at TMC? Consider becoming a Supporting Member of Tesla Motors Club. As a thank you for your contribution, you'll get nearly no ads in the Community and Groups sections. Additional perks are available depending on the level of contribution. Please visit the Account Upgrades page for more details.