最优条纹频率怎么选：从误差公式到标定与推荐算法
增加条纹数量，相同的位置变化会产生更大的相位变化，按理说更容易测准。可条纹太密时，相机看到的明暗起伏又会变弱，甚至接近噪声。到底该选哪一个频率？ 不能只挑画面最清楚的，也不能把别人的“最优 88 个周期”直接填进自己的设备。需要先测出系统在各个频率下的调制幅值，再把它与位置灵敏度放在同一个误差模型里比较。 这篇沿着“推导目标 → 采集标定数据 → 拟合 → 搜索 → 实测验收”展开。主线是扫描式条纹投影的窗口平滑模型；有关数据筛选、全局误差优化和近优集合的做法，会明确标为工程扩展。所有曲线都是本文公式计算的教学示意，不冒充硬件实验结果。 如果还不熟悉背景亮度 A、调制幅值 B、包裹相位和相位展开，可以先看条纹测量基础：相移、展开与深度学习。这里不再重复整套基础，重点回答频率怎样选。 先说清楚：选的是条纹数量，不是相移步数 量 本文记号 含义 条纹数量 f 规定投影范围内的完整周期数 空间频率 ν 单位空间长度内的周期数 条纹周期宽度 T_f 一次“亮→暗→亮”占据的长度 相移步数 N 一组相移图像的张数 投影帧率 fps 每秒投出多少幅图案 若投...
从条纹到三维：相移、相位展开、深度学习与激光线宽
把明暗条纹投到一个石膏头像上，相机能看到鼻梁、卷发和脸颊上的条纹发生变化。接下来怎么把这些亮度值变成三维坐标？ 这件事最容易混淆的地方，是把“求出相位”“确定条纹编号”和“恢复三维位置”当成同一个步骤。再加上单帧解相、CNN、U-Net、MEMS 这些名词，原本的一条测量流程很快就变成了几组不相连的概念。 这篇从一个像素的亮度开始，把它们重新串起来。先手算四步相移，再解释相位展开和学习型解相，最后回到投影端：激光线为什么会把条纹抹平，条纹又为什么不是越密越好。只需要知道正弦、余弦描述周期变化，不需要先学过光学或神经网络。 先看整条测量流程 图中是功能流程，不是某一套装置的光路图。传统相移和学习型解相是两条可选路线；相位展开、几何标定仍需分别处理。 条纹投影轮廓术（Fringe Projection Profilometry，FPP）是一种结构光测量方法。投影器主动给物体加上已知规律的明暗标记，相机从另一个位置观察这些标记，再利用它们之间的几何对应关系恢复表面形状。 结构光（Structured Light）是更大的概念。正弦条纹、点阵、格雷码、随机散斑都可以作为光学编码。这里...
校园网路由器 IPv6 中继长尾：一次卡顿的定位与优化记录
症状有三条：抖音视频能播但评论一直转圈，图片偶发加载失败；游戏延迟显示绿色但操作有滞后；部分网站整页打不开，刷新后恢复。 设备是小米 BE5000（固件 1.0.91），电脑走网线。此前一轮报障已经把校园网出口拥塞定为主因，结论写着”与用户侧设备无关”。 实际结果是两件事叠加：校园网出口分方向异常仍然存在，用户侧修不了；直接造成本次卡顿的是路由器自己的 IPv6 中继。关闭路由器 IPv6 后，50 路并发的最大 TCP 建连时间从 2504 ms 降到 243 ms。 一、分层定位第一轮只做只读测量，不改配置。 层 测什么 结果 网卡 协商速率、错误与丢弃计数 1 Gbps 全双工，计数全 0 电脑 → 路由器 100 包 ping 192.168.31.1 全回，平均 1 ms，最大 3 ms 路由器 → 校园首跳 10.10.30.13 1 ms，0% 丢包 出口分方向 电信、联通、移动、教育网各一个靶标 电信 4 ms、联通 11 ms 正常；移动 29 ms、教育网 39 ms 偏慢 DNS 四个 resolver 各查 5 次计时 1–...
基于 ESP32-C3 的校园网自动认证：从协议分析到实机问题排查
宿舍校园网采用深澜（Srun）认证，掉线频繁，每天早晨恢复供电后需要手动登录一次。为解决这个问题，我用一块十几元的 ESP32-C3 实现了自动认证。 整体思路是：开发板以 STA 模式接入路由器 WiFi，周期性探测网络连通性，检测到掉线后按浏览器的行为完成一次门户登录。校园网认证按 IP 生效，路由器工作在 NAT 模式，因此开发板完成认证后，局域网内所有设备一并恢复联网。路由器无需刷机，也无需安装插件。 一、协议分析：掉线判定与登录流程编码之前，先在已认证的电脑上抓取门户请求，确认几项事实。 掉线判定是第一个关键点。门户劫持时 generate_204 返回 200 与一段 HTML，并非常见的 302 跳转。判定逻辑因此必须只接受 204，返回 200 一律视为掉线。 登录流程为标准 Srun 三步：查询状态、获取 token、提交登录。密码经过 HMAC-MD5，info 字段使用自定义 xencode 与变种 base64，最后附带 SHA-1 校验和。完整接口如下： 1234567连通性探测 http://connect.rom.miui.com/gen...
免费 LLM API Key 渠道清单（转载留存）
这篇是转载留存。原始整理来自 BIGFA 的 免费 API Key 渠道分享 | 持续更新（原文最后编辑 2026-08-26），我按三类重排成表格存一份在自己这儿，免得哪天原站或这些渠道链接失效就找不回来了。推荐指数沿用原作者的评级，我没有逐个实测。 一、免费用高端模型（数据可能被蒸馏） 渠道 说明 入口 原文评级 JustDoWork GitHub 注册，每日签到送额度 https://api.justwoker.icu/register?aff=N7Su ⭐⭐⭐⭐⭐ Agent Router GitHub 注册，每日签到送额度；签到需退出再登录才生效，只支持 Codex 和 Claude Code 原生调用 https://agentrouter.org/register?aff=o0ML ⭐⭐⭐⭐⭐ Jasper 免费分组不消耗积分，等于白用 https://api.yjs.im/sign-up?aff=UiTe ⭐⭐⭐⭐⭐ TaBiAI GitHub 注册，每日签到送额度 https://tabitoken.com/sign-up?aff=A9...
PyStudio Termux 构建踩坑记（四）：Android 私有目录里的路径、npm、pip 和 proot
这篇讲的是 PyStudio 运行时最容易被低估的一类问题：文件都在，命令也能看到，但脚本、解释器、动态库和 prefix 仍然可能指向错误位置。Termux 官方环境里能跑，不代表搬到 Android App 私有目录后还能跑。 我把它拆成几条线：shell 内建命令和外部 ELF 的差异、npm/pip 动态产物的 shebang 兼容、自家包和官方源包的边界，以及 proot 这种 syscall 敏感工具为什么必须单独验收。 只要 prefix 变了，脚本、wrapper、ELF loader 和动态库路径都可能跟着出问题。 为什么 pwd 和 cd 正常，ls 和 pkg 却卡住最早的现象很迷惑：新 app 里运行 pwd、cd 反应很快，但 ls、pkg 回车后没有反应。 后来回头看，这个现象其实很典型： pwd、cd 多数时候是 shell 内建命令。 ls 是外部 ELF。 pkg 是脚本和包管理逻辑。 内建命令能跑，只能证明 shell 基本活着。外部命令卡住，可能是： ELF loader 路径不对。 动态库查找路径不对。 sheban...
PyStudio Termux 构建踩坑记（三）：Gitee、ModelScope 和 Cloudflare Pages 清单站
这篇讲下载入口怎么从“找个国内仓库放一下”变成一套更清楚的镜像架构。最早我想用 Gitee 做国内镜像，后来发现它适合轻量文本，不适合承载大量 release 附件和工具链包。 最后的分工更明确：GitHub Release 保存权威产物，ModelScope 承担大文件镜像，专用清单仓库保存 JSON，Cloudflare Pages 对外提供清单站。清单越轻，大文件镜像越独立，后面才容易按区域优化。 Gitee 的问题不是不能用，而是不适合在这套系统里承担大文件镜像角色。 Gitee 方案为什么失败一开始选 Gitee 的理由很直接：大陆访问速度更好，轻量 JSON 清单应该很适合放上去。 实际踩坑后发现，Gitee release 附件有几个限制： 单个附件大小有限制。 仓库附件总容量有限制。 大量 .deb 或工具链压缩包会很快逼近上限。 上传失败后重试成本高。 比如 C/C++ 工具链压缩包很容易超过 100 MiB。即使某些项目等级能放到更大的单文件，也挡不住总容量限制。把构建产物全推到 Gitee，不是长期方案。 所以 Gitee 只适合“轻量...
PyStudio Termux 构建踩坑记（二）：像 Termux pkg 一样拆包，而不是发布工具链大包
这篇是 PyStudio Termux 构建系列的第二篇，主题是包管理模型。工具链大包一开始很诱人：用户要 Python 就下 python-toolchain，要 Node 就下 node-toolchain。但很快会遇到重复依赖、粗粒度更新、构建失败难定位和版本不可追踪。 最后更接近 Termux/TUR 的路线：一个包一个版本，四个架构对应四个 .deb，每个架构有自己的 Packages.xz。App 侧不必完整复刻 apt，但至少要有一个能解析依赖、跳过已安装包、校验下载结果的轻量 resolver。 文件数量变多不是坏事，失去索引才是坏事。 大包方案的坑大包方案一开始很自然： 1234python-toolchain-aarch64.tar.gznode-toolchain-aarch64.tar.gzcpp-toolchain-aarch64.tar.gzdebug-tools-aarch64.tar.gz 用户需要 Python，就下载 python-toolchain。需要 Node，就下载 node-toolchain。看起来简单，app ...
PyStudio Termux 构建踩坑记（一）：从 bootstrap 大包到可维护构建体系
这篇是 PyStudio Termux 构建系列的第一篇，也是一开始方向转弯最大的一篇。最初我们想直接打一个“什么都有”的 bootstrap，后来发现能编译一次不等于能长期维护。真正的问题不是 CI 多跑几次，而是 bootstrap 承担了太多职责。 后来路线变成：bootstrap 只做基础环境，工具链拆成可选包，包索引负责依赖，清单站负责发现，大文件镜像负责下载。这条线一旦拆清楚，后面 Python LSP、C++、debug、proot 才有地方放。 这张图是这个系列的底图：bootstrap 越小，后续包管理和镜像策略越有空间。 最早的问题：能编译不等于能长期维护最开始的目标很朴素：给 PyStudio 打出一个能在 Android App 私有目录里运行的 Termux 风格环境。能运行 pwd、cd、ls、pkg、python、pip、node，再逐步加上 C/C++、LSP、debugger、proot、distro 这些能力。 早期方案有几个典型坑： bootstrap 成功解压，不代表命令都能跑。 pwd、cd 这类 shell 内建命令...
Sora Editor 上做代码高亮和纠错：Tree-sitter、LSP 与终端包的边界
PyStudio 编辑器这条线最容易混淆三个东西：APK 里给 Sora Editor 用的 Tree-sitter native library、终端里用户能运行的 tree-sitter CLI，以及真正做诊断、补全、Quick Fix 的 LSP server。 它们都和“代码智能”有关，但不是一层能力。终端里 tree-sitter --version 能跑，不代表编辑器高亮生效；Tree-sitter 接好了，也不代表会有语义纠错。把这几条边界画清楚，后面才知道该修 APK native、运行时包，还是 editor-lsp。 这张图先把三层拆开：结构解析、终端工具、语义服务分别解决不同问题。 Tree-sitter 解决的是结构，不是语义Tree-sitter 很适合做增量解析和结构化高亮。对编辑器来说，它能回答： 这是关键字还是字符串； 当前光标在函数、参数、代码块还是注释里； 改了一行后如何增量更新语法树； 是否能基于语法节点做缩进和简单补全。 但它通常不能单独回答： 这个变量有没有定义； 这个函数参数类型是否正确； 这个 import 是否缺包； ...