企业官网建设流程全解析

上个月我做了一台三录仪。拿到户外，晚上它突然开始“哔哔”地响，屏幕上展开一条正在漂移的频谱曲线，一个红色圆点沿着预测轨迹划过星空——那是一颗 Starlink 卫星从头顶低轨飞过。这个项目的英文名字叫“Maker Creates a Tricorder to Detect Starlink Satellites”，网上的讨论大多聚焦在“科幻成真”的浪漫想象上，但真正动手做过的人都会明白：把一个掌上探测器从想法变成现实，里面值得拆解的技术细节，远比新闻标题能呈现的多得多。这篇文章不是复述新闻，而是把我从零到一搭建这台“卫星探测三录仪”的完整过程、核心原理、硬件选型、软件算法和实测数据一次性整理出来。无论你是玩 SDR 的老手，还是刚开始接触卫星通信、开源硬件的创客，都可以从中找到可以直接复制的思路和该避开的坑。

1. 从科幻道具到真家伙：这个创客项目到底要做什么

1.1 Tricorder 的幻想百年，这次偏偏盯上了卫星

Tricorder（三录仪）最经典的形象出自《星际迷航》系列，它像一把灰色的小梳子，随手一挥就能读出生命体征、地质成分、辐射水平等各种环境数据。现实世界里的“三录仪挑战赛”被医疗诊断方向主导了很多年，参与的团队动辄上百人，光学、超声、生化传感全都要塞进一台手持设备里，门槛极高。我作为一个独立创客，想把这个概念落在更容易验证的领域，于是选择了卫星探测，尤其是肉眼看不见但在大量过顶的 Starlink 星座。

选择 Starlink 作为目标有很现实的原因：它数量多、轨道低、下行信号特征相对明显，而且每天过顶时段可以预测。这样一个目标能同时考验射频接收、频谱分析、多普勒判向、轨道预测和交互设计五条技术线，非常适合用来做一个“有科幻感但工程上可完成”的项目。

1.2 探测目标拆解：什么才算“探测成功”

在设计之前，我先定义了四个可量化指标，避免项目变成一团随时膨胀的毛线球。

• 信号捕获时间：卫星进入视场后，设备应在 5 秒内从茫然状态切换到“疑似目标”状态。
• 频段覆盖策略：至少覆盖 UHF/VHF 常见卫星频段，并预留 Ku 频段下变频口。
• 便携与续航：整机重量控制在 800 克以内，连续运行不低于 2 小时。
• 独立工作：不需要手机、不需要联网，所有信号处理在设备本地完成。

这些指标看起来平常，真做起来才发现，想要在手持设备上同时满足“看得快、猜得准、能户外用”三个条件，很多环节都得反复取舍。比如不能把所有希望寄托在“提前导入 TLE 轨道，到点提醒你抬头看”上，因为那样只叫“定时闹钟”，不叫探测器。我要的是设备自己走到一片空地，自己发现“有东西在天上动”，再自己判断“它大概率是卫星”。这个目标直接决定了后面软件算法的复杂度，也决定了它区别于普通无线电频谱仪的价值。

其实还有一个隐藏目标：让探测结果可信可回溯。手机拍到的模糊光点、频谱图上的一根毛刺，这些都不算数。探测器的输出应该是带时间戳、带频谱图、带置信度的结构化日志，方便日后统计分析，也能在社区里作为开源数据共享。听起来不酷，但正是这个东西让它从“会响的玩具”变成“能用的工具”。

2. 探测原理：卫星不是“看”到的，是“听”到的

2.1 Starlink 下行信号：把卫星当作空中的无线电灯塔

很多人以为卫星探测一定要去解调卫星的通信内容，其实不需要。我们要做的只是“听到信号特征”，然后判断“这个特征来自一颗正在运动的卫星”。Starlink 这类通信卫星在工作时，必须持续向地面用户终端发送宽带下行信号，同时还有测控遥测链路在工作。这些信号从几十公里到上千公里的斜距传播过来，强度虽然不大，但完全可以被灵敏度足够的接收机捕获。

