狩猎飓风
1998 年 3 月，我们开始了为 NASA 戈达德太空飞行中心扫描雷达高度计 (SRA) 开发新的基于 Linux 的数据系统。目标是显著减少系统重量和体积，以便将其安装在 NOAA 飓风猎人 WP3D 飞机（见图 1）之一上，用于 1998 年飓风季。SRA 测量飓风定向波谱和风暴潮。这些数据最终将用于帮助改进和完善飓风模型，并提高预报和理解水平。
1998 年的飓风季非常活跃，SRA 成功地飞入飓风 Bonnie、Earl 和 Georges，收集了近 50 小时的实际任务数据。
我们面临的主要障碍是在我们需要在飓风猎人号上投入运行之前的短暂时间框架。SRA 的尺寸、重量、复杂性和功耗也是关键的设计项目，因为地板载荷考虑因素以及 P3 飞机在湍流天气条件（飓风眼壁穿透）下执行长时（10 小时）任务时的有限有效载荷能力。中断响应时间、防崩溃性和免于“死锁”都是为 SRA 选择操作系统时的重要考虑因素。
新的 SRA 数据系统构建在 Red Hat 4.2 系统和 Linux 内核 2.0.29 之上，占用八英寸的垂直机架空间，重约 40 磅，完全由内部 12 伏飞机电池供电，总输入功率约为 120 瓦。它包括一个定制的 ISA 板，带有几个 PIC 微芯片，用于执行雷达的专用功能。它还包括整个雷达 IF（中频）条、探测器和一个 2ns/点波形数字化仪。没有监视器或键盘直接连接到 SRA；相反，Linux 笔记本电脑用于所有控制和显示。这些笔记本电脑运行 Red Hat 5.1 和 2.0 Linux。
RT-Linux（实时 Linux）软件执行以下操作
驱动波形数字化仪。
计算发射脉冲和返回脉冲之间基于质心的距离测量值。
管理 96 个自动增益控制环路。
校正飞机姿态和偏离天底角的角度。
将格式化的数据存放在共享内存块中，正常的 Linux 程序从中提取数据并记录到磁盘文件中。
SRA 广泛使用 Tcl/Tk 和 Blt 图形库进行实时显示。
SRA 数据的后处理使用 Yorick 完成，Yorick 是一种免费且功能非常强大的编程语言，可在 Linux、各种其他 UNIX 平台和 MS Windows 上运行。
SRA 的先前实现是在 1988 年开发的，使用了 Multi-bus-I 背板上的 68020 阵列、装满核物理仪器的 CAMAC 机箱以及 UNIX 和 VRTX（VRTX 是实时内核）的组合。VRTX 在实时处理器上运行，UNIX 在系统主机上运行。CAMAC 机箱非常重，功耗大，占用大量机架空间且价格昂贵。它使用硬件时间间隔单元 (TIU) 来测量雷达脉冲从飞机传播到海洋再返回的时间。它使用“阈值检测”，这会导致 TIU 停止，并使基于 CAMAC 的波形数字化仪采集返回波形。波形数据需要其自己的 68020 处理器来“处理”每个波形并提取某些数据。这些数据用于（飞行后）优化 TIU 进行的距离测量。阈值 TIU 会受到称为“距离游走”效应的影响，这会导致测量的距离随返回脉冲强度的函数而变化。处理器阵列通过驻留在多总线上的 4MB 内存卡相互通信。系统的控制是通过基于字符的终端进行的，实时显示是在由其自己的 68020 处理器管理的 SBX Matrox 图形模块上完成的。其中一个 68020 处理器运行 UNIX；该处理器运行从 4MB 卡中提取雷达数据并将其存储在 9 轨磁带或磁盘文件上的程序。UNIX 处理器托管所有软件开发并管理操作员控制终端。
由于其体积、重量和功耗，我们无法将此版本的 SRA 安装在飓风猎人号上。硬件信号跟踪电路的限制经常会在旁瓣上错误地触发系统，从而有效地消除了真正的距离测量。
SRA 是一种机载、36GHz、向下看、栅格扫描脉冲雷达。传感器的简单示意性框图如图 2 所示。其一度波束（双向）在飞机飞行轨迹上扫描，并对扫描中以 0.7 度间隔发射的 64 个脉冲中的每一个进行精确的飞行时间测量。随着飞机的行进，表面（通常是海浪）的地形图像被开发、记录和显示。SRA 的标称测距精度为 10 厘米。三个差分载波相位 GPS 接收器用于测量安装在飞机顶部的阵列中的三个 GPS 天线的精确位置。地面参考 GPS 设置在航班始发地，地面和飞机 GPS 数据在飞行后进行处理，以生成飞机轨迹，在我们的应用中，通常精确到约 30 厘米。在压力较小的飞行条件下运行时，可以实现更高的精度。
SRA 雷达由一个 20 英寸的 Rexalite 透镜、透镜轴上的一个馈源喇叭（它向上看入一个机械扫描反射镜，该反射镜将馈源喇叭镜像到透镜的焦点）、一个脉冲调制器和 RF 激励器、接收器、1.7KW 扩展互作用放大器 (EIK) 和 RT-Linux 数据系统组成。数据系统是我们将在此处讨论的主题。图 3 是安装在 NOAA 飓风猎人号上的 SRA 扫描仪的照片。照片中已移除整流罩。
图 4 是 SRA 电源系统的框图。SRA 需要不间断电源来为 Linux 和三个差分 GPS 接收器和计算机供电。我们没有选择现成的 UPS，而是选择了 12 伏 25 AH “RG”（复合气体）密封飞机电池作为系统的主要电源。选择它的原因有两个
我们需要不间断电源，因为飞机在发动机启动和关闭期间经常会发生电源中断。
我们需要在每次任务前后一小时内为我们的 12 伏 GPS 接收器供电，而无需施加飞机电源。
我们购买了一个 12 伏输入 150W PC 电源，为数据系统供电。电池可以为数据系统和三个 GPS 接收器供电约两小时，或仅为 GPS 接收器供电五小时。我们将电池放置在定制数据系统外壳的后部。
图 4 描述了我们电源系统的布线。
图 5 是描述 SRA 数据系统内部结构的框图。计算机是一块单板 200 MHz Pentium，它插入带有 ISA 和 PCI 插槽的无源背板。CPU 卡包含 PCI-VGA 视频、PCI-IDE 控制器、PCI 快速宽 SCSI 控制器、64MB RAM、512MB 缓存、两个串行端口、一个并行端口和 CPU。PCI 3c595 网卡提供网络连接，而加载了 PIC 微控制器的专用 ISA 卡提供与雷达系统的接口。6.4GB EIDE 磁盘驱动器用作 /dev/hda，用于保存 Linux 和数据存储。备用 SparQ 1.0GB 可移动驱动器安装为 /dev/hdb。系统没有软盘或 CD-ROM 驱动器。如果需要 CD 或软盘，只需使用 NFS 从具有这两者的 Linux 笔记本电脑远程挂载即可。正常操作不需要键盘或监视器，但如果需要可以插入它们。
最初，我们使用了 4.2GB SCSI 驱动器，但这会消耗过多的电力。早期开发是使用 250W 117vac PC 电源完成的。当我们切换到 12 伏输入 150W 电源时，我们发现我们的功率预算超出了大约 25 瓦。在启动过程中，SCSI 驱动器和波形数字化仪组合消耗的功率会导致电源“尖峰” 5 伏电源并导致重启。我们花了几个小时才找到这个问题。它通常会在 Linux 开始加载时发生，原因是数字化仪已通电并且正在访问驱动器。在 DOS 启动期间，在 DOS 启动并且数字化仪配置程序加载并运行之后，数字化仪才通电。因此，加载 Linux 是压垮骆驼的最后一根稻草。我们最终确定使用 6.4GB EIDE 磁盘驱动器用于 Linux 和数据存储。EIDE 驱动器的功耗远低于 SCSI，并且数据系统的性能没有明显的差异。
图 6 是 SRA 数据系统在开发期间的照片。它一直处于这种“状态”，直到我们首次在 NASA C-130 上进行试飞的前几天。图 8 是数据系统包装后的照片。图 7 显示了从顶部后方看到的数据系统的内部组织结构。外壳与大多数机架安装相反。我们希望能够方便地访问计算机卡连接，而无需卸下后机架盖。后部唯一的连接是用于 GPS 接收器和电池充电器。图 8 中数据系统下方的黑色电源是我们的主要电源/电池充电器。
SRA 中的核心数据采集设备是 GageScope 8500-PCI 波形数字化仪。它提供最多 128KB 的顺序采样，每 2ns（纳秒）采样一次。这使我们能够数字化 256 微秒的波形。我们实际数字化 60 微秒，从雷达脉冲发射前几百纳秒开始，到经过足够的时间以容纳来自我们最高可能高度的信号返回为止。脉冲需要 2 微秒才能传播 1000 英尺并返回，因此为了容纳 30,000 英尺的最大高度，我们需要至少数字化 60 微秒。由于每 2ns 数字化一个点，因此每个波形中将有 30,000 个点。我们不会从数字化仪中读取所有 30,000 个点。我们“跟踪”返回的位置，并且仅读取以我们期望返回到达位置为中心的 256 个点。由于海洋基本上是平坦的，因此这项技术效果很好。
Gage 为 8500 提供的驱动程序代码支持 DOS、Windows 和 Windows NT。至少可以说，它是广泛的。它包含数千行代码，仅用于将 Gage 制造的大多数卡初始化为可操作状态。显然，该卡的许多功能是从 DOS 驱动程序加载到可编程逻辑阵列中的。Gage 驱动程序代码几乎支持在几种不同 OS 平台上制造的每种波形数字化仪。它们广泛使用条件编译来选择所需的数字化仪板和所需的操作系统。他们尝试建立一个隔离的驱动程序代码层，以便一组通用的驱动程序调用出现在他们提供的库的用户面前。
在查看驱动程序启动代码后，我们认为将启动代码移植到 Linux 可能需要比我们能够承受的时间更多的时间。为了避免移植冗长而复杂的启动代码，我们选择使系统双启动 Linux 和 DOS。这种情况效果很好，使我们能够快速启动 DOS 程序，该程序将配置数字化仪。在数字化仪配置之后，autoexec.bat DOS 脚本使用 loadlin 加载 Linux，loadlin 是一个可以从 DOS 加载 Linux 内核的 DOS 程序。DOS 数字化仪启动代码使数字化仪处于已知的可操作状态。使用数字化仪所需的代码实际上不是很广泛，只需要访问 Gage 卡上的一些寄存器和内存位置。Gage 的工作人员在使其工作方面提供了很大的帮助。
波形数据是在雷达脉冲事件发生后从数字化仪中提取的。16C65A 微控制器之一控制触发发射器、启动各种门、触发波形数字化仪以及最终中断 Linux 波形数字化仪中断处理程序的所有方面。
RT-Linux 中断通常在 2 微秒内响应（在我们的 200MHz Pentium 上），偶尔抖动到几微秒。当我们在几年前使用 MS Windows 进行相同的测试时，我们发现最快的响应约为 50 微秒 (486-dx2 66MHz)，抖动高达数十毫秒。Linux 对中断的响应速度令人难以置信。图 9 是数字示波器捕获的图像，其中顶部迹线的上升沿是 ISA 背板上的实际硬件中断信号。底部迹线是由中断代码生成的硬件信号。它只是写入“1”，等待一段时间，然后向打印机端口写入“0”。每个水平分度为 2 微秒。这证明了我们的 RT-Linux 系统的典型延迟。在进行此测试的同时，我们在另一个 xterm 中运行了一个 find 命令，以便系统有一些事情要做。
微控制器允许非常硬性和可靠的实时功能。它们非常适合在许多应用（例如 SRA）中替代芯片阵列和数字逻辑。我们为 SRA 设计了一个特殊的 ISA 接口板，该板涵盖了雷达的大多数特殊要求和特殊接口。
该板目前装有四个 Microchip 16C65A 微控制器。一个微控制器实现了一个实时时钟，该时钟自动维护与我们的 GPS 接收器的时间同步。它的最小有效小数时间位为 200 纳秒，并为 SRA 提供最多 64 位的精确时间信息。该芯片自动捕获每个雷达脉冲的触发时间。Linux 可以读取和写入它及其邻居。
一对微芯片协同工作，将扫描编码器脉冲序列转换为雷达触发事件。当我们的扫描反射镜旋转时，扫描编码器会测量扫描角度。在我们的扫描速率下，它会产生一对 40KHz 方波信号，这些信号的相位差为 90 度。一个微芯片被编程为将这两个信号组合在一起并产生一个 80KHz 信号，然后对其进行计数以确定扫描仪的位置。第二个微芯片被编程为计数 80KHz 信号并在预定义的角度启动雷达脉冲。凭借其 200ns 的指令时间，该微芯片直接控制发射器和接收器电子设备的所有方面，并在波形数字化仪采集波形后向 Linux 生成中断。对于每个 SRA 脉冲，此微芯片
保护接收器前端免受损坏。
验证接收器是否受到保护。
开启数字化仪的门控。
开启 EIK 放大器的门控。
精确延迟 200ns。
触发发射器调制器以生成 8ns 脉冲，并使实时时钟微芯片捕获当前时间。
延迟 200ns，以使发射脉冲完全清除。
启用接收器以接收返回信号。
中断 RT-Linux SRA 模块以从数字化仪中提取波形数据。
RT-Linux 是一个补丁，它为 Linux 提供了实时程序员和嵌入式系统设计人员所需的许多最重要功能。它作为一组模块实现，可以使用 insmod 及其同类工具安装和删除。您还可以使用 insmod 安装您编写的任何实时代码。RT-Linux 程序在内核空间中执行，并且可以完全访问系统硬件和内核代码。
过去，我们使用 Turbo-C 和 DOS 进行了大量的开发，SRA 开发期间我们不得不重新启动 Linux 的频率之低真是令人惊讶。在 DOS 下，我们通常每天必须重新启动几次。使用 Linux，我们在整个开发期间只需要重新启动三到四次。
一旦 RT-Linux 程序/模块捕获到数据，就必须将其写入存储并显示给系统操作员。我们通过使用共享内存来实现这一点。SRA 具有 64MB 的 RAM，我们将内核配置为使用 mem=61m 启动，这会导致内核仅管理较低的 61MB，而保持 3MB 不受影响。我们使用这 3MB 作为实时数据捕获以及 RT-Linux 模块和普通用户空间程序之间的公共通信缓冲区区域。图 10 描述了 SRA 内存使用情况。
我们编写了一个单独的 C 程序 (rgc.c)，该程序提供了 Linux 用户模式和 RT-Linux 之间的大部分接口。该程序是一个简单的命令行样式程序，具有大量命令来读取和写入 RT-Linux 和用户空间之间公共的数据空间。我们的大多数 Tcl/Tk 脚本只是打开一个到该程序的管道，并使用它来传递命令并从系统中提取数据。该程序也可以直接从命令行使用。这使得开发和调试更简单。
rgc 的运行行选项之一导致它循环，测试是否有数据要写入磁盘。如果没有数据准备好，程序将休眠一秒钟。如果数据准备就绪，则会提取数据并将其写入指定的磁盘文件。
我们在 SRA 上一次最多使用五台笔记本电脑：三台用于收集 GPS 数据（每台 GPS 接收器一台笔记本电脑），两台用于控制和显示实时 SRA 数据。个人笔记本电脑用于控制，如果我们都在飞行中，我们可以使用另一台个人笔记本电脑运行多个相同的显示程序实例。我们每个人都有自己喜欢的用于海洋图像的彩色条。我们经常使用一台机器来控制 SRA，而另一台机器在飞行时编写或修改显示或系统软件。笔记本电脑是 Chembook 9780。每台笔记本电脑都有一个 4GB 内部硬盘驱动器和一个模块化 6.4GB 驱动器（代替软盘），一个 14.2 英寸 XGA LCD 显示屏、PCMCIA 以太网卡和一个 233MHz Pentium-Pro CPU。
这些机器中的每一台都双启动 Red Hat Linux 5.1 或 MS Windows 95。为了将笔记本电脑用作 X 终端，我们启动 Linux，然后运行 Xfree86 服务器。我们运行 X 服务器，使笔记本电脑成为 SRA 数据系统的 X 终端。这会将大部分繁重的显示处理放在笔记本电脑处理器上，因为 X 服务器似乎是 CPU 周期消耗的地方。有两种方法可以使 X 充当 X 终端。第一种是
X -query
第二种是
X -indirect目标机器必须运行 XDM（X 显示管理器）才能使其工作。第一种方法将直接链接到目标机器，您将在其中看到典型的 XDM 登录提示。第一种方法是我们控制 SRA 数据系统时使用的方法。第二种方法将为您提供网络上已知支持 XDM 或 X 终端的所有机器的列表。这在实验室中很有用，在实验室中可以从许多潜在的主机中进行选择。
您甚至可以同时运行两个或多个 X 服务器。这是一个例子
X -query first-machine X :1 -query second-machine X :2 -query third-machine X :3 -query fourth-machine
您可以使用以下命令启动本地 X 服务器
startx -- :4为风暴潮测量配置的 SRA 系统由三台 Chembook Pentium 笔记本电脑组成，它们双启动 Linux 和 DOS。GPS 数据采集程序是为 DOS 编写的，因此每台笔记本电脑在收集 GPS 数据时都运行此 DOS 程序。任务完成后，我们将机器重新启动到 Linux 并将数据传输到 SRA 数据系统，在其中与其他任务数据一起存档。一旦所有数据都放在一起，我们就将其传输到两台笔记本电脑。通过这种方式，我们对数据进行了三重备份。然后，我们将笔记本电脑带回酒店并开始分析数据。所有五台笔记本电脑和 SRA 数据系统都在 10baseT 以太网网络上。
一些飞机数据通过 RS-232 读取。为此，我们正在使用标准的 /dev/ttySxx 端口和驱动程序。飞机数据是每秒发生一次的 9600 波特流，GPS 每秒产生两次位置消息。我们使用我们的 GPS 消息来驱动纬度与经度的简单 Blt 图，以便我们可以跟踪飞行的进度。
RS-232 数据实际上是由 rgc 程序捕获的，因为 RT-Linux 模块无法使用本机 Linux 驱动程序，并且我们不需要重写运行良好的驱动程序。一旦读取了数据，它们就会被复制到 61MB 以上的共享内存区域，任何程序都可以访问该区域。通常，它由 rgc 的另一个调用访问和读取。
精确的飞机姿态、航向和航迹角数据对于 SRA 的实时运行至关重要。飞机的俯仰角和横滚角姿态取自机载惯性导航装置 (INU)，使用同步数字转换器，每个参数一个。这些由 RT-Linux 模块在每个扫描线期间读取。航向和航迹信息目前通过 RS-232 从机载飞机数据系统提供，该系统具有与 INU 数字数据流的直接接口。
SRA 雷达数据由 rgc 程序写入磁盘文件。飞机数据由单独的程序捕获并写入单独的磁盘文件。此数据通常在整个飞行期间捕获，从而在单个文件中提供完整的飞行记录。载波相位 GPS 数据从飞行前 45 分钟到飞行后 45 分钟连续捕获。飞行前和飞行后数据对于将飞机位置解析到厘米级是必要的。
在进行任何 Linux 开发之前，我们认为有必要编写一些 DOS 代码来与 Gage 数字化仪板一起工作。需要 Turbo-C 5.0 版来编译和使用 Gage 提供的库。一旦我们成功地使 Gage 示例程序在 DOS 上工作，我们就与 Gage 工程师合作，使用正常的用户模式程序直接与数字化仪通信。主要的技巧是使 DOS 程序配置数字化仪，然后在不关闭电源的情况下退出。第二个技巧是从 DOS 启动到 Linux；事实证明，使用 loadlin 非常容易。
我们通过读取 /proc/pci 来确定数字化仪的 PCI 板设置，然后使用这些值硬编码各种测试程序。我们编写了各种普通用户模式程序来熟悉数字化仪。除了处理中断外，我们能够以各种方式操作数字化仪卡。gdb 调试器在整个开发过程中提供了很大的帮助。
SRA 软件的很大一部分实际上是驻留在各种微芯片上的固件。
Microchip 免费提供了一个非常完整且易于使用的开发包，用于他们的 16C65A（和其他）微控制器。它配备了一个全面的模拟器，可以观看相当广泛的程序的模拟执行。唯一的缺点是系统只能在 MS Windows 上运行。
RT-Linux 扩展为 SRA 等实时数据系统提供了恰到好处的功能。这些扩展提供的功能比我们在 SRA 中实际使用的功能要多得多。我们使用它在每个栅格扫描结束时启动一个 RT 任务。该任务处理在上一次扫描期间捕获的所有数据，并进行一些必要的计算以配置系统以进行下一次栅格扫描。
我们编写了 rgc.c，使其成为 Linux 下的普通用户进程和 RT-Linux SRA 模块之间的联络员。很简单，rgc 设置了一个指向 SRA RT 模块用于数据存储的共享内存空间的指针。它们相互理解，因为它们共享一个通用的 .h 文件，该文件定义了共享内存空间中的数据组织结构。图 11 描述了各种 SRA 实时程序如何相互通信。rgc 通常从 stdin 读取命令并写入 stdout。如果使用某些开关调用它，它会派生并轮询 RS-232 数据和/或将从共享内存捕获的数据写入磁盘，同时从 stdin 获取其命令。命令集是简单的 ASCII 字符串，例如 set thresh 24 或 get roll。Tcl/Tk 程序各自打开一个到其自己的私有 rgc 的管道，然后发送命令并接收返回的数据。除了地形图像显示之外，所有操作都是以这种方式完成的。该程序 creep.c（因为它在屏幕上向上爬行）直接访问共享内存。将所有内容集中到 rgc 中的主要原因是，通常这意味着当在共享内存区域中添加或删除某些内容时，我们只需要重新编译 rgc、creep 和 SRA 模块。简而言之，它可以加快开发速度。
图 12 是飓风 Bonnie 登陆期间 SRA 控制笔记本电脑的屏幕截图。屏幕左侧的图像是实时地形显示。它是灰度编码的，因此越高的地方，看起来越白；越低的地方，越暗。此图像清楚地显示了图像左侧的海浪、中心的沙滩和非常明显的沙丘线。我们还有一个颜色编码版本的程序，但其解释不如直观。蓝色/棕色显示代表飞机的姿态。这是一个简短的 Tcl/Tk 脚本，用于读取 SRA RT-Linux 模块捕获的飞机姿态数据。
明亮的绿色显示屏显示了我们如何控制和指定 SRA 的运行条件。此时，我们使用滑块手动查找返回信号。找到后，我们单击“自动”按钮，无论飞机高度如何变化，系统都会将地面保持在数字化仪窗口的中心。飞行地图是另一个简短的 Tcl/Tk 程序。它从共享内存区域提取 GPS 位置数据，并使用它来绘制我们的位置。
Tcl 7.6 和 Tk 4.2 以及 Blt 2.3 在 SRA 中得到了广泛使用。最初，我们认为它可能仅对原型设计有用，但很快就显而易见，X 服务器将成为显示瓶颈，而不是 Tcl/Tk。
在开发期间以及在我们购买笔记本电脑进行控制之前，我们使用了直接连接到 SRA 系统的监视器。这意味着 X 服务器也将在那里运行。当我们开始尝试使用远程 X 服务器时，我们很快发现 X 服务器的负担也转移到了远程系统。这是一种无需任何努力即可自动将负载分布到系统中一台或多台计算机上的方法。
我们使用 Xview 库用 C 语言编写了图像显示。我们使用此库是因为我们已经有一本关于它的书，并且它看起来不太难使用。它将每条扫描线直接写入显示器，同时写入“像素图”。当发生“重绘”事件时，像素图用于重绘整个图像。在显示计算机 X 服务器上施加负载的一种好方法是抓取图像图并在屏幕上移动它。显示计算机上的负载将急剧增加，但数据系统将保持不受影响。
一旦我们获得了一些 SRA 数据，我们显然需要构建一些软件来查看它。我们希望在多台机器上拥有 SRA 处理软件，并且没有许可麻烦。这样，我们将能够在家里、办公室笔记本电脑（也用于控制 SRA）、SRA 数据系统计算机以及办公室 Linux 和 Windows PC 上开发程序。总共，我们需要在至少五到十个不同的系统上进行处理。我们考虑了 IDL、Matlab 和 Yorick。我们选择的处理工具是 Yorick。它是免费的、功能非常强大，并且可以在各种平台上运行，包括几乎所有已知的 UNIX 机器、Linux 和 Windows。它能够保存数据，以便可以在大端或小端机器上读取数据。
图 13. 来自 Yorick 的初始数据产品，显示叠加在 NOAA 风场图上的表面地形 图像
我们第一次听说 Yorick 是从 Linux Journal 上的一篇文章（“Yorick 编程语言”，Cary O'Brien，1998 年 7 月）中了解到的。我们下载了它并尝试了一下。我们喜欢它的类 C 语法以及加载（和重新加载）程序各个功能的能力。这使其成为一个非常强大且灵活的开发环境。它最好的功能之一是它的成本 — 免费！将 Matlab 或 IDL 放在所有机器上将非常昂贵。由于我们在 SRA 数据系统和控制笔记本电脑上都有 Yorick，因此我们可以使用 Linux 笔记本电脑在现场轻松分析数据，只需付出最小的努力。图 13 显示了来自 SRA 的地形图像，这些图像叠加在 8 月 24 日飞行的风场图上。北部航线上的海况高于 18 米（60 英尺）。
在我们将所有东西打包并运送到佛罗里达州坦帕市的麦克迪尔空军基地，以便安装在 NOAA 飓风猎人号上之前，我们在 NASA C-130 飞机上进行了两到三次短暂的试飞。我们在这些试飞中消除了一些错误，但并非全部。当我们运送系统时，它仍然无法正确跟踪。
一旦我们将所有东西都安装在飓风猎人号上，我们就进行了一次 6 小时的试飞。这使我们能够解决我们之前看到的大部分错误和一些新错误。我们的跟踪代码仍然存在一些问题，无法可靠地跟踪。
我们在飓风邦妮中执行了两次任务：第一次是在 1998 年 8 月 24 日，第二次是在 1998 年 8 月 26 日登陆期间。在第一次从坦帕飞往风暴的途中，我们能够隔离并纠正跟踪器错误，一切开始比预期更好。离开佛罗里达州东海岸后不久，我们的海面地形显示首次启动，显示了真实的海况。8 月 24 日，在飓风的东北象限观测到高达 63 英尺的海浪。图 14 显示了我们在 8 月 26 日登陆期间的飞行轨迹，叠加在飞机气象雷达图像和风场数据的等高线图上。基础图像包括气象雷达、风场和海岸线，由迈阿密的 NOAA 大西洋海洋和气象实验室 (AOML) 飓风研究部门 (HRD) 提供。我们使用 Yorick 制作了这个叠加图。
除了飓风邦妮，我们还飞入了厄尔和乔治斯。
由于 Linux 的可靠性以及该领域中所有现成的实时数据处理程序，我们能够在非常紧张的时间表内组装出一套最先进的数据系统，并具有各种实时显示。事实证明，这些显示器在开发期间的故障排除以及数据采集期间的实时地球物理评估和解释中都具有巨大的价值。因此，我们首次记录了飓风附近波场的空间变化以及与飓风登陆相关的风暴潮的空间和时间变化。
