海事卫星 FleetBroadband 故障代码与错误日志怎么读（SAILOR 与 EXPLORER 全系）

核心摘要：FleetBroadband 的故障排查是四层往下查——先看灯（哪颗红了）、再看事件日志（时间点最早的哪一条）、再看自检 POST（哪一项 FAILED）、最后看 Call log 的 Cause 号。灯告诉你「哪一类问题」，日志告诉你「什么时候开始坏的」，POST 告诉你「哪块板子没通过」，Cause 号告诉你「连接为什么断的」。顺序不能颠倒，尤其别跳过第一步直接去翻日志。

船上的 FleetBroadband 出了毛病，最麻烦的不是修，而是说不清坏在哪——船员只会说「上不了网」，工程师上船前不知道带什么备件，来回一趟就是几千块油钱和几天船期。这篇文章把厂家培训手册里那套排查方法，整理成一份能照着走的路线。

先说清排查的总思路，四层，从上往下：

1. 看灯 —— 哪颗灯什么颜色，先把范围缩到「供电 / 天线 / 入网 / 消息」
2. 看事件日志 —— 找时间最早的那一条，找出问题的起点
3. 看开机自检 —— 哪一项 FAILED，直接指到板子
4. 看连接的 Cause 号 —— 这一次连接为什么被拆掉

顺序不能乱。 手册里专门提醒过一件事：故障会连锁——比如 GPS 模块坏了，会导致天线控制模块自检失败，一次失败又带上后面一堆失败，日志越攒越多。如果一上来就翻最后那几条，看到的往往是"结果"，不是"原因"。

舱内终端面板上有四颗灯。SAILOR 500 / 250 是完整四颗，SAILOR 150 只保留电源指示灯（它的面板设计更简化，把状态都放到网页界面里看）。

🔴 这里有个特别实用的小技巧——两颗灯要合起来看。 手册给了一张组合状态对照表，光看一颗灯会误判：

这就是判断"到底卡在哪一步"的最快办法。 天线绿常亮但终端一直绿闪，说明天线没问题、卡在入网这一步；天线一直绿快闪，说明连卫星都没找到，先查遮挡和线缆，别去折腾终端。

⭐ LAN 的 PoE 灯变红是个很容易被忽略的告警。 它意味着接在网口上的设备（通常是 IP 话机或无线 AP）功率超了，终端供不动。这时候话机会表现成反复重启或直接不通，但终端本身一切正常——问题不在终端，在挂的那个设备上。

终端在三个阶段会检测异常：开机自检（POST）、人工触发的自检（PAST）、运行中持续监控（CM）。检测到需要人工处理的异常，就发一条事件消息，同时点灯。

🔴 一条极重要的操作纪律：出问题后先别断电。 事件日志只保留当前这一个开机周期的完整记录，一重启就清空。日志还会保留前几个开机周期里最早的 50 条故障事件，但那 50 条是有限的、会被顶掉的。船员一发现异常习惯性去重启——这么一搞，最有价值的现场记录就没了。

看日志的正确姿势是找"时间最早的那一条"，不是最新的那条。前面说过故障会连锁，最新那条多半是"结果"。

在网页界面上看事件表：点界面顶部图标栏里的告警符号，就能看到当前生效的红色 / 橙色告警。

开机自检大约 40 个项目，每一项 PASSED 或 FAILED。这一层是"点名"——直接告诉你哪块板子没通过。

手册里的两个典型例子，含义是这样的：

开机自检时找不到天线。通常顺着往下必然带上第二条：

找不到天线，自然也就联系不上天线里的控制模块（ACM / ATB）。

这两条同时出现时，链条是清楚的：天线没连上 → 天线内部的模块也就无法应答。 该查的是天线线缆、接头、供电这条物理链路，而不是去换板子。

这一条不一样：天线本身在，是天线里的 GPS 模块坏了。手册给的结论很直接——更换 GPS 模块。

⚠️ 这时候如果只看日志条数会掉坑：GPS 模块一坏，它会卡住后面的自检项，导致 FAILED 的条数越攒越多。手册专门提醒：这种情况下必须回头看事件日志里最早那一条，才能定位到真正出问题的 GPS 模块。

其他几项常见的自检项含义：

⭐ [0043] 发射线缆损耗这一项，是装机质量的自检。 正常范围 -200 至 2200，超出这个范围就说明线缆有问题（太细、太长、接头没做好）。同时还有一项 [0051] 检查损耗的变化量，范围 -200 至 200。线缆损耗每次重启都会重新测一遍，所以装了新线以后重启一次看这项，是验收线缆最省事的办法。

每一次连接（拨号、数据、PDP 上下线）在 Call log 里都会留一条记录，带一行 Cause:。这一层回答的是"这条连接为什么断了"。

手册里对这条给了明确解释：