关键点在于信号特征会随着卫星运动而变化。低轨卫星从地平线升起到过顶再到落下的过程中，它与接收机之间的距离先变短后变长，加上天线波束覆盖区不同，接收信号强度（RSSI）会出现一个典型的“山丘形”包络：起始接近底噪，中间爬升到最高点，然后回落到底噪。这个包络规律本身就是判断目标是否为低轨卫星的有力证据，因为地面固定信号源或者飞机，都不会出现这种平滑、缓慢、持续时间长达几分钟的能量起伏。

当然，射频方案有一个绕不开的现实：Starlink 的用户下行链路主要在 Ku 波段（10.7–12.7 GHz）。这个频段对天线口径和接收前端的要求都比较高，直接做进手持设备会非常昂贵。更稳妥的策略是“分层接收”：先用低成本 SDR 扫描可覆盖的频段，把周期性出现的未知信号峰记录下来；再用带下变频器的天线对准疑似目标，用多普勒曲线确认身份。这样既控制了设备成本，又保留了对未知目标的发现能力。

2.2 多普勒频移：运动中的卫星会在频谱上画一条 S 曲线

多普勒频移是这台三录仪最核心的物理依据。当一颗卫星朝你靠近时，它发射的电磁波被压缩，接收频率高于发射频率；当它飞过你的头顶开始远离，频率又会被拉伸，低于发射频率。低轨卫星相对接收机的速度可以达到每秒几公里，因此造成的频率偏移在几十赫兹到几十千赫兹之间，具体取决于工作频段和卫星到接收机的相对速度分量。

如果以时间为横轴、频率为纵轴，把峰值频率连成线，就会得到一条典型的 S 形曲线。这条曲线的过零时刻，正好对应卫星飞到离你最近的时刻，也就是仰角最大、地距最短的时刻。这条 S 曲线是卫星身份的重要指纹：地面干扰源不会产生这种形态，飞机上的发射机也不会，它们要么是固定窄线要么是短促脉冲。所以我在算法里明确规定：单有能量峰不算发现，能量峰加上可匹配的多普勒曲线才算发现。

低轨卫星过顶时的多普勒变化节奏是“秒级”的，不会瞬间完成，也不会持续太久。这给了手持设备一个很好的时间窗，大约有三到五分钟可以完成“捕获—跟踪—匹配—记录”的完整流程。

2.3 光学辅助：给射频判断补上一只眼睛

射频通道有天然盲区：卫星可能处于波束关闭状态，或者信号恰好落在你没覆盖的频段。所以我在设备上增加了一个光学辅助通道。低成本做法是用高灵敏度光电二极管配合窄视场透镜，由独立 MCU 持续采样视野内的亮度变化。Starlink 卫星在暮光时段反射阳光，亮度可以达到二等星甚至更亮，完全能够被传感器捕捉到。

这个光学通道并不输出图像，而是输出两类结构化事件：亮度突变发生的时间、相对传感器的方位。射频通道给出“疑似目标”后，光学通道会在几秒内回答“是否看到亮度事件”。我把两条通道的结论综合成三级置信度：

• 第一级：只听到射频信号。
• 第二级：射频信号加上多普勒曲线匹配成功。
• 第三级：射频和光学同时命中。

这个分级设计非常实用，大幅降低了深夜户外单靠“频谱图上有个峰”就兴奋半天的误报挫败感。

3. 硬件系统选型与组装：手持探测器的骨架与感官

3.1 射频前端组合：从 RTL-SDR 到下变频器的三级火箭

硬件方案第一关键是频率覆盖。如果是预算优先的入门版本，最稳妥的选择是 RTL-SDR v4，或者带 TCXO 的经典 RTL2832U，频率范围 24 MHz 到 1.7 GHz。这个方案的软件生态非常成熟，在 Linux 上装好驱动以后，Python 库可以直接拿 IQ 数据流出来做 FFT，适合先把探测逻辑跑通。

如果你想让设备具备接收 Ku 波段的能力，不必急于买昂贵的微波级 SDR。更聪明的做法是使用卫星电视接收常用的 Ku 波段 LNB，它本身就是将 10.7–12.75 GHz 下变频到 950–2150 MHz 的成熟模块，价格便宜且噪声系数可用。你在设备里加一个偏置供电控制开关，当 GPIO 输出高电平时给 LNB 供电，低电平则切断，这样同一台设备就能在低频段和 Ku 频段两种模式之间自由切换。

