-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
AP2.0 Cameras: Capabilities and Limitations?
- Thread starter lunitiks
- Start date
Ok, I played with it some more.
At seemingly random intervals a snapshot is taken from all 7 B&W cameras, this is then packed into an archive and pushed to the mothership.
Main and narrow cameras image is sent twice. (speculation: Once is raw, once is processed in some way). In addition a radar snapshot is added.
I did not get to intercept the actual archive sent out yet and it's a bit hard to predict when they would be triggered too. Apparently I live in a place with too fast cell speeds, so the uploads come and go very fast after which the archive is destroyed.
When I say "image" - I am not sure it's actually one too could be tens to hundreds. Certainly need to capture one of these to see what's inside, just going by logging in the code is inconclusive.
Messages inside are also different.
On a different front - looking into cid code some more, lb appears to be related to some sort of gps thingie. "location based" = lb?
At seemingly random intervals a snapshot is taken from all 7 B&W cameras, this is then packed into an archive and pushed to the mothership.
Main and narrow cameras image is sent twice. (speculation: Once is raw, once is processed in some way). In addition a radar snapshot is added.
I did not get to intercept the actual archive sent out yet and it's a bit hard to predict when they would be triggered too. Apparently I live in a place with too fast cell speeds, so the uploads come and go very fast after which the archive is destroyed.
When I say "image" - I am not sure it's actually one too could be tens to hundreds. Certainly need to capture one of these to see what's inside, just going by logging in the code is inconclusive.
Messages inside are also different.
Code:
RAW: Started 2 live cameras and 5 logging_camerasOn a different front - looking into cid code some more, lb appears to be related to some sort of gps thingie. "location based" = lb?
e-FTW
New electron smell
Go to the middle of nowhere, go to a multi-level underground parking lot, or, obviously stick the whole car in a Mylar bag.
Managed to intercept one.
Hm, I guess not so great news for privacy are: the snapshots are random - meaning it does not matter if you are driving somewhere or are parked in your garage - when the time comes, a snapshot is taken and is then sent out. So behave yourself when you are within view of your car cameras... (they might have at least decided not to take the snapshots while parked and within X amount of time since parking was disengaged (and same for E-brake), oh well).
It also appears that if you spend long time parked once the car wakes up it has a high chance of taking a snapshot within a couple of minutes = most likely still in the garage, passengers loading and such (I think ape starts when you approach the car with the fob).
As I suspected from prior data the snapshot consists of .tar.gz with:
Other interesting bits:
It appears that all the camera capture threads have a buffer for last 10 seconds, so when the request for a snapshot arrives we get past 10 seconds, not 10 seconds from request time onward (based on timestamps in the pictures vs request timestamp).
vision code (and I am sure come other bits) has a bunch of "is vehicle crashing" checks together with detection of crashes on al lsides of the vehicle, rollover and such, that when detected also cause a snapshot like above to be generated (possibly with some more data even), so it does work as a dashcam, but only for crash event and only for last 10 seconds (which should be a-plenty for most of accidents).
Don't forget to ask Tesla for this data if you ever need it.
Hm, I guess not so great news for privacy are: the snapshots are random - meaning it does not matter if you are driving somewhere or are parked in your garage - when the time comes, a snapshot is taken and is then sent out. So behave yourself when you are within view of your car cameras... (they might have at least decided not to take the snapshots while parked and within X amount of time since parking was disengaged (and same for E-brake), oh well).
It also appears that if you spend long time parked once the car wakes up it has a high chance of taking a snapshot within a couple of minutes = most likely still in the garage, passengers loading and such (I think ape starts when you approach the car with the fob).
As I suspected from prior data the snapshot consists of .tar.gz with:
- timestamp (not sure of the format, possibly usec from system boot?) , vehicle type, AP board id, whenever you have a developer car or not, serial number of the snapshot (They are numbered so you can know how many were taken by your car), some sha1 hash, snapshot format version (currently 0.3). - in archive_info.json
- raw sensor dumps from 7 B&W cameras - 10 images, once per seconds each. (so basically 1fps 10 seconds clip)
- for main and narrow cams: 10 seconds of images at 30fps (so 300 images in total each) compressed with .h265 (if the filename is to be believed), one frame per file, no headers or anything, so any suggestions on how to display that would be useful.
- Calibration data for main and narrow cameras.
- For main and narrow cams every image (620 in total) is accompanied by radar snapshot.
- image and radar dump filenames are the timestamp when it was taken (usec from boot?)
- can bus dump of some sort.
Other interesting bits:
It appears that all the camera capture threads have a buffer for last 10 seconds, so when the request for a snapshot arrives we get past 10 seconds, not 10 seconds from request time onward (based on timestamps in the pictures vs request timestamp).
vision code (and I am sure come other bits) has a bunch of "is vehicle crashing" checks together with detection of crashes on al lsides of the vehicle, rollover and such, that when detected also cause a snapshot like above to be generated (possibly with some more data even), so it does work as a dashcam, but only for crash event and only for last 10 seconds (which should be a-plenty for most of accidents).
Don't forget to ask Tesla for this data if you ever need it.
This look like an assertion. In their case the expression being tested is often also an error message, that's may be why a piece of code was put into the binary as text.
JeffK
Well-Known Member
the size depends on how well the stuff compresses, I guess. about 160M for the one I intercepted.Thanks @verygreen!
What is the size of the package uploaded?
So they are uploaded continously while driving, not saved for later upload when parked?
They do appear to be uploading while driving, so the ones transferred from the garage on wifi are likely of the garage,
unless the cell connection was slow or one was generated very shortly before returning.
The one I have does not make too much sense to upload.
I might get a better one eventually.
The problem with the radar image is it's unlikely a picture, so I don't really even know how to visualize it.
It's about 4k in size.
Yes, that'a a fair assumption.
Still the text looks too funny to overlook
I don't have access to their source code, otherwise there would be a lot less guesswork.
Well, it's much slower with a lot bigger memory requirements, so perhaps they decided gzip was good enough for them.
JeffK
Well-Known Member
Memory is cheap these days while network bandwidth is still at a premium. One would think they'd want efficient ways to move more data.
I have no idea whatoever what you are talking about.
I added radar.zip along with main and narrow cams from the lake scene from the other day at Box | Simple Online Collaboration: Online File Storage, FTP Replacement, Team Workspaces
The .inputs file has radar data embedded at offset 0x8, size of it is 38968 bytes.
They snapshot like every other hour or some such, so not too terrible of a burden.
Also cpu might be at a higher premium (remember we still need to run vision tasks in parallel + radar inputs and whatnot)
Hm, I am not reversing code blobs so I can't challenge you realistically.
However, I do keep careful watch of the Tesla wifi usage at my home and exactly with 17.17.4 I noticed major upload bandwidth (at 10 Mbps) for many minutes. That's a lot of data. 17.11.3 (my prior version) never did this as I've always been curious about the data usage of the car while parked. My car will do this every time I park it after a day of driving, without fail. I can reproduce it reliably.
My only assumption (based on nothing at all really) was that that much upload could only really be video data.
I know for sure it is purely upload, there is about 100 kbps of download happening simultaneously but ~10 Mbps is pure upload.
Any ideas what that is?
Similar threads
- Article
