一颗低地球轨道卫星飞过时，任何一处屋顶都只有几分钟可以与它通信，随后轨道几何关系便会关闭链路。把许多屋顶连接起来，短暂的本地窗口便能扩展为更广的地理覆盖；然而今天所谓的“开源地面站”，实际包含着几套差异很大的协作约定。

TinyGS 从一块小型 ESP32 级 LoRa 无线电设备起步，把接收数据包的成本降下来。SatNOGS 将软件定义接收机接入共享排程器、卫星数据库与公开观测档案。UniClOGS 面向需要同时发送指令和接收遥测的大学卫星任务团队。三者不构成成熟度阶梯上的三个等级，它们分处三条路线，彼此之间隔着无线电带宽、操作方权限、数据产品、许可要求，以及对尽力服务式基础设施的容忍度。

这一区分应当先于天线采购。若任务信标适配受支持的低功耗调制解调器，成千上万台 TinyGS 接收机便能带来很大价值。若研究人员需要瀑布图、音频或针对特定卫星的 GNU Radio 处理，所需的是覆盖面更广的 SatNOGS 接收栈。必须发送经过身份验证的遥控指令时，团队需要自有、已获许可且由自己掌管的地面系统；公共接收网络可以补充这一系统，却无法取得它的权限。

图片背景：封面是一座真实的 SatNOGS v2 地面站，2015 年部署于 FOSDEM，也就是该项目赢得 Hackaday Prize 的次年。交叉天线和清晰可见的机械部件提醒人们，这幅图谱立足于实体基础设施，云服务的比喻在这里并不适用。[12][13]

按照各条路线的约定来读

这张表用于引导选择，不能充当兼容性承诺。频率只是第一道门槛；真正匹配还要求调制方式、带宽、数据率、天线方向图、多普勒处理、解码器、地平线条件和法律权限逐项吻合。在这些字段对齐以前，“附近有一座台站”几乎说明不了什么。

TinyGS 将接收机缩小为最小实用单元

TinyGS 把台站端收进一块连接 Wi-Fi 的微控制器开发板，板上集成 LoRa 一类的收发器。其代码仓库列出了搭配 SX126x 或 SX127x 无线电芯片的 ESP32 与 ESP32-S3 开发板，包括受支持的 433 MHz 和 863–928 MHz 版本。浏览器安装器负责首次刷写，可选的无线更新与服务器端自动调谐则能让接收机为即将到来的过境做好准备。[7]

低廉的入门成本来自一条有意收窄的无线电通路。Heltec WiFi LoRa 32 或 TTGO LoRa32 一类的开发板，可以解调其收发器与固件支持的模式，同时省去了 Linux 系统、GNU Radio 和通用 SDR。航天器下行链路与之匹配时，这种设计能以很少的设备换来很高的接收效益。项目若要任意捕获 I/Q、使用更宽的实验带宽、处理未受支持的波形，或让同一前端跨越多个频段，这种抽象就不再适用。

硬件界限也让部署条件变得清晰。天线必须匹配频段；仪表板上的一项设置无法把 433 MHz 射频通路变成 868 MHz 通路。一座台站可以便宜到足以进入课堂或偏远站点，而地理密度能够补偿每个地点只能看见片刻过境的限制。卫星运营方由此可从许多接收机取得带时间戳的数据包，同时省去拥有每一处屋顶的成本。

TinyGS 首先是一张接收网络，虽然它的编程 API 文档也列有发射端点。该 API 标为开发中状态，要求在台站固件中明确启用发射功能，也不会自行授予监管或卫星任务权限。[7][8] 这些条件提示人们谨慎看待把社区上行链路用作常规指令通道的做法：技术上存在一个端点，距离依法许可的接入、经过身份验证的任务控制和排定的运营责任仍有很长一段路。

SatNOGS 将观测作为共享单元

SatNOGS 在台站端配置能力更强的计算机与无线电设备，随后共享整项观测，而不限于已解码的数据包。其参考台站架构包括 satnogs-client、针对特定卫星及通用用途的 satnogs-flowgraphs、GNU Radio、用于 SoapySDR 设备的 gr-soapy、gr-satnogs、配置工具，以及可选的 Hamlib 旋转器控制。[2]

交接从两个公共信息系统开始。SatNOGS DB 通过一套公开读取、采用 CC BY-SA 许可的 REST API，提供卫星与发射机记录。SatNOGS Network 则通过自己的 API 管理台站、排定任务、观测和回传数据。[4][5] 两边职责各自独立：发射机的频率与模式描述能够听到什么，一项观测则记录某座台站在一次过境中尝试接收了什么。