天线方面也非常讲究。在 2.4 GHz 附近，我试过 PCB 平板天线，也试过自制的四叶草天线。实测下来，四叶草天线在接近地平线仰角时的圆极化性能更好，而低轨卫星过顶时极化方向往往在不断变化，圆极化接收能明显减少信号衰落。如果是配 LNB 的 Ku 频段，直接用 LNB 原装馈源喇叭就行，但要注意它的波束很窄，设备上必须依赖罗盘和俯仰传感器辅助指向。

下表是我在选型时画的对比：

3.2 主控与显示：树莓派 Zero 还是 MCU？

主控我前后做了两版。第一版用 ESP32-S3 加 2.4 英寸电容触摸屏，外加外置 SDR 模块，优点是体积小、待机功耗低。但一跑实时 FFT 和瀑布图渲染，算力就捉襟见肘，频谱更新率上不去，界面操作也卡顿。第二版换成了树莓派 Zero 2 W 加同尺寸触摸屏，CPU 性能大幅提升，Python 生态里的 numpy、scipy、rtl-sdr 绑定库全部可用，UI 用 LVGL 或 pyGame 都能顺利开发，迭代速度快了一倍不止。

代价是启动时间比 MCU 慢，关机也慢。但在“设备”这个定位下，开机多等十几秒完全不是问题。为了保证 SDR 采集稳定，我在系统里禁用了 Wi-Fi 省电模式，避免射频模块间歇性掉电导致数据流断流。存储卡也换成高耐久版本，因为设备会持续写入观测日志，普通 TF 卡在写入放大之下坚持不了太久。

3.3 供电、按键与 3D 打印外壳

供电部分，我用两节 18650 串联，再经降压稳压输出两路：一路给主控提供稳定的 5V，另一路给 SDR 和射频前端提供低纹波电源。低轨卫星过顶通常只有几分钟，设备要在户外长时间待命，所以我还加了一个霍尔感应开关，放在包里时自动休眠，拿出来自动唤醒。这个细节非常实用，实测能把一次外出的有效待机时间拉长到接近一天。

外壳是很多新手容易忽略的环节。我建模时把屏幕、按键做成模块化面板，天线接口用 L 型可折叠结构，整机可以在“展开模式”和“收纳模式”之间切换。3D 打印材料推荐 PETG，不要用 PLA，因为户外阳光直射下 PLA 很容易变形。还有一点很重要：射频模块和主控之间要留至少 15 毫米的空间隔离，否则 USB 线缆会拾取 SDR 本地振荡器的泄漏信号，频谱底噪会明显抬高，再好的算法也救不回被污染的数据。

4. 软件逻辑与信号处理：让探测器“开口说话”

4.1 实时频谱构建：从 IQ 采样到瀑布图

软件部分，我使用 Python 做上层逻辑，关键 DSP 用 C 扩展保证实时性。rtl-sdr 库从 USB 接口把 IQ 采样流送进来，numpy 负责做加窗 FFT，每帧分成 1024 到 2048 个频点，计算功率谱后滑动绘制成瀑布图。FFT 的帧率不需要太高，10 帧每秒足够，因为卫星多普勒频率变化是秒级的，远没有到毫秒级突变的程度。

这里有一个特别容易被忽略的权衡：FFT 的分辨率带宽取决于观测时间窗的长短。想要分辨几十赫兹的多普勒偏移，就需要较长的时间窗；但时间窗一长，频谱更新就变慢。鱼和熊掌不能兼得，我的做法是双分辨率策略：全局扫描时用短窗粗扫，发现疑似信号后立刻切换到窄带跟踪模式，用更长的 FFT 窗精测频率变化。这个“粗扫—精跟”的切换逻辑，是设备能否在真实环境里稳定工作的分水岭。

4.2 多普勒匹配与识别算法：别被任何一个单峰骗了

粗扫发现稳定功率峰后，检测线程会记录峰值频率随时间变化的序列。判断它是否属于卫星，我用一个基于轨道预报的匹配器。设备里预存了一份 TLE 编目数据，根据当前经纬度和时间，用 SGP4 模型预测每颗卫星的过顶方位、仰角以及理论多普勒曲线。然后把实测频率序列与理论曲线做滑动相关，相关系数超过 0.8 且持续时间超过 30 秒，就判定为“命中”。

