If a picture is worth a thousand words, a video must be good for a couple gazillions.
With all the debates about how suitable @Tesla cabin cam for driver monitoring, I will let you form your own opinion.
It does look like "full color" RGB based on the red elements
I was a bit surprised that in a city at night there's enough environment lighting to make DM seem very workable.
All these videos are full resolution, 36 fps as Tesla uses them.
Simulated distracted driver part 1
Simulated distracted driver part 2
Passenger in all seats and moving around a bit
Looks like there's a visor position that allows the driver to fully hide the face from the cam:
If you needed more I have a 17 minutes of night footage uploaded to youtube:
there definitely are times with no lights when you can see nothing (eg ~40 seconds 10 seconds in).
Seems feasible in emergency to light up the driver with the screen.
And also 24.5 minutes of daylight footage uploaded to youtube:
(there's nothing really interesting there unless you are into driver monitoring, I guess, so I totally won't fault you if you won't watch it)
you can see the eyes of the driver, head positioning and such even if the angle is not super ideal. You cannot see if they are holding a steering wheel or look at a laptop on the console (vs infotainment screen).
Unlike Tesla renders, steering wheel is definitely not in the frame
I think compared to "eyes only" DMs, you definitely can get more useful data out. Can probably even detect drunks.
Interesting how much the mirror blocks the passenger seat. I wonder how easily removable is it?
Also I was wrong about rear window view usefullness it seems.
hopefully with this info now out, there's nothing else standing between us and the cabin-camera powered "webcam"
• • •
Missing some Tweet in this thread? You can try to
force a refresh
another replacement battery thread (sorry you'd have to bear with me for some time still as I explore the depths of my misfortune).
So I got the car today and found that Tesla changed the bettery to the -H index pack - the one they use in the LR++ (2020H2 cars), but it's a reman pack
While they of course are totally fine to use remanufactured packs owners hope to not end up in a worse situation than they were before.
In my case this basically means that the degradation of this pack is much worse than the original one I had.
Mine degraded from 96.7 -> 92.6 kWh = ~4.75%
Now I cannot really know what this pack was at when new, but we can pessimistically assume it was exactly at rated advertsed range (typically they are a bit better)
that puts it at 100.5 kWh or better new (I typicaly saw them coming out at 102).
So 100.5 -> 91 is 9.5% degradation.
Got a bit of free time over the weekend and noticed that HW4 size of NNs in v13 ballooned from 2.3G total in v12.x to 7.5G on just node B in v13 (and 2.3g on node A).
(for comparison hw3 is 1.2G node A and 3.1 node B now on v12.6)
So I decided to look some more into it.
Just the same as on the hw3, node B now contains all the "secret" E2E bits that have some extra encryption applied to "protect" it.
Node A has 189 NNs and node B only has 110 NNs and of those 61 are shared between A and B. (so there goes your redundancy)
Interesting to see that there are 135 NNs that are shared between HW3 and HW4 in current releases.
It's also interesting that all those "factory driverless stuff" have a dedicated E2E set of (9 sub)networks which makes me think they might not be entirely as environment-agnostic as some people want to believe. (there are other E2E bits for highway, city streets and destination (for when you approach the destination), all these actually exist in two forms, "normal" and "low speed" (except factory where everything is low speed anyway).
Impressions after nearly 600 miles on 11.4.3 with Elon mode (could not get a non-Tesla car to try in time).
It went much better than the prior experiment obviously.
Many contributing factors. I was not as late so I did not mind as much (still ended up 5 minutes late solely
because of FSD foolishness).
So I was more tolerant towards the constant flow of cars passing me on the right and merging in front of me.
It also helped that I did not need to watch for the dreaded nag.
Overall I spent a bunch of time thinking about it and came up with this:
If the car did not need my attention - I'd just plan for late arrival as much as possible and don't care of many of the current very annoying deficiencies.
They are only this annoying because I actually have to watch the car and so I notice them, as they greatly diverge from my
So I decided to look into how Tesla does alternate routes (I know, late) fully expecting to see they just get a few alternatives from Google and that's it and... nope, there's nothing like it!
Instead they grab a route from google (if online nvigation enabled), and then feed that into tesla maps service (in the cloud). And that maps service returns possible alternatives (deduced by unknwon means). But that's not all!
A lot more interesting is that in addition to that they also query that service for "what are the parking lot outline at my location" and "hey, for this route I have, what else do I need to know".
Now that HW4 is widely available I got some firmware samples and discovered that:
The shipping version is internally called 2-SOC and has two possible camera layouts. The current one or the expanded one with added surround view cams (front bumper and two more)
The cameras run at 2880x1876 and run at( up to?) 45fps.
The main and backup cameras differs from the rest of them (and main and backup are a bit different too). vendor TBD.
new GNSS is Teseo V based.
Radar is confirmed ethernet or 192.168.90.110 internal IP.
But a lot more interesting is the 3-SOC version that seems to be up and coming? The camera layouts for that remain same though some internal deserializing routing differs.
There was a rumor that with the GPU in place heat output increased and HW4 was curtailed, so may be this is