机场会在航线任务进度上报中，上报本次执行的航线的结果（thing/product/{gateway_sn}/events主题），机场会在最后一条消息中上报执行错误的结果。可以在前端查看到本次航线文件执行的结果，也可以在后端日志中搜索flighttask_progress，查看最后一条上报消息。
结果上报的消息中会有错误码，需要根据错误码进行排查，如下图有报错信息：
开发者可以根据错误码在上云API文档中查找，如下图所示。大部分错误码可以根据错误提示内容进行解决，如报错电池电量不足等。
下面列举两个私有化比较常见报错319008、314004，以及对应的解决方案。
执行航线报错319008
319008报错是因为机场时间与云端时间不同步导致的，解决方案需要将机场和云端时间进行同步。机场时间同步的逻辑如下：如果机场部署在内网环境，需要云端下发机场能够访问到的ntp服务器地址，使机场能够通过该地址进行时间同步；如果机场部署在外网环境，那么机场会与外网的ntp服务器进行时间同步，则不需要下发ntp地址，即使下发给了机场，机场也会与内部保存的ntp服务进行同步，也不会与下发的地址进行时间同步。
解决方案：在机场开机时会请求云端获取配置信息，云端需要在请求回复的消息中回复机场能够访问的ntp服务器地址，用于机场ntp时间同步使用。
1、检查机场上线时，请求配置更新指令，云端是否正常返回该消息。如果使用的是示例代码，则需要在后端application.yml文件中配置ntp信息，配置后如下：
在后端配置了ntp服务器地址后，示例代码会在机场上线请求配置更新时，回复机场请求配置更新的消息，订阅thing/product/+/events和thing/product/+/events_reply可以进行查看，机场请求和云端回复的消息示例如下：
如果在机场上线时，云端没有正确下发ntp服务地址，则需要开发者自己排查代码，保证云端能够下发正确回复ntp服务地址。
2、机场内部限制了ntp服务的端口只能是123端口，云端部署ntp服务时，不能修改默认端口。ntp服务默认的启动端口就是123端口。
3、通过ntpdate -u命令，检查ntp服务能否正常对时，以及机场网络能否正常访问ntp服务。注意：测试时需要保证笔记本与机场是同一网络环境，可以将机场网线/4G Dongle插入笔记本。
ntpdate命令对时执行成功的结果如下图所示，能够执行成功，则执行下一步，检查机场上报消息的时间戳timestamp，与云端的时间是否同步。
ntpdate命令对时失败执行结果如下图所示，执行失败，则证明ntp服务无法成功对时，需要开发者自己进行排查，检查ntp服务是否正常启动，防火墙是否正确开启。
4、正确下发ntp服务器地址后，可以在机场上报消息的时间戳timestamp字段查看，机场时间和云端时间是否同步。机场时间同步后下发指令后的截图如下所示，从截图中查看查看到两个timestamp相差10ms，10ms是消息传输过程中的时间，从timestamp的结果可以查看到机场与云端时间进行了同步。
如果以上排查方案都进行了排查，机场还是报错319008无法执行航线任务，则需要拉后端日志以及ntp对时成功截图，提单给技术支持获取帮助。
执行航线报错314004
314004报错是因为机场通过flighttask_resource_get获取到航线文件的下载url后，根据url下载航线文件失败报错导致的。该报错绝大部分是因为网络环境导致的。排查方案是获取到云端下发给机场的消息，从消息中获取到下载的url，然后通过url尝试能否下载航线文件。具体步骤如下：
1、使用mqttx工具，订阅thing/product/+/requests、thing/product/+/requests_reply两个主题，机场会通过requests主题请求云端获取航线文件下载的url，云端会在requests_reply主题中回复机场请求的航线文件的url地址。
如请求和回复的示例消息如下所示：
将云端下发给机场的消息中的url复制，将机场有线/4G Dongle插入笔记本，笔记本中打开浏览器，将复制的url粘贴到浏览器中，并按下回车键，需要触发浏览器自动下载该航线文件。
执行成功的结果如下，笔记本成功下载到了kmz文件。
如果根据复制的url下载航线文件失败，需要开发者自己排查问题（如检查机场网络等），下发能够正确下载航线文件的kmz文件。
评论
2 条评论
时间不同步的问题一定会出现么?为什么接入同一个上云服务的机库，几台机库时间是同步的，有个别的时间会不同步？
机场部署在外网环境下，不需要指定NTP服务吗？那默认的NTP服务地址是多少？
请登录写评论。