这个算法里必须有一个容错设计：实测频率不一定完全等于理论预测值，因为卫星可能使用了预失真补偿或跳频机制，所以匹配器允许实测曲线做整体频率偏移，只比对曲线形状和过零时刻的斜率走向。换句话说，设备判断的是“这条曲线的形状像不像卫星的指纹”，而不是“你的频率是不是查表能查到的频率”。这个方法的好处是，即使不知道目标卫星使用的精确频率，也能在相对带宽内把它识别出来。

下面是我简化后的 Python 伪代码结构，完整版本可以从项目的公开仓库里拉取：

def detect_and_match(iq_stream, tle_catalog, position, time): spec = build_spectrum(iq_stream, fft_size=2048, frame_rate=10) candidates = coarse_scan(spec, threshold_db=6) for cand in candidates: freq_series = track_peak(spec, cand.center_freq, duration=30) doppler_curve = predict_doppler_hz( tle_catalog, position.lat, position.lon, position.alt, time, frq_hz=cand.center_freq ) score = sliding_correlation(freq_series, doppler_curve) if score > 0.8: emit_event("IDENTIFIED", cand.center_freq, score)

这个流程真正写完会发现，耗时最多的不是算法本身，而是对边界情况的处理：比如信号中断几秒怎么办，多个候选目标同时出现时怎么分配跟踪线程，以及如何避免把同一个卫星在两次过顶中重复计数。这些细节决定了设备在户外连续工作一晚上会不会“精神分裂”。

4.3 界面交互与反馈：像科幻道具一样果断

界面是这台设备的灵魂。我不想做一个塞满图表的仪表盘，屏幕只显示三样东西：当前方位仰角和目标卫星图标、频谱瀑布图缩略图、探测置信度。当候选事件从“可疑”升级到“命中”时，屏幕会弹出一条绿色轨迹弧线，同时蜂鸣器播放短促提示音。我还加了一个扁平振动马达，强光下不看屏幕也能感知事件发生。

在软件结构上，我用了一个轻量有限状态机：IDLE—SCANNING—TRACKING—IDENTIFIED。状态之间的每次转移都会写日志，方便事后回溯误报原因。界面库用的是 LVGL，在 PC 上先做原型，再交叉编译到树莓派上运行，性能和内存占用都还不错。整套交互设计的原则只有三条：状态可见、反馈及时、操作最少。任何需要使用者盯着菜单猜的界面，在夜晚户外都是灾难。

5. 整机实测与数据解读：第一次过顶捕获实录

5.1 测试环境与调试步骤

实测地点我挑在城外一处山顶空地，四周没有高层建筑，天线可以保持低仰角视野，背景电磁干扰相对少。出发前先更新 TLE 数据，用 GPS 模块等定位收敛。正式测量时，设备以 30 度仰角为基准做持续扫描，同时用一部手机拍摄天空，用来交叉验证“是不是真有卫星经过”。

调试分三步走：先看底噪、确认没有自激；再对着附近已知的数字电视塔做频谱峰值确认；最后才进入卫星过顶时段。这步非常重要，因为如果设备自身存在间歇性自激信号，所有后续判断都会被污染。我那次实测最有趣的瞬间，是第一次看到带明显负多普勒偏移的候选信号。最开始我以为是远处某个地面设备的杂散，拿来匹配多普勒曲线后才发现，它来自一颗低轨卫星。那次经历让我真正认识到：先入为主地判断“信号源一定在地面”，会直接导致漏掉真正目标。

5.2 实测波形：RSSI 包络和多普勒 S 曲线的样子

目标出现时，频谱瀑布图上能看到一条从右上向左下倾斜的亮线，这是多普勒频移的视觉表现。S 曲线从最大正偏逐渐过零再到负偏，过零时大约对应仰角最大的时刻，整个过程持续约一到两分钟，与 SGP4 理论预测基本吻合。

同时，RSSI 包络呈平缓的山丘形：刚进入视场时接近底噪，过顶时爬到最高点，离开时跌回底噪。这两个特征同时出现，我基本可以确信“卫星过顶”。下面是不同信号源特征对比：

熟悉这些“长相”之后，误判会减少很多。