六位的十六进制 Cause 号是终端的内部代码，不是网络给的。

也就是说，看到 0x40003 不该去问运营商"你们为什么拒绝我"。它指向的是本机侧的原因——手册列的可能原因有三种：

1. 终端已经与网络失去连接
2. 信号太弱
3. GPS 定位太旧（GPS 信息过期，终端不知道自己在哪，网络不允许它就位）

排查动作也就对应三条：查 C/No（信号质量）、查 GPS 状态、查事件日志，再核一遍 SIM 卡。

⭐ 这一条对现场判断的价值很高。 船上反映「数据连接一直建不起来」，如果 Cause 是 0x40003，说明不用急着怀疑 SIM 卡欠费或者运营商封号，先看天线是不是被新装的桅杆挡了、GPS 是不是长时间没定位——这两个是船上最常见的实际原因。

配了 Thrane IP 话机（或 SAILOR 系列的 IP 话机）时，系统故障会直接显示在话机屏幕上。按话机的菜单键可以看到告警细节。

手册里给的例子是一条完整链路：

1. 话机屏幕显示：ERROR : Antenna Failure
2. 按菜单键看细节，显示：BGAN alarm — WARNING: Antenna Cross-elevation motor
3. 事件日志里对应的条目是：EV_ATB_CROSS_ELEVATION_MOTOR_VOLTAGE

翻译成人话：天线里那个负责交叉仰角动作的电机，电压或负载电流不对。 手册给的处置是拆罩、物理检查这个电机——具体做法是：断电，用 Torx 25 螺丝刀拆开罩子顶部那 10 颗螺丝（注意垂直提起，别蹭到天线面板），转动天线面板到能碰到电机的位置，试着用手转电机上的齿轮。如果转不动、卡死，就换电机。

需要的工具：Torx 8 号、Torx 25 号螺丝刀，以及 1.5 mm 内六角扳手。

⚠️ 这条链路值得记住的不是具体修法，而是它的路径：话机上的英文告警 → 话机菜单里的细节 → 事件日志里的代码名。三个地方说的是同一件事，现场只要能在话机上读出细节，就等于拿到了日志里的关键词。

网页界面里可以生成诊断报告（Diagnostic report），但那份报告很大——手册里写大约 250 页文本。而且报告里的系统信息基本是当下这一刻的快照，历史很短（只有像 errorlog 这样少数几处带历史数据）。

这意味着两件事：

1. 报告必须在故障发生后尽快生成，隔一天再生成，现场数据已经没了
2. 报告和详细的故障描述不能互相替代——你得先知道要找什么

更快的方式是直接从调试命令行抓。 用任何支持 telnet 的终端程序，连 192.168.0.1 的 23 端口（默认主机地址 192.168.0.1），登录后进入 Thrane & Thrane 的命令行：

💡 没有 telnet 工具怎么办？ telnet 功能已从现代 Windows 和多数 Linux 发行版里默认移除了，但可以直接拿浏览器当网页界面用：把上面这些命令换成网页界面里对应的页面（事件表、事件日志、维护页、诊断报告导出）来看，信息量少一些但都在。

⭐ 默认用户名 admin、密码 1234。 这组凭据是公开的，手册里就这么印着——公开，但现场人员最容易忘。所以这里照原样保留。注意它是本机调试入口，只在设备局域网内可达（192.168.0.1 是终端自己的地址），不用怕外网能登进来；但也别把它当成安全防线，谁能连上这条船的内网，谁就能进。

日志本身长这样（手册里的真实例子）：

021:01:55.002 FATAL  Thread: Alive  UTC Tue Dec 29 09:00:01 2009
[pollTimeout, .../alive/src/alive.cpp line 97]:
ALIVE: Module ADU_MANAGER failed to answer poll request

每一行读四段：运行时刻（021:01:55.002，即开机后 21 小时 1 分 55 秒）→ 级别（FATAL 严重 / NON FATAL 非严重）→ 线程名（Alive）→ 具体描述。

🔴 FATAL（严重）会让系统自动重启。 手册明确写：当发现天线不应答，就会判定为严重错误并重启系统试图恢复。 所以如果船上反映"机器老是自己重启"，第一件事就是抓 errorlog 看有没有 FATAL 行——它记下了每一次重启的原因。日志本身还带一个重启原因统计：

⭐ 这份统计对判断"是不是供电问题"特别有用。 如果 Sudden powerloss 那一栏数字明显偏大，说明这条船的直流供电不稳（或者有人老拔电源），问题不在卫星设备上，而在船的电气上。这类结论光看"上不了网"是推不出来的。

手册给了一张排查流程图，逻辑浓缩下来是这几步：

