Robot36 为什么能用声音"画"出图像
| 项目 | 内容 |
|---|---|
| 软件 | robot36 |
| 版本 | 2.14 |
| 平台 | Android APK |
| 体积 | 4.72M |
| 分类 | 系统工具 |
| 包名 | xdsopl.robot36 |
| 官网 | robot36 官网 |
| 下载一 | robot36 下载，robot36 下载 |
| 下载二 | robot36 下载，robot36 下载 |
| 文档 | robot36 文档 |
| 介绍 | 一款 4.72MB 的 Android APK，如何通过实时音调解调把无线电里的慢扫描电视音频还原成像素画面。从 SSTV 原理到内部解码链路，拆解 Robot36 的设计取舍。 |
Robot36：把声音还原成图像的解码器
Robot36 是一款跑在 Android 手机上的 SSTV（慢扫描电视）解码器。简单说，它接收到一段带有特定音调模式的音频信号，就能在屏幕上画出一张图来。这件事听起来像魔法，但背后是一套从 1980 年代业余无线电圈发展至今的成熟协议体系。
我第一次接触 Robot36 时最直观的疑问是：为什么一款不到 5MB 的 APK，能实时把一串 2400 到 3000 赫兹的音频信号解调回 320×240 分辨率的彩色像素阵列？ 这个问题的答案串联起 SSTV 的技术本质、Robot36 的解码链路设计，以及它在工程取舍上的每一个选择。
SSTV 的核心设计：图像就是音调
要理解 Robot36 在做什么，得先搞清楚 SSTV 到底传输了什么。传统电视每秒要传 25 到 30 帧动态画面，每帧几百行，需要数 MHz 的带宽。但 SSTV 只传一张静态图，而且带宽只有语音信道那么宽——刚好塞进 2400 到 3000 赫兹的范围。
这个带宽限制决定了 SSTV 的传输速度极慢：一张图要花几十秒到几百秒才能传完。Robot 36 模式是入门款，36 秒一张伪彩色图；PD 290 是高分辨率模式，要 290 秒（接近 5 分钟）才能传完一张 RGB 彩色图。扫描时间越长，颜色精度和分辨率越高，但对信号稳定性的要求也越高。
传输流程可以拆成两端：
发送端把图像逐行扫描，每个像素的亮度和颜色映射成特定频率的音调，合成一段连续的音频波形，通过无线电或线路发出去。接收端拿到这段音频后，需要反过来做：把音调频率解调成像素值，一行一行拼回完整画面。
Robot36 就是接收端的核心解码器。它的整个解码链路可以拆成四个环节：
- 模式识别：检测音频开头的校准头（Calibration Header）——一个 1900 赫兹的长音调，用来判断这是 SSTV 信号还是普通语音，以及匹配哪种 SSTV 模式
- 频偏解调：把每个时间点检测到的音调频率转换成对应的像素亮度值
- 行同步：识别每行像素开始时的 1200 赫兹同步脉冲，对齐像素阵列位置，防止画面倾斜或错位
- 颜色还原：按模式规定的颜色空间（RGB 或 YCrCb）把亮度信息还原成彩色像素
整个过程在手机 CPU 上实时完成，4.72MB 的安装包里装的是一套经过优化的数字信号处理（DSP）算法。
为什么支持这么多模式？协议生态的历史包袱
Robot36 最显眼的一个设计是它支持了十几种 SSTV 模式：Robot 系列、PD 系列（Progressive Downsampling）、Martin、Scottie、Wraase SC2-180，还有 HFFAX 和原始回退模式。这不是功能堆砌，而是业余无线电圈协议生态的历史沉淀。
不同模式的差异在于三个参数：扫描行数、行扫描时间、颜色编码方案。PD 系列是目前最常用的，支持渐进式降采样——接收端可以在信号弱时先收低分辨率版本，等信号变好再补全高分辨率细节。实际通联中常用 PD 120 或 PD 160，在速度和质量之间取平衡。Scottie 系列的特点是弱信号下解码更稳定，因为它的同步头设计对干扰更鲁棒。
Robot36 的设计选择是全部内置 + 自动检测。默认情况下它会先听校准头，自动匹配正确模式。这对新手很友好——不用记住发送端用的是哪种模式。但工程上自动检测有一个硬伤：强干扰或电平偏移会导致校准头音调变形，检测失败。这时候就得手动从模式列表里选，也是 Robot36 右上角菜单存在的意义。
原始模式：兜底方案的取舍
Robot36 里有一个值得单独拎出来讲的设计——"原始"模式（Raw Mode）。这个模式不做任何 SSTV 解码，它直接把接收到的音频信号转换成一张频谱图：X 轴是时间，Y 轴是频率，颜色亮度代表该时间点该频率成分的能量。
频谱图本身不是一张可看的图像，但它能帮你快速判断三件事：这是不是 SSTV 信号、大概是什么模式、信号质量如何。有效 SSTV 的频谱图有非常明显的特征——规则的水平条纹（像素行）、周期性的垂直亮线（行同步脉冲）、左侧一个更长的垂直亮条（校准头）。如果是一团乱麻或随机散点，那大概率不是 SSTV 信号。
这个设计的取舍很典型：它牺牲了直接产出图像的能力，换来了在信号失真、模式未识别、甚至不是 SSTV 信号的情况下，给用户一个可视化的诊断入口。类比一下：你收到一段听不懂的外语录音，正常解码就像"直接翻译成中文"，原始模式则是"给你一张语音波形图"——能判断是哪种语言、语速快慢，但给不了翻译结果。
代价也很明确：原始模式只能输出灰度，无法还原颜色，也无法对齐像素阵列。它的定位就是一个"信号有没有"的快速诊断工具，而不是替代真正的 SSTV 解码。
自动检测 vs 手动指定：便利性与鲁棒性的博弈
Robot36 默认自动识别模式，这对新手是最友好的设计——不用记模式名，开了就能用。但我在实际使用中发现，自动检测的成功率高度依赖信号质量。当通联距离较远、信号有衰落、或者经过多次转接后，校准头的 1900 赫兹音调会被干扰破坏，自动检测就会直接失败。
这时候手动指定就成了唯一出路。从原始模式的频谱图里先看条纹密度（Robot 36 条纹少而短，PD 系列每 2 秒一行，高分辨率模式条纹更密），再看持续时间，大致锁定一个候选模式，手动指定后重新解码。这个过程有点像相机的自动对焦和手动对焦——自动对焦大部分时候够用，但在低光或低对比度场景下，手动对焦反而更快更准。
Robot36 的设计在这两者之间做了一个很合理的分工：自动检测是默认路径，手动指定是鲁棒性兜底。原始模式则是兜底的兜底——当你连信号是什么都不确定时，先看一眼频谱图再决定下一步。
权限设计的克制
一个 4.72MB 的应用，权限申请也做得相当克制。Google Play 上的声明是"不与第三方分享任何数据、不会收集任何数据、遵循家庭政策"——没有网络上传，通联记录和解码图像都是纯本地的。
需要的权限只有三个：麦克风（实时接收 SSTV 音频）、存储读写（保存解码图像到相册 / 从文件导入音频）、Android 10+ 的音频捕获（应用内捕获其他应用播放的音频）。其中音频捕获还是可选的，只有你用到"捕获"模式时才会触发。权限被拒绝的话，Robot36 不会强行闪退，只会在界面上给提示，让你去系统设置里手动开启。
这套设计意味着什么
Robot36 的整个设计链路，从自动检测到手动兜底、从多模式支持到原始回退、从本地处理到最小权限，指向的是一个明确的定位：业余无线电通联场景下的接收端解码器。
它适合谁？业余无线电爱好者做图像通联、学校无线电社团教学演示、应急通信场景下的低速图像传输。一张图几十秒的传输速度在这些场景下完全可以接受——毕竟语音信道的带宽只有那么大。
它不适合谁？需要快速传输图像的场景（几十秒一张对实时协作来说太慢了）、完全不了解 SSTV 协议的用户（即使有自动检测，理解原始模式和手动指定的意义还是需要一点背景知识）、需要跨平台同步的重度用户（纯本地设计意味着没有云端备份和解码历史）。
从一个外行第一次接触 SSTV 的角度来看，Robot36 最有意思的地方可能不是"声音变图像"这个现象本身，而是它展示了一种很典型的工程思维：在带宽有限、环境不确定的约束下，通过分层的设计（自动 → 手动 → 诊断），把一个看似魔幻的技术落地成了一个 4.72MB 的 APK。
本文为个人基于网络公开资料整理编写，非官方内容，仅供学习交流参考；软件版权归原作者所有，请支持正版；使用过程中遇到问题请查阅官方渠道，本文不承担任何责任。
