-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
They don't just seem to be, they are commit hashes, just truncated by git to the nearest unique string length.
The full git commit hash as you'd expect was c52886944369e3a99bbecf0fcbea3edee544e924
So, the problem now is, how will ev-fw, etc, sort these darned things.
. If the last 'section' is the first 8 characters of the commit, as we've been thinking for the last several weeks, they won't sort in chrono order.And, beyond that, other 'normal' releases (the old style) seem to be still escaping. There's that 17.28.103 that just appeared.
Beyond that, there's the point that c528869 is 'really 27' based on what you found looking at the release numbers of the download that came along with the commit string, where it's 27 and also then the commit string seems to overwrite the 'classic' release last section number.
So, are we still working with the 'old numbering' and sometimes something happens to include the commit string to overwrite that?
The "numbers don't convey order" issue was there for some time. Just need t odepend on the time it was first reported since 17.17 lived on with releases when 17.18 first ppaeared so you could not say any 17.18 is newer than any 17.17So, the problem now is, how will ev-fw, etc, sort these darned things.
And, beyond that, other 'normal' releases (the old style) seem to be still escaping. There's that 17.28.103 that just appeared.
Beyond that, there's the point that c528869 is 'really 27' based on what you found looking at the release numbers of the download that came along with the commit string, where it's 27 and also then the commit string seems to overwrite the 'classic' release last section number.
So, are we still working with the 'old numbering' and sometimes something happens to include the commit string to overwrite that?
And yes, the developer version, when included seems to overwrite (sometimes? I only have one sample so far) part of the actual release.
It it was internally also referred to as releases/2017.28, so if you have like 2017.28.4, for example, they possibly wanted to just append git hash to that instead of chopping off the last number?
Hm, digging some more it appears that the githash-tagged release was build from a different branch and that might have triggered the extra logic? I definitely need some more samples, so whoever got this new release, send the data to me to connect more dots together
Love it... thanks for the update! This will definitely be an ongoing saga!The "numbers don't convey order" issue was there for some time. Just need t odepend on the time it was first reported since 17.17 lived on with releases when 17.18 first ppaeared so you could not say any 17.18 is newer than any 17.17
And yes, the developer version, when included seems to overwrite (sometimes? I only have one sample so far) part of the actual release.
It it was internally also referred to as releases/2017.28, so if you have like 2017.28.4, for example, they possibly wanted to just append git hash to that instead of chopping off the last number?
Hm, digging some more it appears that the githash-tagged release was build from a different branch and that might have triggered the extra logic? I definitely need some more samples, so whoever got this new release, send the data to me to connect more dots together
Haxster
Member
Here's the deal:
The "cf" stands for "changed or fixed". The numbers following it are the number of "changes or fixes" made to the last version...
or not
The "cf" stands for "changed or fixed". The numbers following it are the number of "changes or fixes" made to the last version...
or not
Last edited:
HankLloydRight
No Roads
Now I'm completely confused...
@Ingineer added his entry and noted "Internal version shows 17.28.103" so that's what I put in. At this point, I do not know if that's the same as 2017.28.4 cf44833
Also note for EV-FW.com, I removed the space, so it's being stored as: 2017.28.4cf44833
Once firmware numbering stabilizes (*IF* it stabilizes), I'll modify the site to properly store and order the firmware release versions. I can also add an internal ordering number if they can no longer self-order.
To me it seems that the first part (2017.28.4) is supposed to be sortable (year, week, build# maybe?), so it might be better to keep it separate from the commit hash.
HankLloydRight
No Roads
As I said, I'm not going to change the system every week another different release format comes out. When I have all the data, I'll fix it once.
The "numbers don't convey order" issue was there for some time. Just need t odepend on the time it was first reported since 17.17 lived on with releases when 17.18 first ppaeared so you could not say any 17.18 is newer than any 17.17
And yes, the developer version, when included seems to overwrite (sometimes? I only have one sample so far) part of the actual release.
It it was internally also referred to as releases/2017.28, so if you have like 2017.28.4, for example, they possibly wanted to just append git hash to that instead of chopping off the last number?
Hm, digging some more it appears that the githash-tagged release was build from a different branch and that might have triggered the extra logic? I definitely need some more samples, so whoever got this new release, send the data to me to connect more dots together
Not looking at the code, but I was suspecting that these releases with the git hash were from a different branch too. The radar seems to have reverted to its pre-8.0 state where it only sees one car in front (not two), but AP2.0 is clearly also seeing traffic in adjacent lanes now too. I honestly think they merged in some AP1.0 logic to get the steering smoother and we lost some radar functionality.
whttiger25
Member
Used it a little today. Can't say I noticed any real difference, if at all.
nah, that was in the previous one, you can see they bolstered some defenses in 17.28.27 c528869 which makes my life a bit harder.
though I guess there are more ways to up the ante still.
StefanSarzio
Member
Speed-dependent audio volume would be great. I already requested that by writing to the Tesla service email address. I hope many people do.
I can almost guarantee this firmware being pushed is to fix this:
Tesla Model S Hackers Return for Encore Attack
Tesla Model S Hackers Return for Encore Attack
Not only should we have speed-adjusted audio volume - we should also have separate volume for each input source.
With BT devices, the volume is adjusted on both the device and the car, and unless you turn the volume of the device all of the way up, you end up increasing the volume in the car's media player. And then when you change to another source - such as radio or USB, the volume is way too loud. If the media player remembered the volume level by source, we wouldn't have this issue...
Similar threads