1. 拿到尽量详细的故障描述 —— 什么时候开始的、什么现象、之前动了什么
2. 复现问题 —— 不能复现的故障没法确认修好
3. 看指示灯 —— 红灯查日志，绿灯闪说明正在进行中（扫天、注册、入网）
4. 看事件表 / 事件日志 / 话机告警 —— 三处交叉印证
5. 看维护页与诊断报告 —— 需要细节时再往下挖
6. 修完必须做一次系统测试 —— 确认故障解除了

第 6 步经常被跳过。 手册特意强调：修完要做系统测试验证问题真的解决了，不能凭"灯变绿了"就收工。船一出海就没法补，这条比在岸上更值钱。

终端通过 AT 命令接口（配合上位机或第三方的通信管理软件）操作时，会返回 +CME ERROR 码。这一部分调试开发时用得上：

注意 103 至 113 这一组都用括号标注了对应的 3GPP 标准码（3GPP 是制定全球移动通信标准的国际组织，它的错误码编号全球通用，如 #3 / #6 / #7 / #11 / #12 / #13）。它们都出现在"附着失败"这一类里——也就是终端想接入网络但被拒。这几条一起看信息量最大：如果是 111（不允许该 PLMN。PLMN 指网络标识，可理解为"哪一家网络"），说明选错了卫星 / 网络区域；如果是 113（不允许漫游），说明这条船的 SIM 卡在当前位置不在服务范围内。

终端灯亮红灯，第一件事该做什么？

查事件日志，不是断电重启。红灯代表严重错误，errorlog 里会留下原因和时间点。日志只保留当前开机周期的记录，一断电就清空了——先抓日志，再谈重启。

船上报"老是掉线"，该从哪查？

先看 Cause 号。如果是 0x40003（PS attach rejected），这是终端内部代码，说明可能是信号太弱、GPS 定位过期、或者已与网络失联，先查天线遮挡和 GPS，别急着怪运营商。同时看 error log 有没有 FATAL 行——有 FATAL 就说明掉线时系统在自动重启。

GPS 模块坏了，日志里会怎么显示？

自检里出现 POST Failed: [0602:16] - GPS alive failed。⚠️ 注意别被日志条数误导——GPS 模块一坏会连累后面的自检项，FAILED 条数越攒越多，必须回头看最早的那一条才能定位到 GPS。

机器会不会自己重启？日志里怎么看出来？

会。发现天线不应答时，系统判定为严重错误（FATAL）并自动重启试图恢复。日志里的重启原因统计会分别列出「人工要求 / 突然断电 / 看门狗 / 严重错误」的次数——「突然断电」这一栏偏大，说明问题在船的供电，不在卫星设备上。

天线灯一直是绿的，终端灯一直闪，是天线坏了吗？

不是。这个组合说明天线已跟踪上卫星、没问题，卡在向网络注册这一步。去查 Terminal 这一侧的入网状态、SIM 卡、以及所选卫星区域是否正确。

能远程把日志取回来吗？

终端自己的网页界面（http://192.168.0.1）和调试命令行都是本机局域网入口，需要有人在同一网内才能访问。想远程抓，得靠船上有人配合导诊断报告，或者走船上的其他管理通道。所以故障发生后有人当场把报告导出来，价值极大——报告很大（约 250 页文本），但历史很短，过了时间窗就没了。

为什么事件日志里的条目顺序越往后越不重要？

因为故障会连锁。一个模块坏了会带出一连串下级的失败，日志是按时间往下记的，越靠后越是"后果"。找原因永远找时间最早的那一条。 手册在讲 GPS 模块故障时专门强调过这一点。

FleetBroadband 故障代码、SAILOR 500 错误日志、SAILOR 250、SAILOR 150、EXPLORER 727、FBB 指示灯含义、Terminal 灯红灯、Antenna 灯绿闪、event list 事件表、event log 事件日志、POST 开机自检、0550 Antenna Present、0602 ACM ATB POST、GPS alive failed、Cause 号、0x40003 PS attach rejected、0x2e PDP without TFT、0x1d 认证失败、0x26 Network failure、BGAN alarm、Antenna Cross-elevation motor、errorlog 命令、call_log 命令、Thrane and Thrane shell、192.168.0.1、CME ERROR、蔡工SATIOT

• 海事卫星 FleetBroadband 船舶宽带：三档终端对比与选型 —— 先弄清 150 / 250 / 500 的分档，再谈排障
• 海事卫星 SAILOR 500 FleetBroadband 船载终端 —— 三档里的顶配，ISDN 与天线线缆两项要求详见此页
• 海事卫星 SAILOR 250 FleetBroadband 船载终端 —— 中间档，6 条语音线
• 海事卫星 SAILOR 150 FleetBroadband 船载终端 —— 入门档，面板无指示灯，状态全靠网页界面
• 海事卫星 Inmarsat 栏目 —— 本栏目全部资料