在台站端，客户端拉取任务、计算多普勒修正、选择接收通路、调用相应流图；若配有兼容的旋转器，也会带动它跟踪，随后上传结果。带版本号的 Client 2.1.1 文档没有把运营细节藏在一个“连接”开关后面：SATNOGS_API_TOKEN 和 SATNOGS_STATION_ID 将安装实例绑定到它在 Network 中的身份；默认任务查询间隔为 60 秒，默认观测提交间隔为 180 秒；精确的纬度、经度和海拔能够改善多普勒修正，同时会降低位置隐私。[3]

实体台站的变化空间因此远大于 TinyGS 节点。SatNOGS 推荐把树莓派作为支持最完善的起点，但接收链既可为信号较强的过境使用固定全向天线，也可把定向八木天线或螺旋天线装在旋转器上，接收更微弱的 CubeSat 信号。SDR、低噪声放大器、滤波器、馈线、本地干扰、地平线遮罩、时钟误差和计算预算都会影响结果。共同的软件约定让异构台站得以接受排程，却不会让它们的测量结果彼此等同。[1][2][14]

正因如此，失败观测在档案中仍然有意义。SatNOGS 于 2026 年 5 月 6 日宣布达到第 1400 万次观测；这一里程碑记录来自里加一座台站对 LUSAT 的接收尝试，结果标记为失败。项目以这次失败说明网络密度与备用覆盖的价值，没有把它当作应当丢弃的记录。[6] 一次漏收的成因很多：航天器没有发射信号，轨道或发射机数据过时，仰角过低，视线受遮挡；干扰、增益或频率存在问题，解码器不匹配，台站自身也有故障。单个负面结果很难指出究竟是哪一项原因占了上风。

公共网络规模很大，却只占完整系统的一部分。Libre Space Foundation 报告称，投入运营的台站超过 500 座，注册台站超过 4,000 座，同时正在积极开展面向服务的重构。它也以开放许可证发布软硬件。[1] 这里需要区分可复现性与可用性：源码访问让其他运营方可以检查或部署组件；公共实例的覆盖范围，则来自一套托管排程器、持续维护的数据库，以及数百位贡献者保持无线电设备正常工作。

UniClOGS 将指令权限留在本地

接收的多样性与航天器指令分属不同的信任域。UniClOGS 全称 University Class Open Ground Station（大学级开放地面站），由 Portland State Aerospace Society 开发。其 OreSat 团队发现，SatNOGS 的接收模式很有价值，却不足以发送指令。由此产生的设计增加了任务方自有的发射机、可配置射频硬件、GNU Radio 处理和控制软件，同时延续开放硬件与开放软件的做法。[10][11]

这一变化把台站带入另一个成本与治理等级。2024 年 Small Satellite Conference 的一篇论文介绍了 UHF、L、S 和 X 频段选项、商用现成射频组件，以及面向业余无线电卫星任务的发射能力；整座台站的估算成本约为 10,000 至 25,000 美元。论文还明确对照了 UniClOGS 与只接收信号的 SatNOGS 网络，并解释非业余上行链路为何难以远程共享。[10]

成本数字多出的几个零，买到的远不只有天线增益。指令台站需要受管理的凭据、获准使用的频率与功率、发射联锁、过境操作流程、操作人员角色、日志、时间同步、保障航天器安全的指令顺序，以及恢复通道。团队还须依据实际卫星验证链路预算。开放的原理图与软件让这些责任可以检查、可以复用，但不会把责任转交给志愿者网络。

因此，UniClOGS 与公共接收路线形成互补。大学可以利用 TinyGS 或 SatNOGS 的观测，查明信标在何处被收到、比较不同地区的接收情况，或取得本地地平线之外的发射后证据。安装在本地的 UniClOGS 则能继续作为遥控指令与更高带宽任务链路的权威通道。两边衔接的是数据与规划，发射密钥仍由任务方独自持有。

互操作从元数据开始，与标志无关

2024 年一项独立研究对 TinyGS 与 SatNOGS 作了比较，结果显示前者部署更简单、成本更低，后者则在研究所采用的 2023 年 7 月 29 日快照中解码了更多种卫星。作者同时说明，原始台站数量不适合作为通用评分：地理分布、受支持的卫星、频率、硬件和网络定义均有差异。[9] 这些数字如今已成为历史记录；持续有效的做法，是把具体任务与每条路线的接收约定逐项比较，放下为网络排出胜负的念头。

对于航天器团队，互操作记录至少应包括：