5.3 误报、假阳性与抗干扰

即便算法再用心，误报也避免不了。最常遇到的干扰源有三类：第一是业余无线电瞬时通联，间歇性占用频段，很容易触发粗扫；第二是同一时段多颗卫星同时过顶，多普勒曲线混叠在一起，候选目标重叠；第三是电子产品辐射的宽带噪声，比如无人机图传或者附近车载雷达。

我坚持的原则是“宁可漏报，不可错报”。候选信号多普勒相关低于阈值时，只写日志不弹提示。事后翻日志发现，多数误报来自树莓派 USB 总线偶发丢包，导致频率序列不连续。后来我给 SDR 加了一个独立供电的 USB Hub，把数据缓冲加倍，问题明显减少。想复现这个项目的朋友，务必把日志记录做好。别把“屏幕亮了一下”当成成功，带时间戳的数据才是以后分析问题、改进算法的基础。

另外提醒一句：户外测试前，先确认你所在地区对无线电接收设备的规定，有些频段的接收也需要遵守相应的管理要求，避免给自己惹麻烦。

6. 避坑清单与扩展方向：想把项目延续下去，还会踩哪些坑

6.1 五个高频问题与解决思路

第一，SDR 输入过载。很多 SDR 前端没有自动增益控制，或者 AGC 响应很慢，天线一旦靠近强基站，整个频段都会被压扁。解决方法是先衰减再放大，我给射频输入加了一级可切换的 10dB/20dB 衰减器，可以在软件里远程切换。

第二，GPS 授时不准。多普勒匹配严重依赖精确的时间戳，手机内置 GPS 的 PPS 误差比较大。我改用外置 GPS 模块，通过 PPS 信号校准系统时钟，匹配精度明显提升。别小看这一秒误差，对多普勒匹配的影响可能完全改变曲线形状。

第三，馈线损耗过高。手持设备内部空间紧张，但劣质同轴线哪怕只有几厘米，也会吃掉大量信号。尽量选择高质量的低损耗电缆，并且让 SDR 尽可能贴近天线接口，把馈线长度压到最短。

第四，OLED 屏幕在阳光下看不清。我在后期加入了自动亮度调节和黑底白字的“夜视模式”。实测晚上比白天好用得多，这提醒我：做户外设备，显示可读性必须放在与性能同等重要的位置上考虑。

第五，TLE 数据容易过期。TLE 超过三天后，轨道预测误差会显著增大。我给设备写了一个边充电边更新的脚本，只要连上 Wi-Fi 就自动拉取最新的 NORAD 编目。可能听起来很基础，但这正是每个长期维护项目都必须处理的“脏活”。

6.2 进阶方向：把三录仪变成移动地面站

这台设备做完后，最大的感受是“探测器”和“地面站”之间的界限其实很模糊。只要在软件里加入自动指向、星历记录和数据导出，它就能变成一套便携式卫星监测系统，在野外也能工作。更进一步，可以让设备在同一时段跟踪多颗卫星，按优先级把天线指向最亮的过顶事件。

另外，它可以扩展成真正意义上的“万能三录仪”。加入紫外传感器、磁场计和简易光谱仪，就能把探测范围扩展到空间气象监测；把每次观测自动归档成 JSON，就可以做历史统计和“卫星火车”可视化。对我来说，三录仪本来就是一个开放概念，卫星探测只是它的第一个技能。

最后分享一点私人体验。做完这个项目，我真正记住的不是那台设备本身，而是第一次在频谱图上看到卫星“画”出那条 S 曲线时的震动。那种感觉就像你突然听见了原本以为无声的宇宙里，有无数个亮点正按自己的节奏说话。做这类项目的价值，不在于证明你能做一个看起来很科幻的玩具，而在于你开始习惯用另一种方式观察世界：换一只耳朵、换一个时间分辨率，原本看不见的东西就开始显形。

如果你也打算动手，我的建议是从一个便宜的 RTL-SDR 和一颗已知过顶的低轨气象卫星开始，先跑通“粗扫—精跟—匹配”的完整链路，再逐步添加性能和交互外壳。不要急着买昂贵的微波硬件，探测卫星的乐趣，很多时候不在于频段多高，而在于你是否能真正读懂那些隐藏在噪声里的规律。