水木社区手机版
- 主题:为什么说特斯拉的行车数据是遮掩的，挑选的，并且美化的
- 我觉得不需要用自己甲方的能力来推测特斯拉这个甲方
在系统更新后，特斯拉上传数据所消耗的流量开始大增，较上月的769MB增长至1.8GB，增幅达到239%
2017-06-15 17:12
https://www.sohu.com/a/149135610_114778
特斯拉 FSD 收集大量数据改进 一天多达 4GB
【 在 moudy 的大作中提到: 】
: 上传是要花钱的。几百万辆车，每辆车每天上传1M数据就是几T的数据。我给厂家做过上传数据的项目，那真是一个字节一个字节的算的，远没有你想的那么舒服。
: 本地滚动啥的说明你不知道车上这些ECU是啥级别。
: 比如当前雷达处理用的S32R274, 对一般的ECU需求来说已经是很nb的CPU了，双核180MHz, 2M（没错2048K)闪存，1.5M内存
: ...................
--
FROM 120.245.28.* - 6点就可以了
【 在 visualarts 的大作中提到: 】
: 何不自信点把大概率三个字去掉？
: 预设立场就没劲了
:
--
FROM 120.245.28.* - 你这帖子是tesla用用户自己家的wifi上传的，你不问他为啥到家才上传？
一般全车最关键的几个信号，方向盘，几个踏板，驾驶模式，雨刷灯光门锁等，100Hz采样的话一秒差不多10K数据，一小时36M数据。差不多一辆车一天100M数据。
【 在 motour 的大作中提到: 】
: 我觉得不需要用自己甲方的能力来推测特斯拉这个甲方
: 在系统更新后，特斯拉上传数据所消耗的流量开始大增，较上月的769MB增长至1.8GB，增幅达到239%
: 2017-06-15 17:12
: ...................
--
FROM 213.95.148.* - 测绘吧。。大旗，细思极恐
【 在 motour 的大作中提到: 】
: 我觉得不需要用自己甲方的能力来推测特斯拉这个甲方
: 在系统更新后，特斯拉上传数据所消耗的流量开始大增，较上月的769MB增长至1.8GB，增幅达到239%
: 2017-06-15 17:12
: ...................
--
FROM 124.64.18.* - 我只回答你存了多少要传的数据，以及反问一些人，多存100M的成本有多高？
你不用套入你做上传的项目背景里，我没说100M都要传，也不讨论这些
总之特斯拉公布了非周期时间点的一些无意义数据，就一定让人怀疑他们有周期性时间点的完整数据
【 在 moudy 的大作中提到: 】
: 你这帖子是tesla用用户自己家的wifi上传的，你不问他为啥到家才上传？
: 一般全车最关键的几个信号，方向盘，几个踏板，驾驶模式，雨刷灯光门锁等，100Hz采样的话一秒差不多10K数据，一小时36M数据。差不多一辆车一天100M数据。
--
FROM 120.245.28.* - 哦，那我确实不了解。
不可以把这些数据先传到车机的磁盘上，然后再用车机程序上传到服务器吗？并且在车机的磁盘上做压缩并滚动保存。上传时，也是上传压缩后的数据。文本的压缩率非常大的，上传原始数据非常不划算。
对车机来说，这些传感器之类也只算是一个外设吧，这样车机从外设读取数据，应该是个非常常规的操作，没有任何难度。
所以我还是想不明白难在哪里了。
上传日志太多确实会导致服务器端压力过大，所以不可能是保持长连接实时上传。所以才需要按定时压缩成包上传。
我也做过互联网公司的日志后期处理，一天几T数据不算太大吧？特斯拉车子现在的保有量也不算大，能上百万吗？百万个客户端应该还不算太多的。
【 在 moudy 的大作中提到: 】
: 上传是要花钱的。几百万辆车，每辆车每天上传1M数据就是几T的数据。我给厂家做过上传数据的项目，那真是一个字节一个字节的算的，远没有你想的那么舒服。
: 本地滚动啥的说明你不知道车上这些ECU是啥级别。
: 比如当前雷达处理用的S32R274, 对一般的ECU需求来说已经是很nb的CPU了，双核180MHz, 2M（没错2048K)闪存，1.5M内存
: ...................
--
FROM 175.190.117.* - tesla对flash是典型的往死里用。这些FSD车主是beta车主，自然更狠的压榨。
ECU项目一个特别重要的就是flash生命周期控制。一辆车要按20年寿命算,64M闪存每秒钟不能超过100K的写入。
现在的新能源平台都大方起来的，终于用GB来配闪存了，就这样Tesla闪存写废了换ECU的事已经出现不少了......
【 在 motour 的大作中提到: 】
: 我只回答你存了多少要传的数据，以及反问一些人，多存100M的成本有多高？
: 你不用套入你做上传的项目背景里，我没说100M都要传，也不讨论这些
: 总之特斯拉公布了非周期时间点的一些无意义数据，就一定让人怀疑他们有周期性时间点的完整数据
: ...................
--
FROM 213.95.148.* - 我觉得tesla有技术能力，车上那个大屏车机也有硬件能力做这个，我也主张他们收集数据，甚至应该一个车机收集常规数据，另一个车机收集其它佐证类数据。比如主车机收集轮上读到的车速，刹车踏板角度，另一个车机收集gps车速，减速度及刹车泵压力之类的。
我就是思考能不能读到
一般车机这些娱乐系统要和刹车等安全性系统隔离开。不然，比如车机被天窗漏雨搞挂了，把刹车总线短路了，那刹车系统就掉线了。安全设计不会允许这种事情发生的。
所以怎么读到准确的数据也是个功夫。
【 在 hellogg 的大作中提到: 】
: 哦，那我确实不了解。
: 不可以把这些数据先传到车机的磁盘上，然后再用车机程序上传到服务器吗？并且在车机的磁盘上做压缩并滚动保存。上传时，也是上传压缩后的数据。文本的压缩率非常大的，上传原始数据非常不划算。
: 对车机来说，这些传感器之类也只算是一个外设吧，这样车机从外设读取数据，应该是个非常常规的操作，没有任何难度。
: ...................
--
FROM 213.95.148.* - 上传数据的地方，应该是在车机系统里吧？如果是这样，那完全没必要把数据写到外设的flash中啊，传到车机中有什么难的吗？保存在车机的硬盘中有什么难的吗？
我很久以前做过嵌入式监测设备里的程序开发，我的数据是直接用程序上传到中心端的，根本不会写到本地flash中。
flash中，我只是把程序烧进去，好像我就没往flash中写什么东西。不知道为什么都十几年过去了，怎么还要往flash中写数据？？？
【 在 moudy 的大作中提到: 】
: tesla对flash是典型的往死里用。这些FSD车主是beta车主，自然更狠的压榨。
: ECU项目一个特别重要的就是flash生命周期控制。一辆车要按20年寿命算,64M闪存每秒钟不能超过100K的写入。
: 现在的新能源平台都大方起来的，终于用GB来配闪存了，就这样Tesla闪存写废了换ECU的事已经出现不少了......
: ...................
--
FROM 175.190.117.* - 哦，这个有道理。可能是这个原因了.
【 在 moudy 的大作中提到: 】
: 我觉得tesla有技术能力，车上那个大屏车机也有硬件能力做这个，我也主张他们收集数据，甚至应该一个车机收集常规数据，另一个车机收集其它佐证类数据。比如主车机收集轮上读到的车速，刹车踏板角度，另一个车机收集gps车速，减速度及刹车泵压力之类的。
: 我就是思考能不能读到
: 一般车机这些娱乐系统要和刹车等安全性系统隔离开。不然，比如车机被天窗漏雨搞挂了，把刹车总线短路了，那刹车系统就掉线了。安全设计不会允许这种事情发生的。
: ...................
--
FROM 175.190.117.*