2025-05-14 09:33:00
如果你畅游社交网络的汽车区,经常有人分享“增程车的增程器就是个充电宝”这样的观点,更有甚者,觉得“1.0L, 1.5L 1.5T 都可以做这个充电宝”。这些排量+是否有涡轮增压的发动机都可以做增程器是不假,但很影响用车体验,并且和车的设计以及定位密切相关,如果是一辆通勤代步小mini车,整车不到4米长,高速需求少,那么增程是非常理想的方案。但是我看大部分买了某 6 7 8 9,以及另一个某8 9 车型的人,是经常跑高速的,这种如果不讨论燃油经济性,也会造成他们的电池很快跑完“可用”循环,并且长时间大功率放电会加速这些电池的衰减。
我从一个点切入,你就知道 1.5T 增程器用在“百万豪车”为何不妥了。
当电池电量 30% 时,三元锂电池整包的放电功率大概只有满电时的60%~70%,如果此时用户正在从【泸定县城】爬往【折多山垭口】,这个例子太具体了,我们换成高速上紧急加速场景。某增程车?6
(?代表一个字符)欣旺达三元锂电池包 36.8度,我查到他峰值是8C的放电倍率(几乎只能维持10+s),但是高负载(能扛住长时间大功率需求)时放电倍率只有3C,满电时放电能力有294.4kW,那么30% SOC 时候放电功率只有 110.4kW,无法满足此时的功率需求。
还有一个重要的点,也许很多人知道但是忽略了,电池包同一时间只能进行充电/放电,不可能既在放电又能充电的。
所以上面的场景下,很大可能是发动机+电池共同出力满足电机需求的。发动机 -> 发电机 -> 驱动电机,如果此部分功率不够,整车系统还会继续从电池中取功率喂给驱动电机。
这部分的能量传输路径是:发动机 - 发电机 - 交流电转直流电(AC to DC)- DCDC控制器 - 直流电转交流电(DC to AC)- 驱动电机 - 减速器/差速器 - 车轮。
能量转换图
发动机 → 发电机(AC) → 整流器(AC/DC) → 高压直流母线 → 逆变器(DC/AC)→ 驱动电机
↓
DCDC(DC/DC)→ 12V系统
所以增程车的增程器只是个充电宝吗?不是,某种意义上他也会参与“直驱”,但是他“直驱”的形式是通过曲轴带动发电机发的电驱动车轮前进。
我们在讨论直驱时,到底是在讨论什么?插混直驱就是发动机曲轴的力通过一些机构直接作用在车轮上,而不经过上面那一大串路径了。城区低速场景,功率需求比较低,大部分时间功率需求都在100kW以内,纯靠电池就能提供,这时候插混和增程是一样的,都是在合适的时间启动发动机专门发电,然后部分功率用于驱动,剩余功率充进电池。
2025-05-12 22:28:00
龙虎巷的高大梧桐树今年被政府砍断了,原本颇有老街风貌的街区瞬间失去了一些色彩,但这里依然还有很多魅力,昨天带上索尼 FE 35mm F1.8 去拍了几张照片,特此分享。
还遇到一个大爷,骑着电瓶车就来我跟前,“小伙子来摄影呀”,还颇健谈,和我讲以前浦镇的神话,甚至邀请我去他家喝酒…… hhhh
2025-05-12 15:46:00
今天看B站动态当中的配图文件格式是 AVIF,瞬间起了兴趣。
然后才发现我的博客这么多图片我一直还在使用 MozJPEG 格式压缩的,虽然 MozJPEG 压缩率已经很高了,但看到更先进的算法不由得还是心动了,于是决定进行一些研究和寻求一些改变。
Squoosh 是 Google chrome labs 推出的,他支持压缩成 AVIF, MozJPEG, BrowserJPEG(就是标准JPEG), WebP 等格式,我一直用他压缩图片。他是开源的,源码在 https://github.com/GoogleChromeLabs/squoosh 支持这么多压缩算法
Squoosh各种压缩算法对比表
算法名称 | 核心技术 | 优势场景 | 劣势 | 兼容性 |
---|---|---|---|---|
AVIF | AV1视频编码 | 超高压缩率(50%+),支持HDR/广色域 | 编码速度慢,旧浏览器不支持 | 需现代浏览器 |
Browser JPEG | 传统JPEG | 快速压缩,广泛兼容 | 压缩率/画质均低于优化算法 | 全平台兼容 |
JPEG XL (beta) | 新一代JPEG | 渐进加载,兼容传统JPEG,超高画质保留 | 尚处beta阶段,生态未普及 | 实验性支持 |
MozJPEG | 优化版JPEG | 比传统JPEG节省20%-30%体积,兼容性好 | 无法突破JPEG格式限制 | 全平台兼容 |
WebP | Google VP8 | 比JPEG小30%+,支持透明通道 | 部分旧设备不支持,不支持渐进加载 | 主流浏览器支持 |
WebP v2 (unstable) | 升级版VP8 | 比WebP体积更小 | 不稳定,可能产生画质异常 | 实验性支持 |
(注:PNG相关算法未列入主推荐,因PNG格式不适合照片压缩)
我的目标是占用存储空间小(用户访问文章图片加载也会更快),画质能接受不能太差,所以最好的方案是 AVIF,但是兼容性差,图床支持也不行。
最佳选择是这样的 优先级排序:AVIF > WebP > MozJPEG
质量等级 65-75
,开启 色域保留
选项。质量等级 75-85
,勾选 自动滤镜优化
。质量等级 75-80
,开启 渐进加载
提升感知速度。下面实测我拍的一张南京长江大桥图片,分别使用 AVIF, MozJPEG, WebP 压缩,每种压缩算法均使用 Squoosh 默认压缩选项,来比比看吧
可以看出,MozJPEG -> WebP -> AVIF 压缩率逐步提升,文件体积不断减小,我看了一下画质均在可接受范围内,其中 WebP 我勾选了【Auto adjust filter strength 自动调整滤镜增强】(不会影响压缩率和文件体积,只会影响画质),一个表格来表达
算法名称 | 压缩率 | 压缩后文件体积 |
---|---|---|
MozJPEG | 88% | 1.09MB |
WebP | 91% | 812KB |
AVIF | 95% | 419KB |
从表格可以看出 AVIF 压缩率和新文件的文件体积都遥遥领先,这正是未来趋势。不过使用 AVIF 压缩时间很久,电脑风扇也会呼呼转,这也是代价。
我使用的图床是 Lsky Pro,不支持 avif,开源版本目前也不会迭代了,更不会增加新需求。综上,我今后将使用 WebP 作为图床图片的格式,虽然比 MozJPEG 也没有强多少,但是总归是要更好的。
2025-04-25 17:18:00
我分享这个 flow 是因为我有分享视频中片段的需求,但是又不想用相机拍摄,相机拍摄效果可能也不好。下载下来再裁剪又太麻烦。尤其是我喜欢看车祸警示录,有时候看到某些事故非常搞笑,我就用这个手段录制下来,视频可能就10s,30s,然后再微信分享,就很 nice 了。如果是分享10min的完整视频那种,就不如直接贴链接,或者直接下载下来再分享,不需要使用本文方案进行录制。
你是否会因为难以下载 YouTube, X(Twitter), 小红书, Instagram, 微博 之类的网站上的视频而发愁呢……虽然下载这些网站的视频大多都有在线工具或者命令行工具,可以在 GitHub 寻找。
但是目前经过我的日常使用,小红书和微博上的视频资源不是很轻松就能下载下来,或者下载用时很久,还可能下载下来文件太大(比如下载时无法执行码率和分辨率),不利于再次分享。
我为了解决这个问题,一开始使用了 NVIDIA Geforce Experience,但是这个只能录制屏幕的完整内容,如果想要录制屏幕当中的某一块区域,英伟达这个软件就不行了。
于是转而使用 Obs Studio。下面这段介绍来自 DeepSeek V3
OBS Studio(Open Broadcaster Software)是一款免费开源的跨平台直播和录屏软件,广泛用于游戏直播、教学演示、视频创作等场景。以下是其核心特点:
官网下载:OBS Project
社区活跃,遇到问题可通过论坛或GitHub快速解决。适合追求高自由度、零成本的用户。
我在使用 Windows 11 电脑。安装好 Obs Studio 之后,打开软件,进行初始化配置,我不直播,所以只进行了 recording 录制相关的初始化,最后 apply settings,应用设置。
添加源。我拿录制B站车祸警示录的视频举例,使用 edge 浏览器播放B站视频,那么来源选择【窗口采集】,选中正在运行的 edge 那个窗口,标题前缀是 [msedge.exe]
,
如果不想录入当前电脑麦克风的声音,请将 Mic 给静音。
此时会录制整个窗口的画面,如果想录制视频播放区域,需要添加一个裁剪/填充
的【滤镜】,如下图,设置好距离左,顶部,右,底部的像素数量关闭即可。
在开始录制前确保输出的视频画面充满整个画布,勾选使用此源的尺寸作为输出分辨率 (重要重要!否则输出的视频可能有很多“留黑”空白区域)
最后再点击【开始录制】,同时播放 edge 浏览器窗口的视频,在视频结束时(或者你想截取的视频片段刚好结束)点击【停止录制】。
最终录制视频呈现的质量,设置项在 【设置】->【输出】->【录制】->【录像质量,录像格式,视频编码器,音频编码器,音轨】等配置。
建议录像格式使用MPEG-4,方便传播,比如微信就可以直接预览 mp4 视频。
2025-04-25 13:40:00
使用了这个插件: https://github.com/zyuzhi/MarkdownKatex-typecho ,下载了 v1.0.1
,但是点击创建文章之后无法返回所有文章页面。另外博客首页也无法加载,禁用插件即恢复正常。懒的去追究原因了,索性不用插件改用其他方法。
我家里的一台机器也部署了 typecho,同样都是 docker compose 部署的,和当前 typecho 实例的区别大概就是
v1.2.0
vsv1.2.1
。家里机器上的 typecho 是 1.2.0,当前实例是 1.2.1,有可能是版本升级导致的原有插件失效,因为上述插件 GitHub 源代码是2018年左右最终打包到 release 发行的。
在 typecho v1.2.1
实例上测试如下方法可以为 typecho 博客添加 latex 支持。
方法参考: https://www.xrgzs.top/posts/typecho-use-mathjax-add-latex-support
将以下代码添加到 header.php 的适当位置。我这个主题这个文件在 components/header.php
。
<script async type="text/javascript"
src="//cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>
<script type="text/x-mathjax-config">
MathJax.Hub.Config({
extensions: ["tex2jax.js"],
jax: ["input/TeX", "output/HTML-CSS"],
tex2jax: {
inlineMath: [ ['$','$'], ["\\(","\\)"] ],
displayMath: [ ['$$','$$'], ["\\[","\\]"] ],
processEscapes: true
},
"HTML-CSS": { availableFonts: ["TeX"] }
});
</script>
注意:footer.php
中就不需要重复引用这个 script 了。
物体所受合外力 $\mathbf{F}$ 与其加速度 $\mathbf{a}$ 满足:
$$ \mathbf{F} = m\mathbf{a} = \frac{d\mathbf{p}}{dt} $$
其中:
两个质点间的引力大小:
$$ F = G\frac{m_1 m_2}{r^2} $$
式中普适常量: $G \approx 6.674 \times 10^{-11}\, \mathrm{m^3 \cdot kg^{-1} \cdot s^{-2}}$
2025-04-25 13:15:11
以下是我和DeepSeek R1的对话
新能源汽车使用7kW 交流慢充和外面的直流快充,哪个充电时损耗更高?7kW 交流慢充的电流大概30A,44度电池大概需要7个小时;使用外面直流快充桩,假如功率是70kW,充满需要1小时,但是充电电流最大180A左右。请计算一下哪种充电方式电损耗更多?
在比较新能源汽车使用7kW交流慢充和70kW直流快充的充电损耗时,需综合考虑线损和转换效率。以下是关键分析步骤:
在合理假设下,直流快充的总损耗更低(约3kWh),因其转换效率更高且充电时间短。但若按用户提供的错误数据(快充输入70kWh),则损耗更高,此情况不符合实际。实际使用中,快充是更高效的选择。
我给出的快充功率70kW,但实际充电功率并不是恒定70kW 呀,功率会随着电池soc的增高而降低的。所以快充充满一般都需要1小时。请再计算看看
在考虑快充功率动态变化的情况下,重新计算两种充电方式的损耗如下:
指标 | 直流快充(动态功率) | 交流慢充(7kW) |
---|---|---|
总损耗 | 约2.54kWh | 约5.55kWh |
损耗比例 | 5.8%(44kWh电池) | 12.6% |
核心原因 | 转换效率高(95%)、时间短、线损低 | 转换效率低(90%)、时间长、线损高 |
即使考虑快充功率随SOC动态下降的情况,直流快充的总损耗(约2.54kWh)仍显著低于交流慢充(约5.55kWh)。核心原因在于:
实际建议:若需减少充电损耗,优先选择直流快充;若考虑电池寿命,可适当使用慢充平衡。