1. 航天器标识符，以及用于预测过境的当前轨道根数；
2. 每条下行链路的中心频率、带宽、调制方式、波特率、成帧方式和预期多普勒范围；
3. 台站位置、地平线遮罩、天线、无线电设备、增益与滤波链、时钟源和软件版本；
4. 观测或数据包标识符、UTC 起止时间、原始或派生数据产物、解码器版本和质量判定；
5. 通路属于公共接收、私有接收还是已获许可的指令链路，以及权限由谁持有。

这份记录让 TinyGS 数据包、SatNOGS 瀑布图或解码帧，以及任务方自有的 UniClOGS 通联可以共同服务于同一项调查，同时把三者作为不同的数据产物分别处理。它也保留了失败发生的界限。若两个网络都漏收一次过境，团队可以检查它们是否采用了相同的发射机元数据。若一座台站收到信号，另一座没有，天线、地平线、噪声底、调谐和解码器便成为可以逐项检验的变量。

先选信号，再选覆盖范围

下行链路适配受支持的低成本无线电硬件，且目标数据产品是数据包流时，TinyGS 是最直接的入口。若卫星任务可以从排定的 SDR 观测、开放发射机元数据、瀑布图、音频或可扩展解调中受益，SatNOGS 是内容更丰富的共享接收路线。组织需要同时掌握上行链路、任务运营和接收时，UniClOGS 才是对应的设计范式。

三条路线都无法把一处屋顶变成有保证的覆盖。社区台站会离线，天线看到的地平线各不相同，本地噪声会变化，中心服务需要维护，解码器与轨道根数会老化，发射活动也始终受到监管。合理的设计采用分层方式：先在一座受控台站上验证波形，再借助公共网络扩展地理多样性、取得独立证据，同时把关乎安全的指令权限留在有人运营的地面系统内。

整个体系的优势，恰恰来自三条路线可以保持差异。TinyGS 可以针对最小实用接收机优化，SatNOGS 可以针对复用程度最高的公共观测优化，UniClOGS 则可以针对可复制的任务台站优化。开放的连接方式随后让卫星团队汇合三方证据，也让每个项目继续专注于自己的地面站类型。

来源

1. Libre Space Foundation，“SatNOGS”——当前项目范围、Network/Client/DB 分工、运营规模、许可证、里程碑与面向服务的发展方向。
2. SatNOGS 文档，“SatNOGS Station Architecture”——Client、GNU Radio 流图、SoapySDR、配置、旋转器控制与上传界限。
3. SatNOGS Client 2.1.1 文档，“Environment variables”——台站身份、API 轮询、数据产物、无线电与旋转器配置，以及位置精度所带来的取舍。
4. SatNOGS Network 文档，“API”——排定任务、观测上传、OpenAPI 参考资料和 CC BY-SA 数据访问。
5. SatNOGS DB 文档，“API”——公开的卫星与发射机元数据，以及采用 CC BY-SA 许可的数据访问。
6. SatNOGS，“New Milestone for SatNOGS: 14M Observations!”（2026 年 5 月 28 日）——里程碑日期、失败的第 14000000 次观测、网络密度论证与开放数据背景。
7. TinyGS 官方固件仓库——对 ESP32 与 SX126x/SX127x 硬件的支持、频段版本、安装、托管数据通路、自动调谐、受支持模式和 GPL-3.0 许可证。
8. TinyGS，“Programmatic API”——beta 状态警告、身份验证，以及由固件开关控制的台站发射端点。
9. João Sá Gomes 与 Alexandre Ferreira da Silva，“TinyGS vs. SatNOGS: A Comparative Analysis of Open-Source Satellite Ground Station Networks”，Telecom 5(1)，2024——独立比较研究，使用有明确日期的 2023 年网络快照。
10. Glenn LeBrasseur 等，“University Class Open Ground Station (UniClOGS)”，Small Satellite Conference，2024——大学卫星任务中的发射能力、射频频段、成本范围、GNU Radio 技术栈与接收网络界限。
11. OreSat，“Ground Stations”——UniClOGS 的起源、运营目的、发射要求、与 SatNOGS 的关系，以及 Portland State 的部署。
12. David Schneider，“The Hackaday Prize Awarded to Satellite Ground Station Project”，IEEE Spectrum（2014 年 11 月 13 日）——关于 SatNOGS 起源与中央服务器网络概念的独立同期报道。
13. Nikos Roussos，“SatNOGS v2 in FOSDEM 2015”，Wikimedia Commons——封面所用地面站档案照片的来源与出处，拍摄于 2015 年 1 月 31 日，采用 CC BY 2.0 许可。
14. SatNOGS Wiki，“Build”——当前参考平台、固定与旋转天线方案、无线电设备、放大措施和硬件支持